5G SA掉线率居高不下？爱立信内部指导书：Counter计数逻辑与CTR排查实战

简介这份《SDCU-SA保持性能分析优化指导书》面向从事5G网络优化的工程师与技术人员聚焦SA独立组网模式下SDCU保持性能的分析与优化问题。内容围绕SA网络保持性指标定义、掉线相关判断流程、掉线counter触发机制及优化策略展开涵盖上下文释放、PDU会话释放与修改流程以及不活动定时器超时、重传超限、上下行失步等典型触发场景并给出参数调整、信令处理效率提升、监控预警与资源优化等思路。资源为1个PDF文档压缩包约613KB篇幅精炼、结构清晰便于按章节快速查阅。目前已有51人学习。读者可借此系统理解SA掉线的信令流程与counter机制掌握利用CTR数据分析定位常见掉线原因的方法为日常网络优化与故障排查提供可落地的参考依据。1. 掉线率居高不下先搞懂 SA 保持性能的计数逻辑做 5G SA 网络优化的兄弟大概率遇到过这种场景小区 KPI 报表里 QoS Flow 掉线率突然飙红但现场测试下载速率正常信令跟踪也没看到明显异常。翻遍参数表改了一轮指标该红还是红。问题往往出在——你根本没搞清楚这些 counter 到底在什么条件下加一。这份《SDCU-SA保持性能分析优化指导书》是爱立信内部流出的 13 页技术文档2020 年 12 月第一版作者 Zhaohe Liu。它不讲空泛的 5G 原理而是把 SA 独立组网下基站侧保持性能的计数机制、信令触发点、参数配置和排查流程拆成了可操作的步骤。核心价值在于它告诉你 pmDrbRelAbnormalAmf5qi 和 pmDrbRelAbnormalGnb5qi 分别在什么信令节点打点tInactivityTimer 超时为什么算正常释放以及 CTR 文件里哪几个字段能直接定位掉线原因。适合谁看一线网优工程师、基站侧性能分析人员、需要处理 SA 掉线投诉的技术支持。如果你正在被 TOP 小区掉线率折磨或者想搞清楚 ENM 网管里那些 counter 的来龙去脉这份文档能省你不少翻协议的时间。2. 保持性能指标与 counter 打点机制从公式到信令节点2.1 QoS Flow 掉线率与 UE 上下文掉线率的计算差异文档给出的两个核心公式直接决定了你排查问题的方向。QoS Flow 掉线率公式(pmDrbRelAbnormalAmfAct5qi pmDrbRelAbnormalGnbAct5qi) / (pmDrbRelAbnormalAmf5qi pmDrbRelAbnormalGnb5qi pmDrbRelNormal5qi)UE 上下文掉线率公式(pmUeCtxtRelAbnormalAmf pmUeCtxtRelAbnormalGnb) / (pmUeCtxtRelAbnormalAmf pmUeCtxtRelAbnormalGnb pmUeCtxtRelNormal)注意分子里带Act5qi后缀的 counter——它们统计的是激活态承载的异常释放。文档明确标注ENM20.07 才支持这两个 counter当前版本不支持。这意味着如果你在旧版本网管上查 QoS Flow 掉线率分子实际上只有非激活态的异常释放数指标会偏低。这是个容易翻车的地方版本没对齐你看到的掉线率和真实用户体验对不上。分母里的pmDrbRelNormal5qi统计正式释放的承载数。什么叫正式释放文档定义得很清楚释放原因为 NORMAL 的情况包括 eps fallback、handover、user inactive 等。换句话说只要释放原因不是这些全部计入异常。2.2 打点时机PDU Session Resource Modify 和 UE Context Release 之后文档第 2.1 节有一句话是关键“在 PDU Session Resource Modify 和 UE Context Release 流程结束后会对过程中的承载释放情况进行判决。”这句话的信息量很大。它说明 counter 不是实时累加的而是在信令流程走完之后做一次批量判决。判决依据是5QI 承载是否为激活态有数据传输以及释放原因是否为 NORMAL。实际排查时这意味着什么如果你在信令跟踪里看到某个 DRB 被释放了但 counter 没有立即变化不要慌——等流程结束再看。反过来如果流程异常中断比如基站侧处理超时判决可能根本没执行counter 就不会累加。这种情况下指标看起来正常但用户已经掉线了。2.3 上下文释放、PDU 会话释放、PDU 会话修改三条信令路径文档第 3 章把掉线相关的信令流程拆成了三条路径每条路径的触发节点和影响范围不同。上下文释放流程分两种发起方。AMF 发起时通过 UE Context Release Command 命令 gNB 释放上下文gNB 回 RRC Release 给 UE。基站发起时先发 UE Context Release Request后续信令相同。关键点上下文释放会释放所有无线资源和所有 PDU Session。所以一旦上下文释放被判定为异常掉线率会一次性跳变。PDU 会话释放流程同样分 AMF 触发和 gNB 触发。AMF 主动触发走 PDU SESSION RESOURCE RELEASE COMMANDgNB 通过 RRC Reconfiguration 通知 UE。gNB 主动触发的情况值得注意当 gNB 检测到 NG-U 传输故障且重新分配失败或者 QoS Flow GBR 速率无法满足时gNB 会发 PDU SESSION RESOURCE NOTIFY 触发核心网发起释放。这种场景下的掉线根因在传输侧或资源分配不是无线环境问题。PDU 会话修改流程由 AMF 主动触发通过 PDU SESSION RESOURCE MODIFY REQUEST 携带 QoS Flow to Release List。gNB 根据这个列表决定释放某个 DRB 上的全部或部分 QoS Flow。如果修改过程中出现异常比如 gNB 无法满足修改后的 QoS 要求可能导致承载被异常释放。2.4 四类 counter 触发机制定时器、重传、上行失步、下行失步文档第 3.2 节列了四种触发机制每种对应不同的 counter 累加条件。不活动定时器超时tInactivityTimer 超时后触发 UE 释放文档明确说“该情况下为正常释放”。所以如果你看到 pmUeCtxtRelNormal 在涨先别慌查一下 tInactivityTimer 设置。默认值 10 秒文档参数表里 GNBCUCPFunction 的 tInactivityTimer 配置为 10如果业务模型是间歇性小包这个值可能偏短导致正常释放被误判为异常。重传超限gNB 检测到 DRB 或 SRB 的下行或上行 RLC 传输达到上限后释放 UE context。参数表里 DataRadioBearer 的 dlMaxRetxThreshold 和 ulMaxRetxThreshold 默认都是 32SignalingRadioBearer 的对应参数是 8。注意 SRB 的阈值远低于 DRB——信令面重传 8 次就释放说明信令面容忍度更低。如果 SRB 重传超限频繁优先查无线环境。上行失步UE 侧 timeAlignmentTimer 超时或 gNB 检测到上行失步。UE 需要通过随机接入重新同步如果 preambleTransMax 次随机接入都失败UE 判断无线链路失败并发起重建。这个过程里如果重建也失败就是掉线。下行失步UE 连续收到 N310 个 out-of-sync 指示后启动 T310 定时器。T310 持续期间如果连续收到 N311 个 in-sync 指示停止定时器链路恢复。如果 T310 超时UE 判断无线链路失败触发 RRC 重建。参数表里 n31020n3111t3102000ms。n3111 意味着只要收到 1 个同步指示就停止定时器恢复条件很宽松但 n31020 意味着要连续 20 个失步才启动 T310启动条件也很苛刻。这种配置下T310 超时通常意味着无线环境已经严重恶化。3. 参数配置与排查流程从网管操作到 CTR 深度分析3.1 关键参数表解读与调整边界文档第 4 章给了两张参数表一张是 DRBSRB RLF 失败判断参数一张是下行无线链路失败判断参数。这些参数直接决定 counter 的触发阈值。先看 DRB 相关参数参数默认值作用dlPollPdu / ulPollPdu32触发轮询的 PDU 数tPollRetransmitDl / Ul40ms轮询重传间隔tStatusProhibitDl / Ul10ms状态报告发送间隔dlMaxRetxThreshold / ulMaxRetxThreshold32最大重传次数SRB 相关参数参数默认值作用dlMaxRetxThreshold / ulMaxRetxThreshold8最大重传次数tPollRetransmitDl / Ul40ms轮询重传间隔tReassemblyDl / Ul35ms重组时长下行无线链路失败参数参数默认值作用n31020连续失步次数阈值n3111连续同步次数阈值t3102000ms失步释放等待时长调整这些参数时要注意边界。比如把 dlMaxRetxThreshold 从 32 调大确实能减少因重传超限导致的异常释放但代价是 UE 在弱覆盖下停留时间更长用户体验可能更差——数据传不上去但连接不断用户感知是“卡”而不是“掉”。反过来调小掉线率可能上升但用户重新接入后可能获得更好的小区。tInactivityTimer 的调整更微妙。默认 10 秒如果业务以短包为主比如 IoT 场景可以适当调大避免频繁的正常释放被误判。但调太大会占用资源影响小区容量。3.2 掉线问题分析流程先区分区域变差还是 TOP 小区变差文档第 5.1 节给了一个清晰的排查决策树。第一步确认是区域内变差还是个别 TOP 小区变差。如果是全网或某片区域整体变差重点核查变差时间点有没有基站版本升级有没有修改参数传输侧及核心网侧有没有网络操作GPS 有没有频偏干扰是否正常如果是个别 TOP 差小区导致走单站分析流程。这个分流逻辑很实用。区域变差通常是人为操作或外部环境变化导致单站变差更可能是无线环境或硬件问题。我一般会先拉时间线把 KPI 恶化时间点和操作日志对齐能排除掉一大半玄学问题。3.3 CTR 文件关键字段与事件取值当常规手段无法确认原因时文档建议用 CTR 深入分析。涉及两个关键 EventCuCpProcUeCtxtRel 和 CuCpProcPduSessionResourceRelease。CuCpProcUeCtxtRel 的关键字段字段含义ue_ctxt_rel_initiator释放触发节点GNB 或 AMFue_ctxt_rel_type释放类型判断是否异常nci16 进制 NCGIreleased_drb_list释放的 DRB 列表released_pdu_session_snssai_list释放的 PDU 及 S-NSSAIue_ctxt_rel_type 的可能取值UE_CTXT_REL_TYPE_NORMALUE_CTXT_REL_TYPE_ABNORMALUE_CTXT_REL_TYPE_UNSPECIFIEDUE_CTXT_REL_TYPE_NO_LICENSEUE_CTXT_REL_TYPE_NO_VALUECuCpProcPduSessionResourceRelease 的关键字段字段含义pdu_session_resource_release_resultPDU 会话释放结果released_pdu_session_snssai_list释放的 PDU 及 S-NSSAIreleased_drb_list释放的 DRBnci小区标识pdu_session_resource_release_result 的可能取值PDU_SESSION_RESOURCE_RELEASE_RESULT_SUCCESSPDU_SESSION_RESOURCE_RELEASE_RESULT_FAILUREPDU_SESSION_RESOURCE_RELEASE_RESULT_NO_LICENSEPDU_SESSION_RESOURCE_RELEASE_RESULT_NO_VALUE实操时我一般先用 nci 过滤出 TOP 小区再看 ue_ctxt_rel_type 和 pdu_session_resource_release_result 的分布。如果 ABNORMAL 占比高再结合 released_drb_list 看是哪些承载出的问题。如果 FAILURE 多重点查核心网侧或传输侧。3.4 六类常见掉线原因的排查优先级文档第 5.2 节列了六类常见原因按我的经验排查优先级应该这样排网元故障AAU 闪断、光模块收发光异常、本地传输网故障。这类问题通常伴随硬件告警先查告警板。弱覆盖上下行误码率恶化上行功率受限终端上行重传超限gNB 主动释放。用 MR 统计和 CTR 文件定位。弱覆盖导致的掉线通常伴随 ulMaxRetxThreshold 超限。过覆盖建网初期基站密度小孤站多超远覆盖导致重叠覆盖和无线环境恶化。邻区缺失也会加剧这个问题。过覆盖的掉线往往发生在小区边缘UE 在多个弱信号之间反复切换失败。高干扰TDD 时钟同步源异常造成网内干扰天线隔离度不足滤波器性能下降网外干扰源。查 pmRadioRecInterferencePwrDistrpusch 平均干扰底噪从 -92dBm 到 -121dBm 分 16 档。如果底噪持续高于 -100dBm基本可以确认干扰问题。切换失败邻区数据配置错误gNB 引导 UE 切向错误小区。或者目标小区不支持某类业务直接释放。这类掉线在 CTR 里通常能看到切换准备失败或切换执行失败的信令。其他前面都排查完没发现异常可以尝试重启或倒换硬件、传输、AAU定位问题环节。4. 避坑与常见问题那些文档没明说但实际会翻车的地方4.1 版本不支持 Act5qi counter 导致指标失真现象QoS Flow 掉线率看起来正常但用户投诉不断。原因ENM20.07 之前不支持 pmDrbRelAbnormalAmfAct5qi 和 pmDrbRelAbnormalGnbAct5qi分子只统计非激活态异常释放。激活态承载的异常释放根本没计入。解决确认网管版本如果低于 ENM20.07不要只看 QoS Flow 掉线率结合 UE 上下文掉线率和用户投诉综合判断。升级网管后重新校准基线。4.2 tInactivityTimer 设置过短导致正常释放被误判现象pmUeCtxtRelNormal 和 pmUeCtxtRelAbnormal 同时上涨掉线率波动大。原因tInactivityTimer 默认 10 秒如果业务模型是间歇性小包UE 频繁进入不活动状态触发正常释放。但如果释放过程中出现信令异常可能被判决为异常。解决根据业务模型调整 tInactivityTimer。短包业务适当调大但注意不要影响小区容量。调整后观察 pmUeCtxtRelNormal 和 pmUeCtxtRelAbnormal 的比例变化。4.3 SRB 重传阈值过低导致信令面先崩现象无线环境尚可但 UE 频繁重建掉线率高。原因SRB 的 dlMaxRetxThreshold 和 ulMaxRetxThreshold 默认只有 8远低于 DRB 的 32。信令面重传 8 次就释放如果无线环境有轻微波动信令面先扛不住。解决查 SRB 重传超限的 counter如果占比高优先优化无线环境。参数调整是最后手段因为调大 SRB 重传阈值会延长信令面恢复时间可能影响切换等关键流程。4.4 CTR 文件字段取值缺失导致误判现象CTR 分析时 ue_ctxt_rel_type 显示 NO_VALUE 或 UNSPECIFIED无法判断是否异常。原因信令流程异常中断判决未执行字段未填充。或者 license 问题导致 NO_LICENSE。解决NO_VALUE 和 UNSPECIFIED 不能简单归为异常或正常需要结合上下文信令和用户面数据综合判断。NO_LICENSE 直接查 license 配置。4.5 过覆盖场景下切换失败与掉线混淆现象掉线率高的同时切换成功率也低分不清是切换问题导致掉线还是掉线导致切换失败。原因过覆盖场景下UE 在多个弱信号小区之间反复尝试切换切换失败后可能触发重建重建失败就是掉线。CTR 里切换失败和掉线事件可能同时出现。解决先看切换失败的原因值如果是“目标小区不支持”或“切换准备超时”优先优化邻区关系和覆盖。如果是“无线链路失败”按掉线流程排查。两者相互影响不要孤立看。5. 进阶技巧用 CTR 事件序列还原掉线现场文档第 5.1.1 节提到用 CTR 深入分析但没展开怎么把事件串起来。我补一个实操方法按时间序排列同一 UE 的 CuCpProcUeCtxtRel 和 CuCpProcPduSessionResourceRelease 事件结合 nci 和 released_drb_list能还原出掉线前的信令路径。具体做法导出 CTR 文件后用 nci 过滤 TOP 小区再按 UE 标识分组。对每个 UE按时间戳排序所有事件。重点看 UE Context Release 之前有没有 PDU Session Resource Modify 或 Release 事件。如果有 Modify 事件且携带了 QoS Flow to Release List说明核心网主动修改了承载掉线可能是修改过程中异常导致的。如果 Modify 事件后紧接着 Release 且 ue_ctxt_rel_type 为 ABNORMAL基本可以定位到修改流程的问题。另一个技巧对比同一小区正常释放和异常释放的 released_drb_list。如果异常释放的 DRB 集中在某个特定 5QI比如 5QI1语音或 5QI5IMS 信令说明该类业务的 QoS 配置或资源保障有问题。如果 DRB 分布随机更可能是无线环境或硬件问题。验证方法调整参数后不要只看整体掉线率要分 5QI 看异常释放比例。如果调整后整体掉线率下降但某个 5QI 的异常释放比例上升说明参数调整引入了新的问题。我一般会连续观察 3 天每天同一时段拉数据对比排除业务量波动的干扰。从那以后我每次分析掉线问题都强制走一遍“先看 counter 版本支持情况再拉 CTR 事件序列最后分 5QI 验证”的流程。这套组合拳下来大部分玄学掉线都能找到根因。希望帮到你。本文还有配套的精品资源点击获取