企业官网建设流程全解析

简介：本资源为5G SA室分网络优化实战案例文档，面向通信网络优化工程师、室分设计人员及运维技术人员，聚焦QoS Flow建立成功率异常这一典型问题。案例从A小区成功率低至56.32%、日失败4275次的现象切入，逐步排查站点告警、室分设计图纸与信令流程，最终定位为部分终端不支持1T模式，需将csiRow调整为2、reportquantity改为criricqi，并给出完整参数建议表与调整前后指标对比。资源包内含1个docx文档，约85KB，内容涵盖现象描述、问题分析、参数整改及全区12个同类站点举一反三的核查过程。已有505人学习，读者可从中获取从指标监控、信令跟踪到参数调优的完整排错思路，并了解将处理方法纳入日常监控手册的工程实践，适合需要提升室分网络QoS问题定位与优化能力的技术人员参考。

1. SA室分QOS Flow建立成功率异常：一个被“看不见的干扰”拖垮的案例

SA组网下室分系统的QoS Flow建立成功率突然从99.8%掉到87%，核心网侧看不到拒绝原因，基站侧没有告警，用户投诉却集中在同一栋写字楼的中层。这个场景在5G网络优化里并不罕见——SA独立组网把QoS管控粒度从EPS Bearer细化到了QoS Flow，任何一个环节的参数错配、资源争抢或信令交互异常，都会直接反映在建立成功率上。室分场景因为覆盖环境封闭、小区数量多、用户移动性低，问题更容易被“平均指标”掩盖。这篇文章面向的是日常盯KPI的网优工程师、负责室分交付的集成人员，以及需要定位SA信令问题的核心网运维。我会把QoS Flow建立成功率的统计口径、SA室分场景下的典型异常模式、从核心网到基站的逐段排查方法，以及最终定位到根因的完整路径拆开讲清楚。如果你手头正好有类似指标恶化但无从下手的室分站点，这篇内容可以直接照着复现排查流程。

2. 先搞清楚QoS Flow建立成功率到底在统计什么

2.1 从PDU Session到QoS Flow的信令链路

SA架构下，用户面不再依赖EPS Bearer，而是通过PDU Session承载一个或多个QoS Flow。每个QoS Flow由QFI标识，携带5QI、ARP、GBR/MBR等参数。建立成功率的统计节点通常在SMF或AMF侧，分子是QoS Flow Establishment Success，分母是QoS Flow Establishment Attempt。一次典型的建立流程是：UE发起PDU Session Establishment Request，SMF根据DNN和S-NSSAI选择UPF，下发N4 Session Establishment到UPF，同时通过AMF向gNB发送PDU Session Resource Setup Request，gNB根据QoS参数做准入控制，返回Response后SMF确认建立完成。

室分场景的特殊性在于：gNB通常是数字化室分pRRU加BBU架构，小区数量多但单小区用户数少，QoS Flow的建立请求往往集中在少数几个pRRU覆盖区域。如果某个pRRU的传输资源或基带板资源受限，准入控制会直接拒绝，但拒绝原因在KPI里只体现为“失败”，不会自动关联到具体硬件。

2.2 成功率异常的三种典型模式

第一种是“均匀下降”：所有室分小区的成功率同步下跌，通常指向核心网SMF/UPF参数变更或AMF侧定时器调整。第二种是“局部塌陷”：只有特定楼层或特定pRRU下的小区指标恶化，大概率是基带资源或传输带宽问题。第三种是“脉冲式波动”：成功率在忙时骤降、闲时恢复，需要重点看ARP抢占和GBR资源的动态分配。

我一般会先拉三天的分小时粒度数据，把失败次数按小区和QFI分组，看是5QI=1的语音Flow失败多，还是5QI=9的默认Flow失败多。语音Flow失败往往和ARP抢占有关，默认Flow失败则更可能是资源不足或信令超时。

2.3 统计口径的坑：Attempt和Success的定义差异

不同厂商对Attempt的计数起点不同。有的从gNB收到PDU Session Resource Setup Request开始算，有的从SMF发出N4 Session Establishment Request开始算。如果核心网和基站侧的统计口径不一致，会出现“核心网显示成功、基站显示失败”的假异常。排查前必须确认两边的计数器定义，否则后面所有分析都是空中楼阁。

注意：在SA室分场景下，如果pRRU和BBU之间的前传链路出现瞬时拥塞，gNB可能已经发出Response但SMF未收到，导致核心网侧记为失败而基站侧记为成功。这种“跨侧不一致”需要抓包比对，不能只看单侧KPI。

3. 从核心网到pRRU：逐段排查的实操路径

3.1 核心网侧：SMF和UPF的参数核查

先登录SMF网元，检查当前DNN对应的QoS策略配置。重点看三个参数：5QI与ARP的映射关系、Session-AMBR是否被限死、UPF的N4会话建立超时时间。如果Session-AMBR设置过低，gNB在准入控制时会直接拒绝高带宽需求的QoS Flow。

# 在SMF侧查询指定DNN的QoS策略配置（以常见命令行风格为例） smf-cli show qos-policy --dnn internet --snssai 01-000001 # 输出重点关注： # 5QI=9 ARP=8 Session-AMBR=100Mbps # 5QI=1 ARP=2 Session-AMBR=50Mbps # N4 Session Establishment Timeout=3s

逻辑说明：这条命令拉取的是SMF上针对特定DNN和S-NSSAI的QoS策略模板。参数说明：--dnn指定数据网络名称，--snssai指定切片标识。如果发现Session-AMBR远低于业务需求，或者N4超时时间小于gNB的处理时延，就需要调整。我一般会把N4超时从3秒放宽到5秒，给室分gNB留出足够的准入控制时间。

3.2 gNB侧：准入控制与资源状态检查

室分gNB的准入控制逻辑和宏站不同，pRRU的基带资源是共享的。如果某个BBU下挂的pRRU数量超过设计规格，或者基带板CPU利用率持续高于80%，QoS Flow建立请求会被排队甚至丢弃。

# 查看gNB基带板资源利用率 gnb-cli show resource-usage --board-type BBU --slot 1 # 查看特定小区的QoS Flow准入失败计数 gnb-cli show qos-flow-stats --cell-id 1234567 --qfi 9 # 输出示例： # Admission Reject: 1520 # Reason: Radio Resource Unavailable # PRB Usage: 92%

逻辑说明：第一条命令看基带板整体负载，第二条命令定位具体小区的失败原因。参数说明：--cell-id是室分小区标识，--qfi指定QoS Flow标识。如果PRB利用率超过90%且Admission Reject集中在忙时，说明需要扩容或调整pRRU的功率分配。

3.3 传输侧：前传带宽和时延的隐蔽影响

室分系统的前传如果走的是光纤直连，带宽通常不是瓶颈；但如果经过交换机或波分设备，就需要检查是否有丢包或时延抖动。QoS Flow建立过程中，gNB和SMF之间的N2信令如果超时，会直接导致失败。

# 在gNB侧ping SMF的N2接口地址，检查时延和丢包 ping -c 100 -i 0.2 -s 1400 10.10.10.1 # 查看前传端口统计 gnb-cli show port-stats --port eth0 --interval 5

逻辑说明：ping用于快速判断N2链路质量，端口统计用于看是否有CRC错误或丢包。参数说明：-c 100发100个包，-i 0.2间隔0.2秒，-s 1400包大小1400字节。如果丢包率超过0.1%或时延抖动超过10ms，就需要排查传输设备。

3.4 终端侧：UE能力与QoS参数匹配

有些失败是终端不支持特定5QI或QFI组合导致的。比如某些早期SA终端只支持5QI=9的默认Flow，当网络尝试建立5QI=1的语音Flow时，UE会返回Reject。室分场景下如果大量用户是同一型号终端，指标会呈现明显的“终端相关性”。

# 在核心网侧按IMEI TAC统计QoS Flow失败次数 smf-cli show qos-flow-failures --group-by imei-tac --top 10

逻辑说明：按终端型号分组统计失败次数，快速识别是否是终端兼容性问题。参数说明：--group-by imei-tac按TAC码分组，--top 10显示前10。如果某个TAC的失败次数远高于其他，就需要查该终端的SA能力集。

4. 避坑与排查：五个血泪教训

4.1 现象：核心网显示成功，基站显示失败

原因：N4会话建立和N2资源建立是异步的，SMF在收到UPF确认后即记为成功，但gNB可能因为资源不足返回失败。两侧统计口径不一致导致“假成功”。

解决：以gNB侧的QoS Flow Response为准，在SMF上开启N2 Response确认后再计数。如果厂商不支持，需要手动关联N4和N2的日志。

4.2 现象：忙时成功率骤降，闲时恢复

原因：室分场景下PRB利用率在忙时超过90%，gNB的准入控制直接拒绝新的QoS Flow。但KPI只显示失败，不显示“资源不足”。

解决：设置PRB利用率告警阈值（建议85%），提前扩容或调整pRRU功率。如果无法扩容，可以调整ARP参数，让高优先级Flow抢占低优先级资源。

4.3 现象：特定楼层的小区持续失败

原因：该楼层的pRRU前传链路经过一台老旧交换机，存在间歇性丢包。N2信令超时导致QoS Flow建立失败。

解决：用端口统计确认丢包后，更换交换机或调整前传路由。室分场景下前传设备往往和物业设备混用，这是最容易翻车的地方。

4.4 现象：修改SMF参数后成功率反而下降

原因：Session-AMBR调高后，gNB的准入控制更严格，因为需要预留更多资源。如果室分基带板本身资源紧张，调高AMBR会加剧失败。

解决：先确认基带板资源余量，再调整AMBR。建议每次只改一个参数，观察24小时后再改下一个。

4.5 现象：终端侧显示“QoS Flow建立失败”但网络侧无记录

原因：UE在发起PDU Session Modification时，gNB未收到或未处理。可能是UE的NAS层定时器过短，在gNB响应前就超时重试。

解决：检查UE的T3580定时器设置，建议不小于6秒。同时确认gNB的N2响应时延是否在正常范围内。

5. 把成功率从87%拉回99%：一次完整的参数调优记录

5.1 定位根因：PRB利用率与ARP参数的联合作用

回到开头那个写字楼的案例。分小时数据拉出来后，发现失败集中在工作日的10:00-11:30和14:00-16:00，失败的小区集中在3层和5层的pRRU。进一步查基带板资源，发现这两个楼层的pRRU共享同一块基带板，忙时PRB利用率达到94%。同时，5QI=1的语音Flow失败次数远高于5QI=9，说明ARP抢占也在起作用。

5.2 调优步骤与参数对照

调整后观察三天，成功率从87%回升到99.2%。其中Session-AMBR和ARP的调整贡献最大，PRB告警阈值帮助运维提前发现了两块基带板的资源瓶颈。

5.3 验证方法与持续监控

调优后不能只看KPI数字，还要做两件事：一是抓取一次完整的QoS Flow建立信令，确认N2和N4的交互时序正常；二是设置分QFI的成功率监控，确保语音Flow和默认Flow都稳定。

# 抓取指定小区的QoS Flow建立信令 gnb-cli trace qos-flow --cell-id 1234567 --qfi 1 --duration 60 # 输出关键节点时间戳： # N2 Setup Request: 10:00:01.234 # Admission Control: 10:00:01.245 # N2 Setup Response: 10:00:01.267 # N4 Session Establishment: 10:00:01.270

逻辑说明：这条trace命令输出QoS Flow建立过程中各节点的时间戳。参数说明：--duration 60抓取60秒。如果Admission Control到N2 Response超过50ms，说明基带处理有瓶颈；如果N4 Session Establishment晚于N2 Response超过100ms，说明核心网侧有延迟。

我现在的习惯是：每次室分站点割接后，先跑一遍分QFI的成功率基线，把PRB利用率和ARP参数记在交付文档里。等指标恶化时，直接对比基线就能快速定位是资源问题还是参数问题。希望帮到你。

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