實時流媒體應用的最大特點是實時性，而延遲是實時性的最大敵人。從媒體收發端來講，媒體數據的處理速度是造成延遲的重要原因；而從傳輸角度來講，網絡擁塞則是造成延遲的最主要原因。網絡擁塞可能造成數據包丟失，也可能造成數據傳輸時間變長，延遲增大。</br>
擁塞控制是實時流媒體應用質量保證(QoS)的重要手段之一，它在緩解網絡擁堵、減小網絡延遲、平滑數據傳輸等質量保證方面發揮重要作用。WebRTC通控制發送端數據發送碼率來達到控制網絡擁塞的目的，其采用谷歌提出的擁塞控制算法(Google Congestion Control，簡稱GCC[1])來控制發送端碼率。</br>
本文是關于WebRTC擁塞控制算法GCC的上半部分，主要集中于對算法的理論分析，力圖對WebRTC的QoS有一個全面直觀的認識。在下半部分，將深入WebRTC源代碼內部，仔細分析GCC的實現細節。</br>
1 GCC算法綜述
</br>
</br>Google關于GCC的RFC文檔在文獻[1]，該RFC目前處于草案狀態，還沒有成為IETF的正式RFC。此外，Google陸續發布了一系列論文[2][3][4]來論述該算法的實現細節，以及其在Google Hangouts、WebRTC等產品中的應用。本文主要根據這些文檔資料，從理論上學習GCC算法。</br>
GCC算法分兩部分：發送端基于丟包率的碼率控制和接收端基于延遲的碼率控制。如圖1所示。
基于丟包率的碼率控制運行在發送端，依靠RTCP RR報文進行工作。WebRTC在發送端收到來自接收端的RTCP RR報文，根據其Report Block中攜帶的丟包率信息，動態調整發送端碼率As。基于延遲的碼率控制運行在接收端，WebRTC根據數據包到達的時間延遲，通過到達時間濾波器，估算出網絡延遲m(t)，然后經過過載檢測器判斷當前網絡的擁塞狀況，最后在碼率控制器根據規則計算出遠端估計最大碼率Ar。得到Ar之后，通過RTCP REMB報文返回發送端。發送端綜合As、Ar和預配置的上下限，計算出最終的目標碼率A，該碼率會作用到Encoder、RTP和PacedSender等模塊，控制發送端的碼率。</br>
2 發送端基于丟包率的碼率控制
</br>
</br>GCC算法在發送端基于丟包率控制發送碼率，其基本思想是：丟包率反映網絡擁塞狀況。如果丟包率很小或者為0，說明網絡狀況良好，在不超過預設最大碼率的情況下，可以增大發送端碼率；反之如果丟包率變大，說明網絡狀況變差，此時應減少發送端碼率。在其它情況下，發送端碼率保持不變。</br>
GCC使用的丟包率根據接收端RTP接收統計信息計算得到，通過RTCP RR報文中返回給發送端。RTCP RR報文統計接收端RTP接收信息，如Packet Loss，Jitter，DLSR等等，如圖2所示：</br>
發送端收到RTCP RR報文并解析得到丟包率后，根據圖3公式計算發送端碼率：當丟包率大于0.1時，說明網絡發生擁塞，此時降低發送端碼率；當丟包率小于0.02時，說明網絡狀況良好，此時增大發送端碼率；其他情況下，發送端碼率保持不變。</br>
最終碼率會作用于Encoder、RTP和PacedSender模塊，用以在編碼器內部調整碼率和平滑發送端發送速率。</br>
3 接收端基于延遲的碼率控制
</br>
</br>GCC算法在接收端基于數據包到達延遲估計發送碼率Ar，然后通過RTCP REMB報文反饋到發送端，發送端把Ar作為最終目標碼率的上限值。其基本思想是： RTP數據包的到達時間延遲m(i)反映網絡擁塞狀況。當延遲很小時，說明網絡擁塞不嚴重，可以適當增大目標碼率；當延遲變大時，說明網絡擁塞變嚴重，需要減小目標碼率；當延遲維持在一個低水平時，目標碼率維持不變。</br>
基于延時的擁塞控制由三個主要模塊組成：到達時間濾波器，過載檢查器和速率控制器；除此之外還有過載閾值自適應模塊和REMB報文生成模塊，如圖1所示。下面分別論述其工作過程。</br>
3.1 到達時間濾波器(Arrival-time Filter)
</br>
</br>該模塊用以計算相鄰相鄰兩個數據包組的網絡排隊延遲m(i)。數據包組定義為一段時間內連續發送的數據包的集合。一系列數據包短時間里連續發送，這段時間稱為突發時間，建議突發時間為5ms。不建議在突發時間內的包間隔時間做度量，而是把它們做為一組來測量。通過相鄰兩個數據包組的發送時間和到達時間，計算得到組間延遲d (i)。組間延遲示意圖及計算公式如圖4所示：</br>
T(i)是第i個數據包組中第一個數據包的發送時間，t(i)是第i個數據包組中最后一個數據包的到達時間。幀間延遲通過如下公式計算得到：</br>
d(i) = t(i) – t(i-1) – (T(i) – T(i-1)) (3.1.1)
公式1.3.1是d(i)的觀測方程。另一方面，d(i)也可由如下狀態方程得到：</br>
d(i) = dL(i)/C(i) + w(i) (3.1.2)
d(i) = dL(i)/C(i) + m(i) + v(i) (3.1.3)
其中dL(i)表示相鄰兩幀的長度差，C(i)表示網絡信道容量，m(i)表示網絡排隊延遲，v(i)表示零均值噪聲。m(i)即是我們要求得的網絡排隊延遲。通過Kalman Filter可以求得該值。具體計算過程請參考文獻[1][4][6]。</br>
3.2 過載檢測器(Over-use Detector)
</br>
</br>該模塊以到達時間濾波器計算得到的網絡排隊延遲m(i)為輸入，結合當前閾值gamma_1，判斷當前網絡是否過載。判斷算法如圖5所示[2]。</br>
算法基于當前網絡排隊延遲m(i)和當前閾值gamma_1判斷當前網絡擁塞狀況[2]：當m(i) > gamma_1時，算法計算處于當前狀態的持續時間t(ou) = t(ou) + delta(t)，如果t(ou)大于設定閾值gamma_2(實際計算中設置為10ms)，并且m(i) > m(i-1)，則發出網絡過載信號Overuse，同時重置t(ou)。如果m(i)小于m(i-1)，即使高于閥值gamma_1也不需要發出過載信號。當m(i) < -gamma_1時，算法認為當前網絡處于空閑狀態，發出網絡低載信號Underuse。當 – gamma_1 <= m(i) <= gamma_1是，算法認為當前網絡使用率適中，發出保持信號Hold。算法隨著時間軸的計算過程可從圖6中看到。</br>
需要注意的是，閥值gamma_1對算法的影響很大，并且閾值gamma_1是自適應性的。如果其是靜態值，會帶來一系列問題，詳見文獻[4]。所以gamma_1需要動態調整來達到良好的表現。這就是圖1中的Adaptive threshould模塊。閾值gamma_1動態更新的公式如下：</br>
gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-gamma_1(i-1)) (3.2.4)
當|m(i)|>gamma_1(i-1)時增加gamma_1(i)，反之減小gamma_1(i)，而當|m(i)|– gamma_1(i) >15，建議gamma_1(i)不更新。K(i)為更新系數，當|m(i)|<gamma_1(i-1)時K(i) = K_d，否則K(i) = K_u。同時建議gamma_1(i)控制在[6,600]區間。太小的值會導致探測器過于敏感。建議增加系數要大于減少系數K_u > K_d。文獻[1]給出的建議值如下：</br>
gamma_1(0) = 12.5 ms
gamma_2 = 10 ms
K_u = 0.01
K_d = 0.00018
3.3 速率控制器(Remote Rate Controller)
</br>
</br>該模塊以過載檢測器給出的當前網絡狀態s為輸入，首先根據圖7所示的有限狀態機判斷當前碼率的變化趨勢，然后根據圖8所示的公式計算目標碼率Ar。</br>
當前網絡過載時，目標碼率處于Decrease狀態；當前網絡低載時，目標碼率處于Hold狀態；當網絡正常時，處于Decrease狀態時遷移到Hold狀態，處于Hold/Increase狀態時都遷移到Increase狀態。當判斷出碼率變化趨勢后，根據圖8所示公式進行計算目標碼率。</br>
當碼率變化趨勢為Increase時，當前碼率為上次碼率乘上系數1.05；當碼率變化趨勢為Decrease，當前碼率為過去500ms內的最大接收碼率乘上系數0.85。當碼率變化趨勢為Hold時，當前碼率保持不變。目標碼率Ar計算得到之后，下一步把Ar封裝到REMB報文中發送回發送端。在REMB報文中，Ar被表示為Ar = M * 2^Exp，其中M封裝在BR Mantissa域，占18位；Exp封裝在BR Exp域，占6位。REMB報文是Payload為206的RTCP報文[7]，格式如圖9所示。</br>
REMB報文每秒發送一次，當Ar(i) < 0.97 * Ar(i-1)時則立即發送。</br>
3.4 發送端目標碼率的確定
</br>
</br>發送端最終目標碼率的確定結合了基于丟包率計算得到的碼率As和基于延遲計算得到的碼率Ar。此外，在實際實現中還會配置目標碼率的上限值和下限值。綜合以上因素，最終目標碼率確定如下：</br>
target_bitrate = max( min( min(As, Ar), Amax), Amin) (3.4.1)
目標碼率確定之后，分別設置到Encoder模塊和PacedSender模塊。</br>
4 總結
</br>
</br>本文在廣泛調研WebRTC GCC算法的相關RFC和論文的基礎上，全面深入學習GCC算法的理論分析，以此為契機力圖對WebRTC的QoS有一個全面直觀的認識。為將來深入WebRTC源代碼內部分析GCC的實現細節奠定基礎。</br>
</br>
</br>
參考文獻
</br>
[1] A Google Congestion Control Algorithm for Real-Time Communication.
draft-alvestrand-rmcat-congestion-03
[2] Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb.
[3] Experimental Investigation of the Google Congestion Control for Real-Time Flows.
[4] Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC). MMSys’16, May 10-13, 2016, Klagenfurt, Austria
[5] RFC3550: RTP - A Transport Protocol for Real-Time Applications
[6] WebRTC視頻接收緩沖區基于KalmanFilter的延遲模型.
http://www.lxweimin.com/p/bb34995c549a
[7] RTCP message for Receiver Estimated Maximum Bitrate. draft-alvestrand-rmcat-remb-03
