尧图网站建设 
简介面向5G网络优化与通信工程从业者这是一份讲解5G切换问题诊断与优化方法的PDF资料内容从NSA与SA两种组网架构切入重点梳理PSCell变更、站内/站间切换流程以及RRC测量报告、连接重配置、随机接入等关键信令交互同时厘清gNB、eNB、AMF在切换中的角色分工。围绕切换成功率、切换时延、切换失败率等KPI指标资料详细说明了指标口径与定位思路并通过异常信令分析识别测量报告错误、信令传输异常、参数配置冲突等典型故障。后续结合真实案例给出从问题发现、信令回溯到参数调整的完整排障路径便于读者直接借鉴。整份压缩包为1个PDF文件大小约1.55MB内容精炼且目录结构清晰适合5G网络维护、优化人员及相关专业学生快速查阅。目前已有205人学习可作为现场排障与技能提升的实用参考资料。1. 5G切换问题分析从信令流程到KPI定位的一线排查路径做过5G网优的人都有个体会越是基础的切换成功率越能藏住网络问题的根因。现场最怕的不是切换失败本身而是KPI掉下去了却分不清是准备阶段失败、执行阶段失败还是完成阶段失败。这份由华为技术培训整理的《5G切换问题分析》课程材料恰好把这条链路讲全了——NSA和SA两套架构、站内站间四条主流程、成功率类KPI的counter定义、异常信令的回放方法以及实际案例里的优化动作。它不是泛泛的科普文档是能直接对着KPI和信令trace做排查的落地指南。适合基站调测、网优工程师、核心网信令分析相关岗位也适合刚接触5G移动性管理、准备从LTE切到NR场景的从业者。文章中我把流程、KPI公式、失败定位方法和几个高频踩坑点拆开讲尽量让新手能照着看信令熟手能直接对参数找问题。2. 5G切换流程回顾NSA与SA的架构差异和四条主信令流程这一章先把切换的底子打牢。5G网络不是只有一种切换NSA和SA两套架构下切换的参与网元、信令走向、失败点完全不同。如果这一层不分清楚后面看KPI很容易看错对象。2.1 NSA与SA切换场景差异PSCell变更与EN-DC双连接NSA架构下UE同时连接LTE主站和NR辅站主站是MeNBMaster eNodeB辅站是SgNBSecondary gNodeB这种跨制式双连接叫EN-DCE-UTRAN-NR Dual Connectivity。在EN-DC里主站管信令辅站管数据所以NSA下的“5G切换”实际上指的是辅站PSCell的变更不是LTE主小区的变更。课程里明确说了本课程所提到的NSA架构下的5G切换均指5G辅站小区的变更。PSCell这个词要记牢——Primary Secondary Cell辅站下的主小区。它是UE在NR侧的锚点小区PSCell一变意味着辅站整条数据链路都要重新建立或迁移。与之相对的PCell是主站下的主小区PCell不变、信令面就不动这是NSA切换能比SA切换做得更轻量的原因。但反过来如果LTE侧发生切换NR辅站也要跟着做Release/Add主站和辅站的配合一旦出问题就会出现“LTE切换成功但5G辅站没加回来”的现象用户速率瞬间被打回4G水平。SA架构则没有主站辅站之分UE、gNB、AMF三者交互。切换涉及UE、源gNB、目标gNB和核心网AMF信令要路过Xn口或Ng口。这里要记住架构选择决定了排查范围NSA切换失败大概率问题在eNB与gNB的交互配合SA切换失败则可能是gNB之间配置不一致也可能是AMF侧接口数据出了问题。2.2 四条切换信令流程拆解站内、站间、Xn、Ng各自的关键步骤课程里给出了四条主要流程。我按信令顺序拆开列每条流程标注出最可能出问题的那一步。NSA架构NR站内切换流程PSCell在同一个SgNB内部变更UE上报Measurement ReportFor NR HoMeNB收到后通过RRC Transfer转发给SgNBSgNB发起SgNB Modification Required下发RRC Connection ReconfigurationIntra-NR HoUE完成重配回复RRC Connection Reconfiguration CompleteSgNB回SgNB Modification ConfirmUE执行Random Access Procedure接入目标NR小区站内流程只有7步没有核心网参与失败点集中在第4步到第7步之间。RRC重配下发后如果UE一直不回Complete大概率是目标小区下行覆盖不够或者重配参数写错随机接入失败则要查PRACH配置和PCI冲突。NSA架构NR站间切换流程PSCell从S-SgNB换到T-SgNBUE上报Measurement ReportMeNB做RRC TransferS-SgNB发起SgNB Change Required通过MeNB向T-SgNB发SgNB Addition RequestT-SgNB回SgNB Addition Request AckMeNB向UE下发RRC Connection ReconfigurationUE回RRC Connection Reconfiguration CompleteS-SgNB回SgNB Change ConfirmT-SgNB收到SgNB Reconfiguration CompleteUE在T-SgNB执行Random Access Procedure 11a/11b. SN Status TransferS-SgNB向T-SgNB转移数据状态Data Forwarding数据转发Secondary RAT Data Volume ReportE-RAB Modification IndicationBearer ModificationEnd Marker PacketNew Path核心网路径切换完成E-RAB Modification ConfirmUE Context Release源SgNB释放上下文站间流程比站内复杂不少两个关键窗口第4步SgNB Addition Request如果被拒就是目标侧接纳问题第11到17步是数据连续性的保证这里一旦断链用户会感受到掉速或者业务中断。排查时优先看Addition请求响应时延和SN Status Transfer是否及时。SA架构NR站内切换流程最短只有5步Measurement Report → 源gNB决策Handover Decide → RRC Reconfiguration → Random Access Procedure → RRC Reconfiguration Complete。注意SA站内没有核心网参与纯基站内部完成。SA架构NR站间切换流程分两种。通过Xn口的流程Measurement Report → Handover Request → Handover Request Ack → RRC Reconfiguration → Random Access Procedure → RRC Reconfiguration Complete → Path Switch Request → Path Switch Ack → UE Context Release。通过Ng口的流程多了一步AMF转发源gNB发Handover Required给AMFAMF再向目标gNB发Handover Request后续流程类似。Xn和Ng的主要区别在于Xn流程是gNB之间直接协商后Path Switch才找AMFNg流程是所有请求都经AMF中转。如果AMF配置了目标gNB的路由却查不到上下文Ng切换的成功率会呈现一种“全小区集中恶化”的特征和Xn的散点恶化区分明显。四条流程摆在一起能看出一个规律NSA切换的信令面走得重但好在主站兜底SA切换干净但Xn链路或者Ng链路一旦出配置问题就是整片区域的切换失败。实际定位时先确认是站内还是站间再锁定是哪一段信令没走通成功率公式只是告诉你“坏了”信令流程才告诉你“坏在哪一步”。3. 5G切换KPI体系成功率公式背后的counter逻辑与统计口径KPI是切换问题定位的第一入口。但KPI公式里的分子分母每个counter的统计范围才是真正决定你能不能从数字里读出问题本质的东西。这一章把课程里的成功率类KPI拆开讲清楚。3.1 五个核心切换KPI公式、counter、测量范围课程里给出了NSA和SA两套架构下最常用的五个成功率指标。我整理成表格对照着看更直观KPI名称测量范围公式适用架构PSCell站内变更成功率小区/簇N.NsaDc.IntraSgNB.PSCell.Change.Succ / N.NsaDc.IntraSgNB.PSCell.Change.Att × 100%NSAPSCell站间变更成功率小区/簇N.NsaDc.InterSgNB.PSCell.Change.Succ / N.NsaDc.InterSgNB.PSCell.Change.Att × 100%NSANR系统内同频站内切换出成功率小区/簇N.HO.IntraFreq.IntragNB.ExecSuccOut / N.HO.IntraFreq.IntragNB.ExecAttOut × 100%SANR系统内同频站间Xn切换出成功率小区/簇N.HO.IntraFreq.Xn.IntergNB.ExecSuccOut / N.HO.IntraFreq.Xn.IntergNB.ExecAttOut × 100%SANR系统内同频站间Ng切换出成功率小区/簇N.HO.IntraFreq.Ng.IntergNB.ExecSuccOut / N.HO.IntraFreq.Ng.IntergNB.ExecAttOut × 100%SA这里有个细节值得注意课程PPT里“NR系统内同频站内切换出成功率”这页的公式分母写成了和分子一样的ExecSuccOut这大概率是课件笔误。按统计口径分母应该是ExecAttOut也就是切换执行尝试次数。你在现网取数的时候如果发现成功率算出来永远是100%就检查一下是不是取counter时把分母取成了成功次数。这种笔误在培训材料里出现很正常但落到考核指标上就是大问题。3.2 成功率公式的统计口径ExecAttOut、ExecSuccOut与“切换出”的语义这些counter的命名都带Exec说明统计的是执行阶段的成败不是准备阶段的成败。什么叫执行阶段就是源侧已经下发RRC重配、UE开始尝试接入目标小区的那一刻。准备阶段的失败不计入这些Exec counter而是体现在另外一些“准备成功率”类指标或信令失败Counter里。所以看成功率KPI时一定要搞清楚统计口径ExecAttOut是从源小区发起的执行尝试次数ExecSuccOut是其中成功的次数。一次切换如果在准备阶段就被目标小区拒绝不会进这个分母如果RRC重配已下发但UE没回Complete超时后才会计为一次执行失败。不同厂商的counter定义会有细微差别但基本逻辑一致。取数时建议同时把Attempt和Succ两个counter一起拉出来算一下差值这个差值就是在“执行窗口”内丢掉的那部分切换。“切换出成功率”和“切换入成功率”也要分清楚。出是从本小区发起切换去别的小区入是别的UE切入本小区。出成功率低问题大概率在本小区的测量配置、邻区配置或下行覆盖入成功率低问题大概率在目标侧的接纳能力、随机接入配置或上行干扰。课程里这五个KPI全是以“变更/切换出”为口径实际分析时再配合每个小区的切入成功率就能把问题扇区定位到“源”还是“目标”。3.3 KPI到问题阶段的映射从数字到信令的桥成功率类KPI只是哨兵真正定位要靠把KPI拆到阶段。我一般把切换拆成三个阶段来对counter准备阶段UE上报测量报告开始到源侧收到目标侧的准备响应为止。这个阶段出问题一般是邻区漏配、外部小区定义错误、目标小区接纳失败、Xn/Ng链路不通。看KPI的话注意准备失败次数和准备成功率。执行阶段从源侧下发RRC重配开始到UE在目标小区完成随机接入为止。这个阶段失败通常是下行覆盖差、PRACH配置冲突、干扰导致随机接入失败、T304定时器超时。对应看随机接入失败次数的counter和T304超时相关的失败统计。完成阶段UE完成随机接入后到核心网路径切换完成、源侧释放上下文为止。这个阶段问题较少但一旦出现就是核心网侧的路由、承载修改问题。比如Path Switch Request发过去AMF不回Ack或者源gNB迟迟收不到UE Context Release。课程里的KPI章节其实没有明确写出三阶段划分但按照信令流程的落点反推这是最实用的分析框架。拿到一个成功率掉点的小区先看是站内还是站间再看是准备失败多还是执行失败多基本能锁定排查范围。把大KPI拆成三个阶段的细粒度counter是切换问题分析从“猜测”走向“定位”的第一步。4. 切换KPI问题分析成功率掉点的定位方法与实践路径KPI掉点之后怎么查这一章把定位思路和操作路径展开。核心原则是先分场景、再分阶段、后看信令。不要一上来就抓log那样会淹没在无用信息里。4.1 定位前的场景拆分站内站间、同频异频、NSA与SA拿到一个切换成功率恶化的指标先别急着看细节先拆场景。第一步区分站内和站间。站内切换成功率低问题几乎必然在基站自身内部——测量配置、小区间邻区定义、目标小区接纳能力、PCI冲突。站间切换成功率低才需要看Xn口或Ng口的链路状态以及目标基站的配置是否一致。课程里四个KPI分别对应站内、站间Xn、站间Ng这个区分本身就是提示。第二步区分NSA和SA。NSA场景看的是PSCell变更成功率问题集中在辅站变更过程中的信令交互比如SgNB Modification Request被拒、SgNB Addition Request超时。SA场景看的是NR系统内切换成功率重点转移到gNB之间或者gNB与AMF之间的接口配置。第三步看周边是否存在同频干扰或异频优先级配错的问题。课程里的KPI明确写着“同频”说明异频切换不在这一组指标里。但现场往往是同频、异频切换混在一起异频测量配置压制了同频测量上报会把同频切换成功率拉低。如果看到某个扇区同频切换成功率异常而邻区正常先查异频测量对象的配置优先级有时候是这个间接原因。4.2 准备阶段失败的主要表现与核查路径准备阶段失败在信令里的表现最典型的是目标侧回了Handover Preparation Failure或者SgNB Addition Request被拒。对应到参数层面按以下顺序核查邻区关系核查。从源小区到目标小区同频邻区、异频邻区、外部小区定义三项都要查。常见问题是只配了同频邻区没配异频邻区或者外部小区里PCI、频点、TAC定义与目标小区实际配置不一致。LTE时代常见的“邻区漏配”问题在5G里一样存在而且因为NSA涉及LTE和NR两张网的邻区关系漏配概率更高。核查时把漏配邻区补上成功率往往能立刻回升。Xn口状态核查。站间Xn切换依赖gNB之间的Xn链路如果Xn链路中断或SCTP偶联断链未恢复切换请求根本送不到目标gNB。核查命令一般是查Xn接口状态和SCTP偶联状态确认链路正常再谈其他。Ng口同理检查gNB与AMF之间的NG链路状态。目标小区接纳能力核查。目标小区接纳失败通常和无线资源不足、license受限、小区状态有关。如果目标小区被人为闭塞或者license容量跑满切换请求会被直接拒绝。这种问题在KPI上的特征是切入某个特定小区的成功率低而该小区切往周边的成功率正常。排查时直接看目标小区的状态和用户数、资源利用率。AMF路由核查Ng切换。SA的Ng切换中AMF要在源gNB和目标gNB之间转发Handover Request如果AMF侧配置的目标gNB路由错误或上下文丢失Ng切换会集中失败。核查AMF上的gNB列表确认目标侧gNB的标识、PLMN、TAC是否与现网一致。这种问题如果出现往往是一个AMF下的多个小区同时失败范围性很强。4.3 执行阶段失败的典型信令表现与参数调整执行阶段的失败信令表现非常集中源gNB已经下发了RRC Reconfiguration但迟迟等不到UE的RRC Reconfiguration Complete最终因为T304超时判定失败。T304定时器核查。T304是切换执行期间允许UE完成随机接入的最大时限现网常用值在1000ms到2000ms之间。如果目标小区覆盖边缘处T304设得太短UE还没完成随机接入就被源侧判定失败。适当调长T304能减少边缘切换失败但要注意调长会让失败的切换占用更多资源通常不作为首选手段先解决覆盖问题。下行覆盖核查。切换执行时UE要解调目标小区的信令如果目标小区信号质量差RRC重配下发后UE根本读不到也就无从执行切换。核查方法是对目标小区的参考信号覆盖做路测或扫频确认切换带内的RSRP是否达到可接入门限。常见问题是切换带设计不合理、站间距过大导致切换带无主导覆盖。随机接入参数核查。随机接入失败可能会体现在切换执行失败里也可能单独统计。核查PRACH根序列配置、前导格式、rach失败重试次数。同频组网下要特别注意PCI和PRACH根序列的冲突两个小区使用相同PCI或相同根序列会导致随机接入互相干扰。NSA还有一点特殊UE在LTE侧发起随机接入和NR侧发起随机接入的频点是分开的NR侧随机接入失败要查NR小区的PRACH配置。4.4 完成阶段失败Path Switch与会话连续性这一阶段的问题占比不高但一出现就涉及核心网排查成本高。SA的Xn切换中UE完成随机接入后目标gNB向AMF发起Path Switch RequestAMF更新用户面路径后回Path Switch Ack。如果Path Switch失败UE已经接入目标小区但核心网还认为数据该往源gNB送结果就是用户看着有信号却没有业务流量。完成阶段失败的原因通常有AMF上用户上下文丢失、路径切换消息超时、核心网SGW路径更新失败。看KPI的话这一阶段失败往往不体现在切换成功率上而是体现在“切换成功后用户速率异常”或者“切换完成后立即掉线”。排查时抓取目标gNB到AMF的NGAP信令看Path Switch Request有没有发出去、AMF有没有回响应、响应里的cause code是什么。课程里的19步站间切换流程第17步New Path和第18步E-RAB Modification Confirm对应的就是这段查信令时对着这两步看就行。5. 异常切换信令分析与问题优化常见陷阱与排查手册信令分析是切换问题定位的最后一步也是信息量最大的一步。这一章先讲排查方法再写几条我实际踩过的坑。5.1 异常切换信令的分析方法从trace里找“第一失败点”拿到一段切换失败的信令trace不要从头到尾逐条读那样效率太低。我的做法是倒着看先找失败响应的消息——比如Handover Failure、SgNB Modification Failure、RRC Reconfiguration Complete缺失——再从这条失败消息往回找原因。具体步骤是先用UE的标识过滤出整个切换过程的所有信令按时间排序定位到失败点那几条消息往前翻三条消息左右看是否出现目标侧拒绝、源侧超时、测量报告异常这三类迹象。如果看到的是目标侧回拒绝消息cause code会直接告诉你原因比如“radio network layer cause: unknown-target-identifier”就说明目标小区标识错了“not supported”则偏向配置能力问题。课程里提到的“异常切换信令分析”本质就是在做这件事。NSA场景下还要额外注意LTE侧和NR侧各自的RRC消息要分开看UE在LTE主站上的信令和在NR辅站上的信令不在同一段trace里分析时要把两条链路的时序对齐。我通常会同时抓MeNB侧和SgNB侧的log再按时间戳对齐不然会误判消息顺序。5.2 避坑记录成功率算出来是100%的counter陷阱现象NR同频站内切换出成功率长期显示100%无论怎么优化都不动。原因取counter时把分母取成了ExecSuccOut也就是分子分母同一批成功次数。课程PPT里这页的公式恰好有同样的笔误容易误导取数的人。解决把分母换成ExecAttOut重新统计。此后每次写取数脚本我都会先核对一遍counter的完整命名确认Att和Succ都取了再套公式。这个坑的成本极低但能让你白白怀疑半天网络。5.3 避坑记录NSA的PSCell变更失败率低但用户速率集体下降现象NSA站内PSCell变更成功率达标但切换后用户吞吐率明显下降部分用户测速掉到4G水平。原因PSCell变更虽然成功但变更过程中UE在NR侧的数据承载被先释放后添加数据转发时延过长导致切换完成后的前几秒速率不稳定。课程里站间流程第12步Data Forwarding、第16步End Marker Packet对应的就是这段数据连续性处理。成功率KPI只统计信令成败不统计数据面中断时长。解决分析时不能只看成功率要同时看切换完成后的速率恢复时延。优化手段包括检查数据转发路径是否经过核心网绕路、确认T-SgNB的承载是否预先建立尽量避免“先断后建”的过程。从那以后我分析NSA切换问题会同时拉成功率和切换完成的速率样本两个指标一起看才算完整。5.4 避坑记录随机接入失败率居高不下的PCI混淆现象某同频组网区域多个小区之间切换失败率异常失败集中在随机接入阶段。原因两个距离较远的5G小区配置了相同PCIUE在切换带上测量时把两个不同小区识别成了同一个小区导致目标gNB收到的随机接入前导对应的上下文不对随机接入反复失败。解决核查周边小区的PCI分配确认PCI模三、模三十不冲突并避免复用距离过近。改完PCI后随机接入失败率下降明显。此后每次扩容或新站入网我都会跑一遍PCI冲突自检防止这类问题带到现网。5.5 避坑记录Xn切换大面积失败问题却不在Xn口配置现象某SA区域所有站间Xn切换成功率同时掉到50%以下核查Xn链路状态全部正常邻区关系完整。原因排查到最后是AMF上用户上下文最大存活时间被误调小大量UE在切换前已经被核心网释放了上下文。Xn切换的Path Switch步骤需要AMF配合AMF如果查不到用户上下文Path Switch Request会被拒。解决检查AMF的用户上下文老化时间配置恢复默认值后Xn切换成功率回升。这是一个典型的“成功率KPI指向gNB根因却在核心网参数”的案例。之后我养成了习惯遇到区域性集中恶化先查核心网侧配置再查无线侧。6. 5G切换案例复盘与参数优化验证三个实战场景的处理过程课程最后一部分放了案例这部分信息密度大适合从“会看”到“会调”进阶。我选三个有代表性的场景做复盘再讲一个我自己常用的验证习惯。6.1 场景一NSA PSCell站间变更成功率低现场情况是某个簇的PSCell站间变更成功率在忙时掉到93%以下闲时恢复。KPI拆开后发现SgNB Addition Request阶段失败占大头重点核查目标侧接纳能力。进一步看信令目标SgNB回的Addition Request Ack时延超过1秒判定为目标侧资源不足。优化动作是把目标SgNB的容量参数做调整开放了部分预留资源给切换业务同时对该簇的NSA辅站做负荷均衡。调整后成功率回升到98%以上。这个案例的关键在于忙时恶化的KPI优先怀疑资源竞争问题而不是配置问题。配置问题通常全天候都存在不会只在忙时出现。6.2 场景二SA同频站内切换成功率掉点另一个场景是SA站内切换失败集中在一个小区的边缘区域表现为RRC Reconfiguration后收不到CompleteT304超时。核查目标小区的下行RSRP发现切换带内RSRP只有-110dBm左右已经处于接入边缘。原因是用边站的下倾角偏大、覆盖收缩切换带落在了弱覆盖区。优化动作是调整天线下倾角把切换带推到RSRP更好的位置同时把T304从1000ms调整到1500ms作为过渡。调整后站内切换成功率恢复正常。这类问题的特征是单小区、单方向恶化和站间批量失败完全不同。排查时用路测数据确认覆盖再决定是调天线还是调参数。天线调整优先T304调长属于临时缓解手段。6.3 场景三Xn切换成功后用户掉线第三种情况更隐蔽Xn切换成功率显示正常但切换完成后部分用户立即掉线。抓信令看到Path Switch Request成功AMF回了Ack但用户在目标小区的上行失步。核查目标小区的随机接入配置发现该小区的前导格式和周边小区不一致UE从源小区带过来的配置在目标侧不适用导致上行同步失败。统一前导格式配置后问题解决。这类问题提醒我们成功率KPI正常不代表用户体验正常。切换完成后是否掉线、用户速率是否达标都要纳入验证范围。看退出成功率KPI之外我还会关注RRC重建比例和切换后掉话率它们是KPI之外的“第二双眼睛”。在合入现网以后的每一次切换参数修改我都会做前后对比修改前取三天KPI基线修改后二十四小时跟踪成功率、RRC重建率、用户速率三个维度不达标就回滚参数。从那以后的每次5G切换优化我都会强制走一遍这个对照流程先抓取基线数据再执行改动并观察足够时长最后做前后指标对比这套方法帮我避免了很多次调错参数还不自知的情况。宕机事故少了、投诉少了用户侧感知也稳得住。希望帮到你。本文还有配套的精品资源点击获取 5G切换问题分析：从信令流程到KPI定位的一线排查路径
简介面向5G网络优化与通信工程从业者这是一份讲解5G切换问题诊断与优化方法的PDF资料内容从NSA与SA两种组网架构切入重点梳理PSCell变更、站内/站间切换流程以及RRC测量报告、连接重配置、随机接入等关键信令交互同时厘清gNB、eNB、AMF在切换中的角色分工。围绕切换成功率、切换时延、切换失败率等KPI指标资料详细说明了指标口径与定位思路并通过异常信令分析识别测量报告错误、信令传输异常、参数配置冲突等典型故障。后续结合真实案例给出从问题发现、信令回溯到参数调整的完整排障路径便于读者直接借鉴。整份压缩包为1个PDF文件大小约1.55MB内容精炼且目录结构清晰适合5G网络维护、优化人员及相关专业学生快速查阅。目前已有205人学习可作为现场排障与技能提升的实用参考资料。1. 5G切换问题分析从信令流程到KPI定位的一线排查路径做过5G网优的人都有个体会越是基础的切换成功率越能藏住网络问题的根因。现场最怕的不是切换失败本身而是KPI掉下去了却分不清是准备阶段失败、执行阶段失败还是完成阶段失败。这份由华为技术培训整理的《5G切换问题分析》课程材料恰好把这条链路讲全了——NSA和SA两套架构、站内站间四条主流程、成功率类KPI的counter定义、异常信令的回放方法以及实际案例里的优化动作。它不是泛泛的科普文档是能直接对着KPI和信令trace做排查的落地指南。适合基站调测、网优工程师、核心网信令分析相关岗位也适合刚接触5G移动性管理、准备从LTE切到NR场景的从业者。文章中我把流程、KPI公式、失败定位方法和几个高频踩坑点拆开讲尽量让新手能照着看信令熟手能直接对参数找问题。2. 5G切换流程回顾NSA与SA的架构差异和四条主信令流程这一章先把切换的底子打牢。5G网络不是只有一种切换NSA和SA两套架构下切换的参与网元、信令走向、失败点完全不同。如果这一层不分清楚后面看KPI很容易看错对象。2.1 NSA与SA切换场景差异PSCell变更与EN-DC双连接NSA架构下UE同时连接LTE主站和NR辅站主站是MeNBMaster eNodeB辅站是SgNBSecondary gNodeB这种跨制式双连接叫EN-DCE-UTRAN-NR Dual Connectivity。在EN-DC里主站管信令辅站管数据所以NSA下的“5G切换”实际上指的是辅站PSCell的变更不是LTE主小区的变更。课程里明确说了本课程所提到的NSA架构下的5G切换均指5G辅站小区的变更。PSCell这个词要记牢——Primary Secondary Cell辅站下的主小区。它是UE在NR侧的锚点小区PSCell一变意味着辅站整条数据链路都要重新建立或迁移。与之相对的PCell是主站下的主小区PCell不变、信令面就不动这是NSA切换能比SA切换做得更轻量的原因。但反过来如果LTE侧发生切换NR辅站也要跟着做Release/Add主站和辅站的配合一旦出问题就会出现“LTE切换成功但5G辅站没加回来”的现象用户速率瞬间被打回4G水平。SA架构则没有主站辅站之分UE、gNB、AMF三者交互。切换涉及UE、源gNB、目标gNB和核心网AMF信令要路过Xn口或Ng口。这里要记住架构选择决定了排查范围NSA切换失败大概率问题在eNB与gNB的交互配合SA切换失败则可能是gNB之间配置不一致也可能是AMF侧接口数据出了问题。2.2 四条切换信令流程拆解站内、站间、Xn、Ng各自的关键步骤课程里给出了四条主要流程。我按信令顺序拆开列每条流程标注出最可能出问题的那一步。NSA架构NR站内切换流程PSCell在同一个SgNB内部变更UE上报Measurement ReportFor NR HoMeNB收到后通过RRC Transfer转发给SgNBSgNB发起SgNB Modification Required下发RRC Connection ReconfigurationIntra-NR HoUE完成重配回复RRC Connection Reconfiguration CompleteSgNB回SgNB Modification ConfirmUE执行Random Access Procedure接入目标NR小区站内流程只有7步没有核心网参与失败点集中在第4步到第7步之间。RRC重配下发后如果UE一直不回Complete大概率是目标小区下行覆盖不够或者重配参数写错随机接入失败则要查PRACH配置和PCI冲突。NSA架构NR站间切换流程PSCell从S-SgNB换到T-SgNBUE上报Measurement ReportMeNB做RRC TransferS-SgNB发起SgNB Change Required通过MeNB向T-SgNB发SgNB Addition RequestT-SgNB回SgNB Addition Request AckMeNB向UE下发RRC Connection ReconfigurationUE回RRC Connection Reconfiguration CompleteS-SgNB回SgNB Change ConfirmT-SgNB收到SgNB Reconfiguration CompleteUE在T-SgNB执行Random Access Procedure 11a/11b. SN Status TransferS-SgNB向T-SgNB转移数据状态Data Forwarding数据转发Secondary RAT Data Volume ReportE-RAB Modification IndicationBearer ModificationEnd Marker PacketNew Path核心网路径切换完成E-RAB Modification ConfirmUE Context Release源SgNB释放上下文站间流程比站内复杂不少两个关键窗口第4步SgNB Addition Request如果被拒就是目标侧接纳问题第11到17步是数据连续性的保证这里一旦断链用户会感受到掉速或者业务中断。排查时优先看Addition请求响应时延和SN Status Transfer是否及时。SA架构NR站内切换流程最短只有5步Measurement Report → 源gNB决策Handover Decide → RRC Reconfiguration → Random Access Procedure → RRC Reconfiguration Complete。注意SA站内没有核心网参与纯基站内部完成。SA架构NR站间切换流程分两种。通过Xn口的流程Measurement Report → Handover Request → Handover Request Ack → RRC Reconfiguration → Random Access Procedure → RRC Reconfiguration Complete → Path Switch Request → Path Switch Ack → UE Context Release。通过Ng口的流程多了一步AMF转发源gNB发Handover Required给AMFAMF再向目标gNB发Handover Request后续流程类似。Xn和Ng的主要区别在于Xn流程是gNB之间直接协商后Path Switch才找AMFNg流程是所有请求都经AMF中转。如果AMF配置了目标gNB的路由却查不到上下文Ng切换的成功率会呈现一种“全小区集中恶化”的特征和Xn的散点恶化区分明显。四条流程摆在一起能看出一个规律NSA切换的信令面走得重但好在主站兜底SA切换干净但Xn链路或者Ng链路一旦出配置问题就是整片区域的切换失败。实际定位时先确认是站内还是站间再锁定是哪一段信令没走通成功率公式只是告诉你“坏了”信令流程才告诉你“坏在哪一步”。3. 5G切换KPI体系成功率公式背后的counter逻辑与统计口径KPI是切换问题定位的第一入口。但KPI公式里的分子分母每个counter的统计范围才是真正决定你能不能从数字里读出问题本质的东西。这一章把课程里的成功率类KPI拆开讲清楚。3.1 五个核心切换KPI公式、counter、测量范围课程里给出了NSA和SA两套架构下最常用的五个成功率指标。我整理成表格对照着看更直观KPI名称测量范围公式适用架构PSCell站内变更成功率小区/簇N.NsaDc.IntraSgNB.PSCell.Change.Succ / N.NsaDc.IntraSgNB.PSCell.Change.Att × 100%NSAPSCell站间变更成功率小区/簇N.NsaDc.InterSgNB.PSCell.Change.Succ / N.NsaDc.InterSgNB.PSCell.Change.Att × 100%NSANR系统内同频站内切换出成功率小区/簇N.HO.IntraFreq.IntragNB.ExecSuccOut / N.HO.IntraFreq.IntragNB.ExecAttOut × 100%SANR系统内同频站间Xn切换出成功率小区/簇N.HO.IntraFreq.Xn.IntergNB.ExecSuccOut / N.HO.IntraFreq.Xn.IntergNB.ExecAttOut × 100%SANR系统内同频站间Ng切换出成功率小区/簇N.HO.IntraFreq.Ng.IntergNB.ExecSuccOut / N.HO.IntraFreq.Ng.IntergNB.ExecAttOut × 100%SA这里有个细节值得注意课程PPT里“NR系统内同频站内切换出成功率”这页的公式分母写成了和分子一样的ExecSuccOut这大概率是课件笔误。按统计口径分母应该是ExecAttOut也就是切换执行尝试次数。你在现网取数的时候如果发现成功率算出来永远是100%就检查一下是不是取counter时把分母取成了成功次数。这种笔误在培训材料里出现很正常但落到考核指标上就是大问题。3.2 成功率公式的统计口径ExecAttOut、ExecSuccOut与“切换出”的语义这些counter的命名都带Exec说明统计的是执行阶段的成败不是准备阶段的成败。什么叫执行阶段就是源侧已经下发RRC重配、UE开始尝试接入目标小区的那一刻。准备阶段的失败不计入这些Exec counter而是体现在另外一些“准备成功率”类指标或信令失败Counter里。所以看成功率KPI时一定要搞清楚统计口径ExecAttOut是从源小区发起的执行尝试次数ExecSuccOut是其中成功的次数。一次切换如果在准备阶段就被目标小区拒绝不会进这个分母如果RRC重配已下发但UE没回Complete超时后才会计为一次执行失败。不同厂商的counter定义会有细微差别但基本逻辑一致。取数时建议同时把Attempt和Succ两个counter一起拉出来算一下差值这个差值就是在“执行窗口”内丢掉的那部分切换。“切换出成功率”和“切换入成功率”也要分清楚。出是从本小区发起切换去别的小区入是别的UE切入本小区。出成功率低问题大概率在本小区的测量配置、邻区配置或下行覆盖入成功率低问题大概率在目标侧的接纳能力、随机接入配置或上行干扰。课程里这五个KPI全是以“变更/切换出”为口径实际分析时再配合每个小区的切入成功率就能把问题扇区定位到“源”还是“目标”。3.3 KPI到问题阶段的映射从数字到信令的桥成功率类KPI只是哨兵真正定位要靠把KPI拆到阶段。我一般把切换拆成三个阶段来对counter准备阶段UE上报测量报告开始到源侧收到目标侧的准备响应为止。这个阶段出问题一般是邻区漏配、外部小区定义错误、目标小区接纳失败、Xn/Ng链路不通。看KPI的话注意准备失败次数和准备成功率。执行阶段从源侧下发RRC重配开始到UE在目标小区完成随机接入为止。这个阶段失败通常是下行覆盖差、PRACH配置冲突、干扰导致随机接入失败、T304定时器超时。对应看随机接入失败次数的counter和T304超时相关的失败统计。完成阶段UE完成随机接入后到核心网路径切换完成、源侧释放上下文为止。这个阶段问题较少但一旦出现就是核心网侧的路由、承载修改问题。比如Path Switch Request发过去AMF不回Ack或者源gNB迟迟收不到UE Context Release。课程里的KPI章节其实没有明确写出三阶段划分但按照信令流程的落点反推这是最实用的分析框架。拿到一个成功率掉点的小区先看是站内还是站间再看是准备失败多还是执行失败多基本能锁定排查范围。把大KPI拆成三个阶段的细粒度counter是切换问题分析从“猜测”走向“定位”的第一步。4. 切换KPI问题分析成功率掉点的定位方法与实践路径KPI掉点之后怎么查这一章把定位思路和操作路径展开。核心原则是先分场景、再分阶段、后看信令。不要一上来就抓log那样会淹没在无用信息里。4.1 定位前的场景拆分站内站间、同频异频、NSA与SA拿到一个切换成功率恶化的指标先别急着看细节先拆场景。第一步区分站内和站间。站内切换成功率低问题几乎必然在基站自身内部——测量配置、小区间邻区定义、目标小区接纳能力、PCI冲突。站间切换成功率低才需要看Xn口或Ng口的链路状态以及目标基站的配置是否一致。课程里四个KPI分别对应站内、站间Xn、站间Ng这个区分本身就是提示。第二步区分NSA和SA。NSA场景看的是PSCell变更成功率问题集中在辅站变更过程中的信令交互比如SgNB Modification Request被拒、SgNB Addition Request超时。SA场景看的是NR系统内切换成功率重点转移到gNB之间或者gNB与AMF之间的接口配置。第三步看周边是否存在同频干扰或异频优先级配错的问题。课程里的KPI明确写着“同频”说明异频切换不在这一组指标里。但现场往往是同频、异频切换混在一起异频测量配置压制了同频测量上报会把同频切换成功率拉低。如果看到某个扇区同频切换成功率异常而邻区正常先查异频测量对象的配置优先级有时候是这个间接原因。4.2 准备阶段失败的主要表现与核查路径准备阶段失败在信令里的表现最典型的是目标侧回了Handover Preparation Failure或者SgNB Addition Request被拒。对应到参数层面按以下顺序核查邻区关系核查。从源小区到目标小区同频邻区、异频邻区、外部小区定义三项都要查。常见问题是只配了同频邻区没配异频邻区或者外部小区里PCI、频点、TAC定义与目标小区实际配置不一致。LTE时代常见的“邻区漏配”问题在5G里一样存在而且因为NSA涉及LTE和NR两张网的邻区关系漏配概率更高。核查时把漏配邻区补上成功率往往能立刻回升。Xn口状态核查。站间Xn切换依赖gNB之间的Xn链路如果Xn链路中断或SCTP偶联断链未恢复切换请求根本送不到目标gNB。核查命令一般是查Xn接口状态和SCTP偶联状态确认链路正常再谈其他。Ng口同理检查gNB与AMF之间的NG链路状态。目标小区接纳能力核查。目标小区接纳失败通常和无线资源不足、license受限、小区状态有关。如果目标小区被人为闭塞或者license容量跑满切换请求会被直接拒绝。这种问题在KPI上的特征是切入某个特定小区的成功率低而该小区切往周边的成功率正常。排查时直接看目标小区的状态和用户数、资源利用率。AMF路由核查Ng切换。SA的Ng切换中AMF要在源gNB和目标gNB之间转发Handover Request如果AMF侧配置的目标gNB路由错误或上下文丢失Ng切换会集中失败。核查AMF上的gNB列表确认目标侧gNB的标识、PLMN、TAC是否与现网一致。这种问题如果出现往往是一个AMF下的多个小区同时失败范围性很强。4.3 执行阶段失败的典型信令表现与参数调整执行阶段的失败信令表现非常集中源gNB已经下发了RRC Reconfiguration但迟迟等不到UE的RRC Reconfiguration Complete最终因为T304超时判定失败。T304定时器核查。T304是切换执行期间允许UE完成随机接入的最大时限现网常用值在1000ms到2000ms之间。如果目标小区覆盖边缘处T304设得太短UE还没完成随机接入就被源侧判定失败。适当调长T304能减少边缘切换失败但要注意调长会让失败的切换占用更多资源通常不作为首选手段先解决覆盖问题。下行覆盖核查。切换执行时UE要解调目标小区的信令如果目标小区信号质量差RRC重配下发后UE根本读不到也就无从执行切换。核查方法是对目标小区的参考信号覆盖做路测或扫频确认切换带内的RSRP是否达到可接入门限。常见问题是切换带设计不合理、站间距过大导致切换带无主导覆盖。随机接入参数核查。随机接入失败可能会体现在切换执行失败里也可能单独统计。核查PRACH根序列配置、前导格式、rach失败重试次数。同频组网下要特别注意PCI和PRACH根序列的冲突两个小区使用相同PCI或相同根序列会导致随机接入互相干扰。NSA还有一点特殊UE在LTE侧发起随机接入和NR侧发起随机接入的频点是分开的NR侧随机接入失败要查NR小区的PRACH配置。4.4 完成阶段失败Path Switch与会话连续性这一阶段的问题占比不高但一出现就涉及核心网排查成本高。SA的Xn切换中UE完成随机接入后目标gNB向AMF发起Path Switch RequestAMF更新用户面路径后回Path Switch Ack。如果Path Switch失败UE已经接入目标小区但核心网还认为数据该往源gNB送结果就是用户看着有信号却没有业务流量。完成阶段失败的原因通常有AMF上用户上下文丢失、路径切换消息超时、核心网SGW路径更新失败。看KPI的话这一阶段失败往往不体现在切换成功率上而是体现在“切换成功后用户速率异常”或者“切换完成后立即掉线”。排查时抓取目标gNB到AMF的NGAP信令看Path Switch Request有没有发出去、AMF有没有回响应、响应里的cause code是什么。课程里的19步站间切换流程第17步New Path和第18步E-RAB Modification Confirm对应的就是这段查信令时对着这两步看就行。5. 异常切换信令分析与问题优化常见陷阱与排查手册信令分析是切换问题定位的最后一步也是信息量最大的一步。这一章先讲排查方法再写几条我实际踩过的坑。5.1 异常切换信令的分析方法从trace里找“第一失败点”拿到一段切换失败的信令trace不要从头到尾逐条读那样效率太低。我的做法是倒着看先找失败响应的消息——比如Handover Failure、SgNB Modification Failure、RRC Reconfiguration Complete缺失——再从这条失败消息往回找原因。具体步骤是先用UE的标识过滤出整个切换过程的所有信令按时间排序定位到失败点那几条消息往前翻三条消息左右看是否出现目标侧拒绝、源侧超时、测量报告异常这三类迹象。如果看到的是目标侧回拒绝消息cause code会直接告诉你原因比如“radio network layer cause: unknown-target-identifier”就说明目标小区标识错了“not supported”则偏向配置能力问题。课程里提到的“异常切换信令分析”本质就是在做这件事。NSA场景下还要额外注意LTE侧和NR侧各自的RRC消息要分开看UE在LTE主站上的信令和在NR辅站上的信令不在同一段trace里分析时要把两条链路的时序对齐。我通常会同时抓MeNB侧和SgNB侧的log再按时间戳对齐不然会误判消息顺序。5.2 避坑记录成功率算出来是100%的counter陷阱现象NR同频站内切换出成功率长期显示100%无论怎么优化都不动。原因取counter时把分母取成了ExecSuccOut也就是分子分母同一批成功次数。课程PPT里这页的公式恰好有同样的笔误容易误导取数的人。解决把分母换成ExecAttOut重新统计。此后每次写取数脚本我都会先核对一遍counter的完整命名确认Att和Succ都取了再套公式。这个坑的成本极低但能让你白白怀疑半天网络。5.3 避坑记录NSA的PSCell变更失败率低但用户速率集体下降现象NSA站内PSCell变更成功率达标但切换后用户吞吐率明显下降部分用户测速掉到4G水平。原因PSCell变更虽然成功但变更过程中UE在NR侧的数据承载被先释放后添加数据转发时延过长导致切换完成后的前几秒速率不稳定。课程里站间流程第12步Data Forwarding、第16步End Marker Packet对应的就是这段数据连续性处理。成功率KPI只统计信令成败不统计数据面中断时长。解决分析时不能只看成功率要同时看切换完成后的速率恢复时延。优化手段包括检查数据转发路径是否经过核心网绕路、确认T-SgNB的承载是否预先建立尽量避免“先断后建”的过程。从那以后我分析NSA切换问题会同时拉成功率和切换完成的速率样本两个指标一起看才算完整。5.4 避坑记录随机接入失败率居高不下的PCI混淆现象某同频组网区域多个小区之间切换失败率异常失败集中在随机接入阶段。原因两个距离较远的5G小区配置了相同PCIUE在切换带上测量时把两个不同小区识别成了同一个小区导致目标gNB收到的随机接入前导对应的上下文不对随机接入反复失败。解决核查周边小区的PCI分配确认PCI模三、模三十不冲突并避免复用距离过近。改完PCI后随机接入失败率下降明显。此后每次扩容或新站入网我都会跑一遍PCI冲突自检防止这类问题带到现网。5.5 避坑记录Xn切换大面积失败问题却不在Xn口配置现象某SA区域所有站间Xn切换成功率同时掉到50%以下核查Xn链路状态全部正常邻区关系完整。原因排查到最后是AMF上用户上下文最大存活时间被误调小大量UE在切换前已经被核心网释放了上下文。Xn切换的Path Switch步骤需要AMF配合AMF如果查不到用户上下文Path Switch Request会被拒。解决检查AMF的用户上下文老化时间配置恢复默认值后Xn切换成功率回升。这是一个典型的“成功率KPI指向gNB根因却在核心网参数”的案例。之后我养成了习惯遇到区域性集中恶化先查核心网侧配置再查无线侧。6. 5G切换案例复盘与参数优化验证三个实战场景的处理过程课程最后一部分放了案例这部分信息密度大适合从“会看”到“会调”进阶。我选三个有代表性的场景做复盘再讲一个我自己常用的验证习惯。6.1 场景一NSA PSCell站间变更成功率低现场情况是某个簇的PSCell站间变更成功率在忙时掉到93%以下闲时恢复。KPI拆开后发现SgNB Addition Request阶段失败占大头重点核查目标侧接纳能力。进一步看信令目标SgNB回的Addition Request Ack时延超过1秒判定为目标侧资源不足。优化动作是把目标SgNB的容量参数做调整开放了部分预留资源给切换业务同时对该簇的NSA辅站做负荷均衡。调整后成功率回升到98%以上。这个案例的关键在于忙时恶化的KPI优先怀疑资源竞争问题而不是配置问题。配置问题通常全天候都存在不会只在忙时出现。6.2 场景二SA同频站内切换成功率掉点另一个场景是SA站内切换失败集中在一个小区的边缘区域表现为RRC Reconfiguration后收不到CompleteT304超时。核查目标小区的下行RSRP发现切换带内RSRP只有-110dBm左右已经处于接入边缘。原因是用边站的下倾角偏大、覆盖收缩切换带落在了弱覆盖区。优化动作是调整天线下倾角把切换带推到RSRP更好的位置同时把T304从1000ms调整到1500ms作为过渡。调整后站内切换成功率恢复正常。这类问题的特征是单小区、单方向恶化和站间批量失败完全不同。排查时用路测数据确认覆盖再决定是调天线还是调参数。天线调整优先T304调长属于临时缓解手段。6.3 场景三Xn切换成功后用户掉线第三种情况更隐蔽Xn切换成功率显示正常但切换完成后部分用户立即掉线。抓信令看到Path Switch Request成功AMF回了Ack但用户在目标小区的上行失步。核查目标小区的随机接入配置发现该小区的前导格式和周边小区不一致UE从源小区带过来的配置在目标侧不适用导致上行同步失败。统一前导格式配置后问题解决。这类问题提醒我们成功率KPI正常不代表用户体验正常。切换完成后是否掉线、用户速率是否达标都要纳入验证范围。看退出成功率KPI之外我还会关注RRC重建比例和切换后掉话率它们是KPI之外的“第二双眼睛”。在合入现网以后的每一次切换参数修改我都会做前后对比修改前取三天KPI基线修改后二十四小时跟踪成功率、RRC重建率、用户速率三个维度不达标就回滚参数。从那以后的每次5G切换优化我都会强制走一遍这个对照流程先抓取基线数据再执行改动并观察足够时长最后做前后指标对比这套方法帮我避免了很多次调错参数还不自知的情况。宕机事故少了、投诉少了用户侧感知也稳得住。希望帮到你。本文还有配套的精品资源点击获取