SA室分QoS Flow建立成功率异常：复合根因定位与修复实践

简介：针对5G SA室分网络中QoS Flow建立成功率异常问题，这份案例文档完整记录了从指标监控、告警排查、信令跟踪到参数优化与全区整改的全流程处理思路。资源面向5G网优、基站维护及工程优化人员，尤其适合处理室分单通道场景下终端能力与基站配置不兼容的问题，同时提供了此类场景的核查思路与规避要点。包体为1个docx文档，大小85KB，篇幅精炼但含具体的现象数据、参数调整前后指标对比及12个同类站点的核查整改结果。目前已有507人学习，可作为日常优化手册中的典型参考。读者可借此掌握CSI-RS启用状态、CSI报告数量等关键参数的调整方法，理解信令特征和参数配置依据，提升QoS Flow建立成功率与网络接通率，并在类似问题的定位与规避中获得可复用的排错经验。

1. SA室分QoS Flow建立成功率异常：为什么一个93%的数字让优化团队紧张

某地市SA网络完成规模开通后，室内语音通话接通慢、视频卡顿的问题集中爆发，后台指标显示室分站点的QoS Flow建立成功率只有93%左右，而室外宏站稳定在99.5%以上。QoS Flow建立成功率衡量的是SA网络从核心网到空口把一条业务承载完整建立起来的能力，它既受核心网侧参数影响，也受无线侧资源、干扰和覆盖的影响。我们团队在这个案例上跑了近三周，先后排除了核心网参数、空口干扰和终端兼容性三个方向，最后定位到互调干扰与AMF侧参数配置在同一时段叠加的复合根因。这篇笔记把完整的排查路径、可复用的脚本方法和参数调整细节拆开讲清楚，适合正在做SA网络优化、想搞清楚这个指标怎么修的工程师参考。

2. SA室分QoS Flow建立的机制与关键参数：先定位指标死在哪一环

2.1 从PDU会话到QoS Flow：一条业务承载在SA下是怎么建起来的

5G SA网络中，终端要发起业务，第一步是建立PDU会话。SMF根据业务流程决定这个会话里要建哪些QoS Flow，再通过AMF经N2接口把PDU会话资源建立请求下发给gNB。这个请求里带了每个QoS Flow的标识和QoS参数，包括5QI、ARP、GFBR、MFBR等。gNB收到请求后做两件事：一是判断自己能否按这套参数把承载建起来，二是把这些QoS Flow映射到具体的DRB上，再通过RRC重配置把DRB参数下发给终端。终端配置完成后回复RRC重配置完成，gNB再向核心网返回PDU会话资源建立响应。到这里，一条QoS Flow才算建立成功。

这里有个容易绕晕的概念：QoS Flow、DRB、PDU会话三者的关系。一个PDU会话可以承载多个QoS Flow，一个DRB上也可以映射多个QoS Flow，但反过来，一个QoS Flow只能映射到一个DRB上。gNB做映射时要把QoS要求相近的Flow合并到同一个DRB，并为每个DRB配置RLC模式、逻辑信道优先级等空口参数。如果核心网下发的5QI组合不常见，gNB侧的DRB生成策略又没覆盖这种组合，就会在承载生成阶段直接失败。这类失败大多表现为QoS Flow建立请求根本没走到空口资源分配，被gNB在参数校验环节就拒绝掉。

2.2 成功率统计口径：尝试数、成功数、失败原因值要一起看

不同厂商对QoS Flow建立成功率的统计口径不完全一致。常见做法是按QoS Flow建立尝试次数统计：核心网发起的PDU会话资源建立请求里带几个QoS Flow就算几次尝试，gNB对每个QoS Flow的处理结果分别计数成功或失败。另一种做法是按会话统计，只有会话内所有QoS Flow全部建成功才算成功一次，只要有一个QoS Flow失败，整个PDU会话都计入失败。两种口径的数字差距很大。VoNR场景一个PDU会话通常先建默认承载再附加语音承载，如果语音承载失败但默认承载成功，按QoS Flow口径只算语音那一次失败，按会话口径整个PDU会话都算失败。与其他团队或厂商对比指标时，一定要先确认平台采用哪种口径，避免拿两个不同口径的数字直接对比。

优化中我会把三个量一起看：尝试次数、成功次数、失败原因值。尝试次数用来判断指标波动背后有没有足够的业务量支撑；失败原因值是定位的钥匙，它在N2接口信令里由核心网或gNB填写，具体取值能从CHR日志中解析。只看一个成功率百分比，很容易被小话务量或偶发失败带偏。我一般会把这三个量按小时聚合，与干扰带、底噪指标放到同一张表里。时间维度对齐后，问题时段的规律会非常明显，比如话务高峰失败集中基本指向资源或干扰，全天均匀分布则优先怀疑参数和策略。

2.3 影响建立的5类关键参数与室分场景的放大效应

我把排查中需要重点核查的参数分成5类，覆盖从核心网到空口的完整链路。

这5类参数在任何站点都可能出问题，但室分场景会把其中3类放大。第一，室分单小区覆盖范围小、用户密度高，PRB资源竞争比宏站更激烈，QoS Flow建立阶段资源不足的概率更高。第二，有源室分设备的功放底噪和天馈互调会抬高上行底噪，MCS被压低后，同样的业务量要占用更多PRB，资源利用率虚高，gNB在资源判断时更容易误判。第三，室分站点常采用多频段共天馈部署，互调产物落入工作频段后，干扰特征与容量问题非常相似，容易把优化方向引偏。

所以SA室分场景做这个指标，不能只盯参数模板，要把干扰排查和资源判断放同等优先级。参数问题表现为全天规律性失败，干扰和容量问题则集中在话务高峰时段失败。这个区分在后面案例里起了关键作用：我们前期一直盯着资源扩容方向，走了一段弯路才意识到两类问题叠加在一起。

3. 从指标异常到根因定位：SA室分QoS Flow成功率排查的标准作业流程

3.1 第一步：用SQL按小时提取小区级QoS Flow统计，锁定问题小区与时段

到达问题后第一件事是取数。取数要覆盖三个维度：时间维度、小区维度、失败原因维度。只取一个成功率均值没有意义，需要取到每个小时每个小区的尝试次数、成功次数、失败次数和失败原因值。

-- 从网管KPI明细表提取小区级QoS Flow建立统计，按小时聚合 SELECT TO_CHAR(START_TIME, 'YYYY-MM-DD HH24:00') AS HOUR, CELL_ID, SUM(QOS_FLOW_EST_ATT) AS ATT_CNT, -- 建立尝试次数 SUM(QOS_FLOW_EST_SUCC) AS SUCC_CNT, -- 建立成功次数 SUM(QOS_FLOW_EST_FAIL) AS FAIL_CNT, -- 建立失败次数 ROUND(SUM(QOS_FLOW_EST_SUCC) / NULLIF(SUM(QOS_FLOW_EST_ATT), 0) * 100, 2) AS SUCC_RATE FROM KPI_5G_QOS_FLOW_HOUR WHERE START_TIME >= TO_DATE('2024-06-01', 'YYYY-MM-DD') AND START_TIME < TO_DATE('2024-06-08', 'YYYY-MM-DD') GROUP BY TO_CHAR(START_TIME, 'YYYY-MM-DD HH24:00'), CELL_ID -- 过滤低话务小区，避免小样本波动干扰问题小区识别 HAVING SUM(QOS_FLOW_EST_ATT) >= 50 ORDER BY SUCC_RATE ASC, ATT_CNT DESC;

脚本里HAVING条件是关键。SUCC_RATE按成功率倒排后，再按尝试次数倒排，保证问题小区优先显示的是话务量较大的那些。实际使用中我会把门槛从50次调到200次再拉一遍，对比两次排序结果，前后一致才是可信的问题清单。取数区间建议拉连续7天，既能看日规律，也能覆盖工作日和周末的业务差异。脚本里的TO_CHAR和TO_DATE是Oracle写法，MySQL等平台要换成DATE_FORMAT，字段名按自己网管平台调整，思路是一致的。

这里有一个容易出错的地方：不同网管平台里QoS Flow建立次数字段差异很大，有的平台把尝试数拆成“PDU会话资源建立请求中携带QoS Flow数”和“新增业务QoS Flow数”两个字段，统计维度不同。如果拿不准口径，先找同一个小区同一个小时的尝试数、成功数、失败数做一次核对，保证ATT等于SUCC加FAIL再往下分析。

3.2 第二步：失败原因值聚类，把责任划到核心网、gNB还是终端

失败原因值是定位的钥匙。QoS Flow建立失败的原因值在信令里是标准化的cause值，加上厂商扩展错误码。实际处理中我把原因值归成三类，每类对应不同的排查方向。

把失败明细按这个分类做一次聚合，哪一侧占比超过90%就优先查哪一侧。经验是不要急着看无线参数。如果核心网侧原因占比很高，无线侧怎么优化都没用，因为QoS Flow还没到gNB的资源分配阶段就被核心网拦掉了。这个分类动作最快，半小时内能完成，它能避免整个优化组在错误的方向上投入好几天。

3.3 第三步：用CHR日志逐条复现失败流程

原因值分类只能判断是哪一侧拒绝的，还不能说明为什么拒绝。这时要拿失败时间点对应的CHR日志和信令跟踪，逐条复现整个流程。我把gNB侧CHR按失败时间过滤，解析出每次失败对应的PDU会话ID、5QI、ARP、失败原因值、所在小区等字段。

import re from collections import Counter # 解析gNB CHR中QoS Flow建立失败记录 log_path = "chr_gnb_20240603.log" pattern = re.compile( r"Time=(\S+)\s+Cell=(\S+)\s+SessionID=(\S+)\s+" r"5QI=(\d+)\s+ARP=(\d+)\s+Cause=(\S+)" ) fails = [] with open(log_path, "r") as fp: for line in fp: m = pattern.search(line) if m: fails.append({ "time": m.group(1), "cell": m.group(2), "session": m.group(3), "5qi": int(m.group(4)), "arp": int(m.group(5)), "cause": m.group(6), }) # 按小区+5QI+原因值聚合，输出Top组合 agg = Counter( (f["cell"], f["5qi"], f["cause"]) for f in fails ) for (cell, qos, cause), cnt in agg.most_common(20): print(f"小区={cell} 5QI={qos} 原因值={cause} 次数={cnt}")

这段脚本输出的聚合列表能直接看出失败集中在哪个小区、哪个5QI、哪个原因值。比如输出里5QI=1的失败占绝大多数，原因值集中在resource_not_available，方向就很明确：语音承载的资源保障出了问题。脚本要注意正则的鲁棒性，不同厂商CHR日志的字段分隔符和顺序不一样，实际使用中先用两三条样本日志验证正则能匹配到关键字段，再批量跑。

这里要强调一个细节：CHR里“无线资源不可用”并不一定代表真的没有资源。调度器判断资源不足可能受到上行底噪抬升、干扰导致MCS下降的影响。所以下一步对室分站点要做干扰专项排查，不能停在“扩容”这个表面结论上。

3.4 第四步：室分场景专项排查，看干扰带、底噪与覆盖特征

室分站点必须查三个数据：上行干扰带、底噪、MR覆盖分布。上行干扰带的排查用网管指标，把每个小区每小时的上行干扰带等级拉出来看。如果干扰等级在4级以上的时段与QoS Flow失败时段完全重合，干扰和失败之间的关联就建立了。底噪抬升还会放大弱覆盖问题，MCS掉下去之后相同数据量要占用更多PRB，进一步加剧资源紧张。

MR数据用来排除弱覆盖因素。室分站点虽然有覆盖设计，但装修隔断、天线老化、功放增益下降都会造成局部盲区。弱覆盖下的用户QoS Flow建立过程反复触发RRC重配置，成功率自然上不去。三个数据源放在一起看，基本能区分弱覆盖、干扰、资源不足三类问题。这一步走完，根因基本就在手上了。

4. 案例处理全程：某商场SA室分小区QoS Flow建立成功率93.2%是怎么修回来的

4.1 现象描述与数据初判：失败集中在话务高峰的5QI=1承载

某商场室分小区，连续三天QoS Flow建立尝试12000余次，成功率93.2%。深入分析失败明细，发现失败集中在每天11点到14点、17点到20点两个时段，失败承载中5QI=1占比超过85%。5QI=1是VoNR语音承载，这个特征说明语音通话建立失败是主要矛盾。

从用户感知看，这两个时段正好是商场用餐和下班高峰，话务量最大。语音承载是GBR型业务，gNB在建立QoS Flow时要为它预留资源，如果资源判断为不足，就会拒绝建立。初步判断方向有两个：真实资源不足，或干扰导致可分配资源虚低。

4.2 失败明细交叉分析：定位到ARP冲突与干扰抬升

用Python对失败明细做交叉分析，按小时、5QI、失败原因三个维度透视。

import pandas as pd # 读取网管导出的失败明细CSV df = pd.read_csv("fail_detail.csv", parse_dates=["report_time"]) df["hour"] = df["report_time"].dt.hour # 按5QI、失败原因、小时聚合 cross = df.pivot_table( index=["5qi", "cause_code"], columns="hour", values="session_id", aggfunc="count", fill_value=0 ) print(cross) # 单独看5QI=1的原因值分布 fail_5qi1 = df[df["5qi"] == 1] print(fail_5qi1["cause_code"].value_counts())

输出里5QI=1的失败原因值主要有两类：一类是资源类原因，集中在话务高峰；另一类是ARP策略拒绝，全天都有少量分布。这个“全天均匀分布”的特点非常关键，提示我们除了高峰资源紧张，还有一条核心网或gNB策略上的问题在全天稳定发生。

顺着ARP策略原因查下去，发现该小区所属核心网AMF侧模板里，5QI=1的默认ARP值配置为1；而gNB侧该室分参数模板的QoS准入白名单里只放行了ARP值2到15的承载，模板是从普通数据业务模板直接拷贝后修改的，白名单沿用旧值。ARP=1的语音承载请求到gNB后，被参数校验判定为超出准入范围，直接拒绝建立。

4.3 根因确认：互调干扰叠加参数冲突，两个问题都要处理

为了确认干扰因素，拉取该小区连续三天的上行干扰带和底噪数据。结果发现两个问题时段干扰带4级及以上占比从平时的5%左右拉升到40%，底噪抬升约8到10dB。进一步检查室分系统结构，发现该站点2.1GHz和3.5GHz两套系统共用一套天馈，3.5GHz功放模块的非线性产物落入2.1GHz接收频段，带内互调产生系统性干扰。这种干扰的特征与话务量强相关，话务越大互调产物越强，失败集中出现在高峰时段就不奇怪了。

到这里两个根因都浮出来了：一个是全天稳定的ARP参数冲突，另一个是高峰时段叠加的互调干扰抬底噪。单独处理任何一个都只能把成功率修回一半左右。这也解释了为什么这个案例前期查了两轮都没有收效，因为两个问题互相掩盖了对方的规律。

4.4 优化执行与效果评估：参数对齐后恢复的不仅是成功率

处理分两步。第一步改参数：把gNB侧室分参数模板的QoS准入白名单补上ARP=1，允许该类语音承载进入资源分配流程，让两侧策略对齐；同时在AMF侧把该区域的5QI=1默认ARP复核了一遍，统一按规划规范值配置。第二步处理干扰：在3.5GHz功放输出端加装带通滤波器抑制互调产物，同时调整2.1GHz天馈系统的接收增益配置，把底噪尽量压回去。

调整后连续跟踪7天，该小区QoS Flow建立成功率从93.2%回升到99.0%以上，失败次数从日均200多次降到20次以内。5QI=1承载的建立成功率从91%左右回升到99.5%。用户感知方面，商场内语音接通时延平均降低约600毫秒，视频通话卡顿投诉基本消失。成功率修复只是表象，真正恢复的是GBR业务在室分场景下的资源保障能力。

4.5 把排查动作沉淀成三项后续巡检

案例处理完，我在工单里记下三条后续动作。一是把室分站点的底噪和干扰带指标纳入日常巡检，每周对全量室分站点做一次底噪排序，发现有持续抬升的小区提前处理。二是建立AMF侧与gNB侧QoS参数模板的季度核对机制，重点核对5QI=1和5QI=2的ARP配置与准入白名单一致性。三是在指标监控上把QoS Flow建立成功率、失败次数、干扰带占比放到同一张监控卡片里，避免单指标误判。

5. SA室分QoS Flow建立成功率排查避坑指南：五个高频翻车点与应对

做室分QoS Flow排查，这几个坑我基本都踩过，每条都是真金白银换回来的经验。下面按现象、原因、解决三个层次写，方便对照自查。

5.1 只盯成功率不看尝试次数：小话务室分小区的波动会骗人

现象：某些室分小区一天只有20次QoS Flow建立尝试，失败两次，成功率显示90%，低于全网99%的均值，被拉进问题小区清单。优化组按清单逐小区排查，一上午看完20个小区，其中一半是这种小话务量的小区，真正有问题的一个没找到。原因：室分小区覆盖面积小，话务量天然低于宏站，成功率是小样本统计，一次失败就让指标掉5个百分点，波动是随机的。解决：问题小区筛选用尝试次数加门槛，推荐50次或100次。低于门槛的小区看失败次数绝对值，10次尝试里失败2次比1000次尝试里失败20次对用户感知的影响小得多。另外，低话务小区还要看指标统计周期，小时粒度比日粒度更能反映随机波动；如果平台只保存日粒度，优先用尝试次数做门限而不是成功率做排序。把门槛加上之后，问题小区清单会缩水一半以上，剩下的才值得投入。

5.2 把核心网策略拒绝当成无线问题调：浪费时间最多的典型路径

现象：QoS Flow建立失败原因值集中在策略拒绝类，优化组反复调DRB参数、改调度权重，成功率纹丝不动。原因：策略拒绝类原因值由核心网SMF在收到会话请求后直接判定返回，gNB只是透传结果，整个PDU会话资源建立请求根本没走到空口资源分配阶段。解决：拿到原因值先判断归属。策略拒绝优先查用户签约、切片和AMF/SMF上的5QI策略，不要一上来就改gNB参数。CHR里能看到流程触发的最后一步，用脚本把原因值和触发节点打出来，确认是哪个网元拒绝的再决定方向。这类问题的排查时限建议控制在半天内：先看原因值归类，再查核心网配置，最后才是gNB参数。顺序反了，三天都走不出来。

5.3 室分互调干扰被误判为容量不足：扩容扩在错误方向上

现象：话务高峰时段QoS Flow建立失败增加，PRB平均利用率也处于高位，初步判断容量不足，扩容方案已经立项。原因：互调干扰抬高上行底噪，MCS被压低，同等业务量消耗更多PRB，资源利用率虚高。真正的问题是干扰，不是容量。解决：先看上行干扰带和底噪，重点对比话务高峰与低谷两个时段的底噪变化量。互调干扰的特征是底噪伴随话务量同步抬升，语音业务高峰尤其明显。有源室分还要查功放互调指标和天馈接头状态，不要只看PRB利用率就下扩容结论。判断标准可以量化：看高峰和低谷底噪之差，如果超过6dB，基本可以认定干扰随话务抬升；再用扫频仪或天馈测试确认互调源。

5.4 忽略终端维度：同一型号同一批次问题扎堆

现象：全网QoS Flow建立失败里，某几个室分小区的失败集中在特定终端型号上，整体成功率只掉了1个百分点，不容易察觉。原因：部分终端软件版本对5QI=1承载或某些DRB参数组合兼容性不足，在室分多频段覆盖场景下更容易暴露。解决：失败明细分析里加上终端型号和软件版本两个维度，发现型号聚集后，找终端厂商确认已知问题，同时看该批次终端在宏站是否正常，区分是终端问题还是室分场景特有问题。终端维度分析不需要额外工具，失败明细表里带上终端型号字段，按型号group by一次就能出结果。

5.5 参数核对只看基站侧回显：两侧模板不同版本互相掩盖

现象：gNB侧参数模板看起来正常，AMF/SMF侧模板也正常，但两侧各自使用不同版本的基线，导致同一参数在不同网元上的语义不一致。原因：室分站点常分批建设，使用不同版本参数模板；核心网升级后策略模板变更，没有同步到无线侧。解决：参数核对以源端配置为准，不能只信基站侧回显。把AMF/SMF和gNB两侧的QoS策略基线拉齐后逐项比对，尤其关注ARP、分配保留优先级和5QI对应的默认GBR值。两侧版本号要一起记录，避免下次升级时再次错位。

6. 效果验证与优化收尾：把一次修复变成长期可复用的处理习惯

确认问题处理完，不是看一两个小时指标就够了。我习惯用一周数据做验证，对比调整前后七天的同期指标，并做三件事：成功率、失败次数、干扰带占比三个指标联合观察；按小时对比确认问题时段消失；对失败次数清零后的小区做业务感知轮询，确认指标恢复确实反映到用户侧。

验证时最容易出问题的是只看平均值。平均值会被正常时段稀释，问题时段的异常看不出来。我一般把调整前后两个时间段的每小时数据画出对比，如果问题时段那一条曲线整体回落才说明真的修复。同时做好参数回退预案，修改过的参数逐条记录原值，确认新参数稳定运行两周无副作用后再归档为新的基线。

这次案例让我印象最深的一点是两个问题同时存在时，任何一个单点排查都无法把指标修回来。前两周团队一直盯着资源不足做扩容评估，忽略了全天均匀分布的那部分策略失败，后来把失败数据按小时拆开才发现两类问题叠加。这个教训我现在带到一个习惯里：拿到成功率异常，第一件事是把失败明细按小时和原因值交叉展开，确认失败是单峰还是双峰、原因值是单类还是多类，再决定往哪个方向投入。

SA室分场景下QoS Flow建立成功率异常，处理路径其实很结构化：指标分层确认问题范围，失败原因值划分责任网元，CHR和信令跟踪复现失败流程，最后用干扰和覆盖数据确认室分特有因素的影响。这四步固化下来，遇到类似问题能少走很多弯路，希望帮到你。

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