5G SA 切换问题参考 - 面包板社区

一、问题描述

目前电信已完成SA站点的初步组网，由于SA站点较少，覆盖缺乏连续性，切换问题导致用户感知差，在前期测试过程中，经常会遇到一些路段切换存在问题，为后续SA网络商用，减少客户投诉，因此 SA 的切换问题显得非常重要。

二、分析过程

2. 1、切换的基本原理

SA 场景下切换与 LTE 切换类似，遵循以下几个步骤：测量控制下发->测量事件上报->切换判决->切换准备->切换执行->目标小区接入；如下图所示为 gNodeB 站内切换流程。

SA 切换场景主要分为 NR 站内切换和 NR 站间切换，其中 NR 站间切换又包括基于 XN接口的站间切换和基于 NG 接口的站间切换。

SA 场景下主要切换流程图

下面列举出SA 场景下主要切换流程，便于快速识别问题点，并针对性的排查。如无特别说明流程图中红色序号分别表示：1、测量控制下发；2、测量上报；3、发起切换(切换判决成功)；4、切换完成；5、目标小区发起随机接入。

SA 场景下 NR 站内切换

SA 场景下 NR 站内切换：

SA 场景下基于 XN 接口的 NR 站间切换

SA 场景下基于 NG 接口的 NR 站间切

2.2 切换正向排查动作

切换问题定位分为“正向排查” +“负向排查” 两部分，其中“正向排查” 部分是强烈推荐必须执行的分析步骤，原因是根据5G 网上切换问题统计， 85%问题根因都是可以通过正向排查可以定位。

2.2.1 软件版本检查

确保 NR、 LTE、 TUE、 CPE、终端的版本是推荐版本且不同网元版本配套,请参考support 发布的配套关系信息。

2.2.2 参数核查

结合FMA 参数核查工具快速排查当前参数设置情况，确保当前参数配置正确，如接口配置、邻区以及邻区 PCI 的设置等。

FMA 工具菜单栏中选择Parameter Check 之后，也会弹出提示框，要求确认参数核查模板是最新的，否则就使用提供的链接去下载后导入：

图 FMA 工具内的参数核查

SA 场景请务必进行SA 参数核查，通过SA Parameter Check 核查可以快速识别出 NG 漏配，通过 gNB Parameter Check 可以快速识别邻区漏配， PCI 冲突等配置问题。

图通过 SA Parameter Check 核查 XN 接口配置

图通过 gNodeB Parameter Check 核查邻区关系

2.2.3 告警故障排查

确保SIM 卡开户正常，与核心网确认所使用 SIM 卡已在 5GC 上正确开户，能正常接入 5G 网络，不被核心网拒绝。

基站的操作，告警和故障日志可以在 U2020 和一键式日志内获取查看。告警重点关注列表如下：

表：主要异常告警信息

2.2.4 上行干扰排查

上行干扰会影响PRACH、 PUSCH 解调性能，从而影响切换过程或者影响在目标小区的随机接入。建议排查一下上行干扰情况，无干扰情况下底噪大约在-115dBm 左右，干扰检测可以通过话统， 2020 干扰监控和 FFT 扫描进行。

2.2.5 覆盖排查

当前大多数切换问题是一线通过路测拉网发现并上报的，如果有 Probe 数据，可以通过probe 日志看看掉话点的地理特征，是否存在集中出现于路测线路上某些位置的情况。如果存在明显的地理特征，需要排查一下是否存在覆盖交叠，越区覆盖，乒乓切换等问题，如果存在这些问题建议 RF 优化。

下图是某局点拉网切换掉话问题，问题点集中于一小段线路上，该位置区域存在明显的覆盖交叠和越区覆盖问题，表现为频偏大， SINA 差，邻区多，多个强邻区(无主导小区)，乒乓切换等问题，需要通过 RF 优化解决。

2.2.6 外部事件排查

SA 场景下站间切换需要通过XN 接口或者NG 接口进行交换。周边设备故障可能导致切换指标突然恶化，比如传输、核心网等设备故障等。因此需要核查问题是否有明显时间特征，出现前后是否存在重大外部事件，比如传输改造升级，核心网改造和升级， 5G 站点升级、现网 MOCN 改造等等。

2.2.7 信令流程分析

不管是站内切换还是站间切换，基于 XN 接口切换还是基于 NG 接口的切换，我们都可以将切换过程分解为：测量控制下发、测量事件上报、测试判决成功、测量准备与执行、目标小区随机接入等这几个过程。信令流程分析的主要要识别清楚一下几点：

1、确认异常流程的位置，切换流程走到了哪一步，在哪里发生了异常？

2、确认问题所属网元(gNodeB、核心网、终端)，源站点还是目的站点？

3、确认异常的主要原因和排查方向。

对于切换流程首先要识别清楚当前终端接入的小区，期望切换的目的小区，这个可以通过标口跟踪， Probe 跟踪或者 CHR->L3ChrIntraSysHoFail 信息确认，以便快速确认异常流程的位置和失败原因。

2.2.7.1 通过 CHR 日志分析异常流程

通过 CHR->L3ChrIntraSysHoOutFail 可以对切换流程和故障点进行快速隔离。打开CHR 日志，过滤 ChrIntraSysHoOutFail 找到对应时间段内切换失败信息。相同时间段内挑选信息量最大的结构体，参考下图进行解析：

2.2.7.2 通过标口跟踪分析异常流程

通过标口跟踪可以快速判断出切换是基于 XN 口的切换还是 NG 口的切换，方法参考下图所示：

图通过标口跟踪识别基于 XN 接口的切换流程

图通过标口跟踪识别基于 NG 接口的切换流程

2.3 切换反向排查-UU 口排查

2.3.1 基站未下发 A3 测量控制

SA 场景下， A3 测量控制一般是在初始上下文建立完成， PDU SESSION 建立之前下发。

图 SA 场景下测量控制和测量报告下发

5G 测量控制和 LTE 测量控制类似，主要分为测量对象、测量报告，测量 ID 三部分：

1、测量对象：主要定义测量对象 ID，测量 SSB 频点，测量带宽。

2、测量报告：主要定义了报告类型，测量门限等

3、测量 ID 配置：主要是将测量对象和测量报告关联起来，并定义一个 ID；

4、滤波系数：当前滤波系数固定为 fc4。

2.3.1.1 未配置任何 5G 邻区

//查询NR 外部邻区（NR 站内切换时不需要查询），确认有没有配置。

LST NREXTERNALNCELL:;

//查询NR 邻区关系，确认有没有配置。

LST NRCELLRELATION:;

2.3.1.2 外部小区配置 SSB 频点错误

现场站点在 MO NREXTERNALNCELL 中的 SsbDescMethod=Global SynchronizationChannel Number 和 SsbFreqPos=2 配置错误。修改为SsbDescMethod=Absolute Frequency, SsbFreqPos=629988 后问题解决。

2.3.1.3 信道受限，包括 PDCCH/PDSCH

下行 DCI 资源分配失败，基站无法调度给 UE 下发测量控制消息。抓取基站 L2CELLDT 跟踪 602/323，反馈给研发分析。

PDSCH 信道拥塞，基站无法及时发送测量控制消息。

2.3.1.4 覆盖原因

根据SSB RSRP/SINR 判断下行信号质量差（比如SSB SINR 在 0dB 以下），可能导致UE 无法接收到测量控制消息。

2.3.2 不上报 A3 测量报告

当终端检测到邻区，并满足 A3 测量控制中下发的测量门限要，就会上报的 5G 的 A3测量报告值(实际报告值需要减去 157 进行换算)。

图 SA 场景下 A3 事件上报的关键信元

根据 A3 测量控制下发的参数条件可知，终端启动 A3 事件报告和退出报告的条件如下：

A3 事件的进入条件：Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off，且上述条件持续TimeToTrig 时间

A3 事件的退出条件：Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off，且上述条件持续TimeToTrig 时间

一般来说终端不上报 A3 测量报告原因主要有两类：1) 终端测不到该频点的小区；2)终端测量到该频点小区，但是达不到上报条件，前者主要要检查小区状态，后者主要要检查参数合理性。

1、终端测量不到同频小区的大致原因可能有：NR 邻区未激活、 NR 临区发功异常信号太小收不到、邻区通道矫正异常、 NR 邻区配置了非典型 SSB 周期(不是 20ms)。

终端测量到同频邻区但是不上报的原因可能有：AAU 发功小、小区功率配置偏低、目标小区给该邻区配置了过大的切换偏执、终端到目标小区距离远路损大。

2.3.2.1 目标小区状态异常

目标小区状态异常，可能导致小区发功异常，导致终端检测不到改下小区的信号。检查小区状态，小区是否被去激活了；DSP NRCELL:;检查小区通道矫正情况：DSPNRDUCELLCHNCALIB: NrDuCellId=XX;//检查小区通道矫正情况，

2.3.2.2 终端检测到的小区信号达不到 A3 上报门限

还有可能是终端检测到邻区的信号，但是邻区信号强度不满足 A3 事件的条件，可以进行如下排查：

1、如果有Probe 跟踪，检查Probe 跟踪上邻区信号和服务小区信号的情况，是否达到了A3 报告门限。

2、检查小区功率是否配置过低导致终端收到目标小区信号太小。

LST NRDUCELLTRP: NrDuCellTrpId=11;

备注：对于 64TAAU， 200W 小区配置的 MaxTransmitPower 是 349。

3、排查GNBMEASCOMMPARAMGRP， RSRP 偏置和幅度迟滞， RsrpOffset 和Hys；

(默认值是 RsrpOffset=2(0.5dB);Hys=2(0.5dB))

4、检查目标小区是否设置了特殊的切换偏执，导致门限过高 ; LST NRCELLRELATION:;

(MO NRCELLRELATION -> CellIndividualOffset 配置越大越容易触发事件上报，越小越不容易上报)。

2.3.2.3 信道受限，包括 PDCCH/PUSCH

UE 上报测量报告要有 UlGrant，如果 PDCCH 无法满足分配，则 UE 无法上报。抓取基站 L2 CELLDT 跟踪 602/323，反馈给研发分析。如果是PUSCH 信道拥塞， UE 也无法及时上报测量报告。

2.3.2.4 终端异常，比如 UE 内部层间丢失

如果终端侧Probe 日志查看到有测量到服务小区和邻区信号已经满足上报门限，但是未上报 MR，则怀疑终端侧可能存在内部异常。需要联系终端侧排查。

2.3.3 切换命令 RRC Conn Recfg 消息丢失

SA 架构， SgNB 会在 UU 口下发切换命令 RRC CONN RECFG 消息给 UE，携带关键信息，包括目标小区 PCI， newUEID 和 t304。

下行 DCI 资源分配失败，基站无法调度给 UE 下发切换命令。抓取基站 L2 CELLDT 跟踪 602/323，反馈给研发分析下行 DCI 资源分配失败，基站无法调度给 UE 下发切换命令。抓取基站 L2 CELLDT 跟踪 602/323，反馈给研发分析。

2.3.3.1 信道受限，包括 PDCCH/PDSCH

下行 DCI 资源分配失败，基站无法调度给 UE 下发切换命令。抓取基站 L2 CELLDT 跟踪 602/323，反馈给研发分析。

PDSCH 信道拥塞，基站无法及时发送测量控制消息。

2.3.3.2 覆盖原因

根据SSB RSRP/SINR 判断下行信号质量差（比如SSB SINR 在 0dB 以下），可能导致UE 无法接收到切换命令消息。

2.3.3.3 gNB 切换判决失败，或内部异常

1、当外部小区NREXTERNALNCELL 中 PhysicalCellId 配置错误，导致测量报告上报后源侧找不到外部邻区，所以不会发起切换。

此种情况下需要结合现场的工参表，跟一线服务和网规网优人员确认后，针对错误配置进行更正。

2、如果 NR 侧源小区下发切换重配置消息， DBG 日志记录：

CU_UEM_LOG_CODE(0x1A67)

2019-01-22 11:25:52(600)

[INFO][FILE]cuuem_intra_cu_ho_ue_acess_proc.cpp

[FUNCTION]CuUemIntraGnbHoUeAcessProc::CuEnvStart CuUemIntraGnbHoUeAcessProc:

send RRC_CONN_RECFG at 112552540, ue_inst = 93, src_crnti = 2000009, tgt_crnti = 8e26.

否则， SgNB 内部可能存在异常，需要继续找开发定位。

2.4 切换反向排查-XN 口排查

2.4.1 Handover Request 消息丢失

源站的 CHR 日志 L3ChrIntraSysHoOutFail 事件中的 DCRecordInfo 字段会记录，具体的DCInnerCause 可以参考附录 DC Value。

2.4.1.1 SgNB 切换判决失败

如果是SgNB 漏配邻区，需要检查下面的配置是否正确：

//查询NR 外部邻区，确认有没有到目标小区的 gNBId， CellId 和 PCI。

LST NREXTERNALNCELL:;

//查询NR 邻区关系，确认有没有到目标小区的 gNBId 和 CellId。

LST NRCELLRELATION:;

如果查询到SgNB 配置的 NR 外部邻区中存在相同 PCI，则需要找网规和工程交付人员确认是否规划或开站脚本配置错误。

2.4.1.2 SgNB 内部异常

如果NR 源站给NR 目标站发送 HO REQ 请求切换入， DBG 日志记录：

CU_UEM_LOG_CODE(0x1771)

"CuUemXnHoReqCmd::OnMsg()"

否则， SgNB 内部可能存在异常，需要找开发继续定位。

2.4.1.3 Xn 口配置错误或传输异常

如果是Xn 口手动配置对端信息，需要注意配置的对端 IP 和 PN 号是否正确。可以参考附录的 MML 示例。

传输异常，可以通过告警和故障日志判断。

2.4.2 Handover Request ACK 消息丢失

如图中 B 点所示，在 Xn 接口切换时，未收到对端 gNodeB 发出的 HANDOVERREQUEST ACKNOWLEDEG 消息及HANDOVER PREPARATION FAILURE 消息。如果切换过程中源小区和目标小区为同频，指标 N.HO.IntraFreq.Prep.FailOut.NoReply 加 1。（目标小区无响应导致同频切换出准备失败次数，指标 ID= 1911817090）。

需要结合 TgNB 的一键式日志进一步分析。

如果目标站发送了 HANDOVER REQUEST ACKNOWLEDEG 消息，会在目标站有DBG 日志记录：

CU_UEM_LOG_CODE(0x1E50)：

Desc:[INFO][FILE]cuuem_hoin_send_ho_req_ack_proc.cpp

[FUNCTION]CuUemHoInSendHoReqAckProc::CuEnvStart CuUemHoInSendHoReqAckProc:

send XNAP_HO_REQ_ACK at 150340154, ue_inst = 20.

源站的 CHR 日志 L3ChrIntraSysHoOutFail 事件中的 DCRecordInfo 字段会记录，具体的DCInnerCause 可以参考附录 DC Value。

2.4.2.1 TgNB 内部异常，回复 Handover Preparation Failure 或不回复

如图中B 点所示，在Xn 接口切换过程中的切换准备阶段，当源小区收到来自目标小区的HANDOVER PREPARATION FAILURE 消息时，如果切换过程中源小区和目标小区为同频，指标 N.HO.IntraFreq.FailOut.PrepFailure 加 1。（目标小区回复切换准备失败消息导致切换出准备失败次数，指标 ID= 1911816920）。

通过 TgNB 的一键式日志，在问题时间点查看是否有异常记录。

源站的 CHR 日志中， SigInfoLst 事件记录XN 口切换出的最后 30 条信令流程消息中有接收到目标站回复的 HANDOVER PREPARATION FAILURE 消息，携带原因值是HO_TGT_NOT_ALLOWED：

源站的 CHR 中 L3ChrIntraSysHoOutFail 事件里面会记录错误日志：

也会对应记录下切换入的这次 CallId，源站的 gNodeBID， CellID 和 Crnti：

目标站的 gNodeBID， CellID：

以及

DCCallProcedureType:Intra System Handover Out (0x41)

DCErrType:RNL_PROCEDURE_ABNORMAL (0x13)

DCInnerCause:CU_UEM_RCV_XN_HO_PRE_FAIL (0x810D022B)

源站的 CHR 日志 L3ChrIntraSysHoOutFail 事件中的 DCRecordInfo 字段会记录，具体的DCInnerCause 可以参考附录 DC Value。

2.4.2.2 NGC 内部异常

如图中B 点所示，在 Xn 接口切换过程中的切换准备阶段，源小区收到来自 AMF 的UECONTEXT RELEASE COMMAND 消息时，如果切换过程中源小区和目标小区为同频，指标N.HO.IntraFreq.Prep.FailOut.AMF 加 1。（核心网原因导致同频切换出准备失败次数，指标 ID= 1911817089）。

需要联系 NGC 侧一起分析异常原因。

源站的 CHR 日志 L3ChrIntraSysHoOutFail 事件中的 DCRecordInfo 字段会记录，具体的DCInnerCause 可以参考附录 DC Value。

2.4.2.3 TgNB 分配专用 preamble 失败，回复 Handover Preparation Failure

通过TgNB 的一键式日志，在问题时间点查看是否有分配专有 preamble 失败的异常记录。

目标站的 CHR 日志中 L2UserChr 事件中 L2_USERCHR_PREAMBLE_INFO 会记录L3Alloc 的信息：

如果UsedFlag=0，表示目标站没有分配出专有前导，则抓取基站 L2 CELLDT 跟踪 1，反馈给研发分析。

2.4.2.4 TgNB 准入失败，或小区状态异常，回复 Handover Preparation Failure或不回复

通过小区类告警和故障排查确认小区状态是否异常。如果小区状态异常，目标小区接收不到 Handover Request 消息，所以也不会做出响应。

触发TgNB 准入失败的可能原因，包括 SRS 资源分配失败， PUCCH 资源分配失败，上行流量 License 受限，下行流量 License 受限，用户连接数 Licence 受限，用户连接数规格受限， RE License 受限，下行传输资源不足，上行传输资源不足。

比如目标站的 RRC 连接用户数 LICENSE 受限，则在 CHR 中 L3ChrIntraSysHoInFail 事件里面会记录错误日志 CU_UEM_LOG_CODE(0x133D)：

也会对应记录下切换入的这次 CallId，目标站的 gNodeBID 和 CellID：

DCCallProcedureType:Intra System Handover In (0x42)、 DCErrType:RNL_UNSPECIFIED(0x10) 、 DCInnerCause:CU_UEM_XN_HOIN_PRE_PROC_FAIL (0x810D0250) ，目标站的CHR 日志 L3ChrIntraSysHoInFail 事件中的 DCRecordInfo 字段会记录，具体的DCInnerCause 可以参考附录DC Value。如图中 B 点所示，在Xn 接口切换过程中的切换准备阶段，当源小区收到来自目标小区的 HANDOVER PREPARATION FAILURE 消息时，如果切换过程中源小区和目标小区为同频，指标 N.HO.IntraFreq.FailOut.PrepFailure 加 1。（目标小区回复切换准备失败消息导致切换出准备失败次数，指标 ID= 1911816920）。

2.4.2.5 SgNB 发送Handover Cancel 消息

如图中 B 点所示，在 Xn 接口切换过程中，当目标 gNodeB 收到源 gNodeB 发送的HANDOVER CANCEL 消息时，则在目标小区中统计相应指标 N.HO.FailIn.HOCancel加1。（目标小区收到切换取消导致切换入失败次数，指标 ID= 1911816914）。

通过 SgNB 的一键式日志，在问题时间点查看切换取消的记录。

2.4.3 Handover Cancel

如图中 B 点所示，在Xn 接口切换过程中的切换准备阶段，当源小区收到来自目标小区的 HANDOVER REQUEST ACKNOWLEDGE 消息时，由于合法性检测失败，源小区判决取消本次切换时，如果切换过程中源小区和目标小区为同频，指标N.HO.IntraFreq.Prep.FailOut.TargetIllegal 加 1。（对端回复切换响应消息合法性检查失败导致同频切换出准备失败次数，指标 ID= N.HO.IntraFreq.Prep.FailOut.TargetIllegal）。