用DoE实验设计告别玄学调参：电子产品参数优化的三步法
2026/9/17 9:05:31
简介：面向5G网络优化与运维工程师的SDCU保持性能分析优化指导文档，聚焦SA独立组网架构下用户连接保持与掉线问题的定位及参数调优。资源为单个PDF文件，大小仅613KB，内容精炼且目录结构完整，便于按需查阅。目前已有51人学习使用。文档系统梳理了SA网络保持性指标定义及counter打点机制，详细讲解上下文释放、PDU会话释放与修改等关键信令流程，并针对不活动定时器超时、重传超限、上下行失步等常见触发场景给出判断依据。在此基础上，进一步汇总了掉线相关参数配置、利用CTR数据分析的深入排查方法，以及网元故障等常见掉线原因的处理思路，适合作为5G SA网络现场优化与问题攻坚的速查手册。
1. SA保持性能分析为什么先看QoS Flow掉线率
4G优化盯RRC掉线率，到了5G SA阶段如果还只看这一项，会漏掉大量用户感知问题。SDCU-SA场景下，真正承载业务数据的是QoS Flow，而QoS Flow挂在PDU Session上，一个UE上下文里可能有多个PDU Session、多条DRB、多个QoS Flow。RRC连接还活着，但某个业务的QoS Flow被异常释放，用户直接断网重连，这类问题在RRC掉线率里完全看不出来。所以爱立信这套保持性能分析体系把QoS Flow掉线率作为第一指标，公式是(pmDrbRelAbnormalAmfAct5qi+pmDrbRelAbnormalGnbAct5qi)/(pmDrbRelAbnormalAmf5qi+pmDrbRelAbnormalGnb5qi+pmDrbRelNormal5qi)，分子只统计激活态异常释放，分母包含正常释放。这套指标把"异常释放"限定在非Normal原因，排除了切换、EPS Fallback、用户不活动等正常流程，定位问题更精准。适合网优工程师、基站运维和核心网联调人员对照着做TOP小区分析。
2. SA掉线判定：上下文释放与PDU会话释放的信令路径
2.1 上下文释放：AMF发起与gNB发起的差异
SA基站上下文释放分两条路径。AMF发起时，核心网通过UE Context Release Command通知gNB释放UE上下文，gNB随后向UE下发RRC Release，无线资源和所有PDU Session一起释放。gNB发起时，先向AMF发送UE Context Release Request，AMF确认后走相同的释放命令流程。
实际排查时要先分清是谁发起的，这决定了问题方向。AMF发起占比高，重点看核心网侧策略，比如不活动定时器、会话管理流程异常；gNB发起占比高，重点看无线侧，比如RLC重传超限、上行失步、硬件告警。CTR事件里的ue_ctxt_rel_initiator字段会明确标记是GNB还是AMF，后面第4章会详细说。
上下文释放是所有释放里影响面最大的，因为它是"连锅端"，所有PDU Session、DRB、QoS Flow一次性释放。如果这里出现异常，而且UE当时还有激活态承载，那QoS Flow掉线率会直接飙高。
2.2 PDU会话释放与修改流程中的QoS Flow释放
PDU会话释放也可以由AMF或gNB触发。AMF主动释放时，通过PDU SESSION RESOURCE RELEASE COMMAND通知gNB，gNB通过RRC Reconfiguration让UE释放对应PDU会话。gNB主动释放的场景和上下文释放不同，通常是检测到NG-U传输故障且重分配失败，或者GBR QoS Flow速率无法满足，这时候gNB通过PDU SESSION RESOURCE NOTIFY请求核心网发起释放。
PDU会话修改流程只由AMF主动触发，走PDU SESSION RESOURCE MODIFY REQUEST。信令里的QoS Flow to Release List字段标明要删除哪些QoS Flow，gNB再通过RRC Reconfiguration通知UE释放某个DRB上的全部或部分QoS Flow。
这三条流程都会造成QoS Flow释放，但打点的口径不同。上下文释放和PDU会话释放是批量释放，PDU会话修改是精确删除。如果某小区掉线率异常，先要看是流程层面整体劣化，还是只有修改流程里的QoS Flow释放异常。修改流程异常往往是核心网下发的QoS参数与基站能力不匹配导致的，和无线覆盖关系不大。
2.3 counter打点机制与异常释放的判决规则
counter打点发生在PDU Session Resource Modify和UE Context Release流程结束后。判决规则是：当5QI承载处于激活态，也就是有数据传输时，释放原因不是NORMAL，就记为异常释放。
| Counter | 作用 |
|---|---|
| pmDrbRelAbnormalAmfAct5qi | AMF异常释放的激活承载数（ENM 20.07起支持） |
| pmDrbRelAbnormalGnbAct5qi | gNB异常释放的激活承载数（ENM 20.07起支持） |
| pmDrbRelAbnormalAmf5qi | AMF异常释放的非激活承载数 |
| pmDrbRelAbnormalGnb5qi | gNB异常释放的非激活承载数 |
| pmDrbRelNormal5qi | 正常释放的承载数 |
| pmUeCtxtRelAbnormalAmf | AMF异常释放的上下文次数 |
| pmUeCtxtRelAbnormalGnb | gNB异常释放的上下文次数 |
| pmUeCtxtRelNormal | 正常释放的上下文次数 |
注意pmDrbRelAbnormalAmfAct5qi和pmDrbRelAbnormalGnbAct5qi这两个激活态counter在早期ENM版本不支持，只有非激活态counter。如果网管版本老，算出来的异常释放会把非激活态也包含进来，数值会偏大。我一般会先确认ENM版本再决定用哪套公式，否则新旧版本对比会失真。
激活态判断由参数counterActiveMode控制，默认是FALSE。如果改成TRUE，则只有承载在释放时有数据传输才计入异常释放；保持FALSE时，非激活态也算。指导书里把这个参数列为"暂无"备注，说明不同版本行为不一样，调优前最好先在测试小区验证打点行为。
3. 保持性能优化参数表：从inactivity timer到RLF阈值
3.1 核心参数总表与默认值
SA掉线相关的参数分散在CUUP、DataRadioBearer、SignalingRadioBearer、RRC这几个MO下。参数调整前先看默认值，理解每个参数触发的边界，不要一上来就改。
DRB和SRB的RLC重传与轮询参数
| MO | 参数 | 默认配置 | 说明 |
|---|---|---|---|
| CUUP5qi | counterActiveMode | FALSE | 承载激活态判断开关 |
| DataRadioBearer | dlPollPdu | 32 | 下行触发轮询的PDU数 |
| DataRadioBearer | ulPollPdu | 32 | 上行触发轮询的PDU数 |
| DataRadioBearer | tPollRetransmitDl | 40 | 下行轮询重传间隔时长 |
| DataRadioBearer | tPollRetransmitUl | 40 | 上行轮询重传间隔时长 |
| DataRadioBearer | tStatusProhibitDl | 10 | 接收端状态报告发送间隔 |
| DataRadioBearer | tStatusProhibitUl | 10 | 接收端状态报告发送间隔 |
| DataRadioBearer | dlMaxRetxThreshold | 32 | 下行最大重传次数 |
| DataRadioBearer | ulMaxRetxThreshold | 32 | 上行最大重传次数 |
| SignalingRadioBearer | dlMaxRetxThreshold | 8 | 信令下行最大重传次数 |
| SignalingRadioBearer | ulMaxRetxThreshold | 8 | 信令上行最大重传次数 |
| SignalingRadioBearer | tPollRetransmitDl | 40 | 信令下行轮询重传间隔 |
| SignalingRadioBearer | tPollRetransmitUl | 40 | 信令上行轮询重传间隔 |
| SignalingRadioBearer | tReassemblyDl | 35 | 下行重组时长 |
| SignalingRadioBearer | tReassemblyUl | 35 | 上行重组时长 |
| GNBCUCPFunction | tInactivityTimer | 10 | 用户不活动定时器时长 |
下行RLF判断参数
| MO | 参数 | 默认配置 | 说明 |
|---|---|---|---|
| Rrc | n310 | 20 | 最大连续失步次数 |
| Rrc | n311 | 1 | 最大连续同步次数 |
| Rrc | t310 | 2000 | 失步后等待时长的定时器 |
3.2 各参数对掉线的实际影响
tInactivityTimer默认10秒，意思是UE在10秒内没有任何用户面数据传输，基站就主动释放上下文。这个释放属于正常释放，不计入异常掉线，但会拉低保持性指标里的上下文存活时间。如果业务模型是高频小包，比如即时通信、遥测，10秒太短，容易频繁释放重建；但调太长又浪费资源。常见做法是先看小区平均数据包间隔，如果大量用户间隔在10-30秒之间，把timer调到20-30秒能明显降低重建频率。
dlMaxRetxThreshold和ulMaxRetxThreshold是RLC层重传上限。数据面默认32次，信令面默认8次。重传次数到上限意味着RLC对端长时间收不到ACK或NACK，gNB判定链路不可救，直接释放UE context。弱覆盖和干扰环境下，这个值影响很大。调大重传次数能提升链路恢复概率，但代价是延长了失效判定时间，用户会感觉"卡住更久才断"。一般先处理覆盖和干扰，不要轻易动这个值。
tPollRetransmit是轮询重传间隔，默认40。如果空口丢包率不高，40毫秒足够；如果丢包频繁，轮询太疏会导致对端迟迟不反馈，白白等一轮。配合tStatusProhibit（默认10）可以加快状态报告反馈频率。这两个参数是联动调整的，只改一个往往没效果。
n310、n311、t310这三个参数共同决定下行RLF判定速度。UE连续收到N310个失步指示后启动T310，T310期间收到N311个同步指示就恢复，否则T310超时判定无线链路失败，触发RRC重建。默认n310=20、n311=1、t310=2000，这个组合对移动性强的用户偏保守，高速场景可以适当降低n310到10，加快重建立，避免业务长时间挂死；但低俗场景调小n310会误判瞬时衰落，需要结合测试。
3.3 用Python脚本从counter导出计算掉线率
日常优化不可能每个小区去ENM界面手工算。我一般会从ENM按小区粒度导出counter原始值，存成CSV后直接用脚本算。假设导出的CSV包含以下列：cell,pmDrbRelAbnormalAmfAct5qi,pmDrbRelAbnormalGnbAct5qi,pmDrbRelAbnormalAmf5qi,pmDrbRelAbnormalGnb5qi,pmDrbRelNormal5qi。
import csv import sys def calc_qos_flow_drop_rate(path): with open(path, newline='', encoding='utf-8-sig') as f: reader = csv.DictReader(f) for row in reader: abn_amf_act = float(row['pmDrbRelAbnormalAmfAct5qi'] or 0) abn_gnb_act = float(row['pmDrbRelAbnormalGnbAct5qi'] or 0) abn_amf = float(row['pmDrbRelAbnormalAmf5qi'] or 0) abn_gnb = float(row['pmDrbRelAbnormalGnb5qi'] or 0) normal = float(row['pmDrbRelNormal5qi'] or 0) numerator = abn_amf_act + abn_gnb_act denominator = abn_amf + abn_gnb + normal if denominator == 0: rate = 0 else: rate = numerator / denominator * 100 print(f"{row['cell']}: QoS Flow掉线率={rate:.3f}% " f"(激活异常释放={numerator:.0f}, 总释放={denominator:.0f})") if __name__ == '__main__': calc_qos_flow_drop_rate(sys.argv[1])这段脚本的核心是严格按公式计算，分子只取带Act的激活态异常释放counter。如果ENM版本不支持激活态counter，脚本会读出0，这时候掉线率变成0，属于假象。所以我在脚本里加了总释放数输出，方便人工核对分母是否合理。实际使用时，建议同时输出pmUeCtxtRelAbnormalAmf和pmUeCtxtRelAbnormalGnb的上下文异常释放次数，如果上下文异常释放明显大于承载异常释放，说明问题出在整UE级别的释放，而不是单承载修改，排查重点要放到RRC重建和RLF上。
参数调整建议：先统计小区级掉线率分布，找到异常TOP小区后，再拉出该小区的pmUeCtxtRelAbnormalGnb和pmDrbRelAbnormalGnb5qi做比值。如果承载异常释放/上下文异常释放比例接近1，说明每次上下文释放都带上了承载释放，此时优先查tInactivityTimer配置和上行失步；如果比例明显大于1，说明一次上下文释放释放了多个承载，往往和PDU会话批量释放有关，需要结合CTR看具体释放原因。
4. TOP小区排查：计数器趋势、CTR事件与常见原因定位
4.1 全网劣化与TOP小区分流
掉线指标恶化时，第一步不是看小区，而是分场景。拉出全市或全区所有小区在恶化时间点前后的掉线率，判断是区域内整体变差还是个别TOP小区变差。
整体变差时，按时间轴核对以下内容：基站版本升级、参数批量修改、传输侧割接、核心网操作、GPS频偏告警、全网上行干扰水平。这些操作任何一项都可能改变释放判决行为，尤其是版本升级后counter定义或打点机制变化，会导致指标跳变但用户感知正常。我遇到过ENM升级后pmDrbRelAbnormalAmfAct5qi开始支持计数，导致掉线率从0.1%跳到0.5%，实际无线环境没任何变化。
个别TOP小区变差时，按小区维度做"时间+ counter + CTR"三段式排查。时间维度看恶化是持续性的还是偶发性的，持续性问题优先查覆盖和干扰，偶发问题优先查告警和传输闪断。
4.2 CTR关键事件字段解读
常规counter只能告诉你"异常释放了多少次"，但回答不了"为什么释放"。这时候要用CTR（Call Trace Record）做精细定位。CTR中两个关键事件：CuCpProcUeCtxtRel记录上下文释放，CuCpProcPduSessionResourceRelease记录PDU会话释放。
| 事件 | 字段 | 含义 |
|---|---|---|
| CuCpProcUeCtxtRel | ue_ctxt_rel_initiator | 上下文释放触发节点：GNB或AMF |
| CuCpProcUeCtxtRel | ue_ctxt_rel_type | 释放类型：NORMAL、ABNORMAL、NO_LICENSE等 |
| CuCpProcUeCtxtRel | nci | NR小区标识，16进制NCGI |
| CuCpProcUeCtxtRel | released_drb_list | 释放上下文时一并释放的DRB列表 |
| CuCpProcUeCtxtRel | released_pdu_session_snssai_list | 释放的PDU会话及对应的SNSSAI |
| CuCpProcPduSessionResourceRelease | pdu_session_resource_release_result | PDU会话释放结果：SUCCESS、FAILURE、NO_LICENSE |
| CuCpProcPduSessionResourceRelease | released_drb_list | 该PDU会话下释放的DRB列表 |
| CuCpProcPduSessionResourceRelease | nci | 小区参考 |
ue_ctxt_rel_type是最关键的字段。如果TOP小区里异常释放的CTR事件全部是UE_CTXT_REL_TYPE_ABNORMAL，再结合ue_ctxt_rel_initiator判断是AMF还是gNB发起。AMF发起的异常释放，CTR里通常能看到核心网下发的释放原因值，指向核心网侧的会话管理策略；gNB发起的异常释放，则要把注意力放到RRC重建请求次数、上行失步counter和干扰指标上。
4.3 从CTR事件统计异常释放原因
CTR文件通常按时间段和小区导出，是压缩文本或CSV。常见做法是先用工具把CTR过滤出包含CuCpProcUeCtxtRel的记录，然后按ue_ctxt_rel_type和ue_ctxt_rel_initiator分组计数。这里给出一个通用shell统计方法，适用于将CTR转成单行JSON或CSV后的场景。
# 假设CTR已经解析为ctr.csv，字段: event, initiator, rel_type, nci, drb_list # 统计各小区异常释放的发起方分布 awk -F',' 'NR>1 && $2=="CuCpProcUeCtxtRel" && $4=="ABNORMAL" { key=$5","$3; count[key]++ } END { for (k in count) print k","count[k] }' ctr.csv | sort -t',' -k3 -rn | head -20这段awk逻辑是：先筛出事件名为CuCpProcUeCtxtRel、释放类型为ABNORMAL的记录，然后按nci（第5列）和initiator（第3列）组合成key计数。输出前20个异常释放最多的小区及其发起方。如果统计结果里某个小区gNB发起占比超过80%，基本可以排除核心网问题，直接查该小区的pmRadioRecInterferencePwrDistr干扰分布、MR覆盖率、切换成功率。
4.4 常见掉线原因与排查动作
| 原因分类 | 典型特征 | 排查动作 |
|---|---|---|
| 网元故障 | AAU闪断、光模块收发光异常、传输丢包 | 查告警、光功率、传输ping丢包率 |
| 弱覆盖 | MR覆盖率低、上行功率余量不足、重传超限 | 调整波束、天馈、加站；注意上行受限场景 |
| 过覆盖 | 孤站、超远覆盖、邻区缺失、重叠覆盖 | 查邻区关系、下倾角、功率；补邻区 |
| 高干扰 | PUSCH干扰底噪抬升，gNB无法解码 | 查GPS同步、天线隔离度、外部干扰源 |
| 切换失败 | 邻区数据错、切向错误小区、目标不支持业务 | 核对邻区配置、切换参数、目标小区能力 |
弱覆盖导致的掉线在CTR里通常表现为gNB发起异常释放，且released_drb_list里包含正在传数据的DRB。过覆盖的问题更隐蔽，因为MR可能不差，但远端信号和近端信号交叠，UE频繁切换失败。高干扰场景下，不仅掉线率恶化，pmRadioRecInterferencePwrDistr会持续落在高干扰档位，这时要先解决干扰，否则改任何RLF参数都是徒劳。切换失败造成的掉线，CTR中能看到UE在目标小区发起RRC重建失败的记录，需要结合切换优化指导书一起看。
5. 用ue_ctxt_rel_type+released_drb_list关联验证异常释放的根因方向
常规排查做到第4章基本能定位大方向，但有一种情况容易误判：gNB发起的异常释放里，有些是真正无线链路失败，有些其实是核心网侧先释放了PDU会话或修改了QoS参数，gNB只是被动执行。区分这两类，需要把CuCpProcUeCtxtRel事件和CuCpProcPduSessionResourceRelease事件按UE维度做时间关联。
具体做法是：从CTR中取出同一UE在异常释放前100毫秒内的所有事件。如果先出现CuCpProcPduSessionResourceRelease且pdu_session_resource_release_result为SUCCESS，随后出现CuCpProcUeCtxtRel且ue_ctxt_rel_type为ABNORMAL，那这个异常释放很可能是PDU会话释放后UE上下文残留，触发核心网强制清理，本质是会话管理流程问题，不是无线问题。反过来，如果CuCpProcUeCtxtRel直接出现ABNORMAL，且released_drb_list里所有DRB都标记为异常释放，同时没有前序PDU会话释放事件，这才是无线侧链路失败导致的释放。
我习惯把released_drb_list和released_pdu_session_snssai_list拉出来做交叉验证。如果异常释放的DRB涉及多个不同SNSSAI的PDU会话，说明问题在公共无线链路；如果只集中在某一个SNSSAI，说明核心网对该切片策略有问题，比如QoS参数协商失败。这个判断直接决定了是找无线优化还是找核心网同事。
在CTR解析工具里，建议额外统计UE_CTXT_REL_TYPE_NO_LICENSE这种特殊值。它表示license不足导致的释放，不是无线和核心网问题，但会顶高异常释放计数。遇到大量NO_LICENSE时，基本不用做无线优化，直接查license容量即可。
最后分享一个很实用的验证技巧：当怀疑tInactivityTimer配置过短导致频繁正常释放，但指标上又误判为异常时，在CTR里筛选ue_ctxt_rel_type为NORMAL且ue_ctxt_rel_initiator为GNB的事件，统计这些事件中UE最后一次数据传输距离释放的时间间隔。如果大量间隔集中在timer配置值附近，说明是timer触发的正常释放，用户感知为"用着用着断了"，可以适当调大timer。如果间隔远小于timer配置值，说明不是timer问题，而是其他异常流程触发，继续往RLF和核心网方向查。这个验证方法不需要额外工具，只要CTR里带有时间戳和承载释放原因就能做，适合在每次参数调整前后对比验证效果。
本文还有配套的精品资源，点击获取