不同厂家的LTE切换算法差异性分析

彭恋恋

1 引言

对于优化工作来说，移动用户的体验与切换成功率密切相关，而准确的数据是保障优化工作正常进行的关键。基于对3GPP协议、用户体验等的不同理解，不同厂家的设备，采集的数据及指标算法各有特色。以某市联通为例，目前其设备厂商有两家。两个设备厂商所采集的数据被用于优化中的日常监控及考核，因此，其所表征的用户体验是否一致，数据恶化所反馈的问题是否相同，考核的门限对两家是否公平等，都需要优化工作对所涉及的重要数据进行深入分析及研究。本文基于某市联通现网情况，以体现覆盖的切换指标为例，分析了其在两个设备厂家的算法差异及影响，并针对该部分差异，提出相应的优化建议。

2 切换算法

LTE基本为同频组网，因此在移动过程中，小区与小区间的切换大都属于同频切换。而也正是因为如此，物理边缘上的干扰易恶化，而加上覆盖易重叠，使得该部分用户的体验相对较差，故对切换的优化势在必行。为了更精准地完成切换的优化，本节对两个设备厂家的切换算法进行了深入研究。而异频在信令层面的流程基本与同频类似，因此不做讨论。

2.1 同频切换的基本定义

当用户处于连接态的移动过程中，与其连接的小区将发生变化，为保证业务的不中断，终端会选择质量最好小区执行切换操作。目前，LTE网络主要有基于网络覆盖、负荷、业务等的硬切换。切换的目标小区通过测量报告（MR）筛选得到，MR分为周期性测量与事件性测量，切换的测量属于后者。

最常见的事件A3是同频切换的判决条件[1]。当测量满足该条件时，终端则会通过S1口或X2口发出切换请求。其中基站间的切换是通过X2口完成的。对基于A3事件的切换，3GPP协议TS 36.331规定如下[2]：

图1 基站间切换信令流程

其中，n代表目标邻区，p代表主服务小区。若测量数据为RSRP，由式(1)可知，目标邻区与主服务小区之间的强度差值由6个参数（偏置、迟滞等）决定。这些参数会由优化人员根据现网实际话务模型及网络情况进行调整，以达到更加平滑的切换效果，避免乒乓切换等问题。

以基站间切换为例，满足以上条件后，网络按图1所示流程，发起切换。

目标小区收到切换请求后，进行资源评估后回复确认，eNB向UE发送携带mobilityControlInfo的“RRC连接重配置”消息，指示小区间同频切换出执行请求。eNB收到MME发送的“UE上下文释放命令”消息[3]或目标eNB发送的“UE上下文释放”消息[4]，指示同频切换出成功。因此，同频切换的基本定义为：

各厂家根据基本定义及协议规定的统计点，结合自身特色，完成对应厂家指标的数据采集及实现。下文将以某市联通的厂家A和厂家B为例具体分析。

2.2 厂家算法实现

小区级KPI指标数据的统计在硬件实现上以基站为单位，在不同的信令点布置不同的计数器进行打点。根据协议规定及运营商的各类规范，多个计数器组合运算，形成指标。协议规定，同频切换的请求次数，以源站点向UE发送的携带mobility Control Info的RRC连接重配置消息为统计点，基站内切换的成功次数以目标基站收到UE发送对应的RRC连接重配置完成为统计点，基站间切换的成功次数则以目标eNB发送的“UE上下文释放”消息为统计点。根据以上描述，厂家算法的实现如下：

（1）厂家A公式：

式(3)中采用了厂家原始的英文counter名，pm表示性能，H表示切换，Exe表示执行（或者激活），IntraF表示同频，Att表示请求（或者尝试）。故pmHoExeSucccLteIntraF为LTE同频切换成功次数，pmHoExeAttLteIntraF为LTE同频切换请求执行次数。基站间的切换部分信令流程图如图2所示。式(2)中的计数器统计点在图中都有呈现。可以看到，其计数规则与3GPP协议规定相符，且切换的成功次数和请求次数都有更小粒度的分QCI统计，能为优化分析提供了更有针对性的数据。

（2）厂家B公式如式(4)所示，其中，L代表LTE网络，HHO表示切换，IntraeNB及IntereNB分别表示基站内和基站间，IntraFreq表示同频，ExecAttOut表示切换尝试（或者请求），ReEst2Src表示重建回源小区。故L.HHO.IntraeNB.IntraFreq(IntereNB).ExecSuccOut(ExeAttOut)为基站内（基站间）同频切换成功（请求）次数，L.HHO.IntraeNB(IntereNB).IntraFreq.Succ.ReEst2Src为基站内（基站间）切换中成功重建回源小区的次数。对于统计点，从信令流程图看厂家B与厂家A完全一致，不再赘述。

2.3 算法差异

单纯从算法公式上看，相对于厂家A，厂家B的切换公式将基站间及基站内的切换统计分开了，特别需要注意的是，它还减去了基站间和基站内切换失败但通过重建回到源小区的次数。该操作也说明，切换的打点计算存在切换内重建计算的区分。而这部分在厂家A的公式中并未体现，也无法直接判断其是否包含，需从信令层面进行打点解析验证。

图2 基站间切换counter统计流程

图3 同频切换成功率分厂家数据统计图（15点）

在信令解析前，从数据层面进行差异验证。根据以上公式从后台提取相关数据，对数据进行了分析处理。目前，全网小区的切换成功率都是根据以上公式计算而来。

本文从现网数据着手，进行了初步分析，统计了连续两周每日15点的全网同频切换成功率数据，结果如图3所示。

由图3可知，厂家数据没有交叠，存在明显的平行差。厂家B的切换成功率平均比厂家A大2.5%左右。从概率角度出发，在数据量足够大的情况下初步推断，两者算法上存在一定的差异。且从公式表达来看，厂家A在重建部分的考虑是否与厂家B一致不得而知。为了解决以上疑问，下文从信令实例等方面进行了解析验证，并分析了其影响。

3 差异解析及其影响分析

3.1 差异解析

指标counter的打点，底层原理上是以特定的信令为计算点来实现的，故本文解析了部分原始信令文件，从打点时间及打点信令详解分析算法的细节。

以15点的厂家A厂家信令文件为例进行解析（时间节点需往后延8小时）：用logtool工具解析了15点到15点15分的文件，然后以ueRef为标识，筛取了其中一个用户的信令。在同一个业务过程中，该标识不会变化。解析出的文件结果如图4所示，解析结果按时间顺序以一个个事件（event）为单位呈现。

信令一共64行，描述了该UE从RRC接入到切换到重建的过程。从第44行开始，UE测量邻区并请求通过X2口进行切换，切换成功响应，在35 s的时候，UE发起RRC重配置的请求，但在38 s前，并未收到重配置完成的消息。

图4 信令文件解析结果

图5 INTERNAL_PROC_HO_EXEC_X2_OUT内容详解

UE开始尝试进行重建恢复连接。图4中的INTERNAL_PROC_HO_EXEC_X2_OUT事件内容显示，重建切换执行失败。因此，由该实例可知，厂家A的重建发生在切换后，不计入切换成功次数。且从图3的时间点可知，重建发生在现网切换定时器T304规定的时间（2 000 ms）后，即切换失败且定时器T304超时后，UE才会通过重建连接到小区。

解析厂家B信令的流程一致，根据解析结果，结合counter定义可知，UE一旦切换失败，在不考虑T304是否超时的情况下就会进行重建。且重建成功计入切换成功次数中，故在公式中减去了重建到源小区的次数。但由于重建到目标小区的消息中，没有携带源小区的切换信息，故无法减去该部分数据。

3.2 差异影响分析

日常的优化及考核，切换是重点指标之一。根据上文所述，两个厂家在算法上有一定的差异，表现在重建的时间点和统计上。为了分析该差异的影响，我们统计了某天内厂家A的重建在切换失败中所占的比例，如表1所示。

从表1可知，占比最大的切换失败原因值为RRC的重建。由于该部分的重建与其他原因引起的重建无法区分，因此我们考虑全网的RRC重建成功率，目前大约80%左右。厂家A的切换指标中加上这一部分的成功次数，指标将有一定的提升。由于厂家B的公式中减去了重建回源小区部分，故我们解析了信令文件，手动统计了所有切换失败导致重建成功次数中，重建回目标小区和重建到源小区的比例如图6所示：

表1 切换失败原因值统计

图6 重建类型占比

由图6可知，在厂家A的切换过程中，目标小区重建的比例达到38.83%。因此，这部分数据的影响对指标的影响不容小觑。为了更直观地看看这部分数据在日常监控中的影响，本文选取了一个小区的数据进行分析。表2是小区A连续三天的切换指标值：

表2 同频切换指标修正案例

在数据修正前，按照目前公式计算，小区A的切换成功率指标都在95%以下。小区A在该时间点前，因为弱覆盖，在连续一周切换成功率低于80%的情况下，被定义为差小区。目前的指标值是在优化工作完成后的显示值，但差小区处理完成的标准为95%以上。而数据修正后，即加上重建成功部分，指标值得到了很大的改善。

由此可见，算法的差异会带来优化工作效率的降低，在厂家未解决产品修正的情况下，建议区分考核。而在优化过程中，对切换指标，建议结合RRC重建次数及其成功率指标综合考虑，提高工作的针对性。当然，对于优化来说，算法的差异不止于统计细节，还有参数，如T304的设置、切换迟滞及频偏的设置等，在此不一一描述。总之，多厂家覆盖的区域，深究厂家间数据算法的差异，保障数据体现的一致性，能有效地提高优化效率，使其更具有针对性，从而更接近用户体验。

4 结束语

本文从理论上研究分析了两个厂家在目前网络内使用的同频切换公式及其统计机制，并通过解析实例信令证明了两者之间的差异，证明了其在切换后重建的统计差别。在此理论基础上，以差小区为例，测试验证了这种统计差异在优化监控考核中的影响。因此，在以后的日常监控及优化处理过程中，应结合用户对应厂家区域，充分考虑其算法统计机制及其他因素在其中的影响。