国内某个5G首发演示保障，与虎牙直播合作，在保障开始前开始的业务联调，存在推流卡顿的问题，具体表现：推流软件（obs）设置码率50M、分辨率4K、30帧，监控到丢帧率较高，速率达不到50Mbps，且深圳观看有明显卡顿。

• 网络拓扑：

推流链路：推流PC->CPE->基站->核心网->承载网->视频服务器

拉流链路：拉流PC 使用potplayer播放器主动从服务器进行拉流观看

• 站点分布：

空口环境测试：UDP灌包和FTP上传可以达到70m以上，说明空口能力达标。

在CPE镜像抓包可见，报文平均RTT时延在17ms左右，无丢包乱序问题，TCP流有少量重传0.27%。

在基站使用IFTS 3201跟踪抓包可见：报文平均RTT时延12.8ms，无丢包乱序重传引入。

CPE镜像抓包和基站抓包说明基站以下时延低，没有引入丢包乱序问题，需要进一步隔离基站以上到核心网问题。

• 安排测试人员到电信机房，直连设备进行推流无卡顿，非核心网以上的问题。

• 基站S1-U会增加36字节GTPU报文头，如果TCP按照MTU 1500协商，发送报文最终会超过1500，基站出端口报文会分片为一个1500左右大包和一个小包，如果链路上某节点组包性能受限，容易引入乱序导致重传，从而限制TCP速率引起卡顿。如果修改终端侧设备MTU 到1400，TCP流会按照整条链路上的最小MTU（即pMTU）发送报文，基站发出报文不会超过1500，可以避免报文分片。

• 若出现分片，可能会导致：

a) 增加了网络接收端处理报文的复杂程度，接收端需将分片报文重组。对链路中的设备能力要求较高。

b) 分片后，任何一片丢失，均须重新发送，增加了网络开销。分片后每片都含一个IP头，导致传输效率降低。

修改终端设备的MTU（CPE）。从1500修改到1400，验证推流无卡顿，可以稳定推流码率50M、60M视频。

推流/拉流电脑进行TCP窗口优化。

a)关闭heuristics功能。netsh int tcp set heuristics disabled

b)优化TCP auto tuning。netsh int tcp set global autotuninglevel=normal

c)修改完之后可以用netsh int tcp show global查看是否修改成功。

成功经验：

• 4K推流对电脑性能要求较高，推流电脑应选用高性能游戏PC或游戏电脑，保证编解码效率和TCP流的稳定性。

• 可以通过修改终端设备的MTU，修改为较低值，使得测试终端设备的MTU比链路MTU小，规避链路上增加报头之后，TCP报文需要分片、重传，导致的速率下降等情况。

不足之处：

• 问题处理过程中仅定位出空口时延和丢包率指标正常，未能定位出基站以上丢包情况。后续类似问题需要总结方法，提升效率，与其他部门联合定位。

推广：

• 高清视频回传/直播等业务对链路要求较高，从推流电脑到光路带宽、服务器等都需要提前按照高规格提供，避免更换设备造成不必要的时间浪费。