简介针对5G SA网络中SDCU保持性能分析优化的指导文档适合5G核心网运维、网络优化工程师及技术支持人员用于定位SA组网下掉线率异常、上下文与PDU会话异常释放等维护难点。内容围绕SA网络保持性指标定义、SDCU相关counter及打点机制、上下文释放与PDU会话释放/修改的判断流程展开并结合不活动定时器超时、重传超限、上下行失步等触发场景对掉线相关counter的触发条件做了系统梳理在此基础上进一步给出调整不活动定时器、重传次数限制等参数配置的优化思路以及提升信令处理效率、监控预警和网络资源分配方面的处理路径。资源仅收录完整指南1份PDF格式大小约613KB属于聚焦单一主题的精读型技术材料。目前已有51人学习下载。文档还包含SA掉线原因分析处理流程、利用CTR数据深入分析的实战方法并配有清晰的目录结构便于按章节定位问题可作为日常优化与专项排查的实用参考。1. 这份 5G SA 保持性优化指导书凭什么值得你花一晚上读完做 5G 网优的都知道SA 比 NSA 难缠多了掉线指标就是其中一块硬骨头。同一个站点NSA 下 RRC 连接成功率、掉线率都正常一切到 SA 模式各种异常释放、上下文释放、PDU 会话释放接踵而来。你翻遍网管counter 没看明白参数不敢动最后只能把问题小区踢给核心网同事结果人家一查问题就在基站侧。这份《SDCU-SA保持性能分析优化指导书》解决的正是这个问题它把 SA 掉线率公式、各 counter 打点机制、三个释放信令流程、以及 N310/T310、重传阈值这类调节参数全串成了一条排查链路。适合正要接手 SA 优化、或者已经被 TOP 掉线小区搞得焦头烂额的人读完你能自己看 counter 定位问题不再靠猜、靠问、靠玄学。2. 掉线率指标定义与 counter 打点机制先搞清楚你优化的是什么2.1 QoS Flow 掉线率和 UE 上下文掉线率两套指标不能混用指导书里给了两个核心公式一个是 QoS Flow 掉线率一个是 UE 上下文掉线率。我第一次优化某个 SA 站点时就误把 QoS Flow 掉线率当成 UE 掉线率来用结果指标已经红了好几天我却盯着另一套数据在做分析白费了两天功夫。QoS Flow 掉线率公式(pmDrbRelAbnormalAmfAct5qi pmDrbRelAbnormalGnbAct5qi) / (pmDrbRelAbnormalAmf5qi pmDrbRelAbnormalGnb5qi pmDrbRelNormal5qi)UE 上下文掉线率公式(pmUeCtxtRelAbnormalAmf pmUeCtxtRelAbnormalGnb) / (pmUeCtxtRelAbnormalAmf pmUeCtxtRelAbnormalGnb pmUeCtxtRelNormal)注意看第一个公式分子用的是带 Act 的 counter分母却不带 Act。这是最容易踩的坑。正常情况下5QI 承载处于激活态时异常释放才会计入分子但分母包含了激活与非激活状态下所有异常与正常释放的承载。这意味着你调整参数减少异常释放只能影响分子分母里非激活态的异常释放占比变大掉线率反而可能上升。后面再细聊这个反直觉的现象。2.2 八个关键 counter 的功能与触发边界指导书列出的 counter 表我按自己的理解整理成了一张速查表你分析 TOP 小区时直接对着查Counter 名称归属网元作用备注pmDrbRelAbnormalAmfAct5qiNRCELLCUAMF 异常释放的激活承载数高版本网管才支持老版本看不到pmDrbRelAbnormalGnbAct5qiNRCELLCUgNB 异常释放的激活承载数同上pmDrbRelAbnormalAmf5qiNRCELLCUAMF 异常释放的非激活承载数注意非激活也计入pmDrbRelAbnormalGnb5qiNRCELLCUgNB 异常释放的非激活承载数同上pmDrbRelNormal5qiNRCELLCU正常释放的承载数分母主要组成部分pmUeCtxtRelAbnormalAmfNRCELLCUAMF 异常释放的上下文次数核心网侧发起pmUeCtxtRelAbnormalGnbNRCELLCUgNB 异常释放的上下文次数基站侧发起pmUeCtxtRelNormalNRCELLCU正常释放的上下文次数RRC 连接正常释放这些 counter 的统计时点是在 PDU 会话修改和 UE 上下文释放流程结束后统一判决不是实时累加。判断承载是否为异常释放就看释放时该承载是否处于激活态以及释放原因是否为 NORMAL。只有激活态 非 NORMAL 原因记入异常。比如一个用户长时间没数据被不活动定时器踢掉同时这个 DRB 上还有激活的 QoS Flow这种情况在打点时就可能被误判为异常释放需要注意。2.3 激活态判断开关一个容易忽略的参数指导书参数表里CUUP5qi MO 下的 counterActiveMode 参数配置为 FALSE备注是承载激活态判断开关。这个参数直接决定异常释放判决逻辑的判定起点。如果这个开关是 FALSE意味着只要释放原因不是 NORMAL就认定异常不管该承载当时是否真有数据传输。和 4G 时代只统计有业务的 DRB相比SA 的统计口径其实更宽松会把一部分本来不算掉线的空闲态释放也拉进异常分母里。我在处理一个商用站点时用户反映掉线率比预期高核查后就是这个开关保持默认值 FALSE某版本软件升级后统计口径发生了变化升版前后数据没有对齐。这个开关现阶段不建议动但必须知道它在那里否则分析半天指标对不上白白浪费时间。3. 掉线信令流程与三类释放场景看懂 UE 是怎么死的3.1 UE 上下文释放流程基站发起和 AMF 发起路径不同上下文释放是最高级别的释放一释放所有无线资源和所有 PDU 会话全部清理相当于把 UE 踢下线。指导书写得很清楚分两条路径AMF 发起核心网下 UE Context Release Command 给 gNBgNB 再向 UE 下发 RRC ReleaseUE 收到后释放 RRC 连接整个过程结束。看 CTR 文件时这个场景的 ue_ctxt_rel_initiator 字段值会是 AMF。gNB 发起基站主动发 UE Context Release Request 给 AMFAMF 随后返回 UE Context Release Command基站再释放 RRC。这个场景的 initiator 字段值是 GNB。实际分析时我一般会先看 initiator 字段区分到底是核心网踢的还是基站踢的。如果全是 AMF 发起异常释放先找核心网同事对 NG 接口信令查 AMF 侧上下文释放的原因值如果全是 GNB 发起再往无线侧排查覆盖、干扰、重传这些问题。省去两边互相踢皮球的环节效率高很多。CTR 数据里对应的事件是 CuCpProcUeCtxtRel关键字段包括ue_ctxt_rel_initiator: UE_CTXT_REL_INITIATOR_GNB / UE_CTXT_REL_INITIATOR_AMF ue_ctxt_rel_type: UE_CTXT_REL_TYPE_NORMAL / UE_CTXT_REL_TYPE_ABNORMAL nci: 十六进制小区标识 released_drb_list: 释放的 DRB 列表 released_pdu_session_snssai_list: 释放的 PDU 会话及网络切片标识按 ue_ctxt_rel_initiator 分组统计配合 ue_ctxt_rel_type第一轮就能判断问题主要在哪一侧后面再针对具体原因值深入排查。3.2 PDU 会话释放流程AMF 主动和 gNB 主动的差异PDU 会话释放的力度比上下文释放小只释放某个会话基站还通过 RRC Reconfiguration 通知 UE。注意这个流程不是直接 RRC ReleaseUE 的 RRC 连接保住了只是删掉了某个 PDU 会话及其承载。AMF 主动触发AMF 发 PDU SESSION RESOURCE RELEASE COMMAND 给 gNBgNB 通过 RRC Reconfiguration 通知 UE 释放 PDU 会话。这种情况通常是 AMF 侧策略决定比如用户去注册流程异常、网络侧主动断开会话等。gNB 主动触发基站检测到 NG-U 传输故障或者 QoS Flow 的 GBR 速率无法满足通过 PDU SESSION RESOURCE NOTIFY 消息告知核心网由 AMF 最终下达释放命令。无线侧真正独自决定释放的场景很少基本都需要核心网联动。CTR 数据里对应的事件是 CuCpProcPduSessionResourceRelease关键字段 pdu_session_resource_release_result 的值只有四种SUCCESS、FAILURE、NO_LICENSE、NO_VALUE。正常情况下结果永远是 SUCCESS——因为通知核心网后核心网总要把会话释放掉。如果看到 FAILURE说明 NG 接口或核心网处理出问题基本不是无线侧能解决的直接上 NG 信令抓包吧。3.3 PDU 会话修改流程QoS Flow 释放藏在 Modify 里容易漏这是我最想提醒你注意的坑点。PDU 会话修改流程AMF 主动发起虽然名字叫 Modify但它同时能删 QoS Flow。AMF 发送 PDU SESSION RESOURCE MODIFY REQUEST 给 gNB携带 QoS Flow to Release List 字段gNB 通过 RRC Reconfiguration 通知 UE 释放某个 DRB 上所有 QoS Flow或者只删除其中某几个。这就意味着你在看掉线 counter 时一个 QoS Flow 的释放其实有三处可能来源上下文释放流程、PDU 会话释放流程、PDU 会话修改流程。最后这一处最隐蔽因为从网管界面看到的是修改而非释放。你在分析某 TOP 小区时发现掉线率很高但不活动定时器没超时、重传也没超限看着像是没规律的掉线。后来抓 CTR 看事件流才发现是 AMF 周期性发起 PDU Session Modify Request 删除某个低优先级 QoS Flow而该承载处于激活态释放原因非 NORMAL全被算成异常释放导致掉线率虚高。这种属于核心网策略与无线侧统计口径的配合问题你在无线侧如何调参数都没用需要找核心网同事核对策略。3.4 四条掉线因果链定时器、重传、失步如何一步步走向掉线指导书 3.2 节写的四条触发机制本质上是因果链各有不同分析时注意交叉组合。不活动定时器超时tInactivityTimer 默认 10 秒。UE 在 10 秒内没有任何用户面数据传输基站触发释放。这是正常释放通道不算掉线。这条链没问题参数也能调。重传超限gNB 检测到 DRB 或 SRB 的上下行 RLC 重传达到 dlMaxRetxThreshold32 次后释放 UE context。这条链最直接也最无争议出现这个说明空口质量极差或终端异常。上行失步链UE 侧 timeAlignmentTimer 超时或 gNB 检测到 UE 上行失步 → UE 发起随机接入 → 随机接入响应窗内没收到响应 → 重发 preambleTransMax 次后仍失败 → 判定无线链路失败 → 发起 RRC 重建。这条链里随机接入失败是核心中间环节常见是干扰或覆盖问题导致 PRACH 无法解调。下行失步链UE 连续收到 N310默认 20次失步指示启动 T310默认 2000ms如果 T310 期间连续收到 N311默认 1次同步指示则恢复T310 超时判定无线链路失败触发 RRC 重建。这条链最值得关注的是N3111 意味着 UE 只要看到一次 in-sync 就认为链路恢复在实际弱覆盖场景中会导致链路状态频繁翻转产生乒乓效应最终 T310 超时掉线。四条链在 CTR 文件里分别对应不同特征不活动定时器对应 NORMAL 释放重传超限对应 ABNORMAL 且释放 DRB 有 RLC 重传记录上行失步和下行失步通常伴随 RACH 失败记录或 RLF 记录。分清楚了后面的问题定位才能走对路。4. 掉线相关参数详解从 RLC 到 RLF一张配置表看懂边界4.1 RLC 重传与轮询参数组调错了反而加重空口负担参数表里 DataRadioBearer 那一组我按控制平面和用户平面分开看理解起来更清楚参数默认值作用调优方向dlPollPdu / ulPollPdu32发送端每 N 个 PDU 触发一次轮询调小则更快发现丢包但增加空口开销tPollRetransmitDl / Ul40ms轮询重传间隔调小则重传更快但可能加剧拥塞tStatusProhibitDl / Ul10ms限制状态报告发送频率调小则反馈更及时适当调大可以减少信令风暴dlMaxRetxThreshold / ulMaxRetxThreshold32RLC 最大重传次数调大则容忍更差无线环境但时延增加tReassemblyDl / Ul35ms重组定时器影响乱序包等待时间这套参数的核心矛盾点在于调大重传门限可以降低掉线率但代价是让用户感知到更长的时延和卡顿。比如上行弱覆盖场景UE 已经功率受限数据包反复重传你如果把 ulMaxRetxThreshold 从 32 调到 64确实能减少异常释放但用户侧体验更差了——每个包要重传十几次才能被基站侧确认这就是典型的指标好看了用户更难受了。我的经验是重传门限不要轻易动除非结合 MR 数据确认覆盖确实无法短期解决用参数先暂时扛住指标。SRB 的重传门限默认只有 8 次与 DRB 的 32 次相差很大。这是因为 SRB 承载的是信令必须快速失败并触发重建不能长时间停留在半死状态。分析时如果把 SRB 重传超限当成普通 RLC 重传问题处理方向就错了。4.2 RLF 判断参数 N310、N311、T310协同关系比单值更重要下行无线链路失败判断的三个参数在 MO Rrc 下参数默认值说明n31020连续失步次数达到该值触发 T310 启动n3111T310 运行期间连续同步次数达到该值停止 T310t3102000ms失步持续 2 秒则判定 RLF这三个参数是联动关系。N3111 这个默认值在弱覆盖场景下会产生问题UE 偶尔收到一个质量尚可的子帧立刻判断 in-syncT310 被停止随后又连续 out-of-syncT310 再次启动。反复横跳的结果是UE 一直处于 T310 运行的边缘状态最终可能在某次 T310 期间始终凑不齐 N311超时触发 RLF。有同行建议将 N311 调大到 3 或 5避免单次同步就判定恢复网络侧参数就是这样一步步优化出来的。这些参数没有绝对标准必须结合具体空口环境的信道质量变化节奏来配因为每个站点的干扰、衰落特征不一样默认值未必适配所有场景。4.3 用户不活动定时器掉线率与资源利用率的平衡杆GNBCUCPFunction 下 tInactivityTimer 默认 10 秒该参数决定 UE 无数据传输多久后释放 RRC 连接。从保持性指标看这个定时器越长用户挂网时间越长掉线率统计周期内异常释放的机会越少但会消耗更多空口资源和基带资源。如果你是站在降低掉线率这个目标下适当延长 tInactivityTimer 是有效杠杆。我处理过一个密集城区站点刚开站时掉线率偏高定位到大量正常释放是 tInactivityTimer10 秒导致的——用户在视频缓冲、页面阅读等场景下数据间隔超过 10 秒被释放。后来我把定时器调到 20 秒掉线率明显下降同时资源利用率也没有明显恶化因为密集城区始终有大量活跃用户覆盖了空闲资源。热点区域建议把 tInactivityTimer 调大比如 20-30 秒减少频繁释放/重建高铁、高速场景建议调小比如 5 秒终端驻留时间短快速释放资源给下一个用户更合理。乡村孤站场景则谨慎调大——本来覆盖就弱UE 掉线后重选回小区本身就困难过长的不活动定时器反而会浪费宝贵的空口资源。5. 避坑指南SA 保持性优化中的五个常见翻车点5.1 现象一统计时间点对不上指标对骂无果现象掉线率指标在下午两点开始恶化持续两个小时后又自动恢复但空口侧没有发现任何异常相邻站点也没问题。原因这个时间段有版本升级操作或者参数发布动作counter 的统计在升版期间会重置或暂停导致分母突变指标出现假性恶化。另一个常见情况是基站升级后counter 的打点逻辑有所变化前后统计口径不一致。解决发现指标突变时在自动诊断前先确认时间点是否有版本变更或参数变更动作优先排除配置变更问题。另外建议在优化前后各导出一份 counter 基线数据做比对不要只看实时值。我每次做参数变更前都会用网管导出一份全量 counter 基线快照变更后两小时再导一份这样即使指标异常也有数据支撑回溯。5.2 现象二掉线率越优化越高参数方向反了现象某 TOP 小区掉线率因覆盖问题居高不下工程师尝试调低 RLF 判断门限结果掉线率反而显著上升。原因参数调整方向错了——本来覆盖就弱你还把 N310 从 20 调到 10、T310 从 2000ms 调到 1000msUE 更快判定无线链路失败异常释放自然更多。这正是参数越调越差的典型路径。解决调低 N310/T310 是缩短失步判断时间适合强覆盖、干扰小区快速释放异常 UE不适合弱覆盖小区这些场景本来就是覆盖不足参数越敏感越容易掉线。先分清场景再动参数弱覆盖优先调整覆盖增强功能如 uplinkCompensation 相关参数或者建议加站/调整天线倾角只有在覆盖良好的区域才应该调整这些 RLF 参数。5.3 现象三激活态承载和非激活态承载统计口径混淆现象同一小区的 QoS Flow 掉线率涨了 3 倍但 UE 上下文掉线率变化不大指标呈现分裂状态。原因QoS Flow 掉线率和 UE 上下文掉线率分子分母都不同而且 QFI 释放和 UE context 释放本来就不同步。一个 PDU 会话里包含多个 QoS Flow其中一个被异常释放QoS Flow 掉线率会计数但 UE 上下文还活着UE 上下文掉线率不受影响。另外非激活态的承载异常释放也计入分母但不计入分子会导致第一个指标分母虚大。解决分析时明确你优化的指标。按指导书注释当前 ENM 版本 QoS Flow 掉线率公式中的 pmDrbRelAbnormalAmfAct5qi 实际不支持ENM20.07 才支持此时指标计算可能不完整要特别谨慎解读。我在出优化报告时如果发现 QoS Flow 掉线率异常会同时查看分母的 pmDrbRelAbnormalAmf5qi 和 pmDrbRelAbnormalGnb5qi确认非激活异常是否为分母的主要贡献者。5.4 现象四全部计数都来自 AMF 异常释放无线侧调整无效现象某 TOP 小区掉线率持续偏高无线侧检查覆盖、干扰一切正常重传指标也完全正常试了几组参数指标纹丝不动。原因ue_ctrl_rel_initiator 字段显示释放全部来自 AMF也就是说核心网主动发起异常释放与无线侧空口质量无关。常见情况是 AMF 侧的计费策略、会话管理策略触发的释放比如用户签约 Qos 参数变更、漫游场景 TAL 更新失败等。解决从 CTR 或 NG 接口信令里把 AMF 发起释放原因值Cause Radio Network Layer 或 Cause NAS 层整理出来发给核心网同事去核对。无线侧一般只需要提供 CTR 文件和时间段让核心网同事同步抓取 AMF 侧日志。千万不要在无线侧空转反复调参数最后发现根源在核心网。5.5 现象五干扰计数器不抬升但掉线真实存在现象某 TDD 站点掉线率很高F1 接口和空口干扰测量值看起来都正常现场测试却发现部分区域 PUSCH 解调失败严重。原因从 counter pmRadioRecInterferencePwrDistr 看平均干扰底噪值正常但某些子帧或 RB 上的突发干扰被平均值掩盖。TDD 制式下GPS 时钟失步会导致相邻基站上下行时隙错位产生持续数毫秒的网内干扰。如果干扰只持续在特定时隙平均 counter 反映不明显对服务质量的破坏却很大。解决先看干扰分布 counter 的分布直方图不只看平均值再结合站点工参查 GPS 时钟状态和相邻站点的同步状态。我当时处理这个问题时最终定位是某站点 GPS 天线被遮挡时钟源丢失后进入保持态导频时隙与邻区错位产生子帧级别的干扰。通过重启该站点 GPS 模块后恢复正常。这类问题你如果只看平均干扰电平很容易漏掉。6. 用 CTR 数据做一次 TOP 小区掉线归因的实操流程处理 SA 掉线问题我习惯按以下顺序操作这套流程把网管 counter、CTR 明细、参数调整串成了一条闭环链路。第一步从网管导出 TOP 小区的掉线 counter 明细时间粒度按小时覆盖问题发生前后至少 24 小时。-- 示例mysql 或类似数据库分析 counter 数据 SELECT cell_id, pm_ue_ctxt_rel_abnormal_amf, pm_ue_ctxt_rel_abnormal_gnb, pm_ue_ctxt_rel_normal, (pm_ue_ctxt_rel_abnormal_amf pm_ue_ctxt_rel_abnormal_gnb) / (pm_ue_ctxt_rel_abnormal_amf pm_ue_ctxt_rel_abnormal_gnb pm_ue_ctxt_rel_normal) AS ue_drop_ratio FROM counter_hourly WHERE cell_id TOPN_CELL AND hour BETWEEN 2024-06-17 00:00 AND 2024-06-18 00:00 ORDER BY hour;查出来的结果重点看哪个时段异常释放显著抬升同时比对 pmRadioRecInterferencePwrDistr 干扰分布 counter判断干扰水平是否同步抬升。这一步能快速排除整体恶化和定点恶化两种情况。第二步从 CTR 文件里提取目标小区对应时段的释放事件。有几种过滤方法我一般先把文件解开再用 Linux 命令或脚本过滤目标事件# 假设 CTR 导出为 JSON 格式按事件类型过滤 grep CuCpProcUeCtxtRel ctr_file.json ue_ctxt_rel_events.txt grep CuCpProcPduSessionResourceRelease ctr_file.json pdu_session_rel_events.txt拿到释放事件后关注两个字段的组合initiator 字段确认是 GNB 发起还是 AMF 发起释放原因值GNB 发起的看是否伴随 RLC 重传超限、随机接入失败AMF 发起的看是否携带 NG 接口层 Cause第三步做原因归类。我按指导书 5.2 节的分类法把前两步数据整理成一张归因表可能原因判定依据对应处理手段网元故障AAU 闪断、光模块告警、传输链路告警重启 AAU、更换光模块、核查传输弱覆盖MR 中弱覆盖采样点占比高、CTR 中上行/下行失步事件多、随机接入失败多调整天线权值、新增站点、调大重传门限过覆盖TA 分布离散度大、越区覆盖导致邻区干扰下压天线倾角、收缩覆盖高干扰pmRadioRecInterferencePwrDistr 高档位占比上升、干扰特征持续存在排查 GPS、外部干扰源切换失败CTR 中切换相关事件失败多并伴随上下文释放核查邻区关系、切换参数核心网异常initiator 为 AMF 且 NG Cause 非无线相关提供 CTR 快照给核心网同事参数配置偏移与基线参数对比发现异常变更回退或修正参数第四步对归因结果做参数调整。参考指导书的参数表弱覆盖场景一般先查 tInactivityTimer 是否设置过短重传超限主导的场景先查 dlMaxRetxThreshold/ulMaxRetxThreshold 是否被调低过失步主导的场景看 N310/T310 是否被调低干扰场景则先清干扰、再考虑参数配合。第五步调整参数后持续观察至少 24 小时并按以下顺序做验证对比调整前后同一时段的掉线 counter 数值确认趋势性改善而非波动性改善跟踪 MR 覆盖率、干扰水平等用户感知关联指标排除指标转移问题用 PM 数据抽查非目标小区确认调整没有影响相邻同配置小区我想起参与过某次专项优化一个 TOP 小区掉线率连续一周超标前几位同事分析结论各不相同有人说是过覆盖有人说是切换失败。最终我拉通 CTR 数据发现释放事件的 initiator 字段绝大多数是 AMF且原因值集中在核心网会话管理异常无线侧的覆盖和干扰数据反而是正常基线水平。拿这个结论找核心网同事核查很快定位到某个定时器配置不规范导致会话异常释放。从那以后我每次做 TOP 小区分析时都会先看 initiator 占比再继续排查无线侧参数不再迷信掉线问题一定源于无线侧。这套流程用熟了单个 TOP 小区从分析到归因控制在半天内完全可行希望帮到你。本文还有配套的精品资源点击获取