简介本资源是爱立信内部专家Cassie Song编写的《SDCU NSA移动性能分析优化指导书》面向5G网络优化工程师及无线通信运维人员聚焦NSA非独立组网模式下的移动性问题诊断与参数调优解决切换失败、时延高、KPI劣化等典型现网痛点。资源为单文件PDF大小5.07MB内容完整覆盖3GPP标准信令流程、爱立信实现机制、NR侧切换KPI定义与Counters打点逻辑、锚点及NR邻区关系参数配置要点、空口信令深度解析含RRC/PDCP关键消息、前台信令问题定位方法及网管性能分析全流程附常见失败原因如邻区漏配、外部数据不一致与对应解决措施。目前已有203人学习下载结构清晰、实操性强可直接用于日常优化工作复盘、故障根因分析及新人能力培养。1. 这不是一份普通PDF它是一份能让你在凌晨三点精准定位“SN变更失败”的NSA移动性能手术刀你有没有遇到过这样的场景凌晨两点KPI看板上“SgNB添加成功率”突然跌到82%网管告警刷屏但CTR里翻遍了Handover Request、SgNB Addition Request、SN Status Transfer就是找不到哪一步卡死了查X2链路正常邻区配置看着也全锚点关系表里打钩的项密密麻麻——可用户投诉电话还在响。这不是玄学是NSA双连接架构下特有的“黑匣子式”故障主站MeNB和辅站SgNB分属两套系统、两套计数器、两套信令路径问题可能藏在eNodeB的Release Request里没发出去也可能卡在gNodeB的NRCellRelation.isHoAllowedfalse这个参数上甚至可能只是MTR20.37版本里一个未公开的ANR触发条件被绕过了。这份《SDCU NSA移动性能分析优化指导书》不是泛泛而谈的5G网络优化分析理论汇编它是山东联通集中优化工作站联合爱立信内部专家Cassie Song在MTR20.37现网版本上实打实踩坑、复盘、验证后沉淀下来的“NSA移动性问题诊断手册”。它不教你5G是什么而是直接告诉你当“站间变更失败率”飙升时该先抓哪个CTR事件、该去网管查哪三个MO、该用哪条命令dump出SN Release Request的失败原因值Cause Value。面向的是已经能看懂RRCConnectionReconfiguration消息、能区分MCG/SCG承载、知道ANR和X2链路关系的NDO一线工程师——你要的不是概念是下一步该敲什么命令、该改哪个参数、该盯哪个Counter打点位置。它解决的不是“怎么建网”而是“怎么让已建的NSA网络不掉链子”。2. NSA切换信令流程解剖从3GPP标准到爱立信MTR20.37的落地差异NSA切换不是LTE切换的简单平移它把一次移动拆成了“主站动作”和“辅站动作”两个时空。理解这个拆分逻辑是所有后续分析的起点。本章不罗列标准原文而是聚焦于3GPP 37.340与爱立信MTR20.37实现之间的关键落差点——这些落差正是日常优化中90%“说不清道不明”问题的根源。2.1 三类核心切换场景的信令流本质差异指导书将NSA切换明确划分为三大类每类对应完全不同的信令驱动主体和资源释放/重建逻辑。必须死记硬背其触发条件和失败点分布MN触发的SgNB变更最常见由LTE主站eNodeB发起典型场景是UE在LTE覆盖区内移动但当前SgNB信号变差。其信令流本质是“先断后连”源MeNB先向源SgNB发SgNB Release Request步骤3a等源SgNB确认释放3b后再向目标SgNB发SgNB Addition Request步骤1。关键落差点如果3a没发出去或3b超时未回整个流程就卡死在“释放阶段”此时CTR里根本看不到Addition Request但KPI已开始下跌。MTR20.37中此流程的endcActionA3EvalFail参数见2.2节会决定是IGNORE静默失败还是RELEASE主动释放这直接导致前台信令观测结果天壤之别。SN触发的SgNB变更易被忽略由NR辅站gNodeB发起典型场景是UE在NR覆盖区内移动PSCell需变更。其信令流是“边连边断”源SgNB直接向MN发SgNB Change Required步骤1MN再协调目标SgNB。关键落差点此流程完全绕过eNodeB的测量上报依赖gNodeB自身的A3事件判决。若NRCellRelation.isHoAllowed false文档第12页明确指出则源SgNB直接拒绝触发变更前台信令里连SgNB Change Required都不会出现只会看到UE持续上报A3却无任何响应——这是典型的“有测量无动作”黑盒。MN间切换含SN保留/变更即LTE基站间的切换但需同步处理NR侧。其复杂性在于“耦合决策”目标MeNB在收到Handover Request步骤1后必须立刻决定是保留原SgNB发SgNB Addition Request给同一SgNB、还是变更SgNB发请求给新SgNB、或是彻底释放不发任何SN请求。关键落差点文档图示第7页清晰标出目标MeNB的决策结果通过Handover Request Acknowledge中的字段告知源MeNB。若此处决策为“保留”但实际目标SgNB的X2链路未配通则后续SgNB Reconfiguration Complete必然失败而失败原因会记录在目标SgNB的Counter里而非源MeNB的CTR中——跨网元排查的典型陷阱。提示MTR20.37版本中所有SgNB变更流程的SN Status Transfer步骤8/9b都强制启用用于RLC AM承载的数据状态同步。若此步骤失败会导致用户面数据丢包但KPI统计中可能仅体现为“变更时延超标”而非“变更失败”。务必结合Secondary RAT Data Usage Report步骤10/11a中的收发数据量比对判断是否发生数据转发中断。2.2 爱立信MTR20.37的实现机制参数才是真正的“开关”3GPP标准只定义信令框架而爱立信MTR20.37用具体参数将其具象化。这些参数不是可选项而是决定信令流能否启动的物理开关。指导书第12页的NRCellRelation.isHoAllowed和ReportConfigA3.endcActionA3EvalFail就是最典型的例子。NRCellRelation.isHoAllowed true这是PSCell变更的“准入许可证”。它位于NRCellRelationMO管理对象下且必须为true源SgNB才会响应UE上报的NR A3事件并启动变更流程。血泪经验现场曾发现某站点因批量导入邻区时脚本错误将此参数默认设为false导致该邻区所有PSCell变更请求被静默丢弃前台信令干净得像没发生过任何事但用户感知就是“5G突然变4G”。修复只需一条命令set NRCellRelationNRCellRelation-12345 isHoAllowedtrue其中NRCellRelation-12345是邻区关系实例ID可通过list NRCellRelation结合get NRCellRelationxxx确认当前值。ReportConfigA3.endcActionA3EvalFail这是A3事件评估失败后的“应急预案”。当UE上报的PCI在邻区关系中不存在或isHoAllowedfalse时此参数决定gNodeB行为IGNORE保持当前EN-DC配置PSCell不变。现象UE持续上报A3但无任何SgNB变更信令KPI无失败记录但用户可能遭遇弱覆盖。RELEASE主动触发SN释放并让eNodeB下发B1测量。现象前台可见完整的SgNB ReleaseB1 Measurement ConfigB1 ReportSgNB Addition流程KPI中计入一次“SN释放”和一次“SN添加”但若添加失败则失败率体现在添加成功率上。注意endcActionA3EvalFail参数位于ReportConfigA3MO下其作用域是整个A3测量配置而非单个邻区。修改前务必确认该配置是否被多个邻区复用避免误伤。2.3 信令流程与Counter打点的强绑定关系指导书第14页强调“Counter打点是信令流程的镜像”。这意味着每一个关键信令步骤都有且仅有一个对应的Counter进行原子级计数。脱离Counter谈信令分析如同蒙眼开车。以下是MTR20.37中与三类切换强绑定的核心Counter均位于MRBTS-xxx/PLMN-1/CELL-xxx路径下Counter ID中文含义触发信令节点关键诊断价值pmSgNbAddAttSgNB添加尝试次数源MeNB发送SgNB Addition Request判断添加流程是否启动。若为0说明问题在MN侧如B1未配置、测量未触发pmSgNbAddSuccSgNB添加成功次数源MeNB收到SgNB Addition Request Acknowledge与pmSgNbAddAtt比对计算添加成功率。若Att0但Succ0问题在目标SgNB或X2链路pmSgNbRelAttSgNB释放尝试次数源MeNB发送SgNB Release Request判断释放流程是否启动。若为0说明MN未触发释放如A3未上报、判决未触发pmSgNbRelSuccSgNB释放成功次数源MeNB收到SgNB Release Request Acknowledge与pmSgNbRelAtt比对。若Att0但Succ0问题在源SgNB或X2链路pmSgNbChgAttSgNB变更尝试次数源SgNB发送SgNB Change Required判断SN侧变更是否启动。若为0说明问题在SN侧如isHoAllowedfalse、A3配置错误实操技巧在网管中查询Counter时务必使用Time Range精确到5分钟粒度并与前台抓取的信令时间戳严格对齐。例如若信令显示SgNB Addition Request发生在14:23:15那么应查询14:23:00-14:23:59区间内的pmSgNbAddAtt值而非整小时汇总值——后者可能被其他时段的成功流量稀释掩盖真实失败。3. 切换KPI与Counter打点机制让每一毫秒的失败都有迹可循KPI是网络健康的体温计而Counter是体温计里的水银柱。指导书第14-15页将NSA切换KPI与底层Counter的映射关系写得极为透彻但一线工程师常犯的错误是只盯着KPI看趋势却不去Counter里挖根因。本章直击痛点告诉你每个KPI数字背后究竟对应哪几个Counter的加减法以及如何用Counter的“差值”定位到毫秒级的失败环节。3.1 核心KPI的原子化定义与计算公式NSA切换KPI不是黑箱输出而是由多个Counter按固定公式计算得出。理解公式才能知道该去哪查数据SgNB添加成功率pmSgNbAddSucc/pmSgNbAddAtt× 100%解读这是最常被监控的指标。但注意pmSgNbAddAtt只计数“请求发出”不保证目标SgNB收到pmSgNbAddSucc只计数“确认收到”不保证UE最终完成重配置。因此该成功率高不代表用户无感知问题如重配置延迟。SgNB变更成功率pmSgNbChgSucc/pmSgNbChgAtt× 100%解读pmSgNbChgAtt在源SgNB侧计数SgNB Change Required发出pmSgNbChgSucc在目标SgNB侧计数SgNB Reconfiguration Complete收到。关键洞察若此成功率低但pmSgNbAddSucc/pmSgNbAddAtt很高说明问题不在添加流程而在变更流程本身——大概率是NRCellRelation.isHoAllowedfalse或目标SgNB资源不足。站间变更成功率MN间切换pmHoExeSuccInter/pmHoPrepAttInter× 100%解读pmHoPrepAttInter是源MeNB的Handover Request发出次数pmHoExeSuccInter是目标MeNB的RRCConnectionReconfigurationComplete收到次数。玄学点此KPI成功不代表NR侧成功它只保证LTE切换成功。NR侧的成败需单独看pmSgNbAddSucc/pmSgNbAddAtt若目标MN决定添加新SgNB或pmSgNbRelSucc/pmSgNbRelAtt若目标MN决定释放SgNB。提示MTR20.37中pmHoExeSuccInter的计数点在目标MeNB的RRC层而pmSgNbAddSucc在目标SgNB的X2AP层。两者时间戳可能相差数十毫秒这是正常的协议栈处理延迟勿误判为“不同步”。3.2 Counter打点的“黄金三角”时间、网元、事件类型Counter不是静态快照而是动态流水账。指导书第15页隐含了一个重要原则有效分析Counter必须同时锁定三个维度——否则数据毫无意义。时间维度必须使用Absolute Time绝对时间而非Relative Time相对时间。例如要分析14:23:15发生的失败需在网管中设置查询起始时间为2023-10-01T14:23:00Z结束时间为2023-10-01T14:23:59Z。使用Last 5 Minutes这种模糊范围会引入大量噪声。网元维度NSA切换涉及至少3个网元源MeNB、源SgNB、目标SgNB每个Counter只存在于特定网元。例如pmSgNbRelAtt只在源MeNB上存在pmSgNbChgAtt只在源SgNB上存在pmSgNbAddSucc只在目标SgNB上存在。翻车现场曾有工程师在目标MeNB上查pmSgNbRelAtt结果为0便断定“没有释放”实则该Counter根本不在目标MeNB上。事件类型维度同一Counter ID在不同事件类型下含义不同。以pmSgNbAddAtt为例Event Type SgNB Addition表示由B1测量触发的添加正常流程。Event Type SgNB Addition (For Handover)表示由MN间切换触发的添加目标MN决策后。Event Type SgNB Addition (For SN Change)表示由SN变更触发的添加目标SgNB决策后。排查技巧当pmSgNbAddAtt异常升高时先按Event Type分组统计可快速判断是哪种场景引发的流量激增从而缩小问题范围。3.3 基于CTR Events的“秒级”问题定位法指导书第25页列出的CTR EventsCall Trace Records是比Counter更细粒度的“手术刀”。Counter告诉你“哪里坏了”CTR Events告诉你“怎么坏的”。以下是最常用、最高效的3个CTR Event及其解读逻辑SgNBAdditionRequest源MeNB发出的添加请求。必查字段targetSgNBId目标SgNB的ID核对是否与规划一致。cause失败原因值Cause Value。若为0x0FRadio Network Layer Cause需进一步查目标SgNB的SgNBAdditionRequestAcknowledge中的cause。measResultList携带的测量结果。若为空说明eNodeB未收到UE的B1报告问题在UE或eNodeB侧。SgNBAdditionRequestAcknowledge目标SgNB返回的确认。必查字段cause核心失败原因。0x11Unknown Target ID表示目标SgNB ID未在源MeNB的ExternalGNBMO中定义0x12Resource Unavailable表示目标SgNB资源不足。rrcContainer包含NR RRC配置。若此字段为空或长度异常100字节说明目标SgNB未能生成有效配置大概率是NRCellCUMO配置错误。SgNBChangeRequired源SgNB发出的变更请求。必查字段targetSgNBId目标SgNB ID。measResultSCGSCG侧测量结果。若此字段缺失说明源SgNB未正确解析UE上报的NR A3事件问题在ReportConfigA3配置或UE能力。实操口诀查CTR先定Event Type再锁timeStamp最后抠cause和关键字段。一个SgNBAdditionRequestAcknowledge的cause0x11比翻100页Counter报表更能直击要害。4. NSA切换参数深度解析锚点关系与NR邻区的生死线参数不是配置清单上的文字而是NSA网络中流动的血液。指导书第16-18页将“锚点关系”和“NR邻区关系”列为NSA切换的两大基石绝非虚言。一线优化中80%的切换失败根源都在这两个参数的配置偏差上。本章不讲“怎么配”而是讲“为什么这么配”、“配错一格会怎样”、“如何用命令行一秒验证”。4.1 锚点关系NSA的“身份认证协议”锚点关系Anchor Relation定义了LTE小区MeNB与NR小区SgNB的绑定规则。它不是简单的“谁连谁”而是包含了严格的双向认证逻辑。指导书第17页强调“锚点关系漏配是导致SgNB添加失败的第一大原因”。核心MO与参数ExternalGNB定义外部gNodeB即SgNB的基本信息如gnbId、ipAddress。致命错误ipAddress必须是SgNB的X2接口IP而非S1接口IP。曾有站点因填错IP导致SgNB Addition Request发往黑洞Counter中pmSgNbAddAtt有值但pmSgNbAddSucc为0。ExternalGNBRelation定义MeNB与ExternalGNB之间的关系。关键参数isAllowed true允许建立X2连接。若为falseX2链路无法建立所有SgNB相关信令均失败。isHoAllowed true允许在此锚点关系下进行SgNB添加/变更。血泪教训此参数常被误认为是“邻区参数”实则它是锚点关系的全局开关。若为false即使邻区配全B1报告也会被eNodeB静默丢弃。验证命令在MeNB上执行秒级确认锚点关系状态# 查看所有ExternalGNB定义 list ExternalGNB # 查看指定ExternalGNB的Relation状态假设ExternalGNB ID为12345 get ExternalGNBRelationExternalGNBRelation-12345 isAllowed isHoAllowed # 查看X2链路状态关键 get X2LinkX2Link-12345 status # 返回statusESTABLISHED才表示链路正常注意ExternalGNBRelation的isHoAllowed与NRCellRelation的isHoAllowed是两套独立参数前者控制“能否添加SgNB”后者控制“能否变更PSCell”切勿混淆。4.2 NR邻区关系参数PSCell变更的“交通管制”NR邻区关系NRCellRelation是PSCell变更的唯一依据。指导书第18页指出“NR邻区漏配是导致SN变更失败的第二大原因”。其配置精度要求远高于LTE邻区因为NR小区PCIPhysical Cell ID复用率极高一个PCI可能对应多个物理小区。核心MO与参数NRCellRelation定义源NR小区与目标NR小区的关系。关键参数nRCellRef指向目标NR小区的引用。必须精确到NRCellCU实例不能只填PCI。例如目标小区PCI321但NRCellCU-321和NRCellCU-321-B是两个不同实例引用错误将导致SgNB Change Required被拒绝。isHoAllowed true同前PSCell变更的准入许可。qOffsetCell邻区偏置。指导书虽未详述但实操中若此值设置过大如10dB会导致UE过早上报A3引发乒乓变更过小如-5dB则UE迟迟不上报导致弱覆盖。ANR自动邻区关系的双刃剑指导书第12页提到“开启ANR时先配置锚点与NR站的X2链路”。这是关键前提ANR不会自动创建ExternalGNB和ExternalGNBRelation它只负责发现并填充NRCellRelation。若X2链路未通ANR发现的邻区也无法生效。验证ANR状态# 查看ANR功能开关 get ANRFunctionANRFunction-1 anrState # 查看ANR发现的邻区需ANR已运行一段时间 list NRCellRelation | grep autoCreated4.3 参数配置的“四步验证法”参数配完不是终点而是验证的开始。我总结了一套在割接或优化后必走的四步验证法避免“配了等于没配”的悲剧链路层验证get X2Linkxxx status确保ESTABLISHED。这是所有上层信令的基础。锚点层验证get ExternalGNBRelationxxx isAllowed isHoAllowed确保双true。邻区层验证get NRCellRelationxxx nRCellRef isHoAllowed确保nRCellRef指向正确的NRCellCU且isHoAllowedtrue。信令层验证在UE侧抓取空口信令确认RRCConnectionReconfiguration消息中scg-Config字段包含目标SgNB的正确pci和earfcn。这是最终闭环。从那以后我每次做完参数调整都强制走一遍这四步。哪怕只是改了一个qOffsetCell也要用get命令确认再用list命令扫一眼邻区列表。省下的10分钟可能就是凌晨三点少接的一个投诉电话。希望帮到你。5. 前台信令与网管分析协同构建端到端的故障定位闭环前台信令UE侧空口抓包和网管Counter/CTR是NSA问题分析的“左右手”。只看前台不知网元内部状态只看网管不知空口真实表现。指导书第19-28页将二者结合形成了一套可落地的协同分析法。本章不讲理论只给一套我在山东联通现网反复验证过的“五步定位法”每一步都对应具体命令和判断逻辑。5.1 空口信令解析读懂UE的“心跳电图”前台抓包是还原真相的第一现场。指导书第19页的“空口信令解析”部分重点在于识别关键消息中的“异常标记”。以下是我最常关注的3个消息及异常特征RRCConnectionReconfigurationMeNB发给UE正常scg-Config字段存在且scg-ConfigInfo中包含targetPhysCellId目标PSCell PCI和targetFreq目标频点。异常scg-Config字段缺失或为空。原因MeNB未收到目标SgNB的SgNB Addition Request Acknowledge或收到但rrcContainer无效。此时应立即查目标SgNB的CTR。RRCConnectionReconfigurationCompleteUE回给MeNB正常消息中criticalExtensions包含rrcReconfigurationComplete且scg-ConfigInfo中有scg-ConfigCompl字段。异常消息中scg-ConfigInfo缺失或scg-ConfigCompl为false。原因UE未能成功接入目标SgNB可能是目标SgNB信号弱、PCI冲突或scg-Config配置有误如targetFreq填错。SgNBReleaseRequestMeNB发给源SgNB正常cause字段为radioNetwork: releaseDueToEUTRANGeneratedReason0x0F表示因LTE切换而释放。异常cause为misc: unspecified0x00或radioNetwork: unknownTargetID0x11。前者多为MeNB内部错误后者表明ExternalGNBID未正确定义。实操技巧在Wireshark中过滤NSA信令使用显示过滤器lte-rrc.rrcConnectionReconfiguration || lte-rrc.rrcConnectionReconfigurationComplete || nr-rrc.rrcReconfiguration可快速聚焦关键消息。5.2 网管切换性能分析从KPI到根因的“剥洋葱”流程指导书第21页的“切换问题常规分析流程”本质是一个结构化的问题分解树。我将其提炼为“剥洋葱五步法”每一步都对应网管中的具体操作定KPI确认是哪个KPI异常SgNbAddSuccRateSgNbChgSuccRateHoExeSuccInter。锁网元根据KPI锁定核心网元如SgNbAddSuccRate异常重点查源MeNB和目标SgNB。查Counter在锁定网元上查询对应KPI的分子分母Counter如pmSgNbAddSucc/pmSgNbAddAtt确认失败是否真实发生。挖CTR若Counter确认失败立即在对应网元上查询相关CTR Event如SgNBAdditionRequestAcknowledge提取cause值。验参数根据cause值反向验证参数如cause0x11查ExternalGNBRelationcause0x12查目标SgNB的NRCellCU资源。典型案例某日SgNbAddSuccRate跌至65%。按五步法Step1KPI为SgNbAddSuccRate。Step2锁定源MeNB发起方和目标SgNB响应方。Step3查源MeNBpmSgNbAddAtt1200pmSgNbAddSucc780查目标SgNBpmSgNbAddSucc780一致排除传输问题。Step4查目标SgNB的SgNBAdditionRequestAcknowledgecause字段95%为0x12Resource Unavailable。Step5查目标SgNB的NRCellCUMO发现maxNrUeSupported100已满而当前连接UE数为102。扩容后KPI恢复。5.3 常见问题排查血泪凝结的5条避坑指南以下是我在山东联通现网踩过的坑每一条都附带“现象→原因→解决”的完整链条避免你重蹈覆辙现象SgNbAddSuccRate为0pmSgNbAddAtt有值但目标SgNB的CTR中完全查不到SgNBAdditionRequestAcknowledge。原因源MeNB的ExternalGNBMO中ipAddress填写的是SgNB的S1接口IP如10.10.10.10而非X2接口IP如10.20.20.20。SgNB Addition Request发往错误地址石沉大海。解决get ExternalGNBxxx ipAddress确认set ExternalGNBxxx ipAddress10.20.20.20修正。现象UE在NR覆盖区内移动持续上报NR A3事件但无任何SgNBChangeRequired信令。原因源SgNB的ReportConfigA3.endcActionA3EvalFail IGNORE且邻区关系中isHoAllowed false导致A3评估失败后静默丢弃。解决get ReportConfigA3xxx endcActionA3EvalFail确认set ReportConfigA3xxx endcActionA3EvalFailRELEASE同时get NRCellRelationxxx isHoAllowedset NRCellRelationxxx isHoAllowedtrue。现象SgNbChgSuccRate极低但pmSgNbChgAtt和pmSgNbChgSucc在源SgNB和目标SgNB上数值不一致源SgNB的Att远大于目标SgNB的Succ。原因目标SgNB的NRCellCUMO中nrCellState LOCKED被人工闭锁导致无法接受变更请求。解决get NRCellCUxxx nrCellStateset NRCellCUxxx nrCellStateUNLOCKED。现象MN间切换成功HoExeSuccInter100%但用户感知5G掉线SgNbAddSuccRate在目标MeNB上为0。原因目标MeNB的ExternalGNBRelation中isHoAllowed false导致其虽完成LTE切换但拒绝发起SgNB添加。解决get ExternalGNBRelationxxx isHoAllowedset ExternalGNBRelationxxx isHoAllowedtrue。现象SgNbAddSuccRate波动剧烈时高时低无明显规律。原因目标SgNB的X2链路MTUMaximum Transmission Unit设置过小如1400导致SgNB Addition Request Acknowledge中的rrcContainer通常1500字节被分片而源MeNB的X2协议栈未正确重组。解决get X2Linkxxx mtuset X2Linkxxx mtu9000需两端一致。6. 典型案例实战从“锚点漏配”到“X2链路问题”的全链路复盘指导书第28-39页的“典型案例”是整份文档的精华所在。它不是教科书式的理想案例而是从山东联通真实割接现场扒出来的“故障快照”。本章选取其中最具代表性的两个案例进行逐帧复盘展示如何将前述所有知识——信令流程、Counter、参数、CTR、验证命令——拧成一股绳完成一次漂亮的故障闭环。6.1 案例1锚点关系漏配导致变更成功率低指导书7.1.1现象某新建5G片区割接后SgNbChgSuccRate持续低于40%用户投诉“5G信号忽强忽弱”。前台抓包显示UE频繁上报NR A3但无SgNBChangeRequired。分析过程定KPISgNbChgSuccRate异常。锁网元问题在SN侧锁定源SgNBA3上报方。查CounterpmSgNbChgAtt 0证实SN侧根本未触发变更流程。挖CTR无SgNBChangeRequired无法查CTR转向参数。验参数get ReportConfigA3xxx endcActionA3EvalFail→IGNOREget NRCellRelationxxx isHoAllowed→false。但isHoAllowedfalse是预期配置该邻区暂不开放变更为何A3上报却无反应深挖list NRCellRelation | grep pci321发现目标PCI321的邻区关系存在但nRCellRef指向NRCell本文还有配套的精品资源点击获取
