简介针对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类覆盖从核心网到空口的完整链路。参数域关键参数对QoS Flow建立的影响QoS参数5QI、ARP、GFBR、MFBR5QI决定调度优先级和时延预算ARP决定承载之间的抢占和准入关系GBR参数决定是否需要预留带宽核心网策略AMF/SMF上各5QI转发策略、切片配置、默认承载策略下发的QoS参数与gNB支持能力不匹配时会在参数校验环节直接拒绝无线承载参数DRB映射策略、RLC模式、逻辑信道优先级映射策略不当会导致高优先级业务与低优先级业务竞争GBR业务得不到保障资源类参数最大PRB数、预留资源、小区可用容量资源不足时gNB对GBR型QoS Flow判定无法新建终端能力UE支持的5QI列表、DRB参数协商、软件版本终端未声明支持某5QI组合时gNB无法生成有效承载配置这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值加上厂商扩展错误码。实际处理中我把原因值归成三类每类对应不同的排查方向。原因值分类典型判断依据首次排查方向核心网下发拒绝SMF对PDU会话资源建立请求直接回reject用户签约数据与请求QoS不匹配AMF/SMF日志、用户签约、切片配置gNB侧拒绝无线资源不足、QoS参数组合不支持、DRB配置生成失败gNB参数模板、资源可用性、底层CHR终端侧原因RRC重配置无响应、UE上下文建立失败、终端不支持5QI终端版本、空口质量、终端日志把失败明细按这个分类做一次聚合哪一侧占比超过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( rTime(\S)\sCell(\S)\sSessionID(\S)\s r5QI(\d)\sARP(\d)\sCause(\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、哪个原因值。比如输出里5QI1的失败占绝大多数原因值集中在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 现象描述与数据初判失败集中在话务高峰的5QI1承载某商场室分小区连续三天QoS Flow建立尝试12000余次成功率93.2%。深入分析失败明细发现失败集中在每天11点到14点、17点到20点两个时段失败承载中5QI1占比超过85%。5QI1是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], columnshour, valuessession_id, aggfunccount, fill_value0 ) print(cross) # 单独看5QI1的原因值分布 fail_5qi1 df[df[5qi] 1] print(fail_5qi1[cause_code].value_counts())输出里5QI1的失败原因值主要有两类一类是资源类原因集中在话务高峰另一类是ARP策略拒绝全天都有少量分布。这个“全天均匀分布”的特点非常关键提示我们除了高峰资源紧张还有一条核心网或gNB策略上的问题在全天稳定发生。顺着ARP策略原因查下去发现该小区所属核心网AMF侧模板里5QI1的默认ARP值配置为1而gNB侧该室分参数模板的QoS准入白名单里只放行了ARP值2到15的承载模板是从普通数据业务模板直接拷贝后修改的白名单沿用旧值。ARP1的语音承载请求到gNB后被参数校验判定为超出准入范围直接拒绝建立。4.3 根因确认互调干扰叠加参数冲突两个问题都要处理为了确认干扰因素拉取该小区连续三天的上行干扰带和底噪数据。结果发现两个问题时段干扰带4级及以上占比从平时的5%左右拉升到40%底噪抬升约8到10dB。进一步检查室分系统结构发现该站点2.1GHz和3.5GHz两套系统共用一套天馈3.5GHz功放模块的非线性产物落入2.1GHz接收频段带内互调产生系统性干扰。这种干扰的特征与话务量强相关话务越大互调产物越强失败集中出现在高峰时段就不奇怪了。到这里两个根因都浮出来了一个是全天稳定的ARP参数冲突另一个是高峰时段叠加的互调干扰抬底噪。单独处理任何一个都只能把成功率修回一半左右。这也解释了为什么这个案例前期查了两轮都没有收效因为两个问题互相掩盖了对方的规律。4.4 优化执行与效果评估参数对齐后恢复的不仅是成功率处理分两步。第一步改参数把gNB侧室分参数模板的QoS准入白名单补上ARP1允许该类语音承载进入资源分配流程让两侧策略对齐同时在AMF侧把该区域的5QI1默认ARP复核了一遍统一按规划规范值配置。第二步处理干扰在3.5GHz功放输出端加装带通滤波器抑制互调产物同时调整2.1GHz天馈系统的接收增益配置把底噪尽量压回去。调整后连续跟踪7天该小区QoS Flow建立成功率从93.2%回升到99.0%以上失败次数从日均200多次降到20次以内。5QI1承载的建立成功率从91%左右回升到99.5%。用户感知方面商场内语音接通时延平均降低约600毫秒视频通话卡顿投诉基本消失。成功率修复只是表象真正恢复的是GBR业务在室分场景下的资源保障能力。4.5 把排查动作沉淀成三项后续巡检案例处理完我在工单里记下三条后续动作。一是把室分站点的底噪和干扰带指标纳入日常巡检每周对全量室分站点做一次底噪排序发现有持续抬升的小区提前处理。二是建立AMF侧与gNB侧QoS参数模板的季度核对机制重点核对5QI1和5QI2的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个百分点不容易察觉。原因部分终端软件版本对5QI1承载或某些DRB参数组合兼容性不足在室分多频段覆盖场景下更容易暴露。解决失败明细分析里加上终端型号和软件版本两个维度发现型号聚集后找终端厂商确认已知问题同时看该批次终端在宏站是否正常区分是终端问题还是室分场景特有问题。终端维度分析不需要额外工具失败明细表里带上终端型号字段按型号group by一次就能出结果。5.5 参数核对只看基站侧回显两侧模板不同版本互相掩盖现象gNB侧参数模板看起来正常AMF/SMF侧模板也正常但两侧各自使用不同版本的基线导致同一参数在不同网元上的语义不一致。原因室分站点常分批建设使用不同版本参数模板核心网升级后策略模板变更没有同步到无线侧。解决参数核对以源端配置为准不能只信基站侧回显。把AMF/SMF和gNB两侧的QoS策略基线拉齐后逐项比对尤其关注ARP、分配保留优先级和5QI对应的默认GBR值。两侧版本号要一起记录避免下次升级时再次错位。6. 效果验证与优化收尾把一次修复变成长期可复用的处理习惯确认问题处理完不是看一两个小时指标就够了。我习惯用一周数据做验证对比调整前后七天的同期指标并做三件事成功率、失败次数、干扰带占比三个指标联合观察按小时对比确认问题时段消失对失败次数清零后的小区做业务感知轮询确认指标恢复确实反映到用户侧。验证时最容易出问题的是只看平均值。平均值会被正常时段稀释问题时段的异常看不出来。我一般把调整前后两个时间段的每小时数据画出对比如果问题时段那一条曲线整体回落才说明真的修复。同时做好参数回退预案修改过的参数逐条记录原值确认新参数稳定运行两周无副作用后再归档为新的基线。这次案例让我印象最深的一点是两个问题同时存在时任何一个单点排查都无法把指标修回来。前两周团队一直盯着资源不足做扩容评估忽略了全天均匀分布的那部分策略失败后来把失败数据按小时拆开才发现两类问题叠加。这个教训我现在带到一个习惯里拿到成功率异常第一件事是把失败明细按小时和原因值交叉展开确认失败是单峰还是双峰、原因值是单类还是多类再决定往哪个方向投入。SA室分场景下QoS Flow建立成功率异常处理路径其实很结构化指标分层确认问题范围失败原因值划分责任网元CHR和信令跟踪复现失败流程最后用干扰和覆盖数据确认室分特有因素的影响。这四步固化下来遇到类似问题能少走很多弯路希望帮到你。本文还有配套的精品资源点击获取