5G SA 掉线优化指导书|rrc|信令|定时器|接入层

源自：前景理论

1、掉线率定义

1.1 掉线率定义

中移对SA掉线率的定义如下，从下面定义可以看出，目前的定义不仅仅是空口信令流程上的失败，中移规定在一定时间内速率为0，也被记为掉线。

SA 掉线率=掉线次数/成功完成连接建立次数× 100%

分子定义：测试任务还在运行中且已经接收到了一定数据的情况下，超过 60s 没有任何数据传输即判断掉线。

分母定义：RRC IDLE状态的终端通过随机接入-RRC连接建立-PDU Session建立空口过程完成与无线网络的连接并开始上下行数据传输，视作成功完成连接建立。

1.2、前台掉线信令表现

本节介绍一下在前台测试中遇到的掉线相关信令流程。前台测试中掉线信令表现主要有如下4种：

1、弱覆盖/SINR导致终端检测到无线链路失败，发起重建立但重建立无响应或失败；

2、在RRC连接态下，终端收到了网络的异常释放导致掉话；

3、在切换执行过程中失败导致掉话；

4、RRC重配阶段（如建立/修改/释放 RB/测量）同步失败导致掉话。

下面结合前台信令给出每个阶段掉话的具体表现。

1）覆盖或 SINR 较差，终端检测到无线链路失败，发起重建立且重建立无响应或失败。

如下图所示，终端发送MR后一直未收到切换命令，源小区信号较差，终端检测到RLF，发起了重建立请求，但未收到 RRCReestablishment，重建立失败。终端读取系统消息选择小区驻留并发起注册流程。若重建立过程成功，则掉话被挽救不算做掉话。（此处案例并非真正弱覆盖，是由于切换不了导致终端一直在覆盖较差的小区从而掉话）

信号较差发起RRC重建立，重建失败导致掉话

如下图所示，终端检测到RLF，发起重建立流程且重建立成功，业务恢复。

发起重建立，重建立成功

2） RRC 连接状态下终端收到网络非正常释放；

如下图所示，在RRC连接态下终端未检测到RLF，但网络侧下发了 RRC Release消息，释放了RRC连接，前台信令看到 RRC 释放未携带原因，只能从流程上进行判断。

（可以结合后台信令确认问题点，该案例是切换准备失败，AMF发送了上下文释放，基站发送RRC释放）

RRC 连接状态下收到网络异常释放

3）切换阶段掉话

在切换执行阶段，UE检测到RLF，发起RRC重建立流程，上报重建立原因为handover failure，但重建立失败导致掉话。如下图所示，在 5->4切换执行过程中，UE检测到RLF，发起了重建立，原因为handover failure，但是重建立无响应，终端重新搜索小区驻留并发起了注册流程。

切换阶段掉话

4）配置修改阶段失败导致掉话

在RRC连接状态下，若需要建立、修改、释放RB或测控信息，则需要通过RRC重配命令将配置下发给终端，终端收到重配命令后启动 T304，若T304超时则发起重建立流程，如果重建立无响应或重建立失败，则会导致掉话。

1.3、无线链路失败流程（RLF）介绍

当终端检测到无线链路失败且满足重建立条件时，则终端发起重建立流程。因此，在重建立发起前，终端会检测无线链路失败情况。协议38.331对RLF进行了详细介绍，较多掉话是由于终端检测到 RLF 失败发起重建立且重建立失败导致，本节对RLF触发机制进行简要介绍。

1.3.1、无线链路失败过程中的常量及定时器

1、T300：UE等待 RRC 连接响应的定时器长度。

当UE发送RRC连接请求消息后将启动定时器T300。在定时器超时前，如果以下事件发生，则定时器停止。

1）UE收到RRCConnectionSetup或RRCConnectionReject；

2）触发Cell-reselection过程；

3）NAS层终止RRC connection establishment过程。

如果定时器超时，则 UE 触发以下操作。

1）重置MAC层

2）释放MAC层配置

3）重置所有已建立RBs（Radio Bears）的RLC实体，通知高层 RRC connection establishment失败。

2、T301：UE等待RRC重建响应的定时器长度。

当UE发送RRC连接重建请求消息时，打开T301定时器。当UE收到 RRC连接重建消息或RRC连接重建拒绝消息后，停止T301定时器；当定时器超时，UE进入IDLE态。

3、T304：UE随机接入到相关 SpCell 定时器长度。

当UE收到携带reconfigurationWithSync的RRC重配消息后将启动定时器T304。

在定时器超时前，如果UE随机接入到相关SpCell则定时器停止；对于SCG而言，如果SCG释放则该定时器停止。

4、T311：UE 监测到无线链路失败后转入idle状态的定时器长度。

当UE发起初始RRC连接重建时，打开T311定时器；当UE重新选择到了一个合适的NR小区或者E-UTRAN小区后，停止T311定时器；当定时器超时，UE进入IDLE态。

5、T319：UE等待RRC连接恢复响应定时器长度。

UE 将在发送 RRC恢复请求时打开T319定时器，在收到RRC恢复响应、RRC建立、带延迟配置的RRC释放、RRC连接拒绝、小区重选或高层取消连接建立时停止该定时器；当定时器超时，UE进入 IDLE态，并且RRC释放原因为RRC恢复失败。

6、N310：UE接收下行失步指示的最大个数。

该参数用于指示UE检测下行失步时，连续接收失步指示的最大个数。

7、T310：UE 监测无线链路失败的定时器长度。

当UE监测主服务小区物理层出现问题，即连续收到N310个out-of-sync指示时，启动T310定时器；在接收到N311 个in-sync指示, 或者收到该小区组带reconfigurationWithSync 信元的 RRC 重配，或者发起RRC连接重建流程时，停止定时器。当定时器超时时，如果T310运行在 MCG(Master Cell Group)，在没有激活安全模式时进入IDLE态，否则发起RRC连接重建流程。

8、N311：UE接收下行同步指示的最大个数。

该参数用于指示UE检测下行同步时，连续接收 in-sync指示的最大个数。

1.3.2连接态下物理层失步/同步检测过程

1）在T300，T301，T304，T311，T319 定时器均未启动，若 UE 高层收到N310个连续的“out-of-sync”指示，UE将启动T310定时器；

2）在T310定时器运行期间，如果UE从底层收到了N311个连续“in-sync” 指示，则停止T310定时器。

1.3.3、RLF检测过程

当出现以下情况之一则表示UE出现RLF：

1）T310定时器超时

2）在T300，T301，T304，T311 ，T319定时器未启动期间出现来自MAC层的随机接入问题

3）RLC层达到最大重传次数

在检测到RLF后，

若接入层（AS）的安全模式未激活，则释放终端，进入 IDLE态，释放原因为other；
若接入层（AS）的安全模式激活，但SRB2和DRB未建立，则终端进入IDLE态，释放原因为RRC connection failure；
其他情况，则触发RRC重建流程。

1.4 RRC重建立流程介绍

在掉话出现前，若满足发起重建立流程条件，则终端会通过发起重建立流程尝试恢复网络连接。因此RRC重建立流程在掉话前出现概率非常高。RRC重建立流程用来重建RRC连接，恢复终端与网络信令连接。本节对 RRC 重建立流程进行详细介绍。

目前版本已支持跨站重建立，需要配置 XN。

1.4.1、RRC重建立信令流程

RRC重建立信令流程分为 2 种：

1）当AS层的安全模式激活且网络能够获取、验证UE上下文，则

在不改变算法前提下，重新激活AS层的安全模式；
使用RRCReestablishment重新恢复SRB1 。

2）当UE重建RRC连接时，若网络侧无法获取或验证UE上下文，则

释放所有AS层的上下文，释放所有RB；
使用 RRCSetup 流程重建连接。

RRC 重建方式 2

1.4.2 发起RRC重建立的条件

1、当满足以下任何一个条件时，UE发起重建立流程：

1）检测到无线链路失败；

2）重配过程中T304超时导致同步失败；

3）UE与RRC重配信令中部分功能或信源适配存在问题；

4）UE与目标系统没有建立连接或存在不匹配信源；

5）从底层收到SRB1和SRB2的完整性保护失败。

2、当满足以下任何一个条件时，则不会触发RRC重建流程，终端直接进入IDLE：

1）若接入层（AS）的安全模式没有激活，则不会发起RRC重建立，终端直接进入IDLE，释放原因为other；

2）若接入层（AS）的安全模式已激活，但 SRB2 和 DRB 没有建立，则不会发起 RRC

重建立，终端直接进入 IDLE 态，释放原因为 RRC connection failure。

1.4.3 RRC重建立原因填写规则

根据协议38.331第5.3.7.4节描述，UE按照如下规则填写RRC重建立原因值：

1、若RRC重建立流程是由于UE无法支持或遵从RRC重配消息中的部分功能或参数而触发的，则RRC重建立原因值填写 reconfigurationFailure；

2、若RRC重建立流程是由于NR系统内切换重配同步失败或从NR 系统切换到其他系统重配同步失败触发的，则RRC重建立原因值填写 handoverFailure；

3、除上面2个原因以外触发的RRC重建立，原因值填写 otherFailure。

2、掉线问题排查流程

掉线是在UE接入完成RRCConnectionReconfigurationComplete 后处于连接态，之后由于干扰问题、覆盖问题、邻区问题、PCI冲突或其他原因导致的UE上下行失步，触发重建立请求但重建立失败或者重建立被拒绝，或未触发重建立请求直接释放到 IDLE态的过程。简单理解可以认为：只要不是终端主动发起的释放都应该算为掉线。

目前前台测试过程中遇到的掉线问题在信令中有如下 3 种表现：

1、连接态下终端发起RRC重建立请求，但重建立无响应；

2、连接态下终端发起RRC重建立请求，重建被拒绝；

3、连接态下终端收到网络侧非正常释放。

对于掉话问题分析，首先确认掉话问题点涉及的站点是否存在软、硬件告警，若存在告警，则优先解决告警。若无告警，则查看是否存在传输丢包，若存在传输丢包问题，则排查传输问题。在SA网络建设初期，终端与基站兼容性问题较多，因此，在遇到掉话问题时可以通过更换不同版本终端或不同品牌终端进行测试，以排除终端异常导致的掉话问题。

SA掉话问题，可以按照如下流程进行分析、排查。

1、检查掉话相关站点是否有告警

先检查掉话位置点相关站点是否有告警，重点检查是否有硬件告警（如 AAU 链路断，输入电源断，光模块不可用告警），软件告警（如 lccm 容器运行异常告警），传输相关告警， XN/NG 链路断告警，这些都是会引起掉话问题的告警，如果有的话，需要首先处理这类告警。

2、检查是否存在传输丢包

在切换过程中，涉及到 XN 或 NG 接口，信令/数据交互需要通过 XN 或 NG 接口进行传输。因此，需要同时核查 XN 和 NG 接口传输是否存在丢包，时延较大或时延抖动较大问题，若存在则需联系传输侧进行排查，解决传输问题。

在设备感知管理->传输分析->IP 通道检测进行传输问题核查。

3、排查终端问题

由于目前SA终端成熟度不高，因此，可以通过升级到最新版本验证是否存在掉话，若仍存在掉话，则更换不同品牌终端，验证是否只是特定品牌终端存在该问题。通过该流程，主要排查终端异常导致的掉话。

4、核查 baseline 参数

出现掉话问题，在进行参数排查时，首先与系统自带baseline参数进行核查，若存在未对齐参数，先对齐参数，进行复测，保证参数与 baseline设置一致。

5、解决弱覆盖/质量较差问题

从前台 log 查看，若发现 RSRP， SINR 较差（一般 RSRP<-110， SINR<-5 左右容易发生掉话），则需进行 RF 优化，解决弱覆盖及质差问题。

6、解决邻区漏配问题

从前台信令查看，终端一直上报 MR，但一直未收到切换重配命令，首先怀疑是否存在邻区漏配，核查后台邻区配置，是否配置邻区，若配置邻区，按照 SA 切换指导书核查切换参数设置是否正确。

7、解决切换不及时问题

终端切换不及时容易导致掉话。从前台表现来看，终端上报 MR 后未收到基站发送的切换重配命令，而后台信令中查看，基站已发送切换重配命令，查看此时源小区RSRP/SINR 是否非常差，若是，则为切换不及时，可通过修改邻区中 CIO 参数加快切换流程触发。

8、解决切换过早问题

9、解决 PCI 冲突问题

在切换流程中，若存在同频同 PCI 问题，则会导致目标小区无法收到切换重配完成消息，从而导致切换失败，引发掉话问题。需确保邻区中不存在同频同 PCI 问题，若存在，则需要对 PCI 进行优化。

10、解决随机接入参数问题

