简介：这份《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 COMMAND，gNB 通过 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 默认都是 32，SignalingRadioBearer 的对应参数是 8。注意 SRB 的阈值远低于 DRB——信令面重传 8 次就释放，说明信令面容忍度更低。如果 SRB 重传超限频繁，优先查无线环境。
上行失步：UE 侧 timeAlignmentTimer 超时，或 gNB 检测到上行失步。UE 需要通过随机接入重新同步，如果 preambleTransMax 次随机接入都失败，UE 判断无线链路失败并发起重建。这个过程里，如果重建也失败，就是掉线。
下行失步：UE 连续收到 N310 个 out-of-sync 指示后启动 T310 定时器。T310 持续期间如果连续收到 N311 个 in-sync 指示，停止定时器，链路恢复。如果 T310 超时，UE 判断无线链路失败，触发 RRC 重建。参数表里 n310=20，n311=1，t310=2000ms。n311=1 意味着只要收到 1 个同步指示就停止定时器，恢复条件很宽松；但 n310=20 意味着要连续 20 个失步才启动 T310，启动条件也很苛刻。这种配置下，T310 超时通常意味着无线环境已经严重恶化。
3. 参数配置与排查流程：从网管操作到 CTR 深度分析
3.1 关键参数表解读与调整边界
文档第 4 章给了两张参数表，一张是 DRB&SRB RLF 失败判断参数，一张是下行无线链路失败判断参数。这些参数直接决定 counter 的触发阈值。
先看 DRB 相关参数：
| 参数 | 默认值 | 作用 |
|---|---|---|
| dlPollPdu / ulPollPdu | 32 | 触发轮询的 PDU 数 |
| tPollRetransmitDl / Ul | 40ms | 轮询重传间隔 |
| tStatusProhibitDl / Ul | 10ms | 状态报告发送间隔 |
| dlMaxRetxThreshold / ulMaxRetxThreshold | 32 | 最大重传次数 |
SRB 相关参数：
| 参数 | 默认值 | 作用 |
|---|---|---|
| dlMaxRetxThreshold / ulMaxRetxThreshold | 8 | 最大重传次数 |
| tPollRetransmitDl / Ul | 40ms | 轮询重传间隔 |
| tReassemblyDl / Ul | 35ms | 重组时长 |
下行无线链路失败参数：
| 参数 | 默认值 | 作用 |
|---|---|---|
| n310 | 20 | 连续失步次数阈值 |
| n311 | 1 | 连续同步次数阈值 |
| t310 | 2000ms | 失步释放等待时长 |
调整这些参数时要注意边界。比如把 dlMaxRetxThreshold 从 32 调大，确实能减少因重传超限导致的异常释放，但代价是 UE 在弱覆盖下停留时间更长，用户体验可能更差——数据传不上去，但连接不断，用户感知是“卡”而不是“掉”。反过来调小，掉线率可能上升，但用户重新接入后可能获得更好的小区。
tInactivityTimer 的调整更微妙。默认 10 秒，如果业务以短包为主（比如 IoT 场景），可以适当调大，避免频繁的正常释放被误判。但调太大会占用资源，影响小区容量。
3.2 掉线问题分析流程：先区分区域变差还是 TOP 小区变差
文档第 5.1 节给了一个清晰的排查决策树。
第一步：确认是区域内变差还是个别 TOP 小区变差。
如果是全网或某片区域整体变差，重点核查：
- 变差时间点有没有基站版本升级
- 有没有修改参数
- 传输侧及核心网侧有没有网络操作
- GPS 有没有频偏
- 干扰是否正常
如果是个别 TOP 差小区导致，走单站分析流程。
这个分流逻辑很实用。区域变差通常是人为操作或外部环境变化导致，单站变差更可能是无线环境或硬件问题。我一般会先拉时间线，把 KPI 恶化时间点和操作日志对齐，能排除掉一大半玄学问题。
3.3 CTR 文件关键字段与事件取值
当常规手段无法确认原因时，文档建议用 CTR 深入分析。涉及两个关键 Event：CuCpProcUeCtxtRel 和 CuCpProcPduSessionResourceRelease。
CuCpProcUeCtxtRel 的关键字段：
| 字段 | 含义 |
|---|---|
| ue_ctxt_rel_initiator | 释放触发节点（GNB 或 AMF） |
| ue_ctxt_rel_type | 释放类型，判断是否异常 |
| nci | 16 进制 NCGI |
| released_drb_list | 释放的 DRB 列表 |
| released_pdu_session_snssai_list | 释放的 PDU 及 S-NSSAI |
ue_ctxt_rel_type 的可能取值：
- UE_CTXT_REL_TYPE_NORMAL
- UE_CTXT_REL_TYPE_ABNORMAL
- UE_CTXT_REL_TYPE_UNSPECIFIED
- UE_CTXT_REL_TYPE_NO_LICENSE
- UE_CTXT_REL_TYPE_NO_VALUE
CuCpProcPduSessionResourceRelease 的关键字段：
| 字段 | 含义 |
|---|---|
| pdu_session_resource_release_result | PDU 会话释放结果 |
| released_pdu_session_snssai_list | 释放的 PDU 及 S-NSSAI |
| released_drb_list | 释放的 DRB |
| nci | 小区标识 |
pdu_session_resource_release_result 的可能取值：
- PDU_SESSION_RESOURCE_RELEASE_RESULT_SUCCESS
- PDU_SESSION_RESOURCE_RELEASE_RESULT_FAILURE
- PDU_SESSION_RESOURCE_RELEASE_RESULT_NO_LICENSE
- PDU_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 时钟同步源异常造成网内干扰，天线隔离度不足，滤波器性能下降，网外干扰源。查 pmRadioRecInterferencePwrDistr，pusch 平均干扰底噪从 -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，比如 5QI=1（语音）或 5QI=5（IMS 信令），说明该类业务的 QoS 配置或资源保障有问题。如果 DRB 分布随机，更可能是无线环境或硬件问题。
验证方法：调整参数后，不要只看整体掉线率，要分 5QI 看异常释放比例。如果调整后整体掉线率下降但某个 5QI 的异常释放比例上升，说明参数调整引入了新的问题。我一般会连续观察 3 天，每天同一时段拉数据对比，排除业务量波动的干扰。
从那以后我每次分析掉线问题，都强制走一遍“先看 counter 版本支持情况，再拉 CTR 事件序列，最后分 5QI 验证”的流程。这套组合拳下来，大部分玄学掉线都能找到根因。希望帮到你。
本文还有配套的精品资源，点击获取
