友情提示:本文共有 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漏配关系》,同时在此感谢原作者。