在切换流程中，若目标侧 PRACH 参数设置错误或 CCE 聚合度参数设置错误，则会导致在切换流程中随机接入失败，若出现随机接入过程失败导致切换掉话，则核查随机接入参数配置问题；

11、解决干扰问题

外部干扰会影响基站接收终端上行信令，若存在上行干扰，基站大概率存在无法接收到终端发送的RRC重配完成信令，从而导致掉话。通过后台进行扫频确认是否存在干扰。

3、掉线原因分析

3.1 覆盖问题

3.1.1 弱覆盖导致掉话

由于弱覆盖导致的掉话，通常有以下表现：

1、掉话前服务小区的RSRP持续变差（如 RSRP<=-105dbm），同时服务小区的 SINR也一起持续变差（小于-5db，甚至更低）；

2、掉话前邻区中没有RSRP更强的邻区信号；

3、掉话后出现较长时间无信令，类似UE脱网。

解决方案：

1、首先明确弱覆盖区域应该由哪个扇区信号覆盖；

2、根据网络拓扑结构和相关无线环境来确定最适合覆盖该区域的扇区及波束，并加强其在此处覆盖；

1）首先确保主覆盖小区运行状态正常，排除软硬件告警问题；

2）检查 powerPerRERef，是否设置过小（注意不要超出 AAU 最大功率）；

3）核查主覆盖小区是否使用单波束，若使用单波束，建议修改为多波束，提升覆盖及SINR；

4）通过后台调整主覆盖小区权值参数进行覆盖优化或使用 AAPC 功能进行优化；

5）若通过后台权值调整无法解决覆盖问题，则需上站调整覆盖；

6）若仍无法解决，可调整5G到4G切换参数，在掉话前切换到 4G 网络。

3.1.2、越区覆盖导致掉话

在移动通信网络中，由于无法精确控制无线信号传播，因此或多或少的都会存在越区覆盖问题，越区覆盖导致的掉话通常表现如下：

1、地理上表现为距离较远的站点在此处形成较强的覆盖；

2、信号上表现：越区覆盖容易产生导频污染。若越区覆盖信号较多，则在覆盖区域内没有稳定的强信号小区做主服务小区会形成导频污染区域。服务小区信号频繁变化或频繁切换是导致掉话的一个主要原因。

解决方案：

越区覆盖一般优化原则是：在区域中已有合理稳定的信号覆盖的情况下尽可能的控制越区覆盖信号。可通过如下手段进行优化：

1、下压越区覆盖小区机械下倾角；

2、调整越区覆盖小区电子下倾角；

3、下调越区覆盖小区 RE 信号功率（优先级最低）

若越区覆盖导致了导频污染问题，可根据网络拓扑及无线环境来确定最适合覆盖该区域的小区，并加强其在此区域的覆盖，减弱其他小区在此区域覆盖。

1、上调主覆盖小区RE功率（确保不超出总发射功率）；

2、优化主覆盖小区机械下倾角，加强覆盖；

3、优化主覆盖小区电子下倾角，或采用多波束，加强覆盖；

4、通过降低功率，调整下倾角等优化动作控制越区覆盖小区信号。

3.2 邻区漏配

邻区优化是无线网络优化中非常重要的环节。邻区漏配导致终端一直占用信号较差小区进行业务，容易引起掉话。

由于邻区漏配导致的掉话有如下现象：

1、掉话前 RSRP/SINR 逐渐变差；

2、掉话前 UE 多次上报切换事件 MR，并且 MR 中上报的邻区 PCI 不在当前服务小区的邻区列表中；

3、终端可能发起了重建立，但重建立无响应；

4、掉话后终端进行小区选择，选择到 MR 中上报的邻区 PCI 小区上驻留发起业务。

解决方案：

1、手动添加漏配邻区；

2、打开 ANR 功能对邻区进行优化。

3.3、邻区错配

外部邻区定义中若PCI、PLMN、TAC配置错误，则会导致切换失败，容易引起掉话。目前在配置5-5邻区时，若源和目标小区共 UME，则无需手动配置外部定义，UME会自动创建。

由于邻区错配导致的掉话有如下现象：

1、掉话前 RSRP/SINR 逐渐变差；

2、掉话前UE多次上报切换事件MR，并且MR中上报的邻区PCI不在当前服务小区的邻区列表中（可能是 PCI 配置错误）或上报的 PCI 存在于邻区关系中，收到切换失败命令；

