TD-LTE切换优化指导书

1、TD-LTE切换优化指导书目录标题 6,1,标题 7,2,标题 8,3 HYPERLINK l _Toc3131960621切换概述 .经过上述逐步分析，大体推断出问题可能是由于BBUID=400011的GPS失星造成对别的小区干扰。后经过后台配合查看，400010、400012当天的GPS状态正常，无任何问题，但是400011的BBU根本没有对GPS上电，但电波信号确已发送，造成对周边小区干扰。后把400011所属的所有小区闭塞后测试，确发现还有400010的一些小区接入切换不成功，提取上行接收功率，仍然存在一定干扰。解决方法及验证对福冈下挂的BBU连接各个小区的接入方式进行分析发现：目前日

2、本福冈采用GC局方式，一个BBU统一管理下挂的所有小区，而每个BBU共享一个GPS信号源，发现400012下的站点共享GPS虽然已上电，可是会出现偶然性的GPS失星，这个也是造成400012下的另外一些离400010站点比较近的小区受到干扰，因此把400011、400012的2个BBU下挂的所有站点闭塞，后再次测试，问题消失，400010下的所有小区接入切换均成功，问题得以解决。问题总结根据上述的分析得知，如果GPS一旦出现异常，那么对周边站点的干扰是比较严重的。对于没有接通GPS的情况要坚决不能开通释放电波。对于偶然存在GPS失星的情况要通过参数来控制其对别的站点干扰，目前后台有关于GPS失

3、星后的控制方案，其中包含2个参数：A. GPS同步保持 开/关；B.GPS同步保持时间门限 60分钟4小时。 具体配置在EMS-eNodeB节点配置表，第一个参数必须配置为开，再设置保持时间，默认是60分钟。参数网管截图如下：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 19 GPS失步闭塞小区配置开关状态为enable，时间默认为60分钟：表示开关打开，基站在60分钟内，GPS没有同步则关闭小区；开关状态为disable，时间默认为60分钟：表示开关关闭，小区状态不受GPS是否同步影响，始终保持正常建立状态；环境复杂引起的切换问题日本T1网络有一下几个特点：所有小区

4、都是全向站点站点密度大环境复杂 由于是与PHS站点共站，采用了全向天线，无法进行工程参数调整，为了保证对于室内的覆盖，站点密度设置也比较大，且日本的城区环境非常复杂，导致RSRP较好但SINR普遍较差，尤其在十字路口附近导频污染非常严重，我们的工作主要围绕在这些失败点进行整体处理思路：避免在十字路口切换：尽量避免在十字路口切换，如切换无法避免则通过调整使切换提前后者推后，必要的时候可以设置单向邻区，但这种做法只用于某些实在无法解决KPI问题的路段，一般不建议使用。对于无线参数的调整需要灵活进行，主要原则是在优化切换问题的同时尽量减少对于其他正常区域的影响减少越区覆盖带来的切换：对于越区覆盖带来

5、的切换问题优先调整覆盖，若无法调整覆盖则尽量避免切换，若都没法解决则添加邻区，调整切换参数案例解析本节通过三个案例来详细介绍问题的处理思路案例一：通过增加正常切换小区的cellA和cellC RS功率提升覆盖，降低路口功率突升突降小区cellB的RS功率减少覆盖，减少不必要的切换测试路线如下图所示图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 20 覆盖引起的切换失败点1终端按照蓝色线路移动，正常切换线路是终端从PCI=336小区切换到PCI=83小区，但在红色交叉线所示位置PCI=4小区RSRP突然升高，终端切换到PCI=4小区后PCI=4小区RSRP陡降，终端接收不

6、到切换命令导致切换失败掉话。RSRP Line Chart如下图所示：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 21 失败点RSRPPCI=4小区信号RSRP LineChart 如上图红色圆圈所示。切换掉话信令如下图图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 22 失败点信令处理过程：由于该路口是PCI=336和PCI=83小区切换点，通过增加PCI=83小区RS Power让83小区覆盖该路口，并使83小区和336小区切换点避开路口位置。 案例二：通过修改邻区cellB和cellC的个体偏移，使UE提前切换到目标小区cellC 避免

7、掉话。测试路线如下图所示：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 23 覆盖引起的切换失败点2终端沿蓝色线路移动，正常的切换过程是终端从PCI=45小区切换到PCI=61小区，但由于改路口被PCI=34小区覆盖，终端经过路口后PCI=34小区RSRP陡降导致终端发送测量报告后没有接收到切换命令导致掉话。切换掉话信令如下图：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 24 失败点信令掉话处RSRP Line Chart如下图所示：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 25 失败点RSRP处理过程：通过把

8、PCI=34小区与PCI=61小区的CIO加3dB，把切换点向西移，终端提前切换到61小区，从而避免了由于PCI=34小区信号急剧恶化导致的掉话。案例三：测试路线如下图所示图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 26 覆盖引起的切换失败点3终端按照蓝色线路移动，正常切换路线是终端从PCI=45小区切换到PCI=8小区，但在红色交叉线所示路口终端成功切换到PCI=4小区，在从PCI=4小区回切PCI=45小区时发生掉话。问题信令如下图：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 27 失败点信令切换掉话点附近RSRP Line Char

9、t如下图所示：图 STYLEREF 1 s 4 SEQ 图 * ARABIC s 1 28 失败点RSRP处理过程：为避免终端在路口向PCI=4小区切换，先后尝试降低PCI=4小区RS Power和调整PCI=45和PCI=4小区个体偏移CIO，但PCI=4小区比PCI=45小区RSRP强17dB，切换掉话问题依然无法解决。分析路口附近各小区RSRP分布，路口东西方向道路是PCI=45小区覆盖，路口向北道路是PCI=4小区覆盖但在路口附近PCI=7和PCI=4小区RSRP相近（如下图所示）。删除PCI=45-PCI=4单向邻区，既可以避免在该测试路线上向PCI=4小区切换，终端在从路口向PCI

10、=4小区移动时也可以通过先切换到PCI=7再切换到PCI=4小区的方式完成。上行失步导致掉话问题处理经验总结现象描述在29日测试过程中发现终端在行至蓝框所在位置后重建，且重建立被拒 现象分析首先检查信令，在重建立之前发送了两次测量报告，但没有收到切换命令，导致终端失步，重建立被拒打开诊断信令，发现终端在发送测量报告前已经终端已经在通过发送SR申请调度了，但一直没有收到PDCCH反馈调度信息，即SR申请失败直到SR发送最大次数后，在源小区发起了随机接入，查询MAC RACH Trigger信令，发送随机接入的原因值为UL data arrival，即SR申请失败，MR未发送成功，为了恢复上行链路

11、发起的随机接入整个随机接入过程在源小区发送msg1都未收到RAR当MSG1发送最大次数后，即在源小区恢复上行链路失败，进入重建流程，重建原因值为Radio link failure但重建需要小区选择，选择的小区没有终端上下文信息，重建被拒，导致掉话解决方法及验证 UL data arrival问题一般出现在源小区弱场，若是切换带可以通过提前切换到其他信号质量较好小区解决 查询问题点RSRP变化情况，发现源小区在在很短的时间内强度陡降，邻区则是短时间陡升的情况，此时调整小区个体偏移效果不明显，故减小当前网络Time to trigger当前网络配置time to trigger为320ms，尝试

12、修改为256ms，缩短A3事件判决时间，修改后经多次测试，问题解决经验总结当前版本CNT的诊断信令中可以看到比较详细的高通内部信令，通过信令的解析可以定位大部分常见问题，在解决问题时需要灵活根据现场情况进行参数调整，达到优化目的。非正常情况引起的切换问题案例版本问题引起的切换异常高通LOG问题现象 LOG名：10-26.11-20.isf在进行切换问题分析时，发现绝大部分切换失败都出现如下情况：收到重配命令后，同一时刻马上上报无线链路失败，导致切换失败，影响切换成功率。若此时重建立到非切换关系小区，则重建立会被拒，影响掉话率下图为其中一个典型的失败点，02:14:05.999时刻收到切换命令（

13、图1-1），而同一时刻终端事件上报无线链路失败（图1-2）图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 1 切换命令图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 2 事件上报通过检查切换前后的RLM（图1-3，图1-4），发现UE没有启动T310，即从测量上看不满足无线链路失败的条件。图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 3 切换前后RLM Report1图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 4 切换前后RLM Report2该问题带来的影响由于该问题毕现，即只要有板内回切现

14、象切换必然失败，严重影响切换成功率切换失败时若重建小区非切换源小区或目标小区，就会重建被拒，影响掉话率影响切换成功率LOG名：Z20111027_192311merge.APT共有7次切换失败从LOG统计中查询所有的失败都与前边提到的问题现象一致序号MS Time原小区目标小区切换结果切换失败说明118:33:55.4822518成功同一单板18:34:52.1701825失败218:42:13.7291825成功同一单板18:43:38.8452518失败419:07:02.3302646成功同一单板19:07:41.3384626失败519:11:15.7843419成功同一单板19:11

15、:20.8641934失败619:13:40.6532518成功同一单板19:14:47.6041825失败719:18:02.2333419成功同一单板19:18:34.7821934失败影响掉话率统计下边分别从2个LOG中摘选出由于切换失败导致的重建立，且重建立失败引起掉话的例子，同样由于同样单板回切失败的情况Z20111017_183015merge.APT前四次是一个连续的过程，反复乒乓，反复重建，18与25是同一单板MS Time原小区目标小区切换结果切换失败说明重建结果17:41:18:0662518成功同一单板17:42:20:9051825失败重建18，成功17:42:21:5

16、371825失败重建18，成功17:42:59:8071825失败重建45，失败17:55:25:0773311成功同一单板17:55:31:5781133失败重建32，失败Z20111018_183519.APTMS Time原小区目标小区切换结果切换失败说明重建结果18:06:44:3743311成功同一单板18:08:04:2341133失败重建34，失败研发初步定位关于RLF的问题，目前我司和高通对该问题的共识是：终端在收到RRC重配消息（切换命令），在PDCP层执行完整性保护校验时FAIL，之后PDCP上报RRC，触发RLF。完保FAIL的原因是:终端收到的MAC-I与实际计算的MA

17、C-I不匹配，如下，其他RB cfg index=33，对应SRB1，01:31:38.030 lte_pdcp_dl_protocol.c MAC-I mis-match RB Cfg idx = 33 seq_num = 0, rxed MAC-I = 0 x783e182b, Calculated MAC-I = 0 xbedccd4b 不同厂商切换差异问题现象在对FT区域边界进行路测时发现大量的切换失败情况，前台信令现象都是在FT网络下发送测量报告未发送切换命令，导致4.1章节所描述情况。或者在未知PCI下（现已确认为华为站点）在收到切换命令后无法在我司小区接入问题分析测试中发现华为给

18、我司切换命令的重配消息中所携带的preamble ID为63，我司在切换中实现方式是从60-63按顺序发送，即在目前单用户切换时目标小区通过源小区对UE提供的preamble ID一般都是60图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 5 华为与我司切换命令差异图 STYLEREF 1 s 5 SEQ 图 * ARABIC s 1 6 收到切换命令后在我司接入信令1：华为下发的切换命令 2：在我司小区接入 3：接入无响应后失步导致重建 4：切换入我司PC I 5：接入时使用的PreambleID为了进一步确认问题，我们截取前后台的信令对比，从我司后台配置上看未配置加X2接口，即如果需要切换的话，华为站点应该从S1口向我司发送切换请求信令，我们对其前后台信令（图5-7，图5-8）进行对齐后发现，在失步之前未收到任何S1口消息，导致没有终端上下文信息，重建立被拒图