简介面向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掉线率作为第一指标公式是(pmDrbRelAbnormalAmfAct5qipmDrbRelAbnormalGnbAct5qi)/(pmDrbRelAbnormalAmf5qipmDrbRelAbnormalGnb5qipmDrbRelNormal5qi)分子只统计激活态异常释放分母包含正常释放。这套指标把异常释放限定在非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 RequestAMF确认后走相同的释放命令流程。实际排查时要先分清是谁发起的这决定了问题方向。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通知gNBgNB通过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 FlowgNB再通过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作用pmDrbRelAbnormalAmfAct5qiAMF异常释放的激活承载数ENM 20.07起支持pmDrbRelAbnormalGnbAct5qigNB异常释放的激活承载数ENM 20.07起支持pmDrbRelAbnormalAmf5qiAMF异常释放的非激活承载数pmDrbRelAbnormalGnb5qigNB异常释放的非激活承载数pmDrbRelNormal5qi正常释放的承载数pmUeCtxtRelAbnormalAmfAMF异常释放的上下文次数pmUeCtxtRelAbnormalGnbgNB异常释放的上下文次数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参数默认配置说明CUUP5qicounterActiveModeFALSE承载激活态判断开关DataRadioBearerdlPollPdu32下行触发轮询的PDU数DataRadioBearerulPollPdu32上行触发轮询的PDU数DataRadioBearertPollRetransmitDl40下行轮询重传间隔时长DataRadioBearertPollRetransmitUl40上行轮询重传间隔时长DataRadioBearertStatusProhibitDl10接收端状态报告发送间隔DataRadioBearertStatusProhibitUl10接收端状态报告发送间隔DataRadioBearerdlMaxRetxThreshold32下行最大重传次数DataRadioBearerulMaxRetxThreshold32上行最大重传次数SignalingRadioBearerdlMaxRetxThreshold8信令下行最大重传次数SignalingRadioBearerulMaxRetxThreshold8信令上行最大重传次数SignalingRadioBearertPollRetransmitDl40信令下行轮询重传间隔SignalingRadioBearertPollRetransmitUl40信令上行轮询重传间隔SignalingRadioBearertReassemblyDl35下行重组时长SignalingRadioBearertReassemblyUl35上行重组时长GNBCUCPFunctiontInactivityTimer10用户不活动定时器时长下行RLF判断参数MO参数默认配置说明Rrcn31020最大连续失步次数Rrcn3111最大连续同步次数Rrct3102000失步后等待时长的定时器3.2 各参数对掉线的实际影响tInactivityTimer默认10秒意思是UE在10秒内没有任何用户面数据传输基站就主动释放上下文。这个释放属于正常释放不计入异常掉线但会拉低保持性指标里的上下文存活时间。如果业务模型是高频小包比如即时通信、遥测10秒太短容易频繁释放重建但调太长又浪费资源。常见做法是先看小区平均数据包间隔如果大量用户间隔在10-30秒之间把timer调到20-30秒能明显降低重建频率。dlMaxRetxThreshold和ulMaxRetxThreshold是RLC层重传上限。数据面默认32次信令面默认8次。重传次数到上限意味着RLC对端长时间收不到ACK或NACKgNB判定链路不可救直接释放UE context。弱覆盖和干扰环境下这个值影响很大。调大重传次数能提升链路恢复概率但代价是延长了失效判定时间用户会感觉卡住更久才断。一般先处理覆盖和干扰不要轻易动这个值。tPollRetransmit是轮询重传间隔默认40。如果空口丢包率不高40毫秒足够如果丢包频繁轮询太疏会导致对端迟迟不反馈白白等一轮。配合tStatusProhibit默认10可以加快状态报告反馈频率。这两个参数是联动调整的只改一个往往没效果。n310、n311、t310这三个参数共同决定下行RLF判定速度。UE连续收到N310个失步指示后启动T310T310期间收到N311个同步指示就恢复否则T310超时判定无线链路失败触发RRC重建。默认n31020、n3111、t3102000这个组合对移动性强的用户偏保守高速场景可以适当降低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, encodingutf-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只能告诉你异常释放了多少次但回答不了为什么释放。这时候要用CTRCall Trace Record做精细定位。CTR中两个关键事件CuCpProcUeCtxtRel记录上下文释放CuCpProcPduSessionResourceRelease记录PDU会话释放。事件字段含义CuCpProcUeCtxtRelue_ctxt_rel_initiator上下文释放触发节点GNB或AMFCuCpProcUeCtxtRelue_ctxt_rel_type释放类型NORMAL、ABNORMAL、NO_LICENSE等CuCpProcUeCtxtRelnciNR小区标识16进制NCGICuCpProcUeCtxtRelreleased_drb_list释放上下文时一并释放的DRB列表CuCpProcUeCtxtRelreleased_pdu_session_snssai_list释放的PDU会话及对应的SNSSAICuCpProcPduSessionResourceReleasepdu_session_resource_release_resultPDU会话释放结果SUCCESS、FAILURE、NO_LICENSECuCpProcPduSessionResourceReleasereleased_drb_list该PDU会话下释放的DRB列表CuCpProcPduSessionResourceReleasenci小区参考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, NR1 $2CuCpProcUeCtxtRel $4ABNORMAL { 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_typereleased_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里带有时间戳和承载释放原因就能做适合在每次参数调整前后对比验证效果。本文还有配套的精品资源点击获取 
长河君 · 2026/9/17 8:07:58 · 阅读 1.2k 5G SA QoS Flow掉线率分析：从counter到CTR的保持性能优化指南
简介面向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掉线率作为第一指标公式是(pmDrbRelAbnormalAmfAct5qipmDrbRelAbnormalGnbAct5qi)/(pmDrbRelAbnormalAmf5qipmDrbRelAbnormalGnb5qipmDrbRelNormal5qi)分子只统计激活态异常释放分母包含正常释放。这套指标把异常释放限定在非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 RequestAMF确认后走相同的释放命令流程。实际排查时要先分清是谁发起的这决定了问题方向。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通知gNBgNB通过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 FlowgNB再通过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作用pmDrbRelAbnormalAmfAct5qiAMF异常释放的激活承载数ENM 20.07起支持pmDrbRelAbnormalGnbAct5qigNB异常释放的激活承载数ENM 20.07起支持pmDrbRelAbnormalAmf5qiAMF异常释放的非激活承载数pmDrbRelAbnormalGnb5qigNB异常释放的非激活承载数pmDrbRelNormal5qi正常释放的承载数pmUeCtxtRelAbnormalAmfAMF异常释放的上下文次数pmUeCtxtRelAbnormalGnbgNB异常释放的上下文次数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参数默认配置说明CUUP5qicounterActiveModeFALSE承载激活态判断开关DataRadioBearerdlPollPdu32下行触发轮询的PDU数DataRadioBearerulPollPdu32上行触发轮询的PDU数DataRadioBearertPollRetransmitDl40下行轮询重传间隔时长DataRadioBearertPollRetransmitUl40上行轮询重传间隔时长DataRadioBearertStatusProhibitDl10接收端状态报告发送间隔DataRadioBearertStatusProhibitUl10接收端状态报告发送间隔DataRadioBearerdlMaxRetxThreshold32下行最大重传次数DataRadioBearerulMaxRetxThreshold32上行最大重传次数SignalingRadioBearerdlMaxRetxThreshold8信令下行最大重传次数SignalingRadioBearerulMaxRetxThreshold8信令上行最大重传次数SignalingRadioBearertPollRetransmitDl40信令下行轮询重传间隔SignalingRadioBearertPollRetransmitUl40信令上行轮询重传间隔SignalingRadioBearertReassemblyDl35下行重组时长SignalingRadioBearertReassemblyUl35上行重组时长GNBCUCPFunctiontInactivityTimer10用户不活动定时器时长下行RLF判断参数MO参数默认配置说明Rrcn31020最大连续失步次数Rrcn3111最大连续同步次数Rrct3102000失步后等待时长的定时器3.2 各参数对掉线的实际影响tInactivityTimer默认10秒意思是UE在10秒内没有任何用户面数据传输基站就主动释放上下文。这个释放属于正常释放不计入异常掉线但会拉低保持性指标里的上下文存活时间。如果业务模型是高频小包比如即时通信、遥测10秒太短容易频繁释放重建但调太长又浪费资源。常见做法是先看小区平均数据包间隔如果大量用户间隔在10-30秒之间把timer调到20-30秒能明显降低重建频率。dlMaxRetxThreshold和ulMaxRetxThreshold是RLC层重传上限。数据面默认32次信令面默认8次。重传次数到上限意味着RLC对端长时间收不到ACK或NACKgNB判定链路不可救直接释放UE context。弱覆盖和干扰环境下这个值影响很大。调大重传次数能提升链路恢复概率但代价是延长了失效判定时间用户会感觉卡住更久才断。一般先处理覆盖和干扰不要轻易动这个值。tPollRetransmit是轮询重传间隔默认40。如果空口丢包率不高40毫秒足够如果丢包频繁轮询太疏会导致对端迟迟不反馈白白等一轮。配合tStatusProhibit默认10可以加快状态报告反馈频率。这两个参数是联动调整的只改一个往往没效果。n310、n311、t310这三个参数共同决定下行RLF判定速度。UE连续收到N310个失步指示后启动T310T310期间收到N311个同步指示就恢复否则T310超时判定无线链路失败触发RRC重建。默认n31020、n3111、t3102000这个组合对移动性强的用户偏保守高速场景可以适当降低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, encodingutf-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只能告诉你异常释放了多少次但回答不了为什么释放。这时候要用CTRCall Trace Record做精细定位。CTR中两个关键事件CuCpProcUeCtxtRel记录上下文释放CuCpProcPduSessionResourceRelease记录PDU会话释放。事件字段含义CuCpProcUeCtxtRelue_ctxt_rel_initiator上下文释放触发节点GNB或AMFCuCpProcUeCtxtRelue_ctxt_rel_type释放类型NORMAL、ABNORMAL、NO_LICENSE等CuCpProcUeCtxtRelnciNR小区标识16进制NCGICuCpProcUeCtxtRelreleased_drb_list释放上下文时一并释放的DRB列表CuCpProcUeCtxtRelreleased_pdu_session_snssai_list释放的PDU会话及对应的SNSSAICuCpProcPduSessionResourceReleasepdu_session_resource_release_resultPDU会话释放结果SUCCESS、FAILURE、NO_LICENSECuCpProcPduSessionResourceReleasereleased_drb_list该PDU会话下释放的DRB列表CuCpProcPduSessionResourceReleasenci小区参考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, NR1 $2CuCpProcUeCtxtRel $4ABNORMAL { 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_typereleased_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里带有时间戳和承载释放原因就能做适合在每次参数调整前后对比验证效果。本文还有配套的精品资源点击获取