企业官网建设流程全解析

简介：针对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 的统计时点，是在 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 给 gNB，gNB 再向 UE 下发 RRC Release，UE 收到后释放 RRC 连接，整个过程结束。看 CTR 文件时，这个场景的 ue_ctxt_rel_initiator 字段值会是 AMF。

gNB 发起：基站主动发 UE Context Release Request 给 AMF，AMF 随后返回 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 Release，UE 的 RRC 连接保住了，只是删掉了某个 PDU 会话及其承载。

AMF 主动触发：AMF 发 PDU SESSION RESOURCE RELEASE COMMAND 给 gNB，gNB 通过 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 重传达到 dlMaxRetxThreshold（32 次）后释放 UE context。这条链最直接也最无争议：出现这个，说明空口质量极差或终端异常。

上行失步链：UE 侧 timeAlignmentTimer 超时或 gNB 检测到 UE 上行失步 → UE 发起随机接入 → 随机接入响应窗内没收到响应 → 重发 preambleTransMax 次后仍失败 → 判定无线链路失败 → 发起 RRC 重建。这条链里，随机接入失败是核心中间环节，常见是干扰或覆盖问题导致 PRACH 无法解调。

下行失步链：UE 连续收到 N310（默认 20）次失步指示，启动 T310（默认 2000ms）；如果 T310 期间连续收到 N311（默认 1）次同步指示则恢复；T310 超时判定无线链路失败，触发 RRC 重建。这条链最值得关注的是：N311=1 意味着 UE 只要看到一次 in-sync 就认为链路恢复，在实际弱覆盖场景中会导致链路状态频繁翻转，产生乒乓效应，最终 T310 超时掉线。

四条链在 CTR 文件里分别对应不同特征：不活动定时器对应 NORMAL 释放，重传超限对应 ABNORMAL 且释放 DRB 有 RLC 重传记录，上行失步和下行失步通常伴随 RACH 失败记录或 RLF 记录。分清楚了，后面的问题定位才能走对路。

4. 掉线相关参数详解：从 RLC 到 RLF，一张配置表看懂边界

4.1 RLC 重传与轮询参数组：调错了反而加重空口负担

参数表里 DataRadioBearer 那一组，我按控制平面和用户平面分开看，理解起来更清楚：

这套参数的核心矛盾点在于：调大重传门限可以降低掉线率，但代价是让用户感知到更长的时延和卡顿。比如上行弱覆盖场景，UE 已经功率受限，数据包反复重传，你如果把 ulMaxRetxThreshold 从 32 调到 64，确实能减少异常释放，但用户侧体验更差了——每个包要重传十几次才能被基站侧确认，这就是典型的"指标好看了，用户更难受了"。我的经验是，重传门限不要轻易动，除非结合 MR 数据确认覆盖确实无法短期解决，用参数先暂时扛住指标。

SRB 的重传门限默认只有 8 次，与 DRB 的 32 次相差很大。这是因为 SRB 承载的是信令，必须快速失败并触发重建，不能长时间停留在半死状态。分析时如果把 SRB 重传超限当成普通 RLC 重传问题处理，方向就错了。

4.2 RLF 判断参数 N310、N311、T310：协同关系比单值更重要

下行无线链路失败判断的三个参数在 MO Rrc 下：

这三个参数是联动关系。N311=1 这个默认值，在弱覆盖场景下会产生问题：UE 偶尔收到一个质量尚可的子帧，立刻判断 in-sync，T310 被停止；随后又连续 out-of-sync，T310 再次启动。反复横跳的结果是，UE 一直处于 T310 运行的边缘状态，最终可能在某次 T310 期间始终凑不齐 N311，超时触发 RLF。

有同行建议将 N311 调大到 3 或 5，避免单次同步就判定恢复，网络侧参数就是这样一步步优化出来的。这些参数没有绝对标准，必须结合具体空口环境的信道质量变化节奏来配，因为每个站点的干扰、衰落特征不一样，默认值未必适配所有场景。

4.3 用户不活动定时器：掉线率与资源利用率的平衡杆

