5G SCG添加成功率及变更成功率分析套路
SCG添加准备阶段包括eNodeB向gNodeB发送SCG添加请求到收到gNodeB的SCG添加确认消息;执行阶段从eNodeB在空口下发重配置过程到向gNodeB发送SgNB重配完成消息。
下表给出了eNodeB和gNodeB侧的SCG添加过程指标定义,包括SCG添加准备阶段、执行阶段以及E2E的成功率统计。
-
话统打点介绍
SCG ADD过程包括三种子场景,分别是NSA终端初始建立SCG、NSA用户进行NR站间切换(LTE站点向目标NR站点发起SCG添加过程)和NSA用户进行LTE站间切换场景(LTE目标站点向NR站点发起SCG添加过程),三种场景的信令流程及LTE侧的Counter打点分别如下图所示:(NR侧的类似)
NSA用户初始添加SCG场景
NR站间切换的SCG添加场景
LTE站间切换的SCG添加场景
如图1、2和3中A点所示,当eNodeB向gNodeB发送SgNB Addition Request消息时,L.NsaDc.SgNB.Add.Att累加。
如图1、2和3中B点所示,当eNodeB收到gNodeB发送的SgNB Addition Request Acknowledge消息时,L.NsaDc.SgNB.Add.Req.Ack累加(19B版本为L.Reserve.10)。
如图1、2和3中C点所示,当eNodeB向gNodeB发送SgNB Reconfiguration Complete 消息时,L.NsaDc.SgNB.Add.Succ累加。
-
相关话统列表
列出SCG添加过程较强相关的Counter,详细的话统打点介绍请参考话统帮助。但分析KPI问题,通常需要尽量多地进行关联指标分析,所以在采集Counter时,建议按照2.2节的NSA KPI监控模板采集,后面各节也类似,不再重复强调。
LTE侧SCG添加过程相关话统:
NR侧SCG添加过程相关话统,NR侧有较多失败原因细分Counter。
2、SCG添加指标问题分析套路
-
异常阶段及原因隔离
SCG添加成功率低问题,首先隔离是准备阶段问题、执行阶段问题还是都有问题,都有问题时给出问题比例。
如果是SCG添加准备阶段异常,进一步通过话统打点细分原因值,如下表所示,eNodeB侧只能区分是否NR返回拒绝(现网大部分均为这种场景),NR侧话统则可以进一步细分拒绝的原因,是传输层问题,还是无线层问题。
下表给出了现网中触发对应指标的常见异常场景。比如gNodeB到核心网S1-U传输未配置或故障、gNodeB到eNodeB的X2-U未配置或故障,均会统计到NR侧TNL导致的SCG添加拒绝中,也会统计到LTE侧的添加拒绝Counter中,此外eNodeB侧NR邻区信息部分参数配置错误,也会导致NR返回SCG添加拒绝。
如果是SCG添加执行阶段异常,则因为包括了空口过程以及UE处理过程。常见的异常原因包括空口弱覆盖和干扰、终端兼容性问题等。
不管是SCG添加准备阶段还是执行阶段的异常,通常需要找到目标NR站点。在20A版本中根据DSP X2interface命令可以找到SCG添加准备阶段失败的TOP站点对,即找到TOP NR站点,在19B时可以根据LTE侧的CHR日志找到TOP NR站点,方法参见SCG添加过程的CHR打点一节。NR侧在20A增加了站点对级的SCG添加话统N.X2Interface.SgNB.Add.*,可以用于找到TOP源站。
-
异常子场景隔离
如前所述,SCG添加过程包括了SCG初始添加,NR站间变更、LTE站间切换等三种子场景,异常子场景的隔离有助于细分问题场景。
LTE侧没有直接的子场景话统,仅能根据其它相关指标进行部分场景的关联分析。NR侧对于NR站间变更子场景,有直接的细分Counter,可以用于隔离该场景的指标差异。下表给出了隔离问题子场景的指标和隔离原则。
SCG添加失败常见原因
SCG添加失败分成添加准备失败和添加执行失败,同时根据信令流程以及异常原因值,可以进一步细分失败场景。常见异常原因可以参考如下导图。
各场景详细描述如下 :
一、NR回复SGNB_ADD_REJ或不响应
此类问题一般需要NR侧主导LTE配合定位。根据NR侧细分话统或标口信令中NR侧的拒绝原因,可以做初步的问题隔离和排查。
如果添加拒绝是传输资源导致(从信令或CHR获取),可以检查TOP NR站点的S1-U传输是否故障,或gNodeB到eNodeB的X2-U传输是否故障。也可以通过NR侧的N.NsaDc.DRB.Add.Att.Fail.TNL.S1(20A)、N.NsaDc.DRB.Add.Att.Fail.TNL.X2(20A)隔离是S1故障还是X2故障。
如果NR返回拒绝原因是Cell not Available,则LTE侧排查对应NR邻区的相关配置和NR的实际值是否一致,排除配置问题后转NR侧定位。
NR不响应问题实际情况很少出现,可以结合TOP NR站点的指标进行分析,隔离是哪一边的问题。
二、LTE空口失败
空口失败,表现为eNodeB接收重配置完成消息超时,或终端发起RRC重建,比如下图给出了空口超时的场景。
一种可能是LTE空口弱覆盖或干扰,这种问题可进一步通过CHR或标口来隔离是否RF问题,以及隔离下行还是上行问题,问题隔离的方法同常规LTE问题处理,这里不详细介绍。
另一种可能是终端兼容性问题,如下图,基站下发SCG添加的重配置消息后,终端发送重配置失败原因的RRC重建,则说明终端已经收到SCG添加的重配置消息,但终端判断L3消息非法,所以发起RRC重建,需要联合终端进行定位。
还有一种可能是添加的是非最优NR小区,由于未配置最优NR小区的邻区,在B1测量报告中有多个NR邻区时,会选择添加次优小区,影响添加成功率。这种问题也可能表现为终端先回复RRC重配置完成,再发起SCG FAILURE,所以并不影响SCG添加成功率(取决与终端实现,大部分终端为后者),比如下面这个示例,SCG添加成功后很快发起SCG Failure。
三、NR回复SCG ADD REQ ACK, LTE立刻释放SCG
这种场景属于明显异常,已知有如下故障场景。
场景1:某局点测试过程中发现SgNB添加后很短时间就被基站释放了,携带的释放原因是Transport-resource-unavailable;该场景确认是L-NR X2 IPPATH闪断导致。
场景2:LTE和NR RLC模式不一致导致NR侧回复ACK后,LTE发起释放SCG,携带原因值bearer-option-not-supported。NR侧19B SPC190版本合入了初始建立场景RLC模式的自适应配置,在20A版本合入了变更场景的RLC模式自适应配置,NR侧会按照LTE配置的RLC模式来配置NR侧的,就不会有该问题。
▋SCG Change成功率分析
1、KPI定义和话统打点介绍
-
KPI定义
SCG Change过程,可以分成SCG Change准备阶段(空口下发RRC重配置之前)和SCG Change执行阶段(下发RRC重配置之后)。下表给出了eNodeB和gNodeB侧的SCG 变更过程指标定义。
-
话统打点介绍
LTE侧的SCG change流程和话统打点如下图:
上图中A点,当eNodeB收到gNodeB发送的SgNB Change Required 消息时,L.NsaDc.SCG.Change.Att累加;
上图4-1中B点所示,当eNodeB向gNodeB发送SgNB Change Confirm 消息时,L.NsaDc.SCG.Change.Succ累加。
变更准备阶段异常:
上图中A点所示,当eNodeB收到gNodeB发送的SgNB Change Required消息后,在空口下发RRC重配置消息之前,如果向gNodeB发送SgNB Change Refuse消息时, L.NsaDc.SCG.Change.Failure累加(20A版本)。
-
相关话统列表
下表给出SCG Change过程较强相关的Counter,详细的话统打点介绍请参考话统帮助。
LTE侧SCG变更过程相关话统:
NR侧SCG变更过程相关话统:
2、SCG变更指标问题分析套路
异常阶段及原因隔离
一、从LTE侧角度进行问题隔离
SCG变更成功率低问题,也可以先按阶段隔离是准备阶段还是执行阶段问题。
准备阶段的问题,主要包括两种类型,分别如下上图和下图所示,下图场景是eNodeB在收到源gNodeB站点的变更请求后,直接回复SCG CHANGE REFUSE,这种异常原因一般包含两种:eNodeB到目标NR站点X2口未配置或故障;eNodeB当前处在LTE切换等非稳态流程中。
下图场景是eNodeB向目标NR站点申请资源被拒绝,因而向源NR站点回复拒绝,这种异常和上一节SCG添加失败类似(比如目标NR站点S1-U传输故障等)。
上述两种场景,场景一只会影响SCG变更成功率,不会影响SCG添加成功率,场景二则两种指标都会影响。
下表给出了使用细分话统进行故障隔离的方法,现网中导致SCG变更成功率低的常见原因是传输问题,特别是LTE到目标NR站点X2问题,可以使用话统项L.NsaDc.SCG.Change.Failure.TNL(19B为L.Reserve.2)进行隔离,如果隔离出是传输问题导致失败,则进一步关联分析SCG添加成功率,如果SCG添加成功率正常,则大概率是L到目标NR站点X2传输不可用,即对应上图的第一种场景,如果SCG添加成功率也异常,则很可能是目标NR站点的传输有问题,即对应上图的第二种场景。
如果是L到目标NR站点X2传输不可用,可以通过维测命令DSP SCGADDFAILUREINFO查询找到目标NR站点。同时检查eNodeB和目标gNodeB是否开启X2自建立功能、是否涉及L和NR跨网管场景(需要特殊配置才能支持自建立)、以及是否eNodeB X2满规格场景(需要开启L-NR X2抢占功能)。
对于SCG变更执行阶段的失败,一种原因是空口覆盖、干扰导致,其它可能还包括终端兼容性等问题。
eNodeB 的20B版本在DSP X2INTERFACE维测中也增加了L-NR站点对级的SCG变更维测打点。
二、从NR侧角度进行问题隔离
NR侧对于传输原因和流程冲突原因导致的SCG变更失败,有对应的子话统可以进行问题比例隔离,分别对应话统项N.NsaDc.InterSgNB.PSCell.Change.Fail.Trans 和N.NsaDc.InterSgNB.PSCell.Change.Fail.Conflict。
对于流程冲突引起的失败,还和eNodeB的负载相关,当eNodeB处于高负载时,内部处理时延变大,会增加这类问题概率,另外X2口时延大时,也会增加这类问题概率。
NR侧对于SCG变更场景的SCG添加,有单独的话统打点,打点对应如下流程A/B/C,对于Cluster分析,可以利用1/2/A/B/C这五个话统,进行子流程的隔离,界定失败发生在哪个阶段。
2、SCG Change成功率低详细分析
SCG Change过程异常的常见原因可以参考如下导图。
1、eNodeB到目标NR站点无X2链路或传输故障
这个是现网最常见的一种问题场景,eNodeB直接给源NR站点返回SCG Change Refuse,且携带原因为传输不可用。
2、eNodeB侧处于切换流程等非稳态
这种场景虽然概率不太高,但目前没有好的优化办法。如下图所示,LTE侧在发起切换的同时,收到了NR站点的SCG change请求,直接发起Change Refuse,携带原因值为message not compatible with receiver state。
而且在eNodeB侧CPU高、内部处理时延变大场景,以及X2时延大场景,问题概率会升高。
还有一种场景,前一次SCG变更还未真正结束,比如由于eNodeB开启了流量上报开关,而gNodeB未开启,eNodeB还在等待源gNodeB的上一次SCG变更的Secondary RAT Data Volume Report消息,此刻收到了目标gNodeB的第二次SCG变更请求,回复Refuse。
这种问题属于LTE和NR侧的流量上报开关不一致导致,需要将如下两个参数设置一致。
3、NR目标站点返回SCG ADD拒绝,eNodeB给源站返回Refuse。
这种异常场景是NR目标站点返回SCG ADD拒绝,异常原因和SCG添加过程类似,请参考SCG添加过程异常详细分析,现网常见的原因是目标NR站点的传输问题。
4、SCG变更空口失败
如下图所示,SCG变更过程中空口已下发RRC重配置过程,但是未收到重配置完成该消息,超时后网络侧发起回退。
这种问题可以先排除是否存在终端兼容性问题,然后判断是否空口弱覆盖、干扰导致。
后台学习装备
1.
2.
3.
入门学习装备
1.
2.
3.
4.
限时免费装备
1.
2.
3.
5G核心技术交流学习【扫码进群】【扫码回复】:‘ 5G群 ’
华为HCS5GRF工程师资格认证【扫码回复】:‘5G认证‘