企业官网建设流程全解析

简介：这份文档面向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收到后转发给SMF，SMF根据UDM里的签约数据和本地策略做QoS授权，生成QoS Rule和QoS Flow Description，然后通过N4 Session Establishment Request下发给UPF。UPF回复N4 Session Establishment Response，SMF再通过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 Description，UPF的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里签约了5QI=2的语音专用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值（比如5QI=80），但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的计数器，最后才查无线侧。核心网的问题往往藏在信令细节里，无线指标正常不代表核心网没问题。希望帮到你。

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