3、终端可能发起了重建立，但重建立无响应；

4、掉话后终端进行小区选择，选择到切换前最好的小区上驻留发起业务。

解决方案：

核查 5-5 外部定义是否正确。

3.4 切换掉话

在外场测试过程中经常会遇到切换过程中导致的掉话问题。针对切换过程中导致的掉话，主要分为：

切换不及时
切换过早
随机接入失败
其他失败（如切换准备阶段等）

对于宏站和微站之间切换，需要注意“宏微切换测量配置策略” 配置为“宏微测量合一” 则宏微切换使用现有宏站切换参数。若“宏微切换测量配置策略” 配置为“宏微测量分开” ，则需自行定制宏微切换测量配置（默认为空，若不配置会导致宏微无法切换从而导致掉话）。

3.4.1、切换不及时

切换不及时导致的掉话，在前台信令中有如下表现：

1、在地理上，容易出现在街道拐角信号突变的地方；

2、在信令上表现为终端上报切换 MR 后源小区 RSRP 急剧恶化，导致下行终端未收到切换重配命令；

3、掉话后终端选择了 MR 中目标小区进行驻留，并发起业务请求。

解决方案：

切换不及时问题大部分是由于街道拐角信号突变导致，针对该场景，可以优先通过优化拐角处覆盖解决，如增加主覆盖小区在此处的覆盖，减弱其他小区在此处的覆盖，或调整切换带尽量避免在拐角发生切换。若调整覆盖较困难，可通过增加到目标小区的 CIO（cellIndividualOffset）来加快往目标小区切换，以避免出现切换不及时导致掉话。

3.4.2、切换过早

在街道拐角等地方由于信号较复杂，可能会导致某个小区信号突然变好但随着终端移动信号又突然变差的问题，若此时终端过早的切换到了目标小区，由于目标小区信号突然变差可能会导致掉话。切换过早主要表现有：

1、一般发生在街道拐角等容易出现信号突变的地方；

2、切换前目标小区信号突然变好满足切换门限，终端发送了 RRC 重配完成命令但目标小区接收不到该消息导致切换失败；

3、终端在与目标小区进行随机接入一直发送 msg1 ，功率攀升，但无法收到msg2，导致切换过程中随机接入到目标小区失败；

4、掉话后终端选择到源小区或其他更好的小区上，而非切换目标小区进行驻留。

解决方案：

1、梳理出切换目标小区，控制目标小区在此区域覆盖；

2、减小到目标小区的 CIO（Cell Individual Offset）来延缓往目标小区切换。

3.4.3 随机接入过程掉话

在切换阶段，终端采用非竞争方式与目标基站进行随机接入，若随机接入失败，则会导致掉话。由于不存在竞争冲突问题，且一般目标小区信号较好，因此该阶段导致的掉话问题较少。随机接入过程失败导致掉话，主要表现为：在切换执行阶段，终端一直发送 msg1，但收不到 msg2，最后 msg1 达到最大重传次数导致随机接入失败。

解决方案：

核查随机接入相关参数是否配置错误，如基站期望的前导接收功率设置过高， PRACH功率攀升步长过小等。

3.5 干扰问题

干扰同样会导致掉话问题，干扰会分为上行干扰及下行干扰。

上行干扰：终端上表现为在覆盖较好区域终端发射功率攀升至较高值。通过基站后台扫频确认，若关闭LNA后NI值仍然较高则怀疑干扰来自于内部，若关闭LNA后干扰值降低，则干扰来自于外部。其主要原理是通过关闭设备上行接收端，来检测设备是否还有干扰，因为这个时候如果还能检测到干扰的话则说明该干扰为设备内部产生的，反之关闭后干扰消失则说明干扰来自设备外。

下行干扰：当下行链路受到干扰时，终端测量到的 RSRP 较好，但是SINR较差。

3.6 拥塞导致掉话

gNodeB小区的资源是有限的，而每个用户接入都会占用一定的小区资源，有限的资源只能给有限的UE提供服务，当请求服务的UE数量超过了小区的能力后，网络稳定性将受到影响，在线用户的体验可能会变差，甚至威胁到站点安全，最终导致gNodeB无法提供无线服务。为解决该问题，gNodeB需要通过接纳控制机制控制业务请求。

接纳控制过程可分为两类：