精品文档SN变更成功率TOP小区处理总结Word文件下载.docx
- 文档编号:13376662
- 上传时间:2022-10-10
- 格式:DOCX
- 页数:9
- 大小:692.17KB
精品文档SN变更成功率TOP小区处理总结Word文件下载.docx
《精品文档SN变更成功率TOP小区处理总结Word文件下载.docx》由会员分享,可在线阅读,更多相关《精品文档SN变更成功率TOP小区处理总结Word文件下载.docx(9页珍藏版)》请在冰豆网上搜索。
eCellId
SN变更成功率(Percentage)
SN变更确认次数
SN变更请求次数
SN变更失败次数
6月11日
7077912
1
7077947
5
8.09%
107
1,323
1216
7077950
3
4
20.82%
177
850
673
7077900
7077904
0%
387
14.48%
64
442
378
7077888
13.73%
56
408
352
7077911
10.17%
36
354
318
7077913
2
20.38%
76
373
297
23.12%
89
385
296
7077952
17.65%
42
238
196
表
(一)变更失败TOP小区
二、分析过程
1.SNChange信令流程及指标定义
SNChange信令流程
SNChange信令流程如图
(一),该场景指在MN不变时,仅SN进行变更切换。
图
(一)SN变更信令流程
SN变更成功率指标定义
SN变更成功率=C600600010/C600600009
SN变更成功率(包含Pscell)=(C600690010+C600690011)/(C600690009+C600690011+C600690012+C600690013+C600690014)
C600600009
CU小区级SN变更请求次数
C600690010
CU小区级SN变更确认次数
C600690011
CU小区级SN内部PSCellChange成功次数,测量触发
C600690012
CU小区级SN内部PSCellChange失败次数,F1Context建立失败
C600690013
CU小区级SN内部PSCellChange失败次数,重配完成超时
C600690014
CU小区级SN内部PSCellChange失败次数,其他原因
SN变更成功率影响因素分析
SN变更流程分析
SN变更场景是指MN不变仅SN变更,如图
(二)所示:
图
(二)SNchange的相关网元
按流程分析如下:
如果缺失图中关系1,即5G-5G邻区关系,则UE不会测量目标SgNB的信号,便不会触发SNChange流程。
如果缺失图中关系2,即4G-源5G的邻区或偶联,则SN添加流程便会异常,无法触发后续SNChange。
如果缺失图中关系3,即4G-目标5G的邻区或偶联,则会出现SNChange准备失败,或者目标SgNB断链也触发SNChange准备失败。
如果SNChange准备成功,在后续信令流程上出现异常,便出现SNChange执行失败。
按照SNChange的流程阶段,将影响SNChange成功率因素总结如下:
1)准备阶段失败:
a.MN和目标侧gNB没有配置X2口
b.MN和目标侧gNB的小区没有配置邻区关系(涉及到reserve4开关)
c.MN和目标侧gNB的X2链路断
d.目标gNB掉站,目标gNB功率不会为0
2)执行阶段失败:
a.MN侧配置的gNB的邻区中PCI混淆
b.无线覆盖等其他原因
三、解决措施
3.1通过计数器分析SN变更成功率
根据LTE侧C373760017分析指标
在LTE侧SNChange失败由于未配置邻区或EN-DCX2链路异常可以通过邻区对计数器体现:
C373760017:
目标SgNB的SgNB修改失败次数,由于其他原因
计数器在MN侧上报,上报点为SNCHANGE准备阶段给源侧SN回复SNCHANGECONFIRM之前除目标侧SN添加超时、拒绝外的其他原因导致的失败。
指标上报携带MN侧eNBID、CellID以及SN侧目标gNBID与CellID,其中如果MN和目标gNB配置邻区关系,则SN侧目标gNB的CellID是正确的,如果MN到目标侧gNBSNChange准备失败,则SN侧目标gNB的CellID标识为65535。
这是由于gNBID为SNCHANGEREQ消息中带过来的目标的gNBID,但是SNCELLID必须要等目标侧SN回复SNADDACK后才可拿到,因为SNCHANGEREQ消息中只携带目标侧候选小区列表,LTE侧无法明确具体要添加目标侧NR的小区,具体目标侧SN添加的小区由目标侧SN在SNADDACK消息中带回给LTE侧,因此这个计数器中的SNCELLID为65535无效值,如图(三)所示:
图(三)LTE侧counter指标分析
实际处理TOP时候,可以根据C373760017过滤出TOP邻区对,从数据中可获取MN侧的eNBID和cellID,以及SN侧目标gNBID。
检查MN侧小区是否与SN侧目标gNB的所有小区都添加了邻区关系,如没有则需补充。
需要去计算MN侧eNB小区至SN侧目标gNB三个物理站点的距离,建议:
添加600m以内站点为邻区,若均大于600m则添加距离最近的一个站点为邻区。
根据LTE侧C373760014分析指标
C373760014:
源SgNB发起的SgNB修改失败次数,由于其他原因
此计数器中填写的gNBID和SNCELLID均为SN侧源gNB的信息,上报点为SNCHANGE准备阶段给源侧SN回复SNCHANGECONFIRM之前除目标侧SN添加超时、拒绝外的其他原因导致的失败。
也可以作为参考分析的指标。
根据NR侧C600600009&
C600600010分析指标
C600600009:
CU小区级SN变更请求次数
C600600010:
CU小区级SN变更确认次数
该计数器可汇总到邻区对级,此指标中可显示源侧NR站点ID、小区ID以及目标侧NR站点ID、小区ID,但无法获取MN侧信息,如图(四)所示:
图(四)NR侧SN变更切换对分析
通过抓取出现问题的TOP邻区对的源侧gGB的信令,可以从SCGBCHANGEREQUIRED中找到target_SgNB_ID,同时有MN的IP地址,然后通过gNB和IP对应工参找到目标gNB的ID。
NR侧与LTE侧计数器联动分析
现在无论从4G或5G侧网管提取指标,仅能获取到2个相关站点的信息,其中最为有效的是根据C373760017分析,但又由于缺少目标小区ID,会出现多加的问题,因此后续可能会出现链路或邻区数量过多导致无法新增数据等问题,产生冗余邻区。
因此建议处理top站点时可以根据NR侧与LTE侧计数器联动分析,如图(五);
图(四)NR侧与LTE侧计数器联动分析
首先从LTE侧获取邻区对级指标C373760014与C373760017,通过降序排序C373760014得到问题邻区关系中MN侧eNB小区信息与SN侧源gNB信息,通过C373760017可获取问题邻区关系中MN侧eNB小区信息与目标侧gNB站点信息,缺失目标侧gNB小区ID信息。
其次从NR侧获取邻区对级指标C600600009与C600600010,通过相减可得SN变更失败次数,根据失败次数降序排序可以得到top邻区对中的SN侧源gNB与SN侧目标gNB信息。
联动分析便可以分析得到准确的4G到5G缺失邻区对关系。
举例:
LTE侧指标通过降序排序,TOP1邻区对中MN侧eNB均为445511-54,SN侧源gNB为7077900-3,目标侧gNB站点为7077904,如图(六)
图(六)锚点站筛选
接着从NR侧根据失败次数降序,得到TOP1邻区对中源gNB为7077900,而目标gNB为7077904。
联合上面LTE侧指标可以知道,该问题定位为445511缺失7077804邻区或链路导致SNChange失败。
图(七)NR站变更失败请求
通过5G侧信令跟踪分析SN变更成功率
信令跟踪确定MN站点:
通过5G网管信令跟踪模块,可以跟踪NR侧基站信令,更准确有效的定位MN侧信息,如图(八)):
图(八)STA信令跟踪模块
在信令中找到SGNBCHANGEREFUSE这条消息,查看对应的SCTP链路,如图(九):
图(九)MN侧ip定位
通过SCTPID找到5-4业务侧IP地址,确定MN站。
通过核查MN-源小区;
MN-目标小区外部、邻区、SCTP链路X2流是不是为3,站点是否故障来处理TOP。
四、经验总结
目前网络建设使用使用NSA组网方式,SN变更TOP小区指标处理过程中,需要通过NR侧与LTE侧计数器联动分析和5G侧信令跟踪来确定MN小区。
然后进行具体分析,精准定位问题发生的原因,最大化的提升工作效率。
使用NSA组网方式,SN变更TOP小区指标处理过程中,需要通过NR侧与LTE侧计数器联动分析和5G侧信令跟踪来确定MN小区。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 精品 文档 SN 变更 成功率 TOP 小区 处理 总结