5G SA室分QOS Flow建立成功率异常排查：从核心网信令到参数调优

简介这份文档面向5G网络优化工程师与运维人员聚焦SA室分场景下QoS Flow建立成功率异常这一典型问题提供从现象定位到参数整改的完整处理思路。资源为单个docx文件压缩包约85KB内容以案例记录与参数配置表为主便于直接查阅与归档。案例从A小区成功率低至56.32%、日失败4275次入手逐步排查站点告警、室分设计与信令流程最终定位到部分终端不支持1T模式需将csiRow调整为2、reportquantity改为criricqi并给出调整前后指标对比。举一反三环节还覆盖全区12个同类室分站点的核查整改并将处理方法纳入日常监控手册。目前已有505人学习适合需要掌握室分QoS优化、终端兼容性排查与参数调整实操的读者参考借鉴。1. SA室分QOS Flow建立成功率异常一个被忽视的5G核心网指标室分场景下的SA组网QOS Flow建立成功率突然从99.8%掉到87%用户感知是“能连上但刷不出内容”。这不是基站信号问题也不是传输闪断而是5G核心网SMF与UPF之间N4会话建立过程中QoS Flow的默认规则和专用规则发生了冲突。很多一线优化工程师盯着无线侧的RSRP、SINR看半天最后发现根因在核心网侧的策略配置上。这个案例要讲清楚三件事SA室分场景下QOS Flow建立流程长什么样、成功率异常时怎么分层排查、以及最终怎么通过信令跟踪和参数调整把指标拉回正常。适合已经接触过5G SA组网、做过室分覆盖但还没深入核心网信令的优化人员。如果你只会看无线参数这篇文章会让你多一个排查维度。2. SA室分场景下QOS Flow建立的完整信令链路2.1 从UE发起PDU会话到QoS Flow落地的五个阶段SA室分场景和宏站最大的区别在于室分系统通常由多个pRRU加一个基带单元组成覆盖区域信号强但切换少用户集中在室内业务类型以视频、办公、扫码为主。这种场景下QOS Flow建立成功率异常往往不是无线侧覆盖不足导致的而是核心网侧对QoS参数的处理出了问题。先理清SA架构下QOS Flow建立的标准流程。UE发起PDU Session Establishment Request消息里带Requested QoS Rules和Requested QoS Flow Descriptions。AMF收到后转发给SMFSMF根据UDM里的签约数据和本地策略做QoS授权生成QoS Rule和QoS Flow Description然后通过N4 Session Establishment Request下发给UPF。UPF回复N4 Session Establishment ResponseSMF再通过AMF把PDU Session Establishment Accept回给UE。整个过程涉及N1、N2、N4、N11四条接口。室分场景的特殊性在于pRRU和BBU之间的前传链路如果出现丢包会导致N2接口的NGAP消息超时SMF等不到AMF的响应就会释放会话。但这种情况在成功率统计上表现为PDU会话建立失败不是QOS Flow建立失败。QOS Flow建立成功率是更细粒度的指标它统计的是SMF向UPF下发QoS Flow Description后UPF成功安装并返回确认的比例。2.2 室分场景下QOS Flow建立成功率的统计口径不同设备厂商对QOS Flow建立成功率的计数器定义有差异但核心逻辑一致SMF侧统计N4 Session Modification Request中携带的QoS Flow Description数量与UPF侧返回的N4 Session Modification Response中成功安装的QoS Flow数量做比值。室分场景下如果SMF和UPF之间的N4链路经过多层交换机且没有配置QoS优先级N4消息可能被丢弃或延迟。常见做法是在SMF上开启N4接口的QoS Flow级统计同时抓取N4口的包分析。我一般会先确认三个计数器smf_n4_session_mod_req_qosflow_num、smf_n4_session_mod_rsp_qosflow_num、smf_n4_session_mod_fail_qosflow_num。如果第三个计数器在特定时间段突增说明UPF侧安装QoS Flow时出了问题。注意室分场景下pRRU数量多单个BBU下挂的pRRU可能超过20个每个pRRU覆盖的区域用户行为不同。如果某个pRRU下的用户集中发起视频业务SMF会频繁下发QoS Flow DescriptionUPF的N4会话表可能溢出。2.3 用Wireshark抓取N4接口验证QoS Flow安装过程在SMF和UPF之间的交换机上做端口镜像抓取N4接口的PFCP报文。Wireshark从3.6版本开始支持PFCP协议解析过滤条件是pfcp。重点看N4 Session Modification Request里的Create QER和Create FAR IE以及Response里的Cause值。# 在SMF所在服务器上抓取N4口报文假设N4口是eth1 tcpdump -i eth1 -w n4_capture.pcap udp port 8805 # 抓取60秒后停止用Wireshark打开分析 # 过滤条件pfcp.msg_type 52 表示Session Modification Request # pfcp.msg_type 53 表示Session Modification Response抓包后重点看Response里的Cause值。如果Cause是“Request rejected”说明UPF侧策略拒绝了QoS Flow安装如果是“Session context not found”说明SMF和UPF的会话状态不一致。室分场景下最常见的是Cause“Out of memory”因为UPF的会话表项被占满。参数说明tcpdump的-i指定网卡-w指定输出文件过滤条件udp port 8805是PFCP的标准端口。抓包时长建议覆盖业务高峰时段至少15分钟否则可能抓不到异常样本。3. 从核心网到无线侧的分层排查方法3.1 先查SMF的QoS策略配置是否与UDM签约一致QOS Flow建立失败的第一层排查在SMF。登录SMF的网管查看当前用户的UDM签约数据里QoS Flow的5QI值、ARP、GBR/MBR参数。然后对比SMF本地配置的QoS策略模板。常见问题是UDM里签约了5QI2的语音专用QoS Flow但SMF的本地策略模板里没有配置对应的QER导致SMF无法生成完整的QoS Flow Description。# 在SMF上查询指定用户的签约QoS信息假设用户SUPI为imsi-460001234567890 smf-cli query subscriber --supi imsi-460001234567890 --qos-info # 输出示例 # 5QI: 2, ARP: 5, GBR: 100kbps, MBR: 200kbps # 5QI: 9, ARP: 8, GBR: 0, MBR: 0 # 对比SMF本地策略模板 smf-cli show qos-template --all如果发现UDM签约的5QI在SMF策略模板里缺失需要补配。补配后不需要重启SMF但需要触发UE重新发起PDU会话建立。室分场景下可以远程让pRRU下的UE去附着再重新注册。参数说明--supi指定用户永久标识--qos-info输出签约的QoS参数。smf-cli是通用示例不同厂商命令不同华为叫DSP SUBSCRIBER中兴叫SHOW SUBSCRIBER。3.2 检查UPF的N4会话表容量和QER安装日志第二层排查在UPF。登录UPF的调试终端查看当前N4会话表的使用率。如果使用率超过80%新来的QoS Flow安装请求可能被拒绝。室分场景下一个BBU下挂几百个用户如果UPF是低配版本会话表很容易满。# 查看UPF的N4会话表使用情况 upf-cli show n4-session-table --usage # 输出示例 # Total: 100000, Used: 85000, Usage: 85% # 查看最近的QER安装失败日志 upf-cli show log --module qer --level error --last 100 # 输出示例 # 2024-01-15 10:23:45 QER install failed: table full, session id: 0x12345678如果确认是会话表满解决方案有两个扩容UPF的会话表规格或者清理僵尸会话。僵尸会话通常是UE已经去附着但SMF没有及时释放N4会话导致的。可以配置SMF的N4会话老化时间从默认的3600秒调整为1800秒。参数说明--usage显示使用率--last 100显示最近100条日志。老化时间调整需要评估业务连续性太短会导致正常业务被误释放。3.3 无线侧参数对QOS Flow建立的间接影响虽然QOS Flow建立成功率是核心网指标但无线侧参数会间接影响。室分场景下如果pRRU的发射功率设置过高导致UE上报的CQI虚高SMF会分配更高的QoS等级UPF安装QoS Flow时需要更多资源。如果UPF资源不足就会拒绝。常见做法是检查pRRU的功率配置确保覆盖边缘的RSRP在-105dBm左右SINR大于15dB。如果功率过高可以下调3到5dB。同时检查PDCCH的聚合等级配置室分场景下建议用AL4或AL8避免AL1导致控制信道误码率高。# 查询pRRU的功率配置假设pRRU ID为0x01 gnb-cli show prru --id 0x01 --power # 输出示例 # TxPower: 20dBm, MaxPower: 24dBm # 调整功率 gnb-cli set prru --id 0x01 --power 17参数说明--power设置发射功率单位dBm。下调功率后需要观察RSRP和SINR的变化如果RSRP低于-110dBm需要回调。4. 避坑QOS Flow建立成功率排查中的五个血泪教训4.1 只看无线指标忽略N4接口丢包现象室分场景下QOS Flow建立成功率下降但RSRP、SINR、切换成功率都正常。原因SMF和UPF之间的N4链路经过一台老旧的接入交换机端口协商模式是半双工导致PFCP报文间歇性丢失。解决在交换机上把N4口强制为全双工并开启流量控制。用tcpdump抓包确认丢包率如果超过0.1%就需要换交换机或调整链路。4.2 UDM签约数据与SMF策略模板不一致现象特定用户群比如某个企业客户的QOS Flow建立成功率极低其他用户正常。原因UDM里签约了非标准5QI值比如5QI80但SMF的策略模板只支持标准5QI。解决在SMF上添加自定义5QI映射表或者修改UDM签约数据为标准5QI。修改后需要同步刷新SMF的策略缓存。4.3 UPF会话表老化时间过长导致资源耗尽现象每天下午3点后QOS Flow建立成功率开始下降晚上8点后恢复。原因UPF的N4会话老化时间是3600秒但室分场景下用户流动性低很多UE去附着后会话没有及时释放到下午累积占满会话表。解决把老化时间调整为1800秒并开启SMF的会话审计功能每5分钟清理一次僵尸会话。4.4 抓包位置不对导致分析方向错误现象在SMF上抓N4包发现Request正常发出但Response超时以为是UPF问题。原因抓包点选在了SMF的出口没有抓到UPF的入口中间经过的交换机可能丢弃了报文。解决在SMF和UPF两侧同时抓包对比Request和Response的时间戳。如果SMF发出后UPF没收到问题在中间网络如果UPF收到了但没回问题在UPF。4.5 忽略pRRU前传链路对N2接口的影响现象QOS Flow建立失败的同时NGAP消息也偶发超时。原因pRRU和BBU之间的前传链路是千兆电口但室分场景下多个pRRU级联总流量超过端口带宽。解决检查前传链路的带宽利用率如果超过70%需要把级联改为星型连接或者升级到万兆前传。5. 把成功率从87%拉回99.8%的实操参数与验证方法5.1 SMF侧N4会话老化时间与QoS Flow重试机制调整最终解决这个案例核心调整在SMF侧。把N4会话老化时间从3600秒改为1800秒同时开启QoS Flow建立失败后的自动重试重试次数设为2次重试间隔500毫秒。重试机制的关键是第一次失败后不立即释放会话而是等500毫秒后重新下发QoS Flow Description。室分场景下N4链路的瞬时拥塞通常在200毫秒内恢复重试能覆盖大部分异常。# 修改SMF的N4会话老化时间 smf-cli set n4-session --aging-time 1800 # 开启QoS Flow重试 smf-cli set qos-flow --retry-enable true --retry-times 2 --retry-interval 500 # 查看当前配置 smf-cli show qos-flow --config参数说明--aging-time单位秒--retry-times最大重试次数--retry-interval单位毫秒。重试次数不建议超过3次否则会延长用户等待时间。5.2 UPF侧QER资源预留与动态扩容UPF侧需要为室分场景预留QER资源。在UPF的配置里把QER表分为默认池和专用池专用池预留给室分场景的QoS Flow。专用池的大小根据室分覆盖的用户数估算一般按每pRRU 50个QER预留。# 配置UPF的QER资源池 upf-cli set qer-pool --name indoor --size 2000 --reserved true # 把室分场景的SMF关联到专用池 upf-cli set smf-association --smf-id smf01 --qer-pool indoor # 查看QER池使用情况 upf-cli show qer-pool --name indoor --usage参数说明--size是QER表项数量--reserved表示预留。预留池不会被其他场景占用但会降低整体资源利用率需要权衡。5.3 验证方法用信令跟踪和计数器对比确认修复效果调整后需要验证。方法一在SMF上开启QoS Flow级信令跟踪跟踪特定用户的PDU会话建立过程确认QoS Flow Description成功下发并收到Response。方法二对比调整前后的计数器smf_n4_session_mod_fail_qosflow_num应该从每天上千次降到个位数。# 开启信令跟踪跟踪SUPI为imsi-460001234567890的用户 smf-cli trace subscriber --supi imsi-460001234567890 --output /tmp/trace.log # 跟踪10分钟后分析 grep QoS Flow /tmp/trace.log | grep -c Success grep QoS Flow /tmp/trace.log | grep -c Fail参数说明--output指定跟踪日志文件grep统计成功和失败次数。如果失败次数仍然偏高需要检查UPF的QER池使用率。5.4 一个容易被忽略的技巧用PFCP心跳检测N4链路质量N4链路的PFCP协议本身有心跳机制但默认心跳间隔是60秒太长了。可以调整为10秒这样能更快发现链路异常。同时开启PFCP心跳的丢包统计如果连续3个心跳丢失SMF就主动切换N4链路到备用路径。# 调整PFCP心跳间隔 smf-cli set pfcp --heartbeat-interval 10 --heartbeat-retry 3 # 查看心跳统计 smf-cli show pfcp --heartbeat-stats # 输出示例 # Sent: 1000, Received: 998, Lost: 2, LossRate: 0.2%参数说明--heartbeat-interval单位秒--heartbeat-retry连续丢失次数阈值。心跳间隔太短会增加N4链路负担10秒是室分场景下的经验值。这个案例让我养成了一个习惯每次处理QOS Flow建立成功率异常先抓N4包再看SMF和UPF的计数器最后才查无线侧。核心网的问题往往藏在信令细节里无线指标正常不代表核心网没问题。希望帮到你。本文还有配套的精品资源点击获取