简介本资源为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 RequestSMF根据DNN和S-NSSAI选择UPF下发N4 Session Establishment到UPF同时通过AMF向gNB发送PDU Session Resource Setup RequestgNB根据QoS参数做准入控制返回Response后SMF确认建立完成。室分场景的特殊性在于gNB通常是数字化室分pRRU加BBU架构小区数量多但单小区用户数少QoS Flow的建立请求往往集中在少数几个pRRU覆盖区域。如果某个pRRU的传输资源或基带板资源受限准入控制会直接拒绝但拒绝原因在KPI里只体现为“失败”不会自动关联到具体硬件。2.2 成功率异常的三种典型模式第一种是“均匀下降”所有室分小区的成功率同步下跌通常指向核心网SMF/UPF参数变更或AMF侧定时器调整。第二种是“局部塌陷”只有特定楼层或特定pRRU下的小区指标恶化大概率是基带资源或传输带宽问题。第三种是“脉冲式波动”成功率在忙时骤降、闲时恢复需要重点看ARP抢占和GBR资源的动态分配。我一般会先拉三天的分小时粒度数据把失败次数按小区和QFI分组看是5QI1的语音Flow失败多还是5QI9的默认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 # 输出重点关注 # 5QI9 ARP8 Session-AMBR100Mbps # 5QI1 ARP2 Session-AMBR50Mbps # N4 Session Establishment Timeout3s逻辑说明这条命令拉取的是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终端只支持5QI9的默认Flow当网络尝试建立5QI1的语音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%。同时5QI1的语音Flow失败次数远高于5QI9说明ARP抢占也在起作用。5.2 调优步骤与参数对照调整项调整前调整后影响Session-AMBR100Mbps80Mbps降低准入资源预留5QI1 ARP24减少语音Flow抢占PRB告警阈值95%85%提前触发扩容N4超时3s5s容忍室分gNB处理时延pRRU功率12dBm10dBm降低重叠覆盖调整后观察三天成功率从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参数记在交付文档里。等指标恶化时直接对比基线就能快速定位是资源问题还是参数问题。希望帮到你。本文还有配套的精品资源点击获取