快捷搜索:  www.ymwears.cn  as  5g55  电子  5G

SCG添加成功率及变更成功率分析套路

SCG添加成功率指标分析

1、KPI定义和话统打点介绍

  • KPI定义

如下图所示,SCG添加过程,可以分成SCG添加准备阶段和SCG添加执行阶段。准备阶段/执行阶段的定义与切换过程类似,即将空口下发重配置消息之前的过程定义为准备阶段,之后定义为执行阶段,后面介绍的其它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(19BL.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过程异常的常见原因可以参考如下导图。

1eNodeB到目标NR站点无X2链路或传输故障

这个是现网最常见的一种问题场景,eNodeB直接给源NR站点返回SCG Change Refuse,且携带原因为传输不可用。

2eNodeB侧处于切换流程等非稳态

这种场景虽然概率不太高,但目前没有好的优化办法。如下图所示,LTE侧在发起切换的同时,收到了NR站点的SCG change请求,直接发起Change Refuse,携带原因值为message not compatible with receiver state

而且在eNodeBCPU高、内部处理时延变大场景,以及X2时延大场景,问题概率会升高。

还有一种场景,前一次SCG变更还未真正结束,比如由于eNodeB开启了流量上报开关,而gNodeB未开启,eNodeB还在等待源gNodeB的上一次SCG变更的Secondary RAT Data Volume Report消息,此刻收到了目标gNodeB的第二次SCG变更请求,回复Refuse

这种问题属于LTENR侧的流量上报开关不一致导致,需要将如下两个参数设置一致。

3NR目标站点返回SCG ADD拒绝,eNodeB给源站返回Refuse

这种异常场景是NR目标站点返回SCG ADD拒绝,异常原因和SCG添加过程类似,请参考SCG添加过程异常详细分析,现网常见的原因是目标NR站点的传输问题。

4SCG变更空口失败

如下图所示,SCG变更过程中空口已下发RRC重配置过程,但是未收到重配置完成该消息,超时后网络侧发起回退。

这种问题可以先排除是否存在终端兼容性问题,然后判断是否空口弱覆盖、干扰导致。

 

参与 5G 热评:

    说点什么吧
    • 全部评论(0
      还没有评论,快来抢沙发吧!

您可能还会对下面的文章感兴趣: