【网络通信 — WebRTC】WebRTC 服务质量 (QoS) — Sender Side BWE

大家好，欢迎来到IT知识分享网。

【网络通信 — WebRTC】WebRTC 服务质量 (QoS) — Sender Side BWE

【1】BWE 简介

BWE (Bandwidth Estimation，带宽估计) 通过接收端反馈的包到达时刻信息、丢包信息和 REMB (Receiver Estimated Maximum Bitrate，接受端最大估计码率) 信息进行当前网络状态的码率评估；

【2】Sender Side BWE 基本原理

图示可见，Sender Side BWE 基于延迟的拥塞控制是通过 trendline 滤波再进行过载判断，最后根据过载情况进行 aimd 码率调控评估出一个 bwe bitrate 码率，该码率结合丢包评估出来的码率 base 和 remb 来决定最后的码率；

【2.1】remb bitrate

仅用作向下兼容使用，以兼容老版本的 Kalman Filter 算法；

【2.2】基于丢包的拥塞控制

Sender Side BWE 基于丢包率控制发送码率，其基本思想是丢包率反映网络拥塞状况；

• 如果丢包率很小或者为 0，说明网络状况良好，在不超过预设最大码率的情况下，可以增大发送端码率；
• 如果丢包率变大，说明网络状况变差，此时应减少发送端码率；
• 在其它情况下，发送端码率保持不变

WebRTC 中发送端收到 RTCP RR 报文并解析得到丢包率后，根据如下公式计算发送端码

• 
  • 当丢包率大于 0.1 时，说明网络发生拥塞，此时降低发送端码率；
  • 当丢包率小于 0.02 时，说明网络状况良好，此时增大发送端码率；
  • 其他情况下，发送端码率保持不变；

注意，调整的码率 (base bitrate) 并不是当前及时码率，而是单位时间窗周期内出现的最小码率，WebRTC 将这个时间窗周期设置在 1000 毫秒内，目的是防止网络间歇性统计造成的网络码率增长过快而网络反复波动；

【2.3】基于延时的拥塞控制

【2.3.1】包组与延迟

WebRTC 在评估延迟差的时候不是针对每个包进行估算，而是采用了包组进行延迟评估，这符合视频传输 (视频帧是需要切分成多个 UDP 包) 的特点，同时减少了频繁计算带来的误差；

• 包组，即距包组中第一个包的发送时刻 t0 小于 5 毫秒发送的所有的包组成的一组，第一个超过 5 毫秒的包作为下一个包组的第一个包；

Trendline 波器需要三个参数即，发送时刻差值 ()、到达时刻差值 () 和包组数据大小差值 (delta_size)，计算公式

【2.3.2】Trendline 滤波器趋势判断

计算过程

• 1. 计算单个包组传输增长的延迟

• 2. 计算每个包组的叠加延迟

• 3. 通过累积延迟计算一个均衡平滑延迟值，alpha = 0.9

• 4. 统一对累计延迟和均衡平滑延迟求平均

• 5. 将第 i 个包组的传输持续时间记作

• 6. 计算趋势的值

趋势斜率的分子

趋势斜率的分母

最终的趋势值

【2.3.3】过载检测

其中，， 为周期包组个数， 为动态阈值；

如果发生过载，WebRTC 通过一个有限状态机进行网络状态迁徙，如下

• 处于 Hold 状态表示维持当前码率
• 处于 Decr 状态表示需要进行码率递减
• 处于 Incr 状态表示需要进行码率递增

【2.3.4】AIMD 码率调节

AIMD 的全称是 Additive Increase Multiplicative Decrease，和式增加积式减少；AIMD controller 是 TCP 底层的码率调节概念，但 WebRTC 并没有完全照搬 TCP 的机制，而是设计了自己的算法，公式如下

• 如果处于 Incr 状态，增加码率的方式分为两种
  • 1. 通信会话刚刚开始，相当于 TCP 慢启动，进行一个倍数增加，当前使用的码率乘以系数 1.08；
  • 2. 通信会话持续状态，其增加的码率值是当前码率在一个 RTT(Round Trip Time) 时间周期所能传输的数据速率
• 如果处于 Decrease 状态，递减原则是过去 500ms 时间窗内的最大 acked bitrate 乘上系数 0.85，acked bitrate 可以通过 feedback 反馈的报文序号查找本地发送列表得到

参考致谢

本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。

【1】WebRTC的拥塞控制和带宽策略

【2】webrtc QOS方法四（Sender Side BWE）