网络优化切换专题MR不处理总结

文档来源网络侵权删除希望此文档能祝您一臂之力网络优化切换专题MR不处理总结目录1 MR不处理问题总体分析 32 具体分析 42.1 配置问题 42.1.1 现象 42.1.2 分析 52.1.3 解决方法 92.2 缺少日志 92.2.1 现象 92.2.2 分析 92.2.3 解决方法 112.3 下行失步 112.3.1 现象 112.3.2 分析 122.3.3 解决方法 132.4 正常周期上报 132.4.1 现象 132.4.2 分析 152.4.3 解决方法 162.5 终端流程问题 162.5.1 现象 162.5.2 分析 172.5.3 解决方法 182.6 丢失 192.6.1 现象 192.6.2 分析 192.6.3 解决方法 213 遗留问题 213.1 切换时MME回复S1AP_PATH_SWITCH_REQ_FAIL 21MR不处理问题总体分析对5月20日拉网log进行分析，共有1295次MR上报，发生了690次切换尝试。经过逐一分析，共有617次MR没有经过处理。（注：从终端log中，有多次切换尝试没有对应的A3测量事件，原因为Log中有A3事件的MR上报，但没Assistant没有统计进来，或发生在log的开头位置等，本文不进行分析）。即有47.5%的MR没有被处理。MR不处理的总体原因分布如图：统计数据如下：原因次数配置问题458缺少日志73下行失步32正常周期上报29终端流程问题13丢失12说明：配置问题：专指由于网络没有配置邻区，或者有重复PCI，导致MR不处理的情况。发生重建：多次上报MR（一般大于三次）后，网络没有响应，随后发生RRC连接重建立的情况。缺少日志：由于终端log是在5月20日拉网得到，没有网络侧log，并且由于时间久远，eNB上DBG日志已经被冲掉，并且网络配置也有可能被更改过，造成目前无法定位。未明确：从现在终端log中，难以准确定位出问题所在。下行失步：指由于终端连续一段时间收不到有效信号后，造成掉线或者RRC连接重建立。正常周期上报：现行网络除了配置A3事件上报外，还配置了周期上报的测量，上报内容为最强邻区。在RRC连接重配中可以看到，此测量ID不用于A3事件的测量ID。此时上报的MR不是A3事件，故网络不进行切换。流程嵌套：在上一次切换重配还没有完成，专用资源还没有重配完毕时又发生MR上报情况，或者已经下发切换的RRC连接重配，但尚未发送RRC连接重配完成消息时，又有MR上报给原小区。丢失：专指终端上报2~3次相同内容的MR，但往往最后一个会被处理，前一个或第二个没有被处理具体分析配置问题现象以2012/5/212:06:36发生的8次MR没有响应为例。终端服务小区为三台山2，每隔200ms上报一次A3事件的MR，前8次上报的邻区PCI都为144，为苏堤南口1小区。最后的MR中RSRP比服务小区RSRP高7dB。而最后一次MR中，增加了一个邻区，PCI为145，RSRP比服务小区高6dB仅接着，网络下方了向PCI为145小区切换到的重配命令。分析没有配置外部邻区或同频邻区通过查询服务小区三台山2的外部邻区配置和同频邻区配置，可以看到：该小区没有配置向苏堤南口1的外部邻区和同频邻区，可以发现，三台上2既没有配置向苏堤南口1切换的外部邻区，也没有配置同频邻区。而现网产品，没有配置外部邻区或同频邻区，是否无法切换的。配置了重复的PCI该现象在浙江图书馆1向黄龙恒励大厦街道站2切换的过程中。检查浙江图书馆1的外部邻区配置，可以看到黄龙恒励大厦街道站2和孤山3的PCI都为248.这种情况下，eNB也不处理MR。存在明显的越区覆盖该现象普遍存在。终端检查到一个远距离的小区，并上报该小区的A3事件，由于该目标小区与服务小区在地理位置上并不相邻，不配置邻区是正常的。如在断桥街道3上报浙大2小区的MR。浙大2与断桥街道3位于湖的两岸，地理距离较远，中间相隔多个小区，不可能直接从断桥街道3切换去浙大2。因此，此现象的根本原因还是在于小区越区覆盖导致。小区覆盖方向有问题在学院路3小区时，会收到浙江广厦3小区的信号，并且会触发A3事件上报。 从eNB上看，学院路3配置了向浙江广厦1切换的同频邻区，但没有配置向浙江广厦3切换的同频邻区。但是从公参地图上可以看到，此时终端位于标红位置，而浙江广厦3小区位于蓝色标出位置。可以明显看出，终端位置不应该属于浙江广厦3小区的覆盖位置，而应该处于浙江广厦1覆盖的位置。因此，eNB没有配置向浙江广厦3切换的同频邻区时有一定道理的。此处收到浙江广厦3小区的信号，但却没有收到浙江广厦1小区的信号，原因可能由于天线方向角有问题，导致小区覆盖方向与设计不一致。邻区配置在路测之后完成由于路测在5月20日晚到5月21日早完成，而该log的详细分析在6月份进行。在分析时查看eNB的邻区配置，可以发现邻区都是正常的。但实际上，邻区配置是在路测之后，分析之前完成的，因此，仅从eNB的现有配置上发现不出问题。但是通过提取eNB的历史操作记录，可以找到邻区配置发生的日期。以杭州渔政渔港1为例，提取历史操作日志可以发现：2012-05-2209:37:02