GNBCUCPFunction 下 tInactivityTimer 默认 10 秒，该参数决定 UE 无数据传输多久后释放 RRC 连接。从保持性指标看，这个定时器越长，用户挂网时间越长，掉线率统计周期内异常释放的机会越少，但会消耗更多空口资源和基带资源。

如果你是站在"降低掉线率"这个目标下，适当延长 tInactivityTimer 是有效杠杆。我处理过一个密集城区站点，刚开站时掉线率偏高，定位到大量正常释放是 tInactivityTimer=10 秒导致的——用户在视频缓冲、页面阅读等场景下，数据间隔超过 10 秒被释放。后来我把定时器调到 20 秒，掉线率明显下降，同时资源利用率也没有明显恶化，因为密集城区始终有大量活跃用户覆盖了空闲资源。

热点区域建议把 tInactivityTimer 调大，比如 20-30 秒，减少频繁释放/重建；高铁、高速场景建议调小，比如 5 秒，终端驻留时间短，快速释放资源给下一个用户更合理。乡村孤站场景则谨慎调大——本来覆盖就弱，UE 掉线后重选回小区本身就困难，过长的不活动定时器反而会浪费宝贵的空口资源。

5. 避坑指南：SA 保持性优化中的五个常见翻车点

5.1 现象一：统计时间点对不上，指标对骂无果

现象：掉线率指标在下午两点开始恶化，持续两个小时后又自动恢复，但空口侧没有发现任何异常，相邻站点也没问题。

原因：这个时间段有版本升级操作或者参数发布动作，counter 的统计在升版期间会重置或暂停，导致分母突变，指标出现假性恶化。另一个常见情况是：基站升级后，counter 的打点逻辑有所变化，前后统计口径不一致。

解决：发现指标突变时，在自动诊断前先确认时间点是否有版本变更或参数变更动作，优先排除配置变更问题。另外建议在优化前后各导出一份 counter 基线数据做比对，不要只看实时值。我每次做参数变更前都会用网管导出一份全量 counter 基线快照，变更后两小时再导一份，这样即使指标异常，也有数据支撑回溯。

5.2 现象二：掉线率越优化越高，参数方向反了

现象：某 TOP 小区掉线率因覆盖问题居高不下，工程师尝试调低 RLF 判断门限，结果掉线率反而显著上升。

原因：参数调整方向错了——本来覆盖就弱，你还把 N310 从 20 调到 10、T310 从 2000ms 调到 1000ms，UE 更快判定无线链路失败，异常释放自然更多。这正是"参数越调越差"的典型路径。

解决：调低 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 节的分类法，把前两步数据整理成一张归因表：

第四步，对归因结果做参数调整。参考指导书的参数表，弱覆盖场景一般先查 tInactivityTimer 是否设置过短；重传超限主导的场景先查 dlMaxRetxThreshold/ulMaxRetxThreshold 是否被调低过；失步主导的场景看 N310/T310 是否被调低；干扰场景则先清干扰、再考虑参数配合。

第五步，调整参数后持续观察至少 24 小时，并按以下顺序做验证：

• 对比调整前后同一时段的掉线 counter 数值，确认趋势性改善而非波动性改善
• 跟踪 MR 覆盖率、干扰水平等用户感知关联指标，排除指标转移问题
• 用 PM 数据抽查非目标小区，确认调整没有影响相邻同配置小区

我想起参与过某次专项优化，一个 TOP 小区掉线率连续一周超标，前几位同事分析结论各不相同，有人说是过覆盖，有人说是切换失败。最终我拉通 CTR 数据发现，释放事件的 initiator 字段绝大多数是 AMF，且原因值集中在核心网会话管理异常，无线侧的覆盖和干扰数据反而是正常基线水平。拿这个结论找核心网同事核查，很快定位到某个定时器配置不规范导致会话异常释放。从那以后，我每次做 TOP 小区分析时都会先看 initiator 占比再继续排查无线侧参数，不再迷信"掉线问题一定源于无线侧"。

这套流程用熟了，单个 TOP 小区从分析到归因控制在半天内完全可行，希望帮到你。

本文还有配套的精品资源，点击获取