点击上方蓝字关注「前景理论」
◆ ◆ ◆
国内某个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查看是否修改成功。