ADDEUTRANEXTERNALCELL:ENODEBID=814411,CELLID=3PHYCELLID=242,TAC=5,CELLNAME="环宇三维3";2012-05-2515:54:09

ADDEUTRANEXTERNALCELL:ENODEBID=814386,CELLID=3PHYCELLID=330,TAC=3,CELLNAME="江边3";这两处邻区配置均是在20日拉网测试之后发生的，因此，在测试时eNB无法发起正常的切换，出现了MR不处理现象。解决方法根据配置问题的不用原因，需要不同的解决方法：对于没有配置外部邻区和同频邻区的，根据网络规划方案，检查小区邻区配置，完善小区邻区配置。对于重复PCI的配置，修改冲突小区的PCI，或减少邻区关系。对于存在越区覆盖的情况，需要完善网络的基础覆盖，调整天线下倾角，减少越区覆盖。对于有可能存在小区覆盖方向与设计不一致的情况，需要调整天线的角度。对于邻区配置在路测之后完成的，是由于拉网和分析时间较远，中间网络配置发生了变化造成的。在后续的分析中，应尽早对进行问题分析，避免网路配置变化对分析问题造成影响。缺少日志现象该现象在路线2中出现在三个站点：法静寺2向云中山庄1切换，五云山疗养院1向珊瑚水厂3切换，联庄3向之江度假村1切换。分析法静寺2向云中山庄1切换和五云山疗养院1向珊瑚水厂3切换，这两处切换发生时，RSRP和SNR均很低。法静寺2发送MR时RSRP低于-129dB。SNR低于-9dB。五云山疗养院1发送MR时，RSRP低于-103dB，SNR低于-3.25dB。法静寺1:五云山疗养院1：这两处地点，怀疑是由于信号较差，eNB没有收到MR，或者eNB下发了重配消息，但终端没有接收到。但由于缺少eNB的log，无法定位。联庄3向之江度假村1切换情况相对更加特殊，MR发送时，服务小区的RSRP为-90dB，SNR达到5.25dB。同样由于缺少eNB的log，但从终端log上无法定位出问题所在。解决方法对于这些地点，需要复测并抓到更详细的log后才能进行分析。复测时需要抓终端log、eNB的UU和S1口log和DBG日志。下行失步现象一般发送四到五次MR后，终端会重新搜网并发起RRC连接重建立流程。而这一流程往往在1s左右完成。分析考察终端发起RRC连接重建立的情况，有以下几种情况：upondetectingradiolinkfailure,inaccordancewith5.3.11;oruponhandoverfailure,inaccordancewith5.3.5.6;oruponmobilityfromE-UTRAfailure,inaccordancewith5.4.3.5;oruponintegritycheckfailureindicationfromlowerlayers;oruponanRRCconnectionreconfigurationfailure,inaccordancewith5.3.5.5;而重建立请求的原因只有三个值：reconfigurationFailure，HOFailure，otherFailure。从log中终端发起重建立请求原因为otherFailure来看，此时终端最有可能是检测到无线链路失败造成的。检查终端此时的信号强度，可以看到RSRP很低，为-116dB，SNR为-12.75dB。信号很差。另外了解到测试终端CPE在SNR低于-6dB之后，有很大可能无法解出信号来。T310定时器是终端在发现radiolinkfailure等待的时长，如果超时，就发起RRC连接重建立流程，如果在T310时长内收到物理层的in-sync指示，就恢复。检查eNB对T310定时器的配置，如下图目前eNB的T310定时器都是默认1s钟。而此MR上报不处理的情况往往在1s钟后发起RRC连接重建立流程，与这种情况比较吻合。但缺陷是由于没有网络侧log，不能准确知道eNB是否收到了MR，是否有无处理，只是终端没有收到。解决方法由于下行失步与网络覆盖、干扰有较大关系，在网络中不能完全避免。而本案例分析中的场景有其独特性。终端和服务小区分别位于江两岸，对岸小区信号的强度要高于本岸小区信号的强度，终端接收从江对面打过来的信号，并成功接入。这更多的与网络基础覆盖相关，因此对发生下行失步的地点进行基础网络优化比较关键。正常周期上报现象在部分小区中可以看到以5s为周期，上报MR。MR中的内容有的只有服务小区的RSRP和RSRQ信息，如下图：有的包含部分邻区的RSRP和RSRQ信息，有可能邻区的信号比服务小区的信号还要弱，不满足A3事件上报的门限，如下图：。分析查看此前的测量重配消息，可以发现一般有两次测量的重配。第一次重配中上报机制是A3事件触发。根据配置，当A3事件触发后，开始变为周期上报，上报周期为240ms，上报次数为无数次。A3事件上报的measID为1.第二次测量重配内容为周期性上报，上报内容为最强邻区，上报周期为5120ms，上报次数为64次。周期上报的测量ID为2而从终端上报MR的measID来看，此时上报的MR是第二次测量重配的MR，即周期上报最强邻区。由于MeasID不一样，这种MR不是A3事件，故网络不必进行切换处理。解决方法正常流程，不必额外处理。终端流程问题现象在某些场景下，会出现本次MR发生在上次切换过程中的现象。如下面选中的MR。或者在切换时，只收到mobilityControlInfo的重配消息，还没有收到测量控制的重配，但依旧会上报MR。分析由于上一条MR后，网络已经下发切换的重配。在终端仍在向目标小区随机接入时，又有下发一条测量报告。根据协议：TheUEshall:1> foreachmeasIdincludedinthemeasIdListwithinVarMeasConfig:2> ifthetriggerTypeissettoperiodical:3> removethismeasIdfromthemeasIdListwithinVarMeasConfig:1> iftheprocedurewastriggeredduetoahandoverorsuccessfulre-establishmentandtheprocedureinvolvesachangeofprimaryfrequency,updatethemeasIdvaluesinthemeasIdListwithinVarMeasConfigasfollows:2> ifameasObjectIdvaluecorrespondingtothetargetprimaryfrequencyexistsinthemeasObjectListwithinVarMeasConfig:3> foreachmeasIdvalueinthemeasIdList:4> ifthemeasIdvalueislinkedtothemeasObjectIdvaluecorrespondingtothesourceprimaryfrequency:5> linkthismeasIdvaluetothemeasObjectIdvaluecorrespondingtothetargetprimaryfrequency;4> elseifthemeasIdvalueislinkedtothemeasObjectIdvaluecorrespondingtothetargetprimaryfrequency:5> linkthismeasIdvaluetothemeasObjectIdvaluecorrespondingtothesourceprimaryfrequency;2> else:3> removeallmeasIdvaluesthatarelinkedtothemeasObjectIdvaluecorrespondingtothesourceprimaryfrequency;1> removeallmeasurementreportingentrieswithinVarMeasReportList;1> stoptheperiodicalreportingtimerortimerT321,whicheveroneisrunning,aswellasassociatedinformation(e.g.timeToTrigger)forallmeasId;1> releasethemeasurementgaps,ifactivated;根据红色部分说明，此时终端不应该再进行MR上报的。此外，还有另一种流程异常的情况。如上图，网络下发了切换的重配命令，终端在上报重配完成时达到HARQ最大重传次数而丢弃，故eNB没有后续的测量控制和专用信道的RRC连接重配命令下来，并且eNB由于没有收到切换的重配完成命令，会造成eNB资源挂死，后续由于定时器超时会删除目标小区上该用户的资源。而根据协议，终端在切换后的上报机制都已经被删除了，因此，如果没有收到新小区的测量控制的话，终端是不应该使用原小区的上报配置，因而不应该发送MR。解决方法该情况发生一般发生在流程嵌套过程中，出现概率比较低。第一种情况需要向终端方了解，看到底是不符合协议，或者是log打点有问题。第二种情况与后来发现的另一种异常情况相似，在3.1节中有描述，并且有eNBlog可以分析。后续应加以关注。丢失现象该现象出现比较随机，没有固定小区复现。从log上看，一般会出现2至3次MR，但往往最后一个会被处理，并且此时的信号都较差。分析观察信令，发现随后虽然有重配，但是并不是切换的重配，并且仅接着就发生了重配失败而导致的重建立流程。在杭四建向老年活动中心也发生了这样的情况，并且针对该现象进行了复测。但在复测时，MR不处理的现象不再出现。首先观察有MR不处理时的信号变化：在上报MR时，同时检测到三个邻区，并且RSRP均为-75dB到-87dB，干扰较大。同时注意到，省侨联的PCI模三为0，与服务小区模三冲突。此时SNR为-3.75dB，信号质量较差。存在由于信道质量导致网络没有收到MR，或网络收到MR并下发切换重配，但终端没有检测到的可能性。在6月1日去现场复测。复测时，没有出现MR不处理现象，而