234G协同优化TD-LTE切换案例分析

234G协同优化TD-LTE切换案例分析第一页，共126页。1、漏配同频邻区导致切换失败2、A2门限太低导致下载速率低问题（含切换）3、C国H地区局点LTE入切换成功率为0%分析4、CIO配置不合理导致切换失败5、LTE重复覆盖导致切换失败和频繁（乒乓）切换6、LTE外部小区配置错误导致同频切换失败7、LTEDT测试中终端发起原因值为otherfailureRRC重建8、P国G项目MR不处理因素导致低吞吐率问题9、W市两个基站之间TAC配置错误导致切换失败10、

ENODEBID设置重复导致无法切换11、LTE一个小区添加俩PCI相同邻区导致的切换问题2第二页，共126页。

1、漏配同频邻区导致切换失败

【现象描述】：切换测试时，在UE移动过程中，发现有比当前服务小区质量好的小区，触发切换A3测量报告，并不停周期上报，但一直收不到网络侧的切换命令。随着UE移动服务小区RSRP越来越差，服务小区SINR越来越差，吞吐率越来越低，而邻区RSRP越来越好。3第三页，共126页。4第四页，共126页。最终在UE下行失步后在邻区发起RRC重建，重建被拒绝后，重新发起RRC接入邻区并建立业务，此时邻区的无线质量较好，业务恢复正常。5第五页，共126页。原因分析【告警信息】无【原因分析】分析切换失败期间的相关信息，发现在UE第一次上报A3测量报告时，RSRP为-106dBm、SINR约5dB：在这样的信号质量条件下，应该完全可以完成切换信令交互而成功切换。说明这里切换失败存在问题，再从网络侧记录的信令跟踪，可以看到eNB的UU口能收到UE上报的测量报告：6第六页，共126页。7第七页，共126页。从这里可以看到eNB收到测量报告后并没有下发切换命令，怀疑是不是X2接口向目标小区切换时失败导致，再查看X2接口，发现X2接口没有消息交互，也即eNB没有向目标小区发起切换请求，说明eNB判决切换测量报告的结果为不切换。再分析eNB不切换的可能原因有：8第八页，共126页。切换惩罚:eNB对于非资源准入切换失败的小区要其经历一定的切换惩罚次数Intra-freqHORetryPenaltyNumber（该值默认为10）后才能再次允许该小区进行切换，切换失败且重建到本小区的UE会受到切换惩罚；目标小区在核心网切换限制列表中；邻区漏配；目标小区禁止切换。对于以上四种原因，需要进一步在处理过程中进行排查和确认。9第九页，共126页。如果是切换惩罚的原因，在IFTS跟踪内可以看到UEMTEXTPRINT显示eNB在收到测量报告后，判断目标小区为RetryPenaltyCell。查看IFTS跟踪文件并没有发现RetryPenaltyCell，而且该小区之前并没有出现非资源准入失败（流程失败），所以排除切换惩罚的原因。经核心网确认并没有将服务小区和目的小区配置进切换限制列表。目标小区禁止切换开关在同频邻区关系中配置和显示的，需要进行同频邻区配置的检查再从LMT上查看ANR开关为关闭，X2口、S1口配置均正常，再查看这两个小区的邻区关系配置，发现两个小区的同频邻区关系没有配置。至此，基本可以确认问题在于邻区漏配。10第十页，共126页。解决过程解决方法1：打开ANR算法开关实现自动邻区增加，命令为：MODENODEBALGOSWITCH:SONAnrAlgoSwitch=IntraRatEventAnrSwitch-1UE在上报A3测量报告后，eNB会下发控制CGI读取的重配置命令。UE测量目标小区，读取CGI后上报给eNB，eNB再发切换命令给UE，从而完成切换流程，成功切换。解决方法2：手工增加邻区配置，用“ADDEUTRANINTRAFREQNCELL”命令给两个小区的邻区关系并打开允许切换开关后也可以使UE正常切换：11第十一页，共126页。12第十二页，共126页。

【建议与总结】

