友情提示：本文共有 1868 个字，阅读大概需要 4 分钟。
【问题分析】
随着疫情发展和各企事业单位的复工和新建站点开通后，福州大学生创业园区SN Change成功率出现劣化，通过精确查找LTE-NR漏配关系和传输配置核查三轮的优化后SN Change指标提升至95%以上，如下图所示：
根据指标判定SN Change失败为NR站点间SN Change失败，即LTE锚点小区不变，NR小区站点间切换；详细流程如下图所示：
图1 SN变更流程
采样点1：当MN收到SN发送的SgNB Change Required消息时，进行采样统计
采样点2：当MN向NR终端下发空口重配消息RRC Connection Reconfiguration消息时，进行采样统计。
采样点3：当MN向源SN发送UE Context Release消息时，进行采样统计
由上图可知，SN change成功配置必须满足以下条件
1. 2个NR小区必须配置互配邻接关系；
2. LTE锚点小区与2个NR小区互配为邻区，且LTE锚点站与2个NR小区所在NR站点互配EN-DC X2口和SCTP链路；
3. 锚点小区和NR小区状态正常，EN-DC X2链路正常；
劣化根因定位：
5G侧指标很少，无法进行根因定位，如下表所示：
4G侧锚点小区SN变更指标完整，可以进行根因定位，如下表所示：
失败原因TOP分析：源SgNB发起的SgNB修改根因
根据第三轮优化指标分析，由上图可知源SgNB Change失败95%以上原因为“源SgNB发起的SgNB修改失败次数，由于其他原因”；
根据第三轮优化指标分析，由上图可知目标SgNB Change失败95%以上原因为“目标SgNB发起的SgNB修改失败次数，由于其他原因”；
针对源NR小区和目标NR小区的SN Change失败原因均为“由于其他原因”，导致“由于其他原因”失败根因为目标侧未在SN Change准备阶段失败，未向目标NR站点发送SN 添加请求，如下图所示：
未向目标SgNB发送SN 添加请求原因如下：
1．邻区配置问题包括：4->5邻区关系漏配，邻区定义PCI,频点，基站号配置错误等；
2．LTE锚点->NR X2链路配置不正确，故障和LTE锚点->目标NR X2链路未配置；
3．检查4->5邻区里存在同频同PCI的情况；
4．配置SCTP及X2接口，SCTP远端端口号建议配置为36998，远端地址配置为5G业务IP地址，出入流个数必须大于等于3，SCTP链路类型配置为“EN-DC X2[2]”；
根据上述原因，全网进行如下优化动作：
1. 核查全网LTE锚点小区外部NR邻区定义和同PCI邻区；
核查NR邻区定义字段：NR基站ID，NR小区ID，PCI，PLMN，带宽，SCS子载波，SSB中心频点，PointA频点；
2 核查全网由于LTE锚点小区与SN Change目标小区漏配问题；
随着5G NSA用户增多，导致LTE锚点小区域NR小区间连接关系需求成倍增长，一个LTE锚点小区避免由于NR邻区漏配问题导致的SN chenge失败需要添加的NR邻接关系数=LTE锚点小区连接关系数*存在邻接关系NR小区的NR邻接关系数-重复的LTE-NR邻接关系。以现网单个锚点小区平均邻接关系24条，NR平均邻接关系26条，去重复前LTE-NR邻接关系需求为24*26=624条，若重复的LTE-NR邻接关系占85%，仍需要配置93.6条。故需要一种精确的方法解决LTE-NR邻区漏配问题。
现有LTE-NR邻接关系指标将漏配的SN Change目标小区显示为MCC:NCC:基站ID：65535无法判定目标小区ID。简单将所将漏配NR基站下所有小区均配置邻接关系，虽然可以提升SN Change成功率，但是增加冗余LTE-NR邻接关系导致LTE-NR邻区超过最大限制问题。
下图为LTE-NR邻接关系指标：
“C373760017:目标SgNB的SgNB修改失败次数，由于其他原因”对应的“邻接关系”列中SN Change目标NR小区信息为460:00:2101433:65535 ，无法判断NR小区ID。
改进措施：
根据相同时间内LTE-NR侧邻接关系指标关联NR邻接关系指标进行分析，改进原有添加邻区方法，减少配置冗余LTE-NR邻接关系；
步骤一：
查询15分钟颗粒度，LTE-NR邻接关系指标，逻辑筛选“C373760014:源SgNB发起的SgNB修改失败次数，由于其他原因”>0或“C373760017:目标SgNB的SgNB修改失败次数，由于其他原因”<0的指标。筛选SN Change失败的邻接关系；
步骤二：
将LTE-NR侧邻接关系原始指标分割为2个表，表1为LTEvsSNR,为原始指标中邻接关系中CellID不为65535的小区记录。
表2为LTEvsTNR,为原始指标中邻接关系中CellID为65535的小区记录，处理为下表
步骤三：
将步骤二中处理好的2个表格导入数据库软件，使用SQL命令生成LTEvsSNR_TNR中间表，命令如下：
Select {LTEvsSNR}.开始时间,{LTEvsSNR}.eNodeB,{LTEvsSNR}.小区,gNBId,cellId,{LTEvsTNR}.开始时间,{LTEvsTNR}.eNodeB,{LTEvsTNR}.小区,eNodebId From {LTEvsSNR} Inner JOIN {LTEvsTNR} ON {LTEvsTNR}.[开始时间] = {LTEvsSNR}.[开始时间] And {LTEvsTNR}.[eNodeB] = {LTEvsSNR}.[eNodeB] And {LTEvsTNR}.[小区] = {LTEvsSNR}.[小区]
处理后LTEvsSNR_TNR中间表为15分钟颗粒度内LTE锚点小区-源SgNB小区-目标SgNB站点间关系表，可能会出现错误关系，需要后续步骤解决.表格中eNodebId为原始表中“邻接关系”列中小区ID为65535的gNB ID。
步骤四：
查询15分钟颗粒度，LTE-NR邻接关系指标，逻辑筛选SN变更成功率(Percentage)<100且C600600009：SN变更请求次数〉0。筛选SN Change失败的邻接关系。
其中eNodebId为Sn Change目标NR站点gNBId,eCellID为目标NR小区ID。
注意：由于4/5G网管开始时间格式不一致，需要处理为格式一致，否则后续步骤SQL命令无法执行。
步骤五：
使用SQL命令将LTEvsSNR_TNR中间表与NR邻接关系原始指标关联分析，剔除步骤三中冗余的LTE锚点小区-源NR小区-目标NR站点间记录，命令如下所示：
Select {LTEvsSNR_TNR}.开始时间,eNodeB,小区,{LTEvsSNR_TNR}.gNBId,{LTEvsSNR_TNR}.cellId,{LTEvsSNR_TNR}.eNodebId,{NRvsNR}.开始时间,{NRvsNR}.gNBId,{NRvsNR}.cellId,{NRvsNR}.eNodebId,eCellId From {LTEvsSNR_TNR} Inner JOIN {NRvsNR} ON {NRvsNR}.
[开始时间] = {LTEvsSNR_TNR}.[开始时间] And {NRvsNR}.[gNBId] = {LTEvsSNR_TNR}.[gNBId] And {NRvsNR}.[cellId] = {LTEvsSNR_TNR}.[cellId] And {NRvsNR}.[eNodebId] = {LTEvsSNR_TNR}.[eNodebId]
由上表可得存在邻区漏配的LTE小区与目标NR小区信息，如上图可知锚点小区156084-68与2101433-5小区存在漏配可能，须与现网邻区关系核对多漏配则需要添加邻区关系。
根据3-14日00:00-17:30分指标，通过步骤1~5可以准确地查找LTE锚点小区与Sn Change目标小区漏配邻接关系，较原有简单添加方法：LTE-NR邻接关系指标“邻接关系”列中包含65535的目标NR站点所有NR小区添加邻区，精确添加较简单添加减少LTE-NR邻接关系量60%以上。
步骤六：
通过4-5邻区添加核查参数工具中Sctp核查模块核查全网4-5G间ENDC X2口问题，核查问题如下：
1）4G添加了5G邻区但是4G没有添加对应5G站点sctp；
2）4G添加了5G邻区但是5G没有添加对应4G站点sctp；
3）4G添加了5G站点sctp但是没有X2AP引用；
4）5G添加了4G站点sctp但是没有X2AP引用；
5）引用的SCTP存在一个SCTP应用多个IP地址情况核查
第一/二轮优化中使用步骤1~5精确添加LTE锚点小区与Sn Change目标小区连接关系，SN Change指标提升至80%，三轮优化中使用步骤1~5精确添加LTE锚点小区与Sn Change目标小区连接关系，同时核查4-5G间SCTP链路问题，优化后指标提至95%
本文如果对你有帮助，请点赞收藏《利用SQL语句精确查找LTE-NR漏配关系》，同时在此感谢原作者。
