5G掉话定位实战：从信令释放原因到参数核查的完整排查指南

简介《5G问题定位指导-掉话》是一份面向5G网络优化工程师、运维人员及通信技术学习者的专项技术文档聚焦5G商用网络中掉话问题的定位与处理。文档先讲解掉话现象、基本原理及常见场景再系统给出正向排查动作软件版本检查、告警/故障日志排查、操作排查、参数核查、信令流程分析、误码排查、覆盖干扰排查、内部释放原因排查等八类方法反向排查则覆盖5G覆盖问题、干扰问题、5G/4G配置问题、切换失败、传输故障、小区故障、SCG重配失败、核心网问题、4G掉话重建导致5G掉话等典型场景并提供话统KPI问题分析方法便于逐层定位根因。资源为单个docx文档压缩包大小约10.26MB目录层级完整既适合日常排障按图索骥也适合系统学习5G掉话优化思路。目前已有459人学习下载对关注5G网络稳定性的从业者具有实用参考价值。1. 5G掉话定位先分清是谁释放的再谈优化5G掉话是所有网优工程师绕不开的硬骨头。拿到一份掉话日志先别急着调功率、加邻区第一步永远是确认一个问题这次释放到底是谁发起的是gNodeB主动释放4G侧代发还是终端上报SCGFailureInformationNR之后被释放方向搞反了后续所有参数调整都是在赌。这份《5G问题定位指导-掉话》把NSA和SA两套掉话定位流程拆得很细从正向的版本、告警、参数、信令、误码核查到反向覆盖、干扰、切换、传输场景再到话统KPI和CHR联合分析基本覆盖了日常5G网络优化中掉话工单的全部入口。适合刚接手5G优化的新手照着做完一次完整定位也适合熟手用来查漏补缺。2. 掉话的两类信令入口被动释放与终端主动上报2.1 终端侧两类掉话现象NSA组网下终端侧掉话只有两条路。第一条终端直接收到网络侧的释放5G命令载体是RRCConnectionReconfiguration里nr-Config-r15下面携带的release信元Probe的Event里能看到NRERABAbnormalRel。第二条终端先上报SCGFailureInformationNR然后再收到基站下发的释放指示这是UE检测到某种异常后主动申请释放SCGFailure消息里会携带原因值比如上行RLC达到最大重传次数。从基站侧看第一类是gNodeB直接发起释放X2口能看到gNodeB给eNodeB发送SGNB_REL_REQUIRED第二类是4G侧收到UU口RRC_SCG_FAIL_INFO_NR之后在X2口给5G发SGNB_REL_REQ。这两条消息就是整个掉话定位的起点。很多新手上来就翻空口日志找RRCRelease其实在NSA组网下5G的释放命令往往是通过4G的RRC重配置携带的直接在5G空口找释放消息反而容易漏掉关键路径。2.2 常见掉话场景与释放主体划分常见掉话场景无非这么几类切换失败、覆盖边缘、干扰、系统内或系统间重选失败以及SCG重配失败。但场景是表层的底层要分清楚释放主体。5G侧发起释放时原因值常见的是Radio-connection-with-UE-lost和No-radio-resources-available4G侧发起释放又分三个子场景UE上报异常导致4G发起释放、核心网发起释放、4G侧重建或掉话连带释放5G。这里有一个容易翻车的地方多小区移动拉网测试时5G站间切换后LTE释放源站也是发SGNB_REL_REQ原因值是mcg-mobility19A SPC120之前叫rrm-purpose这不是掉话。如果一看到SGNB_REL_REQ就开查会白折腾半天。同样覆盖差导致的掉话如果只看RSRP不看释放原因也容易把正常释放和异常释放混在一起整个排查路径就歪了。信令流程分析要确认三件事掉话由谁发起释放原因值是什么掉话前有什么信令流程发生日志来源可以是终端侧log、基站标口信令跟踪UU/S1/X2/虚用户等和CHR。其中CHR的记录在L3事件里通过双击Sigs可以弹出信令窗口但CHR只记录信令流程和关键Cause信元不能像标口信令跟踪那样逐条双击查看所有详细信元所以深入分析还得靠标口信令。2.3 释放原因值对照表先对号入座再动手释放主体释放原因值可能原因与排查方向5G基站Radio-connection-with-UE-lost下行RLC达到最大重传次数排查信号质量、空口误码、RLC参数设置5G基站No-radio-resources-available资源分配失败排查CHR内部释放原因值和debug确认是什么资源分配失败5G基站transport-resource-unavailableS1-U或X2传输问题按传输问题套路排查4G基站Scg-mobility正常释放UE上报A2正常释放检查5G A2门限是否配置过高4G基站failure-in-the-radio-procedureUE空口上报SCG Failure或LTE侧发生RRC重建4G基站rrm-purposeLTE侧其它信令流程异常如NR添加后承载修改超时无响应4G基站Mcg-mobilityLTE站间切换源站正常释放不属于掉话4G基站Unspecified核心网发起释放UE上报randomAccessProblem切换随机接入失败、SR达到最大重传次数、收不到RAR、TA超时Probe KeyEventList可确认具体哪一种UE上报rlc-MaxNumRetx上行RLC达到最大重传次数排查空口误码、RLC参数设置UE上报scg-reconfigFailureUE侧内部流程冲突或校验某信元失败联系UE工程师分析UE上报t310-Expiry终端物理层失步排查外部干扰、邻区干扰、小区状态、发射功率UE上报synchReconfigFailure-SCGUE搜索小区失败收不到SSB排查小区状态、干扰拿到释放原因值后再往前看掉话前的信令流程。比如5G发起释放的一次掉话释放前收到了多次5G测量报告服务小区PCI 116的RSRP已经到-89dBm邻区PCI 120的RSRP到了-82dBm但一直没下发切换命令最终掉话——这种明显是切换不触发、邻区强干扰要往邻区配置方向查而不是调功率。信令里的前因和后果对不上说明定位方向错了及时回头比硬查更省时间。3. 正向排查八板斧从版本核对到信令落地的完整动作3.1 软件版本与告警日志FMA一键式日志的用法版本核查是第一步确保NR、LTE、TUE、CPE的版本是推荐版本且不同网元版本配套。实际项目里我一般先在版本配套表里核对NR和LTE的版本组合再看TUE固件版本。版本不配套的典型表现是网络侧正常添加SCG但终端行为异常这种掉话看信令和参数都看不出问题最后往往回溯到版本策略。版本策略那套推荐清单在内部3ms站点维护每次开局和割接前都要同步一遍不要拿半年前的版本组合套新项目。告警日志排查用U2000实时查询或者用FMA解析主控板一键式日志。安装FMA后在主控板一键式日志上右键打开找到Alarm log和Fault log双击即可打开如果主控板日志里有多个操作日志选择任意一个双击工具会自动全部解析打开。这里要特别注意告警有平滑机制告警出现时间可能在掉话时间点之后所以排查时不要只盯掉话前后5分钟往前多看一个窗口更稳妥。告警编号告警名称对掉话的影响ALM-29800gNodeB X2接口故障告警NSA组网时导致传输掉话ALM-29815gNodeB NG接口故障告警SA场景导致基站释放在线用户ALM-29816gNodeB NG控制面传输中断告警SA场景导致基站释放在线用户ALM-29840gNodeB退服告警基站释放所有在线用户ALM-29841NR小区不可用告警释放小区下所有在线用户ALM-29843NR分布单元小区模拟负载启动告警空口干扰大、误码高产生空口掉话ALM-29844NR分布单元小区不可用告警释放小区下所有在线用户ALM-29870NR分布单元小区TRP不可用告警释放小区下所有在线用户ALM-29871NR分布单元小区TRP服务能力下降告警空口能力下降小区边缘弱覆盖区域容易掉话ALM-26521射频单元接收通道RTWP/RSSI过低告警小区解调性能变差边缘弱覆盖区域容易掉话ALM-26520射频单元发射通道增益异常告警发射功率过大造成越区干扰过小造成覆盖空洞ALM-26529射频单元驻波告警覆盖收缩严重时基站自动关闭发射通道ALM-26260系统时钟不可用告警基站业务处理异常与周边站点互相干扰导致误码、切换失败如果存在上表以外的告警又确认和掉话时间强相关不要自己猜联系总部确认对掉话的影响面。告警的关联判断标准是时间窗口和用户分布一个小区退服告警当然会释放所有在线用户但如果是周边站点的告警影响本小区就要看干扰方向和用户位置。3.2 参数核查影响掉话的关键参数与推荐值通常版本的默认参数不会导致掉话问题但有几类参数在实际工单里反复出错。排查看下面这张表就够了实际操作时对照《参数核查X板斧》做全面检查不确定的反馈总部分析。参数MO参数ID参数名称推荐值对掉话的影响NRDUCELLQCIBEARERUeInactivityTimerUE不活动定时器20参数越小话统掉话率越低单点演示测试场景建议改0避免短时无业务触发基站正常释放被误判掉话NRCellNsaDcConfigPscellA2RsrpThldPSCell A2事件RSRP触发门限-121设置过高时RSRP低于门限会导致gNodeB发起正常释放被误判为掉话NRDUCellUlTaConfigUlTimeAlignmentTimer上行时间对齐定时器INFINITY定时器超时认为UE上行失步NSA组网下上报NRSCGFailure导致掉话NRDuCellRsvdParamRsvdU16Param9TA发送周期3UE移动速度越高取值需越小否则可能导致掉话但空口资源消耗增加NRDUCellTrpMaxTransmitPower—RRU发射功率按规划配置功率过大极近场景功率饱和、解调性能下降功率过小室外拉远场景弱覆盖NRDUCellRsvdOptParamParam1WithParamId128SRS带宽切换门限45配置过小如低于30小区边缘UE不缩减SRS带宽基站测不到准确TA移动场景容易掉话NRDUCellRsvdOptParamParam1WithParamId102双DCI调度开关和TUE配合基站和TUE配置不一致TUE下行DCI解不到RLC AM模式下下行达到最大重传导致掉话NRDUCELLPDSCHRateMatchSwitchPDCCH/SSB RateMatch开关OFF19A不支持19B推荐关闭峰值场景可打开但关注商用终端兼容性gNBRlcParamGroupUeMaxAmRetransNumUE AM模式最大重传次数32配置过小NSA组网下达到最大重传次数UE会上报NRScgFailuregNBRlcParamGroupgNBMaxAmRetransNumgNB RLC最大重传次数32配置过小达到最大重传次数会导致5G基站发起RLC Reset掉话gNBRlcParamGroupUeAmStatusRptProhibitTmrUE状态报告禁止定时器不分流默认分流MS20设置过大容易导致基站发送窗口满下行RLC Reset掉话GNBRLCPARAMGROUPDlRlcSnSize下行RLC序列号长度BITS18如果DlPdcpSnSize配18bit而DlRlcSnSize配12bit状态报告反馈不及时容易发送窗口满参数核查的执行步骤我一般是这样先从网管批量导出NRDUCELL相关MO的配置导出后直接看差异项重点关注上面这张表里的参数ID而不是逐个字段对。演示测试场景优先改UeInactivityTimer和PscellA2RsrpThld这两个参数专门避免“正常释放被当成掉话”拉网测试场景则优先看TA发送周期和SRS带宽切换门限这两个参数直接决定移动场景下的上行同步质量。3.3 信令流程分析标口信令过滤与CHR交叉验证标口信令跟踪是掉话定位最直接的手段。NSA组网下在4G或5G的X2信令里过滤SGNB_REL_REQ和SGNB_REL_REQUIRED两条消息就能快速定位到掉话记录。抓X2口数据包时可以用端口过滤# 抓取X2口信令Probe抓包或服务器侧tcpdump均可 # X2控制面通常走SCTP 38422端口这里演示按端口过滤 tcpdump -i any -s0 -w x2_trace.pcap sctp port 38422抓完包后在Wireshark或Probe里过滤消息名SGNB_REL_REQ和SGNB_REL_REQUIRED。如果是多小区移动拉网测试5G站间切换后LTE释放源站时也会发SGNB_REL_REQ原因值是mcg-mobility不要把这种场景当掉话。4G释放又细分三种UE上报异常导致4G发起释放、核心网发起释放、4G侧重建或掉话连带释放5G。UE上报异常时ScgFailure消息里常见原因值是rlc-MaxNumRetx和randomAccessProblem。拿到掉话记录后往前看掉话前发生了什么流程。比如某次掉话释放前收到了多次5G测量报告服务小区PCI 116的RSRP-89dBm51-140邻区PCI 120的RSRP-82dBm58-140但一直没下发切换命令最终导致掉话——这是典型的切换不触发、邻区强干扰场景需要进一步排查邻区配置而不是查干扰源。再看另一个例子LTE给目标5G站点发送SGNB_ADD_REQ并收到SGNB_ADD_REQ_ACK后5秒内收到目标gNodeB发来的释放请求携带原因值Failure in the Radio Interface说明随机接入失败NR侧专有Preamble等待定时器超时后发起的释放。如果是LTE站间切换时同时释放了NR说明LTE目标站点在切换准备时没有添加NR这时候要回查目标LTE站点有没有发起SCG添加。还有一种常见情况LTE目标站收到切换请求后没有发起SGNB_ADD_REQ直接回复了HO_REQ_ACK。这种直接就能判断是目标站没有发起添加要排查目标LTE站点的NSA开关和与NR站点的X2配置。CHR记录的信令流程在L3事件的SigListInfo下面能看个大概但CHR不保存完整信元所以当需要确认具体Cause值对应的详细场景时还是要回到标口信令跟踪。4. 反向排查场景覆盖、干扰、切换、传输四类掉话链路4.1 覆盖与干扰问题先看告警和误码再动功率5G覆盖问题导致的掉话核心看RSRP和SINR。极近场景功率过大会造成功率饱和解调性能下降导致掉话调整RRU发射功率时让实际接收的RSRP不要超过-60dBm室外拉远场景功率过小造成弱覆盖UE在小区边缘长时间处于低RSRP状态误码率上去了自然掉话。干扰问题要区分外部干扰源和系统内干扰ALM-29843模拟负载告警会直接导致空口干扰大、误码高这类掉话在CHR里能看到明显的上行误码抬升。排查顺序我一般固定为先查掉话时间点前后有没有射频和时钟类告警再看Probe里的Radio Measurement窗口确认上下行初传IBLER是否收敛到目标值通常是10%参数可配残留BLER是否小于1%重传率是否大于30%。如果没有终端侧日志就看CHR里L2UsrChr记录的上下行误码数据。只凭RSRP绝对值判断覆盖问题容易误判要在RSRP低的同时看到BLER抬升才能坐实是覆盖或干扰导致的空口掉话。4.2 切换失败与邻区配置从测量报告找未触发的切换切换失败导致的掉话信令特征通常是先有切换流程然后出现释放。比如UE上报测量报告后基站没有下发切换命令服务小区RSRP已经低于邻区说明邻区关系缺失或切换门限不合理。操作步骤是在后台信令跟踪里定位掉话前的测量报告对比服务小区和邻区的RSRP差值如果服务小区已经明显差于邻区且无切换动作优先查邻区配置和切换策略参数。还有一种切换相关问题要从LTE侧入手LTE站间切换后NR掉话。回看目标LTE站点的切换准备流程确认目标站是否发起SGNB_ADD_REQ没有发就直接回HO_REQ_ACK检查目标LTE站点的NSA开关和NR X2配置发了但被5G侧拒绝看拒绝原因值再往5G侧排查。这种场景在拉网测试里很常见掉话点在5G根因在4G的切换准备流程。4.3 传输与核心网问题从Cause值反推故障域transport-resource-unavailable这个原因值出现时直接往传输方向走。ALM-29800 X2接口故障告警在NSA组网下会导致传输掉话SA场景下ALM-29815和ALM-29816会触发基站释放在线用户。传输问题排查套路是先看告警再看X2/S1-U链路状态和丢包统计最后看核心网侧是否有承载释放记录。核心网发起释放有两种场景一种是发送释放命令把4G和5G一起释放另一种是初始添加5G后或5G站间切换后LTE发起ERAB修改流程核心网反馈承载修改失败导致4G释放5G。第二种场景在信令里表现为先有ERAB修改请求然后收到失败响应最后才是SGNB_REL_REQ。内部释放原因排查要结合CHR内部释放原因值和debug日志确认具体是什么资源分配失败而不是只看表面原因值就下结论。5. 掉话定位避坑记录五条血泪经验5.1 正常释放被当成掉话A2门限过高现象拉网测试中RSRP还很正常终端突然收到releaseProbe标记为掉话。原因PscellA2RsrpThld设置过高RSRP低于门限时gNodeB发起的是正常释放却被测试人员当成掉话。解决核查NRCellNsaDcConfig下的PscellA2RsrpThld推荐值-121。演示场景根据测试需求临时下调门限避免误判。5.2 LTE站间切换误报SGNB_REL_REQ现象LTE切换成功后出现5G释放记录X2信令看到SGNB_REL_REQ。原因LTE源站在切换后释放源侧5G原因值是Mcg-mobility旧版本为rrm-purpose属于正常流程不是掉话。解决核对释放原因值确认是Mcg-mobility后直接跳过不要进入误码排查流程。5.3 UE不活动定时器导致演示掉话现象演示测试时UE短时无业务5G被释放用户当场投诉掉话。原因UeInactivityTimer默认20秒演示场景下UE暂停操作超过定时器就触发基站正常释放。解决单点演示测试场景将UeInactivityTimer改成0避免短时无业务触发释放。商用网络保持默认即可。5.4 TA超时上报NRSCGFailure现象终端上报SCGFailureInformationNR原因值是randomAccessProblem上行失步特征明显。原因UlTimeAlignmentTimer配置过短定时器超时后判定UE上行失步NSA组网下上报NRSCGFailure导致掉话。解决将UlTimeAlignmentTimer设置为INFINITY同时确认TA发送周期参数。UE移动速度越高TA发送周期要调小否则仍可能掉话。5.5 RLC发送窗口满导致下行RLC Reset现象下行full buffer业务场景出现RLC Reset掉话CHR显示下行误码正常。原因DlPdcpSnSize配置了18bit但DlRlcSnSize配置12bit状态报告反馈不及时基站发送窗口满触发RLC Reset。解决将DlRlcSnSize配置为BITS18同时检查UeAmStatusRptProhibitTmr不要设置过大分流场景下保持MS20。6. 话统KPI与CHR联合验证四个动作收尾定位结论掉话定位最后一步一定要回到话统KPI和CHR数据把前面的信令结论和数据对起来否则只凭标口信令容易漏掉多用户场景下的根因。动作一对齐掉话KPI定义。话统里掉话率的统计口径是分原因值的先确认你查的掉话是哪些counter组成避免把正常释放计入分母。不同版本统计点可能有差异以版本配套的话统说明为准。动作二下行误码看CHR的L2UsrChr节点L2_USERCHR_DLSCH_HISTORY_INFO记录了掉话前最后512ms的下行调度次数ACK/NACK/DTX的次数都在里面。要判断下行有没有空口误码看NACK和DTX占比而不是只看平均BLER。动作三上行误码看L2UserChr下的L2_USERCHR_ULSCH_HISTORY_PUSCH_SLOT_INFO最多8组512ms的上行调度信息循环覆盖记录。根据事件头UlDrbChrWriteIndex判断哪一组是掉话前最近的一组时间顺序是Index1、Index0、Index7、Index6这样倒数排列。拿最近一组算上行初传BLER和重传率。动作四把释放原因值、误码结论、参数核查结果三张表放一起。释放原因是rlc-MaxNumRetx但误码正常重点查RLC参数误码高则先查覆盖和干扰不要动RLC参数。释放原因是No-radio-resources-available且误码正常一定要去查CHR内部释放原因值确认到底是什么资源分配失败。说道这里我想起一次掉话工单信令里原因值是No-radio-resources-available但CHR的下行误码NACK占比不到1%最后定位是SRS带宽切换门限配了28小区边缘UE没缩减SRS带宽基站测不准TA导致定时调整失败白调了两天功率。从那以后我每次定位完都强制走一遍“谁发起→原因值→误码→参数核查”四步确认所有环节都对齐了才出报告。希望帮到你。本文还有配套的精品资源点击获取