切换的问题先从信令入手，再分析信令流程失败点所有可能的原因，采用逐一排除、逐一确认的方法来找问题原因。13第十三页，共126页。2、A2门限太低导致下载速率低问题(含切换）【现象描述】TDDLTE校园网，西城中州大学（D频段小区）附近有一路段，UE一直占用师专新校2小区（F频段小区），覆盖比较差，速率低，如下：14第十四页，共126页。优化前RSRP15第十五页，共126页。优化前PDCP层下载速率分布图16第十六页，共126页。【原因分析】车辆在西城中州大学校园自北向南行驶中，UE一直占用F频段师专新校2小区（PCI71），RSRP恶化到-111dbm的时候，eNodeB才向UE下发异频测量控制信息，异频测量切换信令流程如下：17第十七页，共126页。异频测量控制下发

18第十八页，共126页。

UE上报异频测量结果：

19第十九页，共126页。

eNodeB下发切换判决结果，目标小区西城中州大学1小区（PCI75）：

20第二十页，共126页。在后台查询师专新校F2小区（PCI71）的A2RSRP触发门限为-109，A2触发门限太低，主服务器小区信号恶化到-111dbm的时候才发起异频测量，导致该路段RSRP很差，下载速率偏低。21第二十一页，共126页。【解决方案】将师专新校F2小区（PCI71）的A2门限提高到-95，A1

RSRP触发门限由-105改为-91，参数修改之后问题路段指标提升明显，测试情况如下：22第二十二页，共126页。

【建议与总结】：

1.A1和A2是门限用于控制异频和异系统测试量的，A1用于停止测量，A2用于启动测量，A1的值要比A2的值高，因此A2参数修改的时候，A1参数也要同步修改。2.异频测量门限不能设置太高也不能设置太低，设置过低导致源小区信号强度很小，吞吐率已经严重下降的情况下，才发起异频邻区的测量，此时目标小区信号强度已经很强的情况，但是没有及时切换，使得吞吐率迅速下降；A2门限设置过高，导致触发UE过早地进行了异频测量，由于异频测量需要专门分配一定时频资源进行，减少了UE可用的时频资源，导致调度次数不足，影响吞吐率。23第二十三页，共126页。

异频测量参数的设置可参考如下经验值：

24第二十四页，共126页。

3、C国H地区局点LTE入切换成功率为0%分析

现象描述C国H地区进行每日KPI指标统计的时候发现小区出现入切换失败次数为100%。KPI指标如下图所示。25第二十五页，共126页。

查看小时级指标从13号凌晨出现问题。查看对应问题时间点的操作日志，发现在13号凌晨没有任何操作。

26第二十六页，共126页。

原因分析

怀疑是否是由于站点无资源导致的入切换全部失败，但是查看用户数统计发现没有用户在这个站点下面做业务。查询一个月的平均用户数，发现周末应该是有用户使用LTE网络的。27第二十七页，共126页。对小区的其他指标进行分析。发现如下情况：问题时段RRC请求次数为0问题时间段随机接入次数不为0.28第二十八页，共126页。RRC建立之前的随机接入过程是有用户请求，也就是说在下（图5）A点。B点有统计说明随机接入网络侧都是有响应的，但是在进入到了RRC接入过程后（图6），网络L3没有收到终端RRC请求，原因是RRC请求次数为0。29第二十九页，共126页。30第三十页，共126页。

而睡眠小区一般表现为eNodeB的L3收不到UE的RRC建立请求消息。也出问题在图7红色标注部分。与此问题站点的现象非常一致。

没有告警，没有操作日志，DSP小区状态也正常，没有用户接入和流量，但是有随机接入过程。

RRCCONNREQRRU基带L2UEL3eNodeBRARPreamble1、下行同步2、系统消息3、随机接入31第三十一页，共126页。

处理过程

确认疑似睡眠小区的情况后。我们在16日凌晨3：00进行了重启基站的操作。观察指标如下。重启，站点业务恢复正常32第三十二页，共126页。

建议及总结

在商用网中，睡眠小区很有可能会存在在网络中。这种小区查询状态时完全正常（DSPCELL），也没有任何异常告警上报，但用户实际上不能接入，非常影响用户感知，并且很多情况下是客户投诉才发现此类问题。所以在现网维护项目中，尤其在LTE建网初期，一个好的例行指标监控流程及工作必不可少，通过监控可以更早的发现网络中出现的问题，变“救火”为“防火”。睡眠小区的监控可以通过随机接入请求，RRC请求，入切换指标及最大用户数等相关指标来判断。另外，现在处理睡眠小区的途径还只是重启基站这一条路。33第三十三页，共126页。

4、CIO配置不合理导致切换失败

【现象描述】K国Z局点的站点1213中小区7切换到站点1252的小区9过程中，未完成切换流程就出现重建，导致切换失败，业务中断几秒后，UE重建接入小区9中，数传恢复。34第三十四页，共126页。

【原因分析】

对于切换失败问题，可以通过以下几个方面进行定位：从覆盖角度考虑，如果在切换点上存在着覆盖问题，在某区域上某个方向上由于建筑物等的遮挡，导致UE在该区域内出现信号质量的大幅抖动，切换失败。从配置角度考虑，如果出现影响切换的相关参数配置不合理可能导致切换失败，如切换门限设置、切换时间迟滞设置、切换CIO设置，这些参数设置不合理都有可能造成错过最佳切换时机导致切换失败。从传输角度考虑，可能因为存在传输问题导致切换失败，如eNB到核心网的传输，两个站间的传输，这些数传问题都可能导致出现切换失败。35第三十五页，共126页。

【处理过程】

首先考虑覆盖的问题，因为切换点K区域是处于目标小区覆盖信号很弱的拐角点，天线到该位置的直线空间里有一座较高的楼房，一直怀疑该楼房的阻挡影响信号覆盖。现场情况如下：36第三十六页，共126页。其中A、B、C为组成三角关系的三个站点，在K区域发生切换失败，在B站点前面有一个三角形的建筑物，挡住目标站点发到K区域的信号。调整了基站B的目标小区的天线角度以后，K区域的信号也没有提高。可见，现场由于环境限制，无法通过调整覆盖来解决切换问题，接着要尝试能否通过调整参数来解决。37第三十七页，共126页。从消息跟踪结果来看，在UE测量到目标小区的RSRP比服务小区的RSRP差值超过切换门限发出测量报告，但是源小区信号质量下降太快没有收到测量报告，从而使UE只能在目标小区发起随机接入过程。根据实际情况，基站安装位置难以更改，天线调整也起不到作用，这时可以考虑通过调整切换相关参数，提前进入切换流程，应该可以解决问题。38第三十八页，共126页。查看切换相关参数，因为切换门限和迟滞时间都涉及到多个小区，且在和其他小区的切换中不存在这种需要提前切换的问题，所以这几个参数不需要修改。使用查看CIO配置，该配置默认值都为0，因此要修改这个参数让切换提前。经过数次测试，将邻区的小区偏置修改成1dB~2dB以后，切换正常。39第三十九页，共126页。使用LSTEUTRANINTRAFREQNCELL,查看CIO如下：40第四十页，共126页。【建议与总结】在现实场景下，往往会出现许多切换过晚现象，可以通过调整切换相关参数配置来提前切换达到解决切换失败的目的。参数修改过程有一个注意的问题是，修改切换门限和切换迟滞时间固然也可以达到提前切换的目的，但是因为这两个参数都属于小区级参数，一旦修改，将会造成和所有邻区的切换点发生改变，因此修改后风险较大，大多数情况下都不应修改，因此一般可以通过修改CIO配置参数达到相同的目的，而其只对特定的小区有影响。41第四十一页，共126页。

5、LTE重复覆盖导致切换失败和频繁（乒乓）切换

【现象描述】Z省H项目Cluster优化过程中，对Cluster21进行优化发现某拐角区域出现切换失败现象，并且该区域切换频繁，存在两小区间的乒乓切换现象。42第四十二页，共126页。

【原因分析】

从某路段的路测数据中可以发现切换失败导致掉线的事件点。43第四十三页，共126页。我们首先要定位原因，可以看出，在切换前的服务小区为PCI=54小区，查看MeasurementReport测量报告，查看切换的目标小区，明确切换方向。44第四十四页，共126页。MR显示，切换的目标小区PCI=56。实际上切换是发生在站内的54小区向56小区的同频切换。进一步分析所在区域收到的导频信号可以发现，在该切换点上，同时收到了四个小区的导频信号，分别是PCI=54，PCI=7，PCI=56，PCI=6，属于四个小区重复覆盖的区域，且导频信号的参考功率RSRP的值都相当，属于同等覆盖，如下图所示事件点收到的导频信号情况：45第四十五页，共126页。46第四十六页，共126页。可以看出，由于切换时由54小区向56小区发生的，且8小区与56小区Mod3的结果同为2，结果相同，因此导致干扰，该区域的SINR（信干燥比）的值下降，造成了最终的切换失败掉线现象。下图为该区域的SINR变化情况：47第四十七页，共126页。通过分析可以看出，切换发生在54,56小区的基站内部，失败主要是由于相邻基站的小区重复覆盖造成的Mod3干扰所致，并且由于地理位置特殊，处于两处转角的区域，无线环境复杂，干扰较大，在一定的路段出还现了乒乓切换的现象，如下图A点到B点的路段，共发生了6次同频切换过程，且在B点处SINR值很低，干扰严重。因此，对于该区域的优化方案需要综合考虑两基站间和地理环境等因素来解决。48第四十八页，共126页。49第四十九页，共126页。

【处理过程】

将上方基站的8小区与6小区PCI的值进行对调，避免Mod3干扰现象。并且为减少频繁切换，将56小区向原8小区（对调后的6小区）切换的CellIndividualOffset（对应同频切换A3事件进入公式Mn+Ofn+Ocn-Hys>Ms+Ofs+Ocs+Off中的Ocn）的值适当减小，增加切换难度。同时，将56小区向原8小区切换的时间迟滞IntraFreqHoA3TimeToTrig由320ms调整为640ms，防止频繁切换。50第五十页，共126页。

【建议与总结】

由于该区域处于多拐角的区域，需要两个或以上小区的覆盖，无法避免重复覆盖现象，因此在优化中以调整同频切换的参数优先，如果效果不理想，可适当降低干扰小区的天线发射功率，如果还是无法达到理想效果，可考虑压更改干扰小区的天馈系统，减小其对问题区域的覆盖，达到降低干扰的目的。对参数进行调整后复测，切换次数明显减少，未出现切换失败现象。建议在类似的问题及事件处理过程中，结合不同区域的地理及无线环境分析进行有针对性的Cluster优化。51第五十一页，共126页。6、LTE外部小区配置错误导致同频切换失败现象描述某LTE项目，在使用移动终端CPEB593s进行测试过程中，某区域总是切换失败，未成功一次，如下图所示：52第五十二页，共126页。

问题分析

回放测试LOG，对问题进行深入分析，发现该区域主要存在华立大厦-1、华立大厦-2、怡和大厦-1三个小区的信号，UE在由北向南行进，应该由华立大厦-2小区切向怡和大厦-1小区，从图切换失败问题呈现中可以看出，但是，仔细分析发现，UE占用华立大厦-2（PCI=104）切向目标小区怡和大厦-1（PCI=85），而切换请求中目标小区PCI却为84，如下图所示：53第五十三页，共126页。54第五十四页，共126页。55第五十五页，共126页。从上面的分析发现，怀疑邻区相关数据配置存在异常。检查以往的参数修改记录，发现怡和大厦-1和怡和大厦-3小区的PCI由于怡和大厦-1和华立大厦-1的PCI同为MOD0，存在MOD3干扰而进行过PCI互换，如下图所示：56第五十六页，共126页。核查与怡和大厦存在邻区关系的站点的外部小区数据，发现怡和大厦相邻站点的外部小区数据中的PCI数据均未进行相应的调整，这三个站点的外部小区中怡和大厦-1和怡和大厦-3的配置如下表所示：57第五十七页，共126页。58第五十八页，共126页。解决方法及验证

根据上面的分析，由于外部小区数据配置错误，导致同频切换失败，将上述错误修改如下：修改该数据的MML命令如下：MODEUTRANEXTERNALCELL:ENODEBID=524505,CELLID=31,PHYCELLID=85;MODEUTRANEXTERNALCELL:ENODEBID=524505,CELLID=33,PHYCELLID=84;59第五十九页，共126页。调整后切换失败事件消失，问题闭环，如下图所示：60第六十页，共126页。61第六十一页，共126页。

总结与建议

这个问题是典型的优化调整缺乏系统性的一个表现，在GSM网络中，系统以主B频点和BSIC来确定邻区，在LTE中，系统以频点和PCI来确定邻区。跟GSM网络类似，在修改小区的主B频点或者BSIC之后，都要查看是否涉及有外部相邻小区需要更新，在LTE中由于没有了BSC级的网元，每个基站都存在所谓的外部邻区，只要是修改了频点或者PCI，通常情况下都是需要更新外部邻区描述的，这需要作为一个规定动作去落实。62第六十二页，共126页。

7、LTEDT测试中终端发起原因值为otherfailureRRC重建

【现象描述】H省C局项目，进行TD-LTE网络DT测试过程中，车辆行至某两个小区边缘区域时，终端发起原因值为otherfailure的RRC重建，之前无RRC异常释放、RRC重建失败、切换失败等事件。63第六十三页，共126页。【原因分析】使用Assistant对测试Log进行分析，信令RRCReestablishAttempt

原因值为otherfailure。64第六十四页，共126页。上图所示为RRC重建事件点，可看出重建发生在两小区边缘地带，不存在掉线等异常事件。但此时主服务小区RSRP值为-69，而邻区RSRP值为-53，电平差值较大。65第六十五页，共126页。66第六十六页，共126页。根据Serving+nighboringCell图中显示，虽然服务小RSRP值还处于正常水平，但此时邻区电平值已高于服务小区16dBm，服务小区RSRQ已降低到-20。信令上显示，终端一直上报MR测量报告，但未执行同频切换，因此判断终端发起RRC重建原因为：测量邻区RSRP高于服务小区，终端上报MR但未执行切换导致服务小区服务质量快速下降，UE检测到“radiolinkfailure”，发起原因值为“otherfailure”的RRC重建。

进行切换参数确认，分析未及时切换原因，发现该事件中，服务小区向邻小区切换的同频邻小区偏置CIO为-10，属于不合理设置，因此判断为参数设置不当，导致切换不及时67第六十七页，共126页。

【处理过程】

考虑到该区域为基站密集区域，之前调整CIO为-10以减少频繁切换现象，但由于参数值修改过大，导致切换不及时，终端发起RRC重建。通过对切换参数的修改，将CIO调整为0，并将服务小区的切换时间迟滞TimeToTrig由320ms调整为640ms，同频切换幅度迟滞Hys修改为3，以减少频繁切换。

参数修改后复测多次，未出现RRC重建事件。68第六十八页，共126页。【建议与总结】在对于同频切换的优化中，CIO的值修改不宜过大，一般在-3到3dB之间，对于存在频繁切换现象的小区，可考虑对小区级切换参数，时间迟滞及幅度迟滞Hys进行适当调整以减少频繁切换现象。69第六十九页，共126页。

8、P国G项目MR不处理因素导致低吞吐率问题

【问题描述】

P国G项目LTE工程为公司A级项目工程在P国支持G项目LTE工程时，接到客户邮件投诉：作为本国本地区较为重要的商业中心，客户较为关心其信号质量问题，客户择期在连接商业L区与G5区的人行天桥上进行了单独测试，吞吐量结果是：DL在7Mbps左右，UL在500kbps左右，更有甚者，在测试的其中一个地点，DL仅是557kbps，UL仅是154kbps。客户发邮件投诉质疑：为什么在本地区没有LTE其他用户的情况下，吞吐率如此差，要求给出问题原因及解决方案。70第七十页，共126页。

【问题分析】

此问题属于TOP小区问题，为室内分布基站特定地区低吞吐率问题，需实地路测得到测试log，分析后得出问题解决方法。在此案例中，计划用三步骤来分析定位问题：71第七十一页，共126页。首先检查此地区信号覆盖情况：RSRP与SINR（DL）72第七十二页，共126页。由上图可以看出，此段天桥上的覆盖非常弱，RSRP在-90dBm以下占到47%，SINR在5dB以下的达到80%。73第七十三页，共126页。由于下行的RSRP和SINR很差导致下行的吞吐率很低，大部分在10Mbps以下，但是上行的吞吐率没有受到影响，原因在于LTE的上行采用的是SC-FDMA技术，每个用户所分配使用的频带是不一样的，因此上行的干扰主要是来自不同用户之间的干扰，测试时在此地区只有一个测试终端（用户），因此上行吞吐率正常；而下行的干扰主要来自邻区的同频干扰。74第七十四页，共126页。二、检查周边小区情况核查参数ServingRSRP-1stNeighboreRSRP，在此基础上，选择此参数值在-3dBm以下的区域，重点考察这区域的ServingPCI和1stPCIinNeighboreCells，可以初步判断此区域应该是由ServingPCI所对应小区向1stPCIinNeighboreCells所对应小区切换，之所以没有顺利切换，是因为邻区漏配导致，再对相应信令进行核查，做进一步确认。通过核查ServingRSRP-1stNeighboreRSRP，可以看出在此天桥上大部分地区主服务小区的信号都比第一邻区的信号要低很多。两者差值在-3dBm以下的达到86%，这说明存在严重的邻区漏配现象。75第七十五页，共126页。76第七十六页，共126页。进一步看这区域的ServingPCI和1stPCIinNeighboreCells77第七十七页，共126页。由上图可以很清晰地看出：ServingRSRP-1stNeighboreRSRP筛选出小于－3dBm的区域，对应的应该会有两个切换顺利进行才对。由主服务小区PCI12对应的小区理应向PCI82对应的小区切换，主服务小区PCI72对应的小区理应向PCI82对应的小区切换。78第七十八页，共126页。三、从信令流程上确认邻区问题从L3Message上可以看到，终端主服务小区是PCI12对应的小区时，终端每隔240ms上报一次A3事件的MeasurementReport，ENODEB对上报的MR不处理，这些MR上报的邻区PCI均包括82，偶尔会有PCI83。平均来看，PCI为82的小区RSRP比PCI12的小区RSRP要高10dBm左右，如下图：79第七十九页，共126页。80第八十页，共126页。ENODEB侧由于没有检测到配置PCI82作为其邻区，因此一直没有给UE下发切换执行的“RRCConnectionReconfiguration”。最后一次MR中包含了PCI为78的邻区，比主服务小区高6dBm，因为在配置中有此小区作为邻区，因此ENODEB侧给UE下发了向PCI78的目标小区切换执行命令，信号从PCI12的小区切换到PCI78的小区。81第八十一页，共126页。82第八十二页，共126页。对主服务小区是PCI78的小区，进行L3Message跟踪，可以同样发现，PCI78的小区一直上报含有邻区PCI82的MR，因为两者没有配备邻区关系，ENODEB侧一直不下发切换指令。83第八十三页，共126页。四、总结问题原因综上因素，可以判定出现天桥地区低吞吐率问题的原因有以下两点：下行信号覆盖很差，RSRP在-90dBm以下占到47%；此区域段出现邻区漏配现象，作为当前主服务小区的PCI12、PCI78都没有配置PCI82作为邻区，因此导致信号不那切换到最强小区，一直停留在较弱小区。84第八十四页，共126页。

【处理过程】

一、在客户M2000上，检查PCI12与PCI78对应的邻区配置，检查同频邻区关系。在对应小区MML执行LSTEUTRANINTRAFREQNCELL，检查是否有PCI82对应的小区作为邻区。经过检查同频邻区，可以看到有这样的邻区关系：PCI12(GREENBELT4F-1)→PCI82(RIZALDRVF-3)PCI78(GBELTRDEV2F-1)→PCI82(RIZALDRVF-3)由此可见，同频邻区是已经成功配置的了，但是只配置了同频邻区的情况下，还不能确定一定会顺利发生切换，还要额外检查一下外部小区情况。ENODEB侧在处理UE上发上来的MR时，过程是提取MR中所携带的小区的PCI，根据此PCI值在外部小区中检查是否存在此PCI所对应的小区，如果唯一存在，再根据小区名检查是否已经将此小区配置成目标小区的邻区。如果上述两步都唯一存在，ENODEB侧就下发切换指示。85第八十五页，共126页。二、运行MML命令LSTEUTRANEXTERNALCELL，看到：1、PCI12(GREENBELT4F-1)配置有两个PCI为82的外部小区，一个是正确的对应小区RIZALDRVF-3，另外一个是配置出现错误的小区，显示名字是NULL，但是PCI是82，其他配置都同RIZALDRVF-3一样，分析原因可能是无线侧在下发配置邻区脚本时出现手工错误，这一小区导入了两次，导致出现了PCI相同的外部小区。2、PCI78(GBELTRDEV2F-1)配置的外部小区中没有找到PCI82对应的小区RIZALDRVF-3，因为配置LTE同频邻区的步骤是首选配置外部小区，然后再配置邻区，邻区是包括在外部小区里的。既然没有配置外部小区，那么单纯的配置邻区是没有作用的。找到上述问题后，对于PCI12(GREENBELT4F-1)小区的操作是：删除多余的外部小区，保证PCI82唯一存在；对于PCI78(GBELTRDEV2F-1)小区的操作是：增加RIZALDRVF-3为外部小区。86第八十六页，共126页。

【总结与建议】

配置邻区时，外部小区和邻区是对应的，不能只顾配置了邻区关系而忽略了外部小区，如果外部小区没有配置正确，单纯看邻区关系是没有意义的，同样ENODEB侧也不会处理MR。87第八十七页，共126页。9、W市两个基站之间TAC配置错误导致切换失败问题现象：从A基站2小区到B基站2小区过程中，发现一段道路主服务小区的RSRP一直处于-128dbm以上，而辅服务小区的信号都在-80DBM左右，在此种情况下没有发生站间切换。88第八十八页，共126页。问题分析首先判断是否由于邻区漏配导致。通过后台查询发现A基站2小区与B基站3个小区都已经配置了邻区。故此问题不是由于临区漏配导致的.观察切换信令流程是否正确。站间切换流程从ASSISTANT分析如下（目前X2接口还没有配置，发生S1接口切换）（1）首先有MeasurementReport上报89第八十九页，共126页。90第九十页，共126页。从中可以看到A基站3个临小区的RSRP都在-75dbm左右，都属于信号强点。而此时A基站二小区RSRP为-123dbm。根据此A3报告应该要发生切换的动作。（3）其次看到了TrackingAreaUpdateRequest，W市的TAC和G网的LAC配置的完全一致，一个基站目前就是一个TAL。所以目前从基站到基站侧的肯定会有TAU更新的操作。91第九十一页，共126页。92第九十二页，共126页。从LOG可以看到目标小区TAC为39198.通过后台查询，目标小区的TAC为3918893第九十三页，共126页。发现配置的TAC和实际后台配置的TAC不同，可见后台对于TAC配置错误。(4)紧接出现TrackingAreaUpdateReject.94第九十四页，共126页。从LOG中可以看到ATU拒绝的原因是由于Implicitlydetached（隐式分离）导致的。再次之后，他会重新发起ATTACH流程，驻网成功，以下是协议对隐式分离的解释。#10 (Implicitlydetached); TheUEshalldeletethelistofequivalentPLMNsandshallenterthestateEMM-DEREGISTERED.NORMAL-SERVICE.TheUEshalldeleteanymappedEPSsecuritycontextorpartialnativeEPSsecuritycontext.TheUEshallthenperformanewattachprocedure. IfA/GbmodeorIumodeissupportedbytheUE,theUEshallhandletheGMMstateasspecifiedin3GPP

TS

24.008

[13]forthecasewhenthenormalroutingareaupdatingprocedureisrejectedwiththeGMMcausewiththesamevalue.95第九十五页，共126页。总结建议由以上分析可知，是由于目标小区TAC配置错误，导致ATU流程失败导致，从基站A切换到基站B失败。通过修改为正确TAC问题已经解决。96第九十六页，共126页。10、ENODEBID设置重复导致无法切换现象描述14号大街（华虹光电附近），UE占用华虹光电1，RSRP为-93dBm，SINR为1.0dB，一直未切换到得力纺织2，导致下载速率为1Mbps左右。97第九十七页，共126页。98第九十八页，共126页。99第九十九页，共126页。原因分析设备是否存在故障；功率设置是否合理；切换参数设置是否合理；邻区配置是否遗漏；邻区PCI是否混淆或者冲突。100第一百页，共126页。处理过程1、查询基站运行情况，小区状态正常，无告警；2、功率设置该小区CRSPW=8.2dBm，在正常范围之内；3、查看切换参数，邻区得力纺织2RSRP=-84dBm，满足切换门限邻区比服务小区高3dB，持续时间640ms切换条件；4、查看邻区配置完整性，周围两层邻区均正确配置；5、查看外部邻区的PCI设置，没有PCI混淆和冲突情况；6、分析前台测试log，发现终端持续上报MR，在UE多次上报测量报告无法正常切换情况下；后台虚用户跟踪信令出现MME回复S1AP_HANDOVER_PREPARATION_FAIL消息，详细原因为MME无法识别目标基站（710499），提示unknown-targetid（未知目标标识）。101第一百零一页，共126页。102第一百零二页，共126页。根据经验，unknown-targetid存在两种可能：一、上报的目标eNodeB不存在；二、在同一核心网EPC下如果上报的目标eNodeBID存在重复现象，核心网在无法辨别的情况下，也是发送unknown-targetid消息的；核心网EPC与eNodeB的映射是通过S1AP链路连接，所以，一条S1AP链路对应一个eNodeB，且链路号必须核心网和eNodeB侧必须一致。但是从核心网侧查询到eNodeBid为710499站点对应两个基站，IP地址分别为172.29.60.81和172.27.60.18，所以华为EPC下面下挂两个相同eNodeB标识的基站，其中IP地址172.29.60.81为得力纺织站点，而172.27.60.18在华为OMC网管并未查询到该站点103第一百零三页，共126页。104第一百零四页，共126页。后发现在EPC上诺西有相同有一站点eNodeB标识710499，修改后，外场验证测试时，得力纺织仍然存在无法入切换问题，复位S1接口后再次复测，华新电缆3能够正常切入得力纺织1小区了。下载速率由1Mbps提升到30Mbps以上。105第一百零五页，共126页。106第一百零六页，共126页。107第一百零七页，共126页。

持续观察得力纺织基站入切换话统指标，eNodeB间入切换指标已恢复正常

108第一百零八页，共126页。建议总结在建网初期，NODEBID的规划需要按照规则进行，保证全网站点NODEBID规划合理并且唯一涉及到切换问题，首先应核查切换参数合理性、PCI是否混淆或者冲突；涉及到其他网元问题，应顺藤摸瓜，找到问题的根因并处理。109第一百零九页，共126页。11、LTE一个小区添加俩PCI相同邻区导致的切换问题问题描述M国FDDLTE局点，添加邻区时发现同一小区下，可以同时添加两个相同频点相同PCI的不同小区为同频邻区。M2000上源小区MML命令LST邻区信息如下所示：110第一百一十页，共126页。111第一百一十一页，共126页。上图信息可以看出，L_CHI_011号站第一小区同时添加了100371号站点2小区PCI：226频点3250和102155号站点1小区