【问题描述】

掉话率是5G KPI提升的一个关键指标，也是5G优化的一个难点，本案例从5G网络（SGNB_REL_REQUIRED）和4G网络（SGNB_REL_REQ）两端入手，通过5G下行RLC达到最大重传次数、5G非空口原因释放、非空口原因触发LTE释放5G、UE给LTE发送SCG Fail Ind四大维度进行分析来优化5G掉话问题，并且根据现网的实际应用结果提供了案例。

两端四维法：

【问题分析】

一、掉话原理

NSA网络区分掉话为2大类，一类是5G基站主动发起的释放；从基站侧看到的信令则是如下所示：

图1：5G基站侧发起释放导致的掉话

第二类LTE主动发起的异常释放，这种场景主要有是UE检侧到某种异常后主动申请释放。SCGFailureInformationNR消息里会携带原因值，例如下面示例表示上行RLC达到最大重传次数。

从基站侧看到的信令如下所示：UU口收到RRC_SCG_FAIL_INFO_NR，然后4G在X2口给5G发SGNB_REL_REQ。

图2：LTE发起释放的掉话

二、掉话KPI定义

掉话KPI的定义，可以从流程和承载的方式来定义，也可以从异常释放的发起方来定义，总的定义如下：

三、问题隔离定界

发生掉话问题时，如果跟踪了标口信令，第一时间使用标口信令就可以完成掉话原因的初步隔离定界，方法如下：

Step1打开掉话时刻点的X2信令，判断是LTE释放用户还是5G释放用户。LTE通过SGNB_REL_REQ消息释放用户，并会携带释放用户的原因值：

SGNB_REL_REQ常见原因值场景如下：

(1) failure in radio interface：UE上报RRC_SCG_FAIL消息给LTE

(2) transport resource unavailable：传输故障

(3) unspecified：LTE用户释放触发的5G释放或核心网eRAB Mod失败

(4) rrm purpose：LTE切换触发的5G SCG释放或UE重建

5G通过SGNB_REL_REQUIRED释放用户，并会携带释放用户的原因值。

(1) no radio resource available：小区故障或License数受限

(3) cell not available：小区去激活或小区故障

(4) scg mobility：5G A2上报触发UE释放

(5) failure in the radio interface procedure：基站侧接入定时器超时没收到UE上报的Msg3

(6) radio connection with UE lost：下行RLC最大重传掉话

(7) user inactivity：不活动定时器超时释放

Step2根据Step1的发起释放的来源和释放原因，分场景进一步分析。

1. SGNB_REL_REQ：

（1）failure in radio interface：查看LTE Uu口，LTE Uu口会有一条RRC_SCG_FAIL消息，RRC_SCG_FAIL会携带失败的原因值。

常见的原因值对应场景：

Rlc-MaxNumRetx：上行RLC最大重传

Access Failure：接入失败

（2）transport resource unavailable：查看LTE 是否有相关链路的传输告警。

（3）unspecified：查看LTE S1标口信令，释放SCG释放时刻是否有LTE用户释放的记录，如果有，则继续定位LTE用户释放原因。

查看LTE S1标口信令，释放SCG释放时刻是否有eRab Mod失败的记录，eRab Mod失败通过核心网下发的S1AP_ERAB_MOD_CONF消息中携带Cause信元来判断，如果携带该信元，说明eRab Mod失败，出现eRab Mod失败在需要联合核心网和LTE继续定位。

（4）RRM Purpose：正常释放

2. SGNB_REL_REQUIRED：

(1) no radio resource available：查看对应时刻是否有小区相关告警

查看小区用户数License是否足够

(2) transport resource unavailable：查看5G是否有相关链路（X2、S1-U）的传输告警

(3) cell not available：查看对应时刻是否有小区相关告警或者小区去激活操作

(4) scg mobility：查看X2口是否有携带A2事件的RRC Container发送到5G，A2门限设置是否合理，如果A2门限设置合理，则该释放为正常释放

(5) failure in the radio interface procedure：继续定位随机接入失败问题

(6) radio connection with UE lost：按照本指导书下行RLC最大重传掉话定位套路继续定位

(7) user inactivity：不活动定时器超时释放，为正常释放

问题案例

案例1：状态报告调度不及时导致上行RLC最大重传掉话

接入2个用户后进行下行灌包，再接入一个用户进行上行灌包能够大概率出现最后一个用户一段时间后出现RLC LINK FAIL。

上行RLC最大重传掉话是UE侧判断的，因此需要抓取TUE TTI跟踪，分析TUE掉话时刻，并将基站跟踪中TUE掉话后的数据去除（此时基站虽然还在调度用户，但是TUE的活动已经停止）。

TUE侧TTI跟踪显示TUE掉话时刻为470帧，掉话前UE长时间没收到基站反馈的RLC状态报告：

基站侧333跟踪（RLC上行接收RLC PDU的跟踪）显示直到466帧基站都收到了UE发送的RLC PDU：

下一步则需要看基站是否正确下发状态报告。查看基站侧334跟踪（基站RLC发送状态报告的跟踪），发现334跟踪里没有该用户（SusrId=196）的状态报告下发：

说明此次用户掉话的原因是基站不发送状态报告导致的UE上行RLC最大重传掉话。继续分析基站状态报告不发送的原因，首先查看335跟踪（RLC向SUSR模块推送数据量的跟踪），发现335跟踪显示RLC已经将待传数据量发送到了下行调度模块：

说明问题为下行调度模块收到了数据量但是未调度该用户。下行调度用户的顺序为：将用户加到调度链->用户空分分组->调度链按用户优先级排序->按优先级从高到低调度用户。因此，首先检查该问题用户是否加到了下行调度链当中。从基站侧507跟踪（下行空分分组跟踪）看到，在每帧调度链初始时，SusrId=196的用户都是优先级最高，排在最前，但是调度链重整后，将该用户排序到了最后，并且每个Slot都是这样，至此问题定位，是下行调度重整调度链过程中用户排序错误导致问题发生。

【问题结论】

该问题是由于多用户排序存在异常，高优先级用户排序到最后，进而导致下行状态报告无法及时发送从而导致UE掉话。

案例2：NSA接入后几分钟,在X2口看到每隔10分钟就会重复释放该用户

【问题现象】

NSA接入后几分钟,在X2口看到每隔10分钟就会重复释放该用户，现象如下：

1.从X2跟踪看到，用户callid为2的用户在17:59:02开始接入，并且收到重配置完成消息完成接入，在后续每隔十分钟开始发起释放请求同一个用户。

2.通过代码和日志，每十分钟核查一次GTPU，由于和测试确认，用户名配置有问题会导致GTPU核查失败，会发起释放用户。

3.可以看到用户没有释放导致周期性核查不断再尝试释放用户，代码中在释放用户前启动了5秒定时器，发起释放后会启动20秒定时器等待释放响应，如果超时后会自行释放用户，由于测试在LTE侧是模拟系统没有回响应，由于5秒定时器先超时导致用户无法在超时后再去释放，再去核查GTPU时再去释放，这样会循环释放用户。

GTPU异常释放用户时启动了5s定时器，NSA用户释放时没有收到MeNB的释放请求，20s超时才会内部释放，此时5s定时器已经超时，导致用户释放不了。