企业官网建设流程全解析

简介：面向5G网络优化与运维工程师的实战案例文档，聚焦SA室分场景下QoS Flow建立成功率异常问题，完整呈现从指标监控、告警排查、信令分析到参数调优的闭环处理流程。资源为单个Word文件，压缩包约85KB，内容涵盖问题现象与关键指标对比、根因定位（部分终端不支持1T传输模式）、室分单通道场景下CSI参考信号及CQIMeasureCfg等配置参数的调整建议，并附有参数修改前后接通率与建立成功率变化数据，以及全区12个同类站点的举一反三整改结果。文档还总结了跨部门与研发专家协作经验，并将处理方法纳入日常监控手册，便于后续快速识别与处理同类问题。已有507人学习下载，适合需要掌握5G SA QoS保障、室分覆盖优化以及故障案例复盘的中高级网络技术人员，也可作为日常优化排障的参考模板。

1. SA室分QOS Flow建立成功率异常：一个让常规指标集体失灵的问题

做室分优化时，我最怕的不是掉线率升高，而是QOS Flow建立成功率单独往下掉、其他指标一切正常。某次处理某个综合体的SA室分问题时，整体成功率在一周内从99%滑到90%附近，但RRC连接建立成功率、切换成功率和掉线率全部正常。翻指标看不出毛病，最后靠失败原因值分布，才锁定是合并小区里一条支路的上行通道出了问题。类似这种问题，单看成功率曲线会绕远路，因为QOS Flow建立成功率本身是一个叠加指标，无线侧、传输侧、核心网参数、终端能力，任何一层出问题都会体现在这条曲线上。这篇文章就围绕SA室分场景，讲QOS Flow建立的完整链路、分层定位方法，以及现场排查中反复出现的踩坑点，适合正在处理同类指标的网优和接入优化工程师。

2. 从访问请求到DRB落地：QOS Flow建立链路与SA室分的三个特殊坑点

2.1 从UE发起到RAN准入：QOS Flow建立经过的四个阶段

QOS Flow是5G里承载QoS的最小粒度，一个PDU会话内可以有多个QOS Flow，每个QOS Flow对应一组相同的QoS特征。简单说，用户业务数据要能传，必须先把这个“管道”建出来。在SA室分场景下，从终端发起业务到QOS Flow建立成功，信令面上会依次经过RRC连接、上下文建立、PDU会话资源建立、Uu口承载配置四个阶段，每个阶段的失败表现完全不同。

RRC阶段最直观。终端先发起随机接入，完成RRC连接建立，然后在RRCSetupComplete消息里携带5G-NAS消息，其中就包含PDU Session Establishment Request。如果这一步失败，后台首先看到的是RRC连接建立成功率下降，QOS Flow成功率很少单独出问题。接着是上下文建立阶段，gNB收到NAS消息后，会对核心网发起Initial Context Setup流程，由核心网确认用户上下文、切片信息和签约数据。这个阶段的失败，多数和NG接口传输、核心网侧配置有关，观察点是NG接口InitContextSetupResponse里的cause值。

真正让QOS Flow成功率单独波动的是第三个阶段。核心网根据终端注册时选择的切片、DNN和签约信息，生成一个或多个QOS Flow描述，通过PDU Session Resource Setup Request消息下发给gNB，gNB要对每个QOS Flow做准入控制，检查无线资源是否够调度、逻辑小区是否达到用户数上限、传输带宽是否足够、QOS参数是否在RAN支持范围内。这个评估过程直接影响QOS Flow能不能建立成功，响应消息里的PDU Session Resource Setup Response就是成败的直接证明。

最后是Uu口承载配置阶段。gNB决定QOS Flow映射到哪条DRB，通过RRCReconfiguration消息把承载配置下发给终端，终端回复RRCReconfigurationComplete才算真正建好。这个阶段最常见的失败是上行失步导致重配消息收不到，终端不回包，流程超时后NAS层报失败。四个阶段可以整理成一张判断表，现场排障时先用它做方向判断。

2.2 室分场景的三个特殊坑点

室分和宏站的最大区别在于，无线链路里多了一大段无源分布系统。从信源到天线之间，要经过合路器、功分器、耦合器以及大量馈线接头，任何一个环节出现驻波异常或损耗加大，都会让上行接收灵敏度下降。QOS Flow建立过程需要多次交互，下行重配消息在质量差的链路上会反复重传，上行NAS消息解调失败也很常见。最坑的是这类故障在后台往往没有硬告警，只能看到成功率小幅恶化。

多RRU合并小区是室分另一个典型特征。分布式站点的多个pRRU或RRU常合并成一个逻辑小区，后台统计的是合并后的平均指标。某个支路上行有干扰，会被其他支路“平均”掉，指标曲线看起来只是轻微劣化，像是用户增多导致的自然波动。而准入控制是按整个逻辑小区的资源评估的，实际用户只占用自己所在支路的物理资源，这种评估和真实的信道质量容易脱节，让问题更隐蔽。

上行受限也是室分特有麻烦。5G室分通常跑在高频段，上行覆盖距离天然受限，终端在房间深处或隔断较多的位置，功控会一路往上调发射功率，直到上行失步。表现为QOS Flow建立过程中RRC重配置完成消息反复重传，失败原因值落在radioNetwork相关条目上。这种问题在宏站可以通过加功率解决，在室分里只能靠改善分布系统质量或调整功控策略。

2.3 指标口径：默认QOS Flow与非默认QOS Flow必须分开看

很多现场排查卡住，是因为后台统计口径只覆盖了默认QOS Flow。PDU会话建立时，核心网会下发一个默认QOS Flow，后续根据业务需要再增加非默认QOS Flow，比如IMS语音、视频通话这类单独承载。如果QOS Flow建立成功率这个指标只统计默认部分，那它的走势基本等于PDU会话建立成功率，问题会和注册、切换流程纠缠在一起，难以区分是核心网参数问题还是室分无线问题。

我在现场的习惯是先做拆解，把成功率按默认QOS Flow和非默认QOS Flow分成两条曲线，再按小区、按小时聚合。非默认QOS Flow对无线质量极其敏感，室内深层覆盖差时，它们会先于默认QOS Flow恶化。如果看到非默认成功率明显低于默认，优先查无线侧覆盖和干扰，而不是急着去核对核心网参数。这一步能帮你省掉至少半天的无效排查。

注意：任何对成功率异常的判断，都要先确认统计口径是否包含非默认QOS Flow，否则后面的参数核查很可能跑偏。

3. 三步定位法：把SA室分的QOS Flow建立失败按指标、信令、参数拆开

3.1 指标分层：判断异常发生在哪一层

面对QOS Flow建立成功率异常，我从来不会只看这一条曲线。先把三级指标拉出来放在同一张图里：RRC连接建立成功率、PDU会话建立成功率（NG接口口径）、QOS Flow建立成功率（RAN侧口径）。如果RRC成功率也同步下降，先查随机接入和覆盖干扰；如果RRC正常、PDU会话成功率正常，只有QOS Flow成功率异常，问题大概率在RAN侧的QOS Flow映射、DRB建立或Uu口重配置环节；如果PDU会话成功率本身也不正常，那就要往NG接口链路和核心网方向查。

判断逻辑虽然简单，但实际执行时经常有人只看了全天平均值就下结论。平均值是最会骗人的东西，必须看时间维度。全天持续偏低，多半是配置或覆盖问题；只在忙时偏低，拥塞概率大；突然在某天某个时刻跳水后不恢复，优先怀疑网管操作或硬件告警。再按小区维度拆：全网同时变差，核心网或传输的共性原因嫌疑大；只有某个小区差，把范围缩小到这个小区的覆盖、分布系统或资源上限。这种分层筛法，能把定位范围从“全网”收敛到“某个支路”。

指标分层还有一个容易被忽略的动作，就是看关联指标。比如PDU会话建立成功率正常，但QOS Flow建立成功率低，再看一下DRB建立成功率、RRC重配完成率和上行BLER，基本就能判断卡在哪一层。关联指标不需要很多，三到五个就够。

3.2 信令定位：用失败原因值锁定责任网元

指标只能告诉你“哪里坏了”，信令才能告诉你“为什么坏”。定位QOS Flow建立失败，优先看两条NG接口消息：PDU Session Resource Setup Response和Initial Context Setup Response。失败原因值由3GPP定义，按大类分radioNetwork、transport、nas、protocol。RAN侧最常见的是radioNetwork下的insufficient resources、unknown or already allocated ARP、not supported QoS combination；传输类常见的是transport resource unavailable。

拿到失败原因值后，不要急着改参数，先统计它在全天内的分布。一个很实用的做法是把基站侧导出的信令文本日志，按cause字段做聚合排序。日志格式各家不同，但处理思路一致：

# 假设基站导出日志为文本格式；先找出所有失败记录，再按 cause 字段统计 grep -E "PDUSessionResourceSetup|QOSFlowSetup" qos_flow.log \ | grep -v "success" \ | sed -n 's/.*cause=\([^,]*\).*/\1/p' \ | sort | uniq -c | sort -nr

这段命令先过滤出和QOS Flow建立相关的过程，排除掉success的记录，然后从每条日志里提取cause字段，最后按出现次数排序。你会看到失败原因是否集中。如果某类原因占绝对多数，直接按它去查对应网元；如果原因值分散，说明用户接入环境差异大，优先查覆盖和干扰，而不是参数冲突。这里的字段名和日志格式需要按现场导出的实际格式调整，但“先找失败全集，再按原因聚合”这个思路是通用的。

把原因值映射到排查方向，可以做成一张表挂在手边：

如果NG接口上根本没有失败记录，去Uu口看RRC重配流程。用终端侧的日志或基站空口日志，查RRCReconfiguration消息是否下发、终端有没有回RRCReconfigurationComplete。下发没回应，基本就是上行失步或终端没能力执行这条重配；如果终端回了失败，多半是配置参数终端不支持。

3.3 参数核查：QOS Flow建立相关的必查字段

信令定位之后，如果方向指向RAN侧参数，再开始查配置。QOS Flow建立相关的参数不多，但每一个都可能成为“凶手”。最常出问题的字段我列在下面，这也是每次做参数核查时的底稿。

实际核查时不要每个字段都当嫌疑犯，先做三个对照。第一，把核心网在信令里下发的5QI是否在RAN支持范围内；第二，ARP优先级是否和现网已有承载冲突；第三，GBR类的GFBR总和是否超过小区实际吞吐能力。这三个对照做完，大部分QOS Flow建立失败都能找到方向。

提示：QOS Flow到DRB的映射策略常被忽略。默认配置通常允许相同5QI聚合到同一DRB，但某些版本或手工调整后可能变成每个QOS Flow建一条DRB，高层室分小区用户一多，DRB资源立刻成为瓶颈。

4. 现网踩坑记录：五个典型异常现象与反推过程

4.1 全场成功率下滑，但RRC和切换指标全部正常

某个商住综合体的案例，现象是全天QOS Flow建立成功率从99%缓慢滑到90%附近，忙时最低到87%，而RRC连接建立成功率、切换成功率、掉线率都在正常范围，网管上也没有小区退服告警。起初怀疑核心网参数，但全网其他小区正常，只有这一个室分逻辑小区异常，于是把范围收回到半径分布系统。

逐步排查后发现，是分布系统里某一条支路的无源器件指标劣化，导致该支路区域RSRP偏低、SINR差。由于这个区域话务占比不大，合并小区的整体成功率只被拉低了几个点，不容易引起注意。处理办法是逐RRU核查上行通道，利用基站侧的通道校正和驻波比数据锁定故障支路，然后分段排查馈线接头。处理完之后，把该小区按楼层拆成小区级成功率柱状图，差异楼层立刻暴露。这个坑提醒我：室分场景看指标一定要拆到支路级别，逻辑小区的平均值没有参考价值。

4.2 只有特定楼层失败率高，问题出在上行光模块

另一个案例是同一个逻辑小区覆盖三层楼，中层用户的QOS Flow建立失败率明显高于上下层，而且失败集中在非默认QOS Flow。从指标看，像是覆盖问题，但测试终端在中层RSRP并不弱，SINR也正常。翻看合并小区的RTWP数据，数值只是轻微抬升，完全不像有干扰。

后来把每个pRRU的上行接收电平和RTWP单独导出，才发现中间楼层对应的那台pRRU上行光模块性能劣化，接收灵敏度下降，该支路用户在上行功控抬到顶之后，仍然无法可靠传输NAS消息，RRC重配置消息在高层反复丢失。更换光模块后复测，指标恢复。这个案例的教训是，合并小区的RTWP是平均结果，单支路的干扰或灵敏度问题会被稀释掉。现在处理室分问题，我会把各支路的上行指标按小时单独拉出来，作为例行巡检项。

4.3 早晚高峰成功率下降，忙时资源准入拒绝

某写字楼室分小区，QOS Flow建立成功率与用户数曲线高度负相关，晚上八点最差，白天正常。失败原因值集中在insufficient resources。乍一看像硬件容量不足，但小区PRB利用率并没有到顶，RRC连接数也没到上限。

排查后确认是DRB资源瓶颈。高层室分小区常一个小区覆盖整层楼，忙时用户多业务叠加，每个用户占用多条DRB，gNB准入控制评估DRB总数后拒绝新的QOS Flow。解决方式是开启该小区相关邻区的负荷均衡，把可切换用户分担出去，同时核查每用户DRB数上限和小区DRB总数上限，不做无谓的硬件扩容。调整后忙时成功率回到目标值。这个案例说明，insufficient resources不一定是总带宽不够，可能是某个特定维度资源达到上限，必须逐项拆开看。

4.4 成功率“正常”，但用户实际感知很差

某栋办公楼的后台指标天天达标，QOS Flow建立成功率稳定在99%，但用户频繁反馈语音拨号偶发失败、视频通话卡顿。这属于典型的统计口径掩盖问题。该后台的QOS Flow成功率只统计了默认QOS Flow，而语音和视频是单独建立的5QI承载，属于非默认QOS Flow，建立失败没有被计入指标。

把报表拆成默认/非默认两个维度之后，发现语音5QI的建立成功率只有70%左右。问题聚焦到VoNR的QOS参数协商和覆盖质量，最终通过调整语音承载的QOS映射参数和改善室内弱覆盖区域解决。这个案例的提醒是：依赖任何成功率指标之前，先问清楚统计口径，否则你会被一条“正常”的曲线带偏，在错误的方向上浪费好几天。

4.5 换一批终端后成功率大幅回升，问题在UE能力

同一个小区的同一时间段，某终端型号批量失败，另一型号几乎全部成功。失败原因值集中在not supported QoS combination，但这个组合其他终端都能正常建立，核心网下发的参数也没有明显异常。抓取两类终端的UE能力信息对比后，发现批量失败的终端在上报能力里缺少对特定5QI的支持，或者对某些双连接特性支持不完整。

gNB按统一的QOS模板下发承载配置，终端在RRC重配置阶段执行失败。临时手段是在RAN侧把对该终端的QOS Flow映射降级到通用模板，保证业务可用；长期手段是推动终端软件版本升级。这个案例让我在后续排查里多了一个习惯：当失败集中在某个终端型号时，不要默认“终端没问题”，先抓UE能力信息做横向对比，比反复调整基站参数有效得多。

5. 调优闭环：量化效果、控制变量与日常盯指标的自动化

5.1 调整前后的基线：在同一业务模型下做对比

QOS Flow建立成功率这类指标受用户行为、时段、业务类型影响很大，调整前后必须有一个对比基线，否则你根本不知道改善是参数起了作用，还是恰好遇到了闲时。我的做法是，动参数之前先记录至少一个完整忙闲周期的小区级数据，包括每小时的QOS Flow建立成功率、失败原因值分布、平均用户数、PRB利用率和DRB利用率。

调整过程坚持控制变量原则。一次只改一个变量，观察两天再动下一个。比如先改QOS Flow到DRB的映射策略，确认成功率变化后再碰功控参数。现场最大的翻车往往来自“顺手把几个参数一起改了”，指标好转却说不清是谁的功劳，后续回归和推广完全没有依据。基线记录表不复杂，但必须坚持填。

5.2 成功率之外还要看的三个伴随指标

成功率上去了不代表业务体验一定好。我在评估调优效果时，至少还会看三个伴随指标。第一个是QOS Flow建立平均时延，成功率靠重传和等待堆上去的时候，时延会明显变长，用户感知依然差。第二个是非默认QOS Flow的成功率，它是所有被平均指标里最容易漏掉的。第三个是上行BLER和MCS分布，如果上行MCS长期偏低，即使QOS Flow建立成功，GBR类业务也跑不动。

这三个指标不用单独建系统，网管后台通常都有现成报表，重要的是在评估环节把它们列入观察项，而不是只看主指标。主指标决定“这一步优化算不算成功”，伴随指标决定“这个成功能不能兑现成用户感知”。

5.3 用小脚本盯指标趋势，替代天天人工看曲线

现场最耗时间的环节，是每天人工翻报表找恶化的小区。我习惯把每天导出的小区级CSV放在一个目录里，用一个简单的Python脚本按天聚合，自动找出连续恶化的小区：

import csv, glob, statistics from collections import defaultdict # 假设每天一个CSV，字段包含：小区名,日期,QOSFlow建立成功率 rows = defaultdict(list) for path in glob.glob("qos_daily/*.csv"): with open(path, newline="") as f: for rec in csv.DictReader(f): cell = rec["小区名"] date = rec["日期"] rate = float(rec["QOSFlow建立成功率"].replace("%", "")) rows[cell].append((date, rate)) for cell, series in rows.items(): series.sort() vals = [rate for _, rate in series] if len(vals) >= 3 and vals[-1] < vals[-2] < vals[-3]: print(f"{cell} 连续三天递减: {series[-3:]}")

这段脚本按小区名分组，把每天的数据按日期排序，检查最近三天是否连续下降。连续三天递减说明问题在恶化，需要进后台看信令。它不能替代根因分析，只是让“该查谁”这件事不再靠运气。脚本里的表头名称要和实际导出文件一致，如果表头里带空格或百分号，先做清洗再参与计算。

6. 把排障做成模板：从失败原因值到下一轮优化的动作清单

处理完一个案例之后，我最常做的事情是把现场手记整理成一张可复用的动作清单，下次遇到类似问题直接按顺序执行，而不是每次从头开始“灵感排障”。这个模板的核心，是把失败原因值和动作一一对应起来。

第一步永远是拆口径。先确认后台统计的QOS Flow建立成功率包含哪些类型，默认和非默认是否分开。第二步看分布，失败集中在哪个时段、哪个小区、哪个终端型号，三个维度缺一不可。第三步才是看信令，取失败方向上的原因值，按前面那张cause映射表决定下一个动作。insufficient resources就去查忙时用户数、DRB利用率和每用户DRB上限；not supported QoS combination就去比5QI和ARP配置；radioNetwork层泛化原因就去查支路级的上行质量和分布系统状态。

我在现场踩过最深的坑，是太信任单一指标曲线，在覆盖优化上白绕了两天。后来给自己立了规矩：任何QOS Flow异常，先回答三个问题——坏的是默认还是非默认？坏在哪个时段？失败原因值收敛在哪一类？回答完这三个问题，再决定要不要碰参数。这套习惯帮我处理过不少看似“玄学”的室分成功率波动，其实多数问题都逃不出这个框架。

5G室分的QOS Flow建立问题之所以让人头疼，是因为它把无线、传输、核心网、终端的边界全搅在一起。但只要把流程拆到信令和原因值层面，多数问题都能在半天内收敛。希望帮到你。

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