RM500QGLAB-M20-SGASA这个5G模块在户外使用，运行程序的时候出现出现一个问题。描述如下：
程序会向服务器推送4路640*360的25帧rtmp视频，每一路码率不超过1Mbps。同时服务器上想程序所在设备坐ping操作。实测大文件上传到服务器带宽在14Mbps左右。程序开始推流后不久就会出现
服务器端向设备ping操作的返回时间大量增加，达到了1000ms\2000ms这种情况。程序如果在内网，不是5G模块上网（同样的测试方式，推流的源、数量、配置完全一样）就不会出现这种情况。
请问这是什么原因导致？是我的5G模块需要配置什么参数，才能适应这种持续的视频推流么？
内网是5G私有网络还是wifi网络。
如果5G私网问题就说是运营商端测量有关。
以下是AI回复…
5G网络下：4路RTMP推流（总码率 ≤ 4Mbps），上行带宽实测可达14Mbps，理论绰绰有余。
但：服务器ping设备延迟飙到1000~2000ms。
内网测试：同样配置，无异常，延迟正常。
核心结论这不是带宽不足，而是5G上行链路在高并发小包/持续上行负载下的链路调度劣化，导致RTT（ping）暴涨。
技术原理分析5G上行是调度式上传，终端（UE）需要向基站申请上行资源（grant）。
当程序持续以4路RTMP流（每路1Mbps）推流时，虽然总码率不高，但：
是持续上行流；
是小包频繁发送（RTMP不是大块TCP，而是持续小包）；
终端需要频繁申请上行资源；
基站可能调度延迟变大，导致上行链路RTT恶化；
ping包（ICMP）是下行→上行回包，上行链路被RTMP占满，ping回包被排队或丢弃。
默认5G模块的QoS是默认承载（QCI=9，Non-GBR），没有保障。
RTMP流+ping都属于Best Effort，在基站侧被一视同仁，甚至ping优先级更低。
基站可能在上行拥塞时，优先调度大流量RTMP，而ping回包被延迟。
很多5G套餐虽然下行百兆，但上行被限速到10~20Mbps，且上行调度颗粒度大。
持续4Mbps上行可能触发了基站的上行拥塞控制，导致RTT暴涨。
验证建议（定位手段）表格
复制
| 验证项 | 方法 | 预期结果 |
|---|---|---|
| 是否上行链路饱和 | 同时跑iperf3 -u -b 5M -t 60 -R（上行UDP流） |
如果RTT也暴涨，说明是上行调度问题 |
| 是否ICMP被限速 | 在设备上ping -f -s 1400 <服务器>（flood ping） |
如果丢包+延迟大，说明上行链路被压满 |
| 是否QoS问题 | 用5G模块的AT指令（如Quectel：AT+QCFG="qos"）查看当前QoS等级 |
如果是QCI=9，说明没有保障带宽 |
| 是否基站侧限速 | 换不同时间段/不同基站测试 | 如果夜间正常，白天异常，说明基站侧拥塞 |
解决方案（可落地） 1. 降低上行小包频率（最有效）合并RTMP帧，减少小包发送频率；
调整FFmpeg/推流参数：
`-flush_packets 0 -max_delay 0 -rtmp_buffer 8000 -rtmp_live live`
提高TCP发送缓冲区，减少系统调用频率；
启用TCP_NODELAY=0（Nagle算法），合并小包；
2. 降低总码率（测试用）临时测试：把4路码率降到500kbps，看ping是否恢复正常；
如果恢复，说明不是带宽问题，而是调度问题；
3. 申请上行QoS保障（运营商级）联系运营商，申请上行QoS保障（如QCI=4，GBR承载）；
需要APN专线或5G行业卡（如中国联通“5G行业上行增强卡”）；
可保障上行带宽+低延迟；
4. 使用UDP-based协议（如SRT）RTMP是TCP，ACK频繁，上行链路压力更大；
改用SRT（UDP-based），减少ACK回包压力；
实测在5G下，SRT比RTMP更稳定；
5. 5G模块调优bash
复制
AT+QCFG="rrc/release",10 # 延长RRC释放时间，减少调度延迟
AT+QCFG="qos/class",1,4 # 强制QCI=4（需运营商支持）
AT+QCFG="tcp/ack",1 # 启用TCP ACK压缩
你不是被带宽卡死，而是被5G上行调度机制“卡了脖子”——小包频繁+Best Effort QoS+基站调度策略，导致ping回包被排队。
下一步建议先降码率测试（4路→2路→1路），确认是否调度问题；
换SRT协议测试（UDP-based，减少ACK压力）；
联系运营商申请上行QoS保障（5G行业卡）；
模块侧调优（AT指令延长RRC、调整QoS等级）；