【lte实战】td-lte切换优化指导书.doc

1                       切换概述

1.1                   切换流程介绍

1.1.1               切换流程图

图 1‑1  切换流程图

-                Measurement Control

测量控制，一般在初始接入或上一次切换命令中的重配消息里携带

-                Measurement Report

测量报告，终端根据当前小区的测量控制信息，将符合切换门限的小区进行上报

-                HO Request

源小区在收到测量报告后向目标小区申请资源及配置信息（站内切换的话为站内交互，站间切换会使用X2口或者S1口，优先使用X2口）

-                HO Request Ack

目标小区将终端的接纳信息以及其它配置信息反馈给源小区

-                RRC Connection Reconfiguration

将目标小区的接纳信息及配置信息发给终端，告知终端目标小区已准备好终端接入，重配消息里包含目标小区的测量控制

-                SN Status Transfer

源小区将终端业务的缓存数据移至目标小区

-                Random Access Preamble

终端收到第5步重配消息（切换命令）后使用重配消息里的接入信息进行接入

-                Random Access Response

目标小区接入响应，收到此命令后可认为接入完成了，然后终端在RRC层上发重配完成消息（第9步）

-                RRC Connect Reconfiguration complete（HO Confirm）

上报重配完成消息，切换完成

-                Release Resource

当终端成功接入后，目标小区通知源小区删除终端的上下文信息

1.1.2               切换分类介绍

按照我们实际情况，切换可分为eNb站内切换，X2口切换以及S1口切换，下边分别进行介绍（下边介绍的所有切换都是基于已经接入且获取到了测量配置后）

1.1.2.1                站内切换

站内切换过程比较简单，由于切换源和目标都在一个小区，所以基站在内部进行判决，并且不需要向核心网申请更换数据传输路径

图 1‑2  站内切换信令流程图

1.1.2.2                X2口切换

用于建立X2口连接的邻区间切换，在接到测量报告后需要先通过X2口向目标小区发送切换申请（图1-1第3步），得到目标小区反馈后（图1-1第4步）才会向终端发送切换命令，并向目标测发送带有数据包缓存、数据包缓存号等信息的SNStatus Transfer消息，待UE在目标小区接入后，目标小区会向核心网发送路径更换请求，目的是通知核心网将终端的业务转移到目标小区，X2切换优先级大于S1切换

图 1‑3  X2口切换信令流程图

1.1.2.3                S1口切换

S1口发生在没有X2口且非站内切换的有邻区关系的小区之间，基本流程和x2口一致，但所有的站间交互信令都是通过核心网S1口转发，时延比X2口略大

图 1‑4  S1口切换信令流程图

1.2                   前台信令解析

切换的大部分问题可在前台信令中进行分析，本文以前台信令为主介绍整个切换流程及问题分析思路

图 2‑1  正常切换信令

注意：这里的重配完成只是组包完成，实际是在MSG3里发送的

前台信令窗的交互过程主要是是图1-1里的1、2、5、7、8、9几步，现在来分别介绍

1.2.1               测量控制

测量控制信息是通过重配消息里下发的，测量控制一般存在于初始接入时的重配消息和切换命令中的重配消息中。

图 2‑2  重配消息中的测量控制（RRC CONNECT RECONFIGRATION）

1：测量控制

测量控制信息包括邻区列表、事件判断门限、时延、上报间隔等信息

1.2.2               测量报告

终端在服务小区下发的测量控制进行测量，将满足上报条件的小区上报给服务小区。

1.2.3               终端测量机制

首先了解下终端是如何进行事件判断的，当前网络中采用的是a3事件，即目标小区信号质量高于本小区一个门限且维持一段时间就会触发。图 2‑2比较直观的介绍了这一个过程，终端在接入网络后会持续进行服务小区及邻区测量（邻区测量与传统意义上的邻区不同，是对整个同频网络中的小区进行测量，类似Scanner进行TopN扫频），当终端满足Mn+Ofn+Ocn-Hys＞Ms+Ofs+Ocs+Off且维持Time to Trigger个时段后上报测量报告

Mn：邻小区测量值

Ofn：邻小区频率偏移

Ocn：邻小区偏置

Hys：迟滞值

Ms：服务小区测量值

Ofs：服务小区频率偏移

Ocs：服务小区偏置

Off：偏置值

图 2‑3  a3时间报告示意图

1.2.4               测量报告内容

测量报告会将满足事件的所有小区上报。需要注意的是LTE中终端上报的测量报告不一定是邻区配置里下发的邻区，目前网络暂不支持邻区自优化，故在分析问题时可以使用测量报告值及测量控制中的邻区信息来判断是否为漏配邻区，在4.1.2中详细介绍漏配邻区的检测方法。

图 2‑4  测量报告内容

MeasResults：源小区测量值   MeasResultNeighCells：满足a3事件小区测量值

1.2.5               切换命令

这里的切换命令是指带有mobilityControlInfo的重配命令，mobilityControlInfo里包含了目标小区的PCI以及接入需要的所有配置

图 2‑5  切换命令

1：切换命令； 2：目标PCI ；3：T304配置； 4：C_RNTI ；5：RACH配置

1.2.6               在目标小区随机接入（MSG1）

终端在目标小区使用源小区在切换命令中带的接入配置进行接入

图 2‑6  MSG1

1.2.7               基站回应随机接入响应（RAR）

目前切换都为非竞争切换，所以到这一步基本上就可以确认在目标小区成功接入

图 2‑7  MSG2

1.2.8               终端反馈重配完成，切换结束

实际上重配完成消息在收到切换命令后就已经组包结束，在目标侧的随机接入可认为是由重配完成消息发起的目标侧随机接入过程，重配完成消息在包含在MSG3中发送（整个过程可参见图 2‑8）。

图 2‑8  切换执行过程

1：重配完成消息组包  2：MSG3

图 2‑9  MSG3

2                       切换优化整体思路

所有的异常流程都首先需要检查基站、传输等状态是否异常，排查基站、传输等问题后再进行分析。

整个切换过程异常情况我们分为几个阶段

测量报告发送后是否收到切换命令

收到重配命令后是否成功在目标测发送MSG1

成功发送MSG1之后是否正常收到MSG2

图3-1为切换问题整体过程流程图，在某一环节出现问题我们可查询相应处理流程进行排查

图 3‑1  切换问题分析整体思路

2.1                   测量报告发送后未收到切换命令

这个情况是我们外场最常见问题，处理定位也比较复杂，分析流程见图3-2：

基站未收到测量报告（可通过后台信令跟踪检查）：

检查覆盖点是否合理，主要是检查测量报告点的RSRP,SINR等覆盖情况，确认终端是否在小区边缘，或存在上行功率受限情况（根据下行终端估计的路损判断）。如果是该情况，按照现场情况调整覆盖，及切换参数，解决异常情况

目前现场测试建议在切换点覆盖RSRP不要低于-120dBm   SINR不要小于-5dB

检查是否存在上行干扰，可通过后台MTS查询，如：在20M带宽下，基站接收无终端接入时接收的底噪约为-98dBm，如果在无用户时底噪过高则肯定存在上行干扰，上行干扰优先检查是否为邻近其他小区GPS失锁导致，当前版本暂不支持后台工具定位干扰源位置，只能将通过关闭干扰源附近站点，使用Scanner进行CW测试来排查

基站收到了测量报告：

1.     未向终端发送切换命令情况：

（1）   确认目标小区是否为漏配邻区，漏配邻区从后台比较容易看出来，直接观察后台信令跟踪中基站收到测量报告后是否向目标小区发送切换请求即可；漏配邻区也可在前台进行判断，首先检查测量报告中给源小区的上报的PCI，检查接入或切换至源小区时重配命令中的MeasObjectToAddModList字段中的邻区列表中是否存在终端测量报告携带的PCI，具体方法可参考4.1章节；如果确认为漏配邻区添加邻区关系即可

（2）   在配置了邻区后若收到了测量报告后，源基站会通过X2口或者S1口（若没有配置X2偶联）向目标小区发送切换请求。此时需要检查是否目标小区未向源小区发送切换响应（图1-1 第4步），或者发送HANDOVER PREPARATION FAILUE信令，在这种情况下源小区也不会向终端发送切换命令

          此时需要从以下三个方面定位：

-                   目标小区准备失败，RNTI准备失败、PHY/MAC参数配置异常等会造成目标小区无法接纳而返回HANDOVER PREPARATION FAILUE

-                   传输链路异常，会造成目标小区无响应

-                   目标小区状态异常，会造成目标小区无响应

2.     向终端发送切换命令情况：

主要检查测量报告上报点的覆盖情况，是否为弱场，或强干扰区域，优先建议通过工程参数解决覆盖问题，若覆盖不易调整则通过调整切换参数优化

图 3‑2  发送测量报告后未收到切换命令处理流程

2.2                   目标小区MSG1发送异常情况

正常情况测量报告上报的小区都会比源小区的覆盖情况好，但不排除目标小区覆盖陡变的情况，所以首先排除掉由于测试环境覆盖引起的切换问题。这类问题建议优先调整覆盖，若覆盖不易调整则通过调整切换参数优化

当覆盖比较稳定却仍无法正常发送的话就需要在基站测检查是否出现上行干扰，该问题详见4.2.1节

2.3                   接收RAR异常情况

接收RAR异常情况，该情况一般主要检查测试点的无线环境，处理思路仍是优先优化覆盖若覆盖不易调整再来调整切换参数

3                       切换相关常用参数汇总

小区参考信号的功率

基本信息

参数功能描述

该参数指示了小区参考信号的功率(绝对值)。

小区参考信号用于小区搜索、下行信道估计、信道检测，直接影响到小区覆盖。该参数通过SIB2广播方式通知UE，并在整个下行系统带宽和所有子帧中保持恒定，除非SIB2消息中有更新(如RS功率增强)。

参数调整影响

下行信道的功率设定，均以参考信号功率为基准，因此参考信号功率的设定以及变更，影响到整个下行功率设定。RSRP过大，会造成导频污染以及小区间干扰；过小会造成小区选择或重选不上，数据信道无法解调等。

中心UE的PDSCH与小区RS的功率偏差

基本信息

参数功能描述

表示某一UE的数据RE（不含导频的OFDM符号内）功率与导频RE功率的比值。

参数调整影响

小区选择所需要的最小接收水平

基本信息

参数功能描述

Qrxlevmin指示了小区满足选择和重选择条件的最小接收电平门限。被测小区的接收电平只有大于Qrxlevmin时，才满足小区选择的条件。

参数调整影响

该参数的配置影响小区下行覆盖范围。

测量时的RSRP层3滤波系数

基本信息

参数功能描述

物理层上报的RSRP测量结果需要经过层3滤波以消除抖动，RRC使用的结果都需要经过层3滤波后方可使用。滤波公式为，其中a = 1/2^(k/4)

Fn为更新后的滤波测量结果，Fn-1为旧的滤波测量结果，Mn为最新收到的来自物理层的测量结果。上式中的k即为层3滤波系数

参数调整影响

Event Identity

基本信息

参数功能描述

该参数指示了频内测量触发的事件标识，与测量量相关

参数调整影响

小区个体偏移

基本信息

参数功能描述

对每个被监视的小区，都用带内信令分配一个偏移。偏移可正可负。在UE评估是否一个事件已经发生之前，应将偏移加入到测量量中，从而影响测量报告触发的条件。

参数调整影响

设置为正值，易切换到该小区；设置为负值，不易切换到该小区。

Time to Trigger

基本信息

参数功能描述

该参数指示了监测到事件发生的时刻到事件上报的时刻之间的时间差。只有当事件被监测到且在该参数指示的触发时长内一直满足事件触发条件时，事件才被触发并上报。

Time to trigger设置的越大，表明对事件触发的判决越严格，但需要根据实际的需要来设置此参数的长度，因为有时设置的太长会影响用户的通信质量。

参数调整影响

Hysteresis

基本信息

参数功能描述

进行判决时迟滞范围, 用于事件的判决。

参数调整影响

事件上报次数

基本信息

参数功能描述

该参数指示了在触发事件后进行测量报告上报的最大次数。 当事件触发后，UE根据报告间隔上报测量结果，如果上报次数超过了该参数指示的值，则停止上报测量结果

参数调整影响

事件上报周期

基本信息

参数功能描述

该参数指示了周期报告规则中周期报告的时间间隔

参数调整影响

最大上报小区

基本信息

参数功能描述

该参数指示了测量上报的最大小区数目

参数调整影响

4                       切换优化常见问题及案例

4.1                   漏配邻区

漏配邻区一般可通过无线参数表结合测试数据检查，或者可以在后台直接通过信令跟踪确认收到测量报告后源小区是否向目标小区发生切换请求来确认，但某些场景下我们不易取得无线参数表，且无法进行后台信令跟踪，那么我们可以通过前台信令来分析的到：

LTE网络在协议中是一个自优化的网络，终端上报测量报告中会按照a3事件判断原则进行上报，上报的小区不受测量控制中邻区影响，所以只需要将切换异常点的测量报告和当前服务小区的测量控制中的邻区进行对比就可得出是否为漏配邻区

4.1.1               前台分析漏配邻区的现象

4.1.1.1                多次测量报告

正常的流程终端在发送测量报告后基站会很快发送切换命令，但如果有漏配邻区，源小区就无法得知目标小区的基站信息，无法正常完成切换流程介绍中的（见图1-1）中的第三步，故无法发送切换命令消息，此时由于终端仍在行进中，源小区信号越来越差，满足a3事件小区逐渐增加，触发新的测量报告，直到有邻接关系的小区出现，基站才能正常发送切换命令

下边选取一个典型问题分析：

在某次路测中发现如图4-1情况，前三次测量报告目标PCI都是28（前三次类似图4-2，PCI相同，RSRP测量值略有差异），第四次测量报告（见图4-3）中有PCI28、19两个小区，从测量值上看，28比19高3个dB，接着收到了切换命令，切换命令（见图4-4）中的目标小区不是最高的28而是19。此时即可初步怀疑28为漏配邻区，

图 4‑1  多次测量报告现象

图 4‑2  第一个测量报告内容

图 4‑3  第四次测量报告内容

图 4‑4  切换命令

1：目标小区PCI

图 4‑5  源小区测量控制信息

1：邻区列表中带有PCI19小区

4.1.1.2                测量报告发送后无响应

4.2.1.1介绍了漏配邻区导致的多次测量报告，直到某一次测量报告中上报的目标小区是源小区的邻区则才会收到切换命令，但如果上报的测量报告基站还未响应就失步则会发起重建流程，终端上报掉话事件

这种情况的分析方法基本和4.1.1.1一致

下边选取一个典型例子：

某次路测中发现终端在发送测量报告后未收到切换命令，导致无线链路失败发起了重建过程（如图4-6），首先检查测量报告内容（图4-7，两个测量报告PCI都为30），目标小区PCI为30，检查源小区测量控制（图4-8），发现的确未配置邻区。

图 4‑6  漏配邻区引起的掉话

图 4‑7  第一个测量报告内容

图 4‑8  源小区测量控制信息

4.1.2               漏配邻区带来的影响

4.1.2.1                流量降低

在3.1.1.1节叙述的四次测量报告的情况下，可以明显看出这由于未及时切换导致SINR变差（图3-9），业务速率低（图3-10）

图 4‑9  SINR

图 4‑10  流量

4.1.2.2                掉话

在3.1.1.2节中介绍的情况就是测量报告无响应后失步掉话，该问题会影响掉话率、业务速率等指标

4.1.3               漏配邻区处理方法

添加邻区

对于某些特殊路段需要删除邻区并调整功率等操作，具体会在4.2章中介绍

4.2                   无线环境引起的切换异常

4.2.1               上行干扰引起的目标测接入困难

本节以站点GPS异常引起的其他站点小区上行干扰严重导致的切换与接入成功率差情况为案例，整个处理思路可用来定位上行干扰问题

4.2.1.1                问题现象

在测试福冈网络指标摸底阶段中，经常出现接入不成功，切换后异常掉话现象，这种显现表现无一定规律，有时成功有时失败。测试掉话点分布如图所示：

图 4‑11  上行干扰问题点

通过掉话点分布，可以看到掉话点基本在东南边。

本次长保拉网的指标统计如下：

从统计指标看到掉话率、切换成功率都非常差。

4.2.1.2                问题分析

1.     针对该问题，我们挑选了部分小区定点做了测试，发现定点拨测中始终连接不到网络，高通终端状态指示灯一会红色(异常)一会绿色，同时自研UE也无法接入：

自研UE表现如下：

图 4‑12  上行干扰引起的问题现象

自研UE不断尝试接入，始终无法成功，从RRC请求到最后RRC释放，频繁出现。

高通终端表现同样如此，一直在IDLE、CONNECTED之前乒乓，无法正常接入。

图 4‑13  上行干扰引起的问题现象2

2.     查看当时测试LOG，在服务小区出现RRC重建后被拒绝。

通过高通分析软件QCAT查看掉话过程及重建过程。看到UE原因为UL_DATA后DCI0未达，SR达到最大次数，触发MSG1，由于MSG1无法到达网络侧，不断重发8次后失败，后触发重建。

图 4‑14  上行干扰引起的问题3

为了验证问题是否有规律性，对站点了定点测试，测试区域如图所示：

图 4‑15  上行干扰问题验证

蓝色的小区随机接入和切换成功率比较高，而红色区域一些站点接入较困难，切换测试RRC重配后无果，随后触发重建后又被拒，后再次接入失败。

经过上述分析，初步怀疑可能是干扰导致上行数据异常造成。目前福冈站点分别是采取GC局的形式，一个BBU下挂几个RRU做为站点，且日本是全向站，站点分布如图：

图 4‑16  上行干扰引起的集中掉话区域

红色区域是掉话集中区域，目前测试阶段未初期性能摸底阶段，因此测试只是围绕Ref区域进行（图中蓝色方框内）。后查看掉话点与BBUID关系，发现有一定联系，非掉话区域隶属于BBUID=400010，越靠近掉话区域的隶属于BBUID=400011、400012的BBU下挂小区。因此怀疑可能BBUID为400010与400011、400012某些关联问题导致。

3.     根据上述分析查看后台设备告警，首先查看GPS状态，发现400010和400012站点正常，400011站点GPS未锁定。

400010、400012的GPS状态正常：

图 4‑17  正常GPS后台查询图形

400011站点GPS未锁定：

图 4‑18  异常GPS后台查询图形

看站点分别400011、400012插花式分布，集中在一起，400011无GPS锁星，那么可能导致其下挂的小区对周边小区造成GPS干扰，造成其他小区上行接入失败。后对接入切换不成功的小区提取MTS跟踪上行接收功率数据，发现基站侧接收功率普遍抬高（普通应该在-96~99dbm左右），评价在-80dbm左右，显然明显收到上行干扰。干扰情况如下表显示：

基站侧接收到的RxPow0～3都很高，上行干扰严重。

4.     经过上述逐步分析，大体推断出问题可能是由于BBUID=400011的GPS失星造成对别的小区干扰。后经过后台配合查看，400010、400012当天的GPS状态正常，无任何问题，但是400011的BBU根本没有对GPS上电，但电波信号确已发送，造成对周边小区干扰。后把400011所属的所有小区闭塞后测试，确发现还有400010的一些小区接入切换不成功，提取上行接收功率，仍然存在一定干扰。

4.2.1.3                解决方法及验证

对福冈下挂的BBU连接各个小区的接入方式进行分析发现：目前日本福冈采用GC局方式，一个BBU统一管理下挂的所有小区，而每个BBU共享一个GPS信号源，发现400012下的站点共享GPS虽然已上电，可是会出现偶然性的GPS失星，这个也是造成400012下的另外一些离400010站点比较近的小区受到干扰，因此把400011、400012的2个BBU下挂的所有站点闭塞，后再次测试，问题消失，400010下的所有小区接入切换均成功，问题得以解决。

4.2.1.4                问题总结

根据上述的分析得知，如果GPS一旦出现异常，那么对周边站点的干扰是比较严重的。对于没有接通GPS的情况要坚决不能开通释放电波。对于偶然存在GPS失星的情况要通过参数来控制其对别的站点干扰，目前后台有关于GPS失星后的控制方案，其中包含2个参数：

A. GPS同步保持  开/关；

B.GPS同步保持时间门限 60分钟~4小时。

具体配置在EMS-eNodeB节点配置表，第一个参数必须配置为开，再设置保持时间，默认是60分钟。参数网管截图如下：

图 4‑19  GPS失步闭塞小区配置

开关状态为enable，时间默认为60分钟：表示开关打开，基站在60分钟内，GPS没有同步则关闭小区；

开关状态为disable，时间默认为60分钟：表示开关关闭，小区状态不受GPS是否同步影响，始终保持正常建立状态；

4.2.2               环境复杂引起的切换问题

4.2.2.1                日本T1网络有一下几个特点：

l   所有小区都是全向站点

l   站点密度大

l   环境复杂

由于是与PHS站点共站，采用了全向天线，无法进行工程参数调整，为了保证对于室内的覆盖，站点密度设置也比较大，且日本的城区环境非常复杂，导致RSRP较好但SINR普遍较差，尤其在十字路口附近导频污染非常严重，我们的工作主要围绕在这些失败点进行

4.2.2.2                整体处理思路：

1.      避免在十字路口切换：尽量避免在十字路口切换，如切换无法避免则通过调整使切换提前后者推后，必要的时候可以设置单向邻区，但这种做法只用于某些实在无法解决KPI问题的路段，一般不建议使用。对于无线参数的调整需要灵活进行，主要原则是在优化切换问题的同时尽量减少对于其他正常区域的影响

2.      减少越区覆盖带来的切换：对于越区覆盖带来的切换问题优先调整覆盖，若无法调整覆盖则尽量避免切换，若都没法解决则添加邻区，调整切换参数

4.2.2.3                案例解析

本节通过三个案例来详细介绍问题的处理思路

案例一：通过增加正常切换小区的cellA和cellC RS功率提升覆盖，降低路口功率突升突降小区cellB的RS功率减少覆盖，减少不必要的切换

测试路线如下图所示

图 4‑20  覆盖引起的切换失败点1

终端按照蓝色线路移动，正常切换线路是终端从PCI=336小区切换到PCI=83小区，但在红色交叉线所示位置PCI=4小区RSRP突然升高，终端切换到PCI=4小区后PCI=4小区RSRP陡降，终端接收不到切换命令导致切换失败掉话。

RSRP Line Chart如下图所示：

图 4‑21  失败点RSRP

PCI=4小区信号RSRP LineChart 如上图红色圆圈所示。

切换掉话信令如下图

图 4‑22  失败点信令

处理过程：

由于该路口是PCI=336和PCI=83小区切换点，通过增加PCI=83小区RS Power让83小区覆盖该路口，并使83小区和336小区切换点避开路口位置。

案例二：通过修改邻区cellB和cellC的个体偏移，使UE提前切换到目标小区cellC 避免掉话。

测试路线如下图所示：

图 4‑23  覆盖引起的切换失败点2

终端沿蓝色线路移动，正常的切换过程是终端从PCI=45小区切换到PCI=61小区，但由于改路口被PCI=34小区覆盖，终端经过路口后PCI=34小区RSRP陡降导致终端发送测量报告后没有接收到切换命令导致掉话。

切换掉话信令如下图：

图 4‑24  失败点信令

掉话处RSRP Line Chart如下图所示：

图 4‑25  失败点RSRP

处理过程：

通过把PCI=34小区与PCI=61小区的CIO加3dB，把切换点向西移，终端提前切换到61小区，从而避免了由于PCI=34小区信号急剧恶化导致的掉话。

案例三：测试路线如下图所示

图 4‑26  覆盖引起的切换失败点3

终端按照蓝色线路移动，正常切换路线是终端从PCI=45小区切换到PCI=8小区，但在红色交叉线所示路口终端成功切换到PCI=4小区，在从PCI=4小区回切PCI=45小区时发生掉话。

问题信令如下图：

图 4‑27  失败点信令

切换掉话点附近RSRP Line Chart如下图所示：

图 4‑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=4小区移动时也可以通过先切换到PCI=7再切换到PCI=4小区的方式完成。

4.3                   上行失步导致掉话问题处理经验总结

4.3.1               现象描述

在29日测试过程中发现终端在行至蓝框所在位置后重建，且重建立被拒

4.3.2               现象分析

首先检查信令，在重建立之前发送了两次测量报告，但没有收到切换命令，导致终端失步，重建立被拒

打开诊断信令，发现终端在发送测量报告前已经终端已经在通过发送SR申请调度了，但一直没有收到PDCCH反馈调度信息，即SR申请失败

直到SR发送最大次数后，在源小区发起了随机接入，查询MAC RACH Trigger信令，发送随机接入的原因值为UL data arrival，即SR申请失败，MR未发送成功，为了恢复上行链路发起的随机接入

整个随机接入过程在源小区发送msg1都未收到RAR

当MSG1发送最大次数后，即在源小区恢复上行链路失败，进入重建流程，重建原因值为Radio link failure

但重建需要小区选择，选择的小区没有终端上下文信息，重建被拒，导致掉话

4.3.3               解决方法及验证

   UL data arrival问题一般出现在源小区弱场，若是切换带可以通过提前切换到其他信号质量较好小区解决

   查询问题点RSRP变化情况，发现源小区在在很短的时间内强度陡降，邻区则是短时间陡升的情况，此时调整小区个体偏移效果不明显，故减小当前网络Time to trigger

当前网络配置time to trigger为320ms，尝试修改为256ms，缩短A3事件判决时间，修改后经多次测试，问题解决

4.3.4               经验总结

当前版本CNT的诊断信令中可以看到比较详细的高通内部信令，通过信令的解析可以定位大部分常见问题，在解决问题时需要灵活根据现场情况进行参数调整，达到优化目的。

5                       非正常情况引起的切换问题案例

5.1                   版本问题引起的切换异常

5.1.1               高通LOG问题现象

    LOG名：10-26.11-20.isf

在进行切换问题分析时，发现绝大部分切换失败都出现如下情况：收到重配命令后，同一时刻马上上报无线链路失败，导致切换失败，影响切换成功率。若此时重建立到非切换关系小区，则重建立会被拒，影响掉话率

下图为其中一个典型的失败点，02:14:05.999时刻收到切换命令（图1-1），而同一时刻终端事件上报无线链路失败（图1-2）

图 5‑1  切换命令

图 5‑2  事件上报

通过检查切换前后的RLM（图1-3，图1-4），发现UE没有启动T310，即从测量上看不满足无线链路失败的条件。

图 5‑3  切换前后RLM Report1

图 5‑4  切换前后RLM Report2

5.1.2               该问题带来的影响

由于该问题毕现，即只要有板内回切现象切换必然失败，严重影响切换成功率

切换失败时若重建小区非切换源小区或目标小区，就会重建被拒，影响掉话率

5.1.2.1                影响切换成功率

LOG名：Z20111027_192311merge.APT

共有7次切换失败

从LOG统计中查询所有的失败都与前边提到的问题现象一致

5.1.2.2                影响掉话率统计

下边分别从2个LOG中摘选出由于切换失败导致的重建立，且重建立失败引起掉话的例子，同样由于同样单板回切失败的情况

l   Z20111017_183015merge.APT

前四次是一个连续的过程，反复乒乓，反复重建，18与25是同一单板

l   Z20111018_183519.APT

5.1.3               研发初步定位

关于RLF的问题，目前我司和高通对该问题的共识是：

终端在收到RRC重配消息（切换命令），在PDCP层执行完整性保护校验时FAIL，之后PDCP上报RRC，触发RLF。

完保FAIL的原因是:终端收到的MAC-I与实际计算的MAC-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 = 0x783e182b, Calculated MAC-I = 0xbedccd4b

5.2                   不同厂商切换差异

5.2.1               问题现象

在对FT区域边界进行路测时发现大量的切换失败情况，前台信令现象都是在FT网络下发送测量报告未发送切换命令，导致4.1章节所描述情况。或者在未知PCI下（现已确认为华为站点）在收到切换命令后无法在我司小区接入

5.2.2               问题分析

测试中发现华为给我司切换命令的重配消息中所携带的preamble ID为63，我司在切换中实现方式是从60-63按顺序发送，即在目前单用户切换时目标小区通过源小区对UE提供的preamble ID一般都是60

图 5‑5  华为与我司切换命令差异

图 5‑6  收到切换命令后在我司接入信令

1：华为下发的切换命令  2：在我司小区接入  3：接入无响应后失步导致重建  4：切换入我司PC I 5：接入时使用的PreambleID

为了进一步确认问题，我们截取前后台的信令对比，从我司后台配置上看未配置加X2接口，即如果需要切换的话，华为站点应该从S1口向我司发送切换请求信令，我们对其前后台信令（图5-7，图5-8）进行对齐后发现，在失步之前未收到任何S1口消息，导致没有终端上下文信息，重建立被拒

图 5‑7  前台发送的重建立消息

1：前台看到重建信令里失步小区（即接入失败小区）PCI及终端的C-RNTI

图 5‑8  后台收到重建立消息

1：后台看到重建信令里失步小区（即接入失败小区）PCI及终端的C-RNTI

5.2.3               问题总结

通过这个现象我们初步怀疑华为站点在实现切换的方式上和我司存在一定差异，可能会将63作为预留Preamble ID，待切换请求中存在未添加邻区的小区时使用，优先满足切换成功率，但由于实现机制不同，导致了我们网络的KPI指标收到比较大的影响