第三章 Scalable Codec over DCCP
3.5 演算法設計
3.5.1 壅塞偵測
表 11 Scalable Codec 10~
Max_level
Quality Bit-rate(Kbps) Packet Size (Payload only) 路串流封包。CCID3 又名 TCP-Friendly Rate Control(TFRC)，透過 RTT (Round Trip Time) 與封包遺失率(Packet Loss Rate)等參數計算傳輸速率。
DCCP 傳送端傳送封包時會在封包中加入封包序號以及 Timestamp。每傳送 一個封包，封包序號會遞增一，並規定序號的範圍大小要夠大，才不會造成接收 端所以記錄的歷史序號出現重複的狀況。Timestamp 則是說明該封包是何時傳送
‧
CCID3 的壅塞控制機制中，接收端會回傳 Feedback Packet 給傳送端，
Feedback Packet 中包含 t_recvdata、t_delay、X_recv 以及 P 等欄位。t_recvdata 指的是發出 Feedback Packet 前收到最後一個封包的 Timestamp。t_delay 則是指 發出 Feedback Packet 前收到最後一個封包的到達時間和目前傳送 Feedback 的時 間之間的時間延遲。X_recv 則表示從前一個 Feedback Packet 到目前為止接收端 估計的資料傳送率。P 則代表與封包遺失率相關的 Loss Event Rate。傳送端在 接收到接收端的 Feedback Packet 後會計算封包來回時間。首先會計算該次收到 Feedback Packet 的封包來回時間採樣 R_sample，公式如下：
R_sample = (t_now – t_recvdata) – t_delay (4)
並利用指數加權移動平均(Exponential Weighted Moving Average, EWMA) 的概念，計算平均 Run Trip Time 如公式(5)：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
34
RTT 以及遺失率，觀察其變化。
圖 11 觀察網路壅塞時 RTT 及封包遺失率的變化的實驗網路拓墣
圖 12 網路壅塞時封包來回時間的變化
圖 13 網路壅塞時封包遺失率的變化
如圖 12、圖 13，可以看出隨著通話數的增加，網路發生壅塞狀況，RTT
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
35
以及封包遺失率也隨之增長，而當網路壅塞狀況舒緩，網路恢復正常時 RTT 以 及封包遺失率也隨之減少，可以看出封包傳送到接收端時，RTT 應該在一個固定 的時間範圍之內；當頻寬不足時，RTT 會拉長，偵測到此現象時可視為網路壅塞。
我們假設假設 RTT 的時間為 ，且服從常態分配，則 RTT 可用 表 示，其平均值為 (6)，標準差為 (7)，並且為避免重複計算標準差，我們可以 將(7)推導成(8)。依照常態分配之經驗法則，我們可以估計出：下一個 RTT 時 間 在 範圍之機率為 68.3%。下一個 RTT 時間 在
範圍之機率為 95.4%。下一個 RTT 時間 在 範圍之機率為 99.7%。
(6)
(7)
(8)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
36
圖 14 常態分配之經驗法則
3.5.2
High Delay Response 演算法利用常態分配之經驗法則我們可以推測，如果 RTT 大於 則判斷為 網路壅塞，我們訂定調降 Bit-rate 的門檻值 HDThresh(High Delay Threshold)。
如果連續 HDThresh 個封包之 RTT 大於 ，且所選擇的語音編碼層次高於 Base_rate，則將層次立即降低至 Base_rate，如果所選擇的語音編碼層次已經低 於 Base_rate 且不低於最低層次，則只需降低一個層次，演算法如圖 15、圖 16 所示。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
37
double[] RTTHistroy = new double[HistorySize];
If no feedback has been received before R = R_sample;
Else
R = q*R + (1-q)*R_sample;
add R to RTTHistroy;
End If
If R > average(RTTHistroy)+3*stdev(RTTHistroy) and HDCount > HDThresh If codec_level > Base_rate
Set the codec_level as Base_rate;
Else If codec_level > the_lowest_level codec_level - -;
End If
HDCount = 0;
Else If R > average(RTTHistroy)+3*stdev(RTTHistroy) HDCount + +;
Else
HDCount = 0;
End If
圖 15 High Delay Response 演算法( pseudo code )
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
38
圖 16 High Delay Response 演算法流程圖
‧
3.5.3
High Loss Response 演算法TFRC 利用 RTT 與封包遺失率可以立即得知網路狀況，再利用 RTT 以及封包
由以上論述，我們設定 HLThresh(High Loss Threshold)，HLThr esh 必須依照 應用程式類型所能忍受的封包遺失率訂定。當封包遺失率小於 HLThresh 時表示 尚能忍受少量封包遺失的壅塞程度，並不做壅塞控制反應，讓網路持續保持小壅 塞訊息，讓 TCP 可以感受到網路壅塞的狀況並降緩其傳送封包的數量。當封包 遺失率大於 HLThresh 時表示，壅塞程度已經讓封包遺失量到達已經不能忍受的 程度了，將採取壅塞控制反應，演算法如圖 17、圖 18 所示。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
40
圖 18 High Loss Response 演算法流程圖 Receive feedback Packet and get the p(loss event rate) If p >HLThresh
If codec_level > Base_rate
Set the codec_level as Base_rate;
Else If codec_level > last_level codec_level - -;
End If End If
圖 17 High Loss Response 演算法( pseudo code )
‧
3.5.4
Low Delay Response 演算法利用常態分配之經驗法則我們可以推測，如果 RTT 小於 則判斷為 網路壅塞狀況舒緩，我們訂定調升 Bit-rate 的門檻值 LDThresh (Low Delay Threshold)，如果連續 LDThresh 個封包之 RTT 小於 LDThresh，則將 Bit-rate 提 升一個層次，演算法如圖 19、圖 20 所示。
double[] RTTHistroy = new double[HistorySize];
If no feedback has been received before R = R_sample;
Else
R = q*R + (1-q)*R_sample;
add R to RTTHistroy;
End If
If R < average(RTTHistroy)-3*stdev(RTTHistroy) and LDCount > LDThresh If codec_level < the_highest_level
codec_level + +;
End If
LDCount = 0;
Else If R > average(RTTHistroy)-3*stdev(RTTHistroy) LDCount + +;
Else
LDCount = 0;
End If
圖 19 Low Delay Response 演算法 ( pseudo code )
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
42
圖 20 Low Delay Response 演算法流程圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
43
第四章 實驗與效能評估
本研究在實際網路上進行實驗以評估本系統的效能。實驗一中，假設網路中 僅使用同一種傳輸協定，以 MOS 與 E-Model 作為評量標準，評估(CBR over UDP) 以及 Flexible Bit-rate 以及 Scalabe Codec 三種方式在不同的網路壅塞程度之下 的通話品質。實驗二中假設同時存在使用 TCP 傳輸協定的應用程式，評估 Scalable Codec 搭配 DCCP 對於頻寬的競爭能力，亦即公平性。
4.1 評估指標
MOS(Mean Opinion Score)是直接利用人耳對於語音的感覺，並給予 1 到 5 分的分數。但有限的人力難以進行大量的評估工作，故大部分採用 E-model，以 網路的工程參數，如 Packet Delay、Packet Loss、Jitter 和經編碼器(Codec)壓縮 後的失真程度來計算效能，並換算成 MOS。
4.2 實驗環境
在實驗一和實驗二中，我們利用兩部 PC 做為發話端和收話端，作業系統為 Windows 7，實驗程式安裝在 Java eclipse-SDK-3.7.2-win32 上。接收端安裝在 政治大學行動計算與網路通訊實驗室並連上台灣學術網路。發送端同樣安裝在政 治大學行動計算與網路通訊實驗室，但透過連結 D-Link DIR-600 Wireless 150 Router 作為網路瓶頸點，在控制功能選項中有 QoS 引擎功能可限制連線通過的頻
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
44
寬流量，之後再連結台灣學術網路，硬體設備如表 12 所示。
表 12 實驗設備硬體規格
PC1 Processor: Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz 1.87GHz Installed memory(RAM): 2.00 GB
System type: Windows 7, 32-bit Operating System
PC2 Processor: AMD Athlon(tm) 64X2 Dual Core Processor 6000+ 3.10GHz Installed memory(RAM): 2.00 GB
System type: Windows 7, 32-bit Operating System Router D-Link DIR-600 Wireless 150 Router
4.3 實驗一
圖 21 實驗一網路拓樸
實驗總共傳送數量為100通VoIP語音通話，因無法透過耳朵實際收聽所有電 話，因此我們僅以人耳收聽10通電話作為MOS評分參考，其餘則利用在實驗過 程中記錄下封包遺失率及bit-rate的變化透過圖表呈現。
4.3.1 CBR over UDP VoIP 實驗結果與分析
圖 22中記錄著以CBR配合UDP作為VoIP的傳輸協議時的封包遺失率與語 音通話品質MOS的變化，圖 23為傳輸bit-rate與MOS的變化。實驗中每隔10秒增 加10通VoIP語音通話進入網路，直到網路中有著100通VoIP同時進行傳輸為止，
之後每隔10秒鐘減少10通電話，直到結束所有通話。實驗時間共190秒。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
45
實驗時間40~50秒時，網路中共存在著50通網路電話，此時封包遺失率近乎 為零，代表網路尚能負載這些資料量。但隨著網路電話通話數增加至60通，封包 遺失率逐漸增加，透過封包遺失率的變化我們可以發現，由於UDP沒有依照網路 狀況做調整，網路壅塞的情形越來越嚴重，已無法維持整體網路的穩定，語音通 話品質也由原來的MOS 4.35分，下降至普通的MOS 2.93分。
當網路電話通話數到達80通時，網路壅塞加劇，封包遺失率超過30%，整體 通話品質更降到糟糕的MOS 1.5分；當實驗時間90~100時，同時通話數到達100 通時，整體封包遺失率已超過40%，此時的MOS降到幾乎完全無法聽清楚對話內 容的1.5之下。
實驗時間100秒後，每隔10秒結束10通VoIP語音通話，直到所有語音通話結 束後終止實驗。在這個過程中可以看到因為網路狀況逐漸舒緩，封包遺失率逐步 下降，此時仍在通話中的網路電話，其語音通話仍持續有斷話，但是有慢慢減少，
直到網路頻寬足夠時才能恢復到原本的品質。
實驗數據詳細記載於表 13、表 14與表 15，表中白色網底是封包遺失率介 於0%到10%之間，在VoIP中可能還聽不太出來差異，淺色網底的是封包遺失率介 於10%到20%之間，這是VoIP勉強還能容忍的範圍，深色網底的是封包遺失率大 於20%，已經嚴重影響到通話品質。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
46
圖 22 Packet Loss Rate 與 MOS 之變化-CBR over UDP
圖 23 Bit-rate 與 MOS 之變化- CBR over UDP
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 1 0.00 0.00 0.00 0.00 0.00 0.03 0.21 0.31 0.22 0.22 0.30 0.23 0.27 0.17 0.02 0.00 0.00 0.00 0.00 0.10
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 36 0.00 0.00 0.14 0.21 0.32 0.48 0.43 0.43 0.28 0.18 0.04 0.00 0.00 0.19
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss
71 0.27 0.31 0.39 0.27 0.29 0.31
‧
4.3.2 Flexible Bit-rate VoIP 實驗結果與分析
圖 24中記錄著以Flexible Bit-rate傳送VoIP時的，封包遺失率與通話品質
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
51
圖 24 Packet Loss Rate 與 MOS 之變化-Flexible Bit-rate
圖 25 Bit-rate 與 MOS 之變化-Flexible Bit-rate
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 1 0.00 0.00 0.00 0.00 0.00 0.01 0.08 0.04 0.09 0.10 0.09 0.08 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.03
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 36 0.00 0.00 0.00 0.05 0.07 0.10 0.12 0.08 0.02 0.00 0.00 0.00 0.00 0.03
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss
71 0.07 0.11 0.05 0.03 0.06 0.06
‧
4.3.3 Scalable Codec VoIP 實驗結果與分析
圖 26中記錄著以Scalable Codec 傳送 VoIP時的，封包遺失率與通話品質 MOS的變化，圖 27為傳輸bit-rate與MOS的變化。實驗中每隔10秒增加10通VoIP
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
56
圖 26 Packet Loss Rate 與 MOS 之變化-Scalable Codec
圖 27 Bit-rate 與 MOS 之變化- Scalable Codec
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss 36 0.00 0.00 0.03 0.08 0.00 0.08 0.10 0.00 0.00 0.00 0.00 0.00 0.00 0.02
‧
Calls 0~10 10~20 20~30 30~40 40~50 50~60 60~70 70~80 80~90 90~100 100~110 110~120 120~130 130~140 140~150 150~160 160~170 170~180 180~190 Loss
71 0.00 0.01 0.00 0.00 0.00 0.00
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
60
4.3.4 三種傳輸方式實驗結果與分析
圖 28、圖 29顯示了CBR over UDP、Flexible Bit-Rate以及Scalable Codec 三種方式傳輸VoIP的效能比較，分別為封包遺失率、通話品質(MOS)，以及頻 寬效率。
結果顯示，如果是頻寬充裕的情況下，一般的CBR配合UDP的方式來傳輸封 包的VoIP，的確能有最佳的通話品質，不過當頻寬不足時可以看得出來，封包 遺失率大幅的增加，在實驗中的網路環境中能支持50通以CBR配合UDP傳輸的網 路電話進行最佳品質的語音通話，可是當通話數量到達100通時，比起10通VoIP 時，話品質指標MOS下降了60%左右，封包遺失率增加了40%以上。
使用Flexible Bit-rate以及Scalable Codec來傳輸VoIP通話時，可以看出相較 於CBR配合UDP，他們都可以擁有比較好的MOS以及較低的封包遺失率。不過 在比較壅塞況狀時，Scalable Codec因為利用DCCP偵測網路狀況的RTT以及封包 遺失率來做網路偵測，而且有較細緻的語音層次，所以可以馬上得知網路的狀 況，並且做最適當的反應，因此封包遺失率都來的比Flexible Bit-rate低，而且對 於控制整體網路狀況的穩定性也比Flexible Bit-rate來的好。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
61
圖 28 三種方式傳輸 VoIP 的封包遺失率比較
圖 29 三種方式傳輸 VoIP 的 MOS 比較
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
62
4.4 實驗二
圖 30 實驗二實驗拓墣
在圖 30的網路情境下，本研究透過實際網路的實驗環境評估，分別以CBR over UDP以及Scalable Codec VoIP在頻寬不足時和TCP同時存在於網路中，比較 對於頻寬的競爭能力的表現。以及比較在頻寬不足時，多個Scalable Codec VoIP(沒有其他TCP)的狀況下，Scalable Codec VoIP之間的頻寬競爭公平性。
4.4.1 CBR over UDP VoIP vs TCＰ實驗結果與分析
我們實驗觀察CBR over UDP VoIP先進入網路，之後TCP再進入網路中頻 寬競爭的狀況。圖 31、表 22中記錄著CBR over UDP VoIP先進入網路以CBR over UDP VoIP在頻寬不足時和TCP同時存在於網路中所佔的網路Throughput百 分比變化。在頻寬瓶頸為256Kbps的網路環境下，在實驗開始時傳送5通CBR over
我們實驗觀察CBR over UDP VoIP先進入網路，之後TCP再進入網路中頻 寬競爭的狀況。圖 31、表 22中記錄著CBR over UDP VoIP先進入網路以CBR over UDP VoIP在頻寬不足時和TCP同時存在於網路中所佔的網路Throughput百 分比變化。在頻寬瓶頸為256Kbps的網路環境下，在實驗開始時傳送5通CBR over