一個以計算阻塞機率為基礎的允入控制方法

全文

(1)一個以計算阻塞機率為基礎的允入控制方法研究生：吳佳駿. 指導教授：陳俊麟. 博士. 國立屏東商業技術學院資訊管理系(所). 摘要本文提出一個以阻塞機率計算為基礎的允入控制方法。阻塞機率（blocking probability）是利用網城內每條 source-destination 路徑內所有通過的路由器之間連結成功與否而量測計算出來。Ingress 路由器則藉由計算所有 source-destination 路徑的阻塞機率來進行選擇一條最佳的路徑給新的語音連線請求。最後，實驗模擬結果顯示本文提出的方法由 utilization, end-to-end delay, loss-rate 的觀點來看可以有效達到可擴充性、網路利用率高及復原性佳的目的。. 關鍵字： QoS, VoIP, call admission control, blocking probability. I.

(2) A new VoIP call admission control based on blocking probability calculation Student：Chia-Chun Wu. Advisor：Dr. Chin-Ling Chen. Dept. of Information Management, National Pingtung Institute of Commerce. ABSTRACT. We present a new VoIP admission control scheme calculation based on blocking probability calculation. Blocking probabilities were measured carrying VoIP for every router across the source-destination path. Ingress router selects the optimal path for the new request by calculating blocking probabilities across all source-destination paths. Experiment has shown that the proposed approach guarantees the target of high scalability, high network utilization, high recovery in terms of end-toend delay, utilization and loss rate.. Keywords：QoS, VoIP, call admission control, blocking probability. II.

(3) 誌. 謝. 進入研究所就讀給我的第一個印象就是天然茂密的樹林，每當上課經過時，就好像走到了都市的森林公園一般讓人心曠神怡。感謝學校提供如此優雅的就學環境，讓莘莘學子如沐春風。本論文能順利完成首先要感謝指導教授陳俊麟博士，在教授細心的指導下，讓我瞭解了研究的方向及方法使得本論文能夠更加的充實及正確。陳教授不傴在學術專業上有所成就，他獨有的待人處事態度讓人倍感佩服，實在是一位讓人由衷敬重的良師益友。其次要感謝吳雪馥主任、蕭文鋒教授、戴逸民教授及楊書成教授在各領域知識上的授業與解惑以及特別感謝吳雪馥主任在學務上的協助。此外，還要感謝論文口詴委員陳偉業教授、魏大雅教授及陳俊麟教授在口詴時給予指導，使本論文可以更趨完整。同時也要感謝這兩年多來，陪我度過風風雨雨的同學及學長弟們，我的好友-馮文賢、林晉民、胡凱文、陳冠霖…等，多謝你們的如此般的友情陪伴，讓我的研究所生涯充實了許多。最後，親愛的家人及女友永遠是我最大的支柱，有了他們的支持讓我無後顧之憂全力衝刺在學業上，進而讓我能順利地完成學業，如今我將這個成果獻給他們，感謝他們對我的關愛與照顧，他們永遠是我最大的驕傲與幸福。願與你們共享我的喜悅與榮譽。吳佳駿（Chia-Chun Wu）謹誌於屏東商業技術學院資訊管理所中華民國 98 年 1 月. III.

(4) 目錄 1 . 前言 ...................................................................................................... 10 1 . 1 研究背景 ..................................................................................... 10 1 . 2 研究動機 ..................................................................................... 10 1 . 3 研究目的 ..................................................................................... 11 1 . 4 論文架構 ..................................................................................... 12 2 . 文獻探討 ............................................................................................... 13 2 . 1 整合式服務網路（InstServ）vs. 差異式服務網路（DiffServ） . 13 2 . 2 基本的允入控制（Basic admission control） ............................... 16 2 . 2 . 1 參數式允入控制 ............................................................... 17 2 . 2 . 2 量測式允入控制 ............................................................... 17 2 . 3 端點式允入控制（End-point admission control） ......................... 18 2 . 3 . 1 集中式允入控制（Centralized admission control） ............ 18 2 . 3 . 1 . 1 頻寬仲介者（Bandwidth Broker） ................... 18 2 . 3 . 2 分散式允入控制（Distributed admission control）............. 19 2 . 3 . 2 . 1 探測式允入控制............................................. 19 2 . 3 . 2 . 2 改良式頻寬仲介者法 ..................................... 21 2 . 3 . 2 . 3 分散式訊標式允入控制法 ............................. 22 3 . 一個以計算阻塞機率為基礎的允入控制法 ........................................ 25 IV.

(5) 3 . 1 基本架構 ..................................................................................... 25 3 . 2 計算阻塞機率 ............................................................................. 25 3 . 3 阻塞機率演算法（Blocking probability calculation, BPC） .......... 27 3 . 3 阻塞機率立即回饋演算法（Blocking probability calculation with instant feedback, BPC-IF） ...... 28. 4 . 模擬分析 ............................................................................................... 30 4 . 1 實驗網路架構 ............................................................................. 30 4 . 2 網路模擬器（Network Simulator, version-2） ........................... 32 4 . 3 模擬結果 ..................................................................................... 33 4 . 3 . 1 實驗一：使用不同流量密度（traffic density）量測 ...... 34 4 . 3 . 2 實驗二：使用不同節點數（number of nodes）量測...... 43 4 . 3 . 3 實驗三：使用不同阻塞節點數（number of blocking nodes）量測 .................... 50 5 . 結論與未來研究方向 ........................................................................... 55 參考文獻........................................................................................................................... 56 附錄 ....................................................................................................................................59. V.

(6) 圖目錄. 圖 2.1. 整合式服務網路（Integrated Service, IntServ） ............................. 14. 圖 2.2. 差異式服務網路（Differentiated Service, DiffServ）.................... 15. 圖 2.3. 差異性服務欄位（Differentiated Service field, DS field） .......... 16. 圖 2.4. 頻寬仲介者網路架構 ............................................................................... 19. 圖 2.5. 探測式網路架構......................................................................................... 20. 圖 2.6. 探測式封包處理程序 ............................................................................... 21. 圖 2.7. 改良式頻寬仲介法 .................................................................................... 22. 圖 2.8. 訊標式允入控制執行過程 ......................................................................24. 圖 3.1. 允入控制網路架構 .................................................................................... 25. 圖 3.2. 計算阻塞機率演算法 ............................................................................... 27. 圖 3.3. 阻塞機率立即回饋演算法 ......................................................................29. 圖 4.1. 網路模擬架構 ............................................................................................. 30. 圖 4.2. VoIP packet size........................................................................................... 31. 圖 4.3. 阻塞機率在不同流量密度的變化（G.711） .....................................34. 圖 4.4. 阻塞機率在不同流量密度的變化（G.729）.....................................35. 圖 4.5. 阻塞機率在不同流量密度的變化（G.723.1） .................................36. 圖 4.6. 平均封包遺失率在不同流量密度的變化（G.711） ....................... 37. VI.

(7) 圖 4.7. 平均封包遺失率在不同流量密度的變化（G.729） ..................... 37. 圖 4.8. 平均封包遺失率在不同流量密度的變化（G.723.1） ................... 38. 圖 4.9. 不同流量密度的 end-to-end delay（G.711） .....................................39. 圖 4.10. 不同流量密度的 end-to-end delay（G.729）.....................................40. 圖 4.11. 不同流量密度的 end-to-end delay（G.723.1）..................................40. 圖 4.12. 網路利用率在不同流量密度的變化（G.711） ................................ 41. 圖 4.13. 網路利用率在不同流量密度的變化（G.729） ................................ 42. 圖 4.14. 網路利用率在不同流量密度的變化（G.723.1） ............................. 42. 圖 4.15. 阻塞機率在不同節點數量的變化（G.711） .....................................43. 圖 4.16. 阻塞機率在不同節點數量的變化（G.729）.....................................44. 圖 4.17. 阻塞機率在不同節點數量的變化（G.723.1） .................................44. 圖 4.18. 各節點數量的平均封包遺失率（G.711） ......................................... 45. 圖 4.19. 各節點數量的平均封包遺失率（G.729） ......................................... 46. 圖 4.20. 各節點數量的平均封包遺失率（G.723.1） ......................................46. 圖 4.21. 各節點數量的 end-to-end delay（G.711）.......................................... 47. 圖 4.22. 各節點數量的 end-to-end delay（G.729） ......................................... 48. 圖 4.23. 各節點數量的 end-to-end delay（G.723.1） ......................................48. 圖 4.24. 各節點數量的網路利用率（G.711） ................................................... 49. 圖 4.25. 各節點數量的網路利用率（G.729）................................................... 49 VII.

(8) 圖 4.26. 各節點數量的網路利用率（G.723.1） ............................................... 50. 圖 4.27. 不同阻塞節點數量的阻塞機率（G.711） ......................................... 51. 圖 4.28. 不同阻塞節點數量的平均封包遺失率（G.711） ........................... 52. 圖 4.29. 不同阻塞節點數量的 end-to-end delay（G.711） ........................... 52. 圖 4.30. 不同阻塞節點數量的網路利用率（G.711） .....................................53. VIII.

(9) 表目錄. 表 2.1. 常見的允入控制方法.................................................................................. 13. 表 4.1. 標準語音編碼格式 ...................................................................................... 31. 表 4.2. 模擬參數設定................................................................................................ 32. 表 4.3 Quality of Service Metrics .......................................................................... 32 表 4.4. 量測 QoS 參數 .............................................................................................. 33. IX.

(10) 1 . 前言. 1.1. 研究背景快速的網路發展，使得越來越多的應用程式需要即時地傳送資料並. 且保有一定的頻寬，如網路語音電話（Voice over IP, VoIP）、視訊會議。所以，現今網路傳送的內容已不再只是單純的文字資料數據，而是包含影像語音的多媒體。同時 VoIP 也是目前網路上最普遍被使用的服務，主要是因為平台建置容易、收費低廉、通訊的安全性以及輕易跨越長途國界這一些優點。然而 IP 網路一開始並不是被設計用來支援這一些即時語音的應用程式，於是 IP 網路便產生出一些直接或間接影響語音品質的因素，如：delay、packet loss、jitter…等。要如何在有限的頻寬下能有一套方法去有效利用與控制分配這些頻寬，進而達到良好的服務品質（Quality of Service, QoS）[1]，是目前急需解決的問題。因此，網際網路工程小組（Internet Engineering Task Force, IETF）為了能提供良好的服務品質，研發且訂定出二種重要的網路架構，從原先傳統只提供盡力傳送服務（best effort service）的網路，演化到提供絕對性保證頻寬服務（guaranteed service）[2]的整合式服務網路（Integrated Service, IntServ） [3] 以及提供相對性保證頻寬服務的差異式服務網路（ Differentiated Service, DiffServ）[4]。整合式服務及差異式服務這二種網路架構皆能提供不錯的服務品質，第 2 章節會在各別簡單介紹這二種網路架構的差別。 1.2. 研究動機硬體設備與技術發展的突破，已經使得傳統以來在網路上頻寬不足. 的問題獲得相當的改善，但是頻寬畢竟是有限的，如何能有一套方法去 10.

(11) 有效控制分配這些頻寬及提升連線傳輸的品質，進而達到良好的服務品質，這是本文主要的研究動機。允入控制（admission control）主要是用來解決當有一個新的語音連線請求時，是否可以被允入來存取網路資源。網路在進行語音封包傳輸時，可能會因為同時有其它的資料封包在這條連結上面進行傳輸，而造成 blocked、queuing、甚至是 dropped、retransmission 等問題，這樣易造成 delay，同時嚴重影響到語音封包的服務品質。因此，允入控制的工作就是在進行傳輸前，對網路內部已使用的資源及未使用的資源，做一有效的評估及管理，以維持連線傳輸的品質。 1.3. 研究目的評估一個允入控制機制方法的好壞，取決於網域內部頻寬是否有效. 率地利用，以及是否能提供良好的服務品質給終端使用者。而一個良好的允入控制機制為了必頇能適應真實的網路狀況，有幾種基本的需求必需達到：（1）可擴性佳（scalability）：一旦網路規模越來越大，該機制必頇能適用於更大型的網路。（2）網路利用率高（high network utilization）：能充份的利用網域內的頻寬，使每條連結（link）的利用率最好能達到極限。（3）復原性佳（high recovery）：當發生故障或是錯誤時，必頇仍做到允入控制，系統盡可能快速並且容易地回復原本正常的狀態。本文目的希望能利用機率的特性設計一個以計算阻塞機率為基礎的允入控制方法來對語音傳輸進行允入控制。為了能適應現實的網路狀況，我們的方法除了盡可能滿足前述幾點，同時也希望能滿足在網路負載較 11.

(12) 高時能有效進行允入控制及提升語音傳輸的效能。此系統建構在差異性服務網路，利用差異性服務網路 core-stateless 的特性以獲得可擴性。在復原性的部份，因為我們提出的方法是分散在 ingress router，不像集中式的允入控制法會有單一錯誤點的缺點，所以復原性會較佳。而在最後二點我們使用網路模擬器（networks simulator version-2, NS2）來實驗模擬驗證我們提出的方法是否有效。 1.4. 論文架構本論文架構共分為五大章：首章介紹本論文的研究背景、研究動機. 及研究目的，使讀者能夠瞭解本論文所適用的背景以及瞭解開始此研究的原因、研究過程及最終目的；第二章介紹一些相關文獻探討，介紹相關方法並加於評論比較，因而導出此研究方法的基礎並產出此論文；第三章介紹我們提出的一個以機率預測為基礎的允入控制方法，也就是本論文主體，逐一詳述本論文所提出一個以計算阻塞機率為基礎的允入控制方法，從整個架構到細部方法的描述至演算法；第四章呈現出整個模擬結果，再根據模擬結果來驗證我們提出的方法，其中模擬過程使用不同參數及其它方案來互相做比較；第五章是結論與未來方向，說明了一個以計算阻塞機率為基礎的允入控制方法和原有的允入控制法的不同點，以及說明為何一個以計算阻塞機率為基礎的允入控制方法會比原有的允入控制法效能更好，並討論其缺點為何進而提出未來研究的方向。. 12.

(13) 2 . 文獻探討以往允入控制的議題大多是針對網路流量的現況來決定是否提供及分配適當網路頻寬給每一位終端使用者所提出的請求。本文則是採用不同的思維，不使用網路流量來進行允入控制，而是採用計算各路徑的阻塞機率（blocking probability），然後再根據阻塞機率來選擇傳輸路徑。可擴性佳（scalability）、網路利用率高（high network utilization）、復原性佳（high recovery），這些特性主要是用來判斷允入控制法效能優劣所依據的原則。本章會特別去介紹不同網路架構幾個常見的允入控制方法，匯整如表 2.1 所示：. 表 2.1 常見允入控制方法 IP 網路架構（無 QoS 功能）參數式允入控制. IP 網路架構（有 QoS 功能）差異性服務網路（DiffServ）集中式分散式. 整合式服務網路（InstServ）. 量測式允入控制. 頻寬仲介者. 探測式允入控制改良式頻寬仲介者分散式訊標式允入控制. 2.1. 整合式服務網路（InstServ） vs. 差異式服務網路（DiffServ）在整合式服務網路（圖 2.1），所有的路由器（router），不論是端. 點路由器（edge router）或是內部路由器（core router）皆根據應用程式所提出請求（request）的頻寬做保留的動作並將每條資料流（flow）的 13.

(14) 資訊儲存起來。它提供了嚴格的服務品質及支援絕對性保證頻寬的服務。主要的方法是使用資源保留的方式-資源保留協定（Resource Reservation Protocol, RSVP）來規劃網路資源分配，藉由這個方法可以得到精確的服務品質。整合式服務網路架構之所以能夠嚴格保證每條資料流（flow）的頻寬，主要是因為它需要在網域內所有的路由器（router）上去維護每條資料流的狀態（state）資訊，因此這些路由器相對地所要負載的資訊會大量的增加，也就是必頇為每一個請求服務的應用程式建立一組相對應的服務品質參數，並且持續地去計算及儲存相關參數。由於這樣的原因，使得它無法應用於較大型的網路，意即其可擴性（scalability）不佳。 use RSVP protocol. IntServ domain. request edge router. edge router. destination. application. core router. 圖 2.1 整合式服務網路（Integrated Service, IntServ）. 差異式服務網路（圖 2.2），端點路由器根據所制定的合約來設定，並依據服務品質等級將封包分類，放入相對應的佇列（queue）。內部路由器（core router）則根據 IP header 上面的分類直接傳送封包而不需儲存任何資訊（core-stateless）。它提供了相對的服務品質和支援相對性保證頻寬的服務，端點路由器依照先前使用者與網路服務提供者 14.

(15) （Internet Service Provider, ISP）所制定的合約設定，將所有需要服務品質應用程式的封包請求，依據所制定的分類原則加以分類 – 也就是使用 IP header 中服務類型（type of service, TOS）欄位[5]來代表分類等級（圖 2.3），對於每一類分別給予一組服務品質參數。如此一來便可以改進 IntServ 網路資料量太多的問題；換句話說，也就是不需要再去儲存網域內所有路由器的資訊，只需要在其端點路由器儲存資訊及控制其資源分配。因此網域內路由器有著不需要維護資料流狀態資訊（corestateless）的特性。因此，DiffServ 這種網路架構有著較良好的可擴性並且可支援大型的網路，但也就是因為用使用分類的方法來支援服務品質，會易造成提供不精凖的服務品質，只能提供相對性的服務品質，也就是其缺點為不支援絕對性保證頻寬的服務。. 資料封包傳遞方向. DiffServ domain. 傳送資料封包. edge router. edge router. application. core router. 圖 2.2 差異式服務網路（Differentiated Service, DiffServ）. 15. destination.

(16) 圖 2.3 差異性服務欄位（Differentiated Service field, DS field）. 從以上的描述，我們可以看出二種網路架構的主要差異：整合式服務網路有著較佳的頻寬保證，而差異式服務網路有著較佳的可擴性。但不論是整合式服務網路或是差異式服務網路皆頇有專門一套負責管理及分配網路上頻寬資源的機制，也就是允入控制（admission control）機制。當任何應用程式的請求到達時，則必需藉由允入控制機制來決定需要採取什麼行動、接納或拒絕此請求以及是否提供頻寬給使用者。因此，我們則可以經由這兩種網路架構搭配上一套良好的允入控制機制，來達到可擴性佳和支援絕對性保證頻寬服務的這兩項優點。 2.2. 基本的允入控制（Basic admission control）如今 Internet Protocol（IP）已經成為網際網路最主要的通訊協定，. 過去網路所需要傳遞即時性或請求服務品質（Quality of Service, QoS）高的流量及機會並不多，因此 IP 網路只需要提供盡力而為傳送的服務（best effort service），這樣一來封包在 IP 網路中可能會被延遲、重覆、以及遺失。其允入控制（admission control）機制主要只是為了避免網路頻寬太過壅塞，並未對於服務品質有著特別的注意，因此只會依照當時傳送資料流之後所呈現出來的情形，來對於所有欲傳送的請求做進一步的決定，只有當反應出網路狀況過於壅塞時才會拒絕請求的進入，而如果過於壅塞時所引起個別請求頻寬不足的現象則無法解決，這也代表了無法提供保證頻寬的服務，因此，基本允入控制針對服務品質來做網路 16.

(17) 內頻寬的控制與分配效果是有限的。在 IP 網路下基本允入控制主要有兩種方法：（1）參數式允入控制（Parameter-based admission control, PBAC ）以及（ 2 ）量測式允入控制（ Measurement-based admission control, MBAC）[6-9]。 2 . 2 . 1 參數式允入控制（Parameter-based admission control, PBAC）此法依據一些特定資料流統計模型導出的相關參數，來取得關於這些資料流的特性並且依此特性計算出往後所有欲傳送資料流的請求之門檻值，並利用此值來做允入控制。這裡會產生一個問題，如果這些特定資料流主要都是不需要服務品質的應用程式，則結果可能會讓需要服務品質高的應用程式無法達到它們所需要的服務品質，也就表示無法保證頻寬；相反地，如果這些特定資料流主要都是需要服務品質高的應用程式，則可能會造成利用率不佳。也就和本文一開始所提出基本需求的第二項，要達成網路利用率高的原則相違背。 2 . 2 . 2 量測式允入控制（Measurement-based admission control,MBAC）量測式允入控制機制，主要可分為兩個階段：（1）測量目前網路狀態的方法：經過一段時間依據網路上各種情形計算並推論目前網路狀態，如 time windows 、 exponential average …等。（2）依據設定的原則來做允入控制：當獲得網路上目前情況的資訊後，按照之前所設定好的存取原則，來拒絕或接受往後的請求。總而言之，量測式允入控制法是將階段（1）的結果套用階段（2）所訂定的原則，並採取相對應的行動。量測式允入控制法亦無法保證絕對的頻寬，而且有可能因為一時的網路狀況而做出錯誤的決策，使得網 17.

(18) 路利用率效果不佳。 2.3. 端點式允入控制（End-point admission control）為了提高服務品質網路發展出二種不同的架構：整合式服務網路和. 差異性服務網路。由於此網路架構的特性，只需在網域內的端點路由器進行允入控制，因此稱之為端點式允入控制（ end-point admission control），端點式允入控制又可分為二大類：（1）集中式允入控制及（ centralized admission control ）（ 2 ）分散式允入控制（ distributed admission control）。 2 . 3 . 1 集中式允入控制（Centralized admission control）集中式允入控制[10]將允入控制機制的所有權和決定權集中在單一節點下，在這裡以頻寬仲介者（Bandwidth Broker, BB）方法來說明，它是在差異式服務網路下最初使用的允入控制機制。 2 . 3 . 1 . 1 頻寬仲介者（Bandwidth Broker）此法主要是在網路內部建立一個頻寬仲介者，而頻寬仲介者主要負責在管理分配這個網域內的所有頻寬。為了達到請求的服務品質，因此會在各方面，如 peak rate、delay、…等上有所限定。頻寬仲介者的網路架構（圖 2.4），當 domain A 內的 ingress 請求抵達目的端時，會去詢問 domain A 內的 BB 是否可接受頻寬請求，而 domain A 的 BB 和 domain B 的 BB 則會互相溝通傳遞訊息，以了解往目的端途中的網域是否也可以提供所請求的頻寬，而各 domain 的 BB 內儲存自己網域內部所有連結頻寬的資訊。 18.

(19) domain A. domain B core. core. egress. ingress. ingress. egress. application. destination BB. BB. 圖 2.4 頻寬仲介者網路架構. 頻寬仲介者有一個主要的缺點，當有許多的請求來到端點路由器，而詢問頻寬仲介者的訊息可能多到令頻寬仲介者周圍的連結一時負荷不了而造成擁塞；又或頻寬仲介者出現錯誤，造成整個網域內頻寬的利用停滯。因此，這表示頻寬仲介者的可擴充性低。 2 . 3 . 2 分散式允入控制（Distributed admission control）分散式允入控制的決定權不像集中式允入控制集中在單一節點上，而是分散在網域內每一個端點路由器（edge router）上，由每一個端點路由器自己依據允入控制法，來判斷是否接受其請求，因此它的可擴性較佳。目前常見的分散式允入控制方法有三種：探測式允入控制法（probe-based admission control）[11]、改良式頻寬仲介者法（improved bandwidth broker）[12-13]及訊標式允入控制法（distributed admission control based on token passing）[14]。 2 . 3 . 2 . 1 探測式允入控制法（Probe-based admission control）探測式允入控制法是屬於量測式允入控制法的範疇，利用探測封包的方式量測網路現況。探測式允入控制法的網路架構（圖 2.5）。當入口端點路由器（ingress router）收到欲進入網域使用頻寬的請求後，首 19.

(20) 先會送出少量探測封包（probe packet）到目的端，在傳送至目的端過程中，經過同網域的出口端點路由器（egress router）時，此出口端點路由器收到探測封包時會回覆訊息封包，再由入口端點路由器從回覆的訊息封包中解析出現有網路狀況的資訊，進而判斷網路狀況來決定是否接受或拒絕請求。早期的探測式允入控制法主要是利用回覆的訊息封包來得知探測封包的遺失率，若遺失率（loss-rate）大於預先設定的門檻值（threshold）時，發出 nack 則此請求就不被允許，如圖 2.6（a）。而之後改良式的探測式允入控制法為了能滿足支援保證頻寬服務，改為利用回覆的訊息封包中來得知探測封包的速率，同時將下一輪探測封包的速率向上調整到請求的速率，同時也經由回覆的訊息封包之中其他資訊來得知現在網路是否壅塞、是否可以進行傳送下一輪的探測封包，當超過所設定的門檻值表示網路壅塞，則停止發送探測封包，在此之前如果尚未調整到請求的速率則會拒絕請求；反之，如果探測封包已調整到請求的速率，則允許請求進入並且可以提供其請求的速率，達到頻寬保證的服務。如圖 2.6（b）所示。 DiffServ domain. 探測封包訊息封包. request application. edge router. edge router. core router. 圖 2.5 探測式網路架構 20. destination.

(21) new session. new session probe. measurement probe length loss-rate > threshold. nack. measurement probe length loss-rate < threshold. timeout. timeout. probe. measurement probe length loss-rate < threshold. probe ack ack. data. new session. probe. timeout. timeout. ack. probe. measurement probe length loss-rate < threshold. probe ack ack. data data (b). (a). 圖 2.6 探測式封包處理程序. 在分散式方法中，探測式允入控制法是個不錯的選擇，但是為了探測，使用一些不必要的探測封包會降低了網路頻寬使用率以及網路的狀態是無時無刻在改變的，這樣不但違反了允入控制的基本需求，且若遇到大量（burst）的網路狀況，探測的結果將會有所誤差無法採信，進而影響到網路的服務品質和使用率。 2 . 3 . 2 . 2 改良式頻寬仲介者法改良式頻寬仲介者法，不再將允入控制機制所有決定權交給頻寬仲介者（BB），而是將允入控制機制決定權分散式地分給各個 edge router。改良式頻寬仲介者內的頻寬仲介者（BB）根據網域內各個 edge router 所回覆的資訊，分析網域內頻寬存取目前的狀態，同時修正重新計算之後各個 edge router 能存取網域內每個頻寬的門檻值（threshold），而各 edge router 根據這個門檻值來進行往後的請求做允入控制。如圖 2.7，頻寬仲介者（BB），根據 edge router 回傳的資訊，每間隔一段時間修 21.

(22) 正 edge router 可以接受存取的頻寬總值，當應用程式的請求抵達各 edge router 時，edge router 便根據此值來決定是否接受或拒絕請求。. core router. edge router. application. edge router. BB. application. 表示計算及更新各 edge router 頻寬存取值的動作. 圖 2.7 改良式頻寬仲介法. 2 . 3 . 2 . 3 分散式訊標式允入控制法傳統的訊標式允入控制法因為採用集中式允入控制，擴充性不佳變成主要的缺點。為了解決此問題，有學者改良了訊標的功能，產生出訊標分散式允入控制（distributed admission control based on token passing）的方法[14]。在介紹分散式訊標式允入控制法之前，必需先了解如何利用訊標（token）來做允入控制的基本概念。允入控制主要是採用訊標傳遞方式（token pass protocol）為基礎（圖 2.8）。圖 2.8（a）假設訊標傳遞的順序是依照 edge router 所標示的編號 1、 2、3 的方向來傳遞，且三角形代表訊標目前位置，訊標內存資訊為網域內各連結的頻寬值，只有持有訊標者才擁有權力可以在網域內各頻寬之間進行存取；圖 2.8（b）當訊標傳遞到 edge router 1 時，此時有一個 request 抵達 edge router 1 並請求傳送至目的地 edge router 3，而所請求 22.

(23) 的頻寬為 4，此時持有訊標 edge router 1 將會查看訊標內的資訊，從資訊中可以看到要通往 edge router 3 會使用到的 Link 為 1 -> C 及 C -> 3，此時頻寬尚有 10 units，故可直接接受請求 edge router 1；圖 2.8（c），同上述（b），當訊標傳遞到 edge router 2 時，此時有一個 request 抵達 edge router 2 並請求傳送至目的地 edger router 3，而所請求的頻寬為 3，此時持有訊標 edge router 2 將會查看訊標內的資訊，從資訊中可以看到要通往 edge router 3 會使用到的 link 為 1 -> C 及 C -> 3，此時頻寬剩下 6 units 尚可滿足，因此直接接受請求 edge router 2。從圖例可得知，只有持有訊標的 edge router 才可以直接對請求來進行決定。同時不難發現使用分散式訊標式允入控制法如同改良式頻寬仲介者法，不同的是這裡使用訊標計算及更新各 edge router 存取頻寬的上限值，這樣一來便可以解決可擴性的問題並且達到頻寬保證的功能。由於頻寬仲介者法主要是配置在差異性網路中的一台獨立伺服器，透過 Simple Network Management Protocol（SNMP）協定對 edge router 與 core router 進行溝通，並且適時在 edge router 上的設定進行調整動作，也就正這樣的原因，造成改良式頻寬仲介者法在硬體上不易修復及修復緩慢的缺點。不論是改良式頻寬仲介者法或傳統式頻寬仲介者法，它們部分的決定權還是得依賴 BB，這樣的先天條件是主要造成硬體上不易修復的主要原因。. 23.

(24) R1 request for 4 units 1. 1 3. C 2. Link. Capacity. 2. Link. 1 -> C. 10 units. 1 -> C. 6 units. 2 -> C. 10 units. 2 -> C. 10 units. 3 -> C. 10 units. 3 -> C. 10 units. C -> 1. 10 units. C -> 1. 10 units. C -> 2. 10 units. C -> 2. 10 units. C -> 3. 10 units. C -> 3. 6 units. R1 request for 4 units. Capacity. R1 end. 1. 1 3. C 2. 3. C. 3. C 2. R2 request for 3 units. R2 request for 3 units. Link. Capacity. Link. Capacity. 1 -> C. 6 units. 1 -> C. 6 units. 2 -> C. 7 units. 2 -> C. 7 units. 3 -> C. 10 units. 3 -> C. 10 units. C -> 1. 10 units. C -> 1. 10 units. C -> 2. 10 units. C -> 2. 10 units. C -> 3. 3 units. C -> 3. 3 units. 圖 2.8 訊標式允入控制執行過程. 24.

(25) 3 . 以計算阻塞機率為基礎的允入控制方法. 基本架構. 3.1. 以計算阻塞機率為基礎的允入控制方法是根據歷史流量通過連結成功的機率，進而去計算該路徑的阻塞機率。基本架構如圖 3.1 所示，我們假設從 ingress 到 egress 有 m 條路徑可以達到。又假設在第 i 條路徑上有 𝑥𝑖 個連結（link），其中 𝑖 = 1,2,3, … , 𝑚 。且每一個連結代表的是路由器與路由器之間的連結。也就是第 1 條路徑上有 𝑥1 個連結，第 2 條路徑上有 𝑥2 個連結，依此類推。 DiffServ domain. m path. link egress. ingress. destination. source. xm links 圖 3.1 允入控制網路架構. 3.2. 計算阻塞機率本文假設 𝑃𝑠 𝑥𝑖 為在第 i 條路徑上所有經過連結 𝑥𝑖 成功傳輸的機. 率，公式如下：. 25.

(26) 𝒙𝒊. 𝒙𝒊. 𝑳𝑺𝑷 𝒊𝒓 =. 𝑷𝒔 𝒙𝒊 = 𝒓=𝟏. 𝟏 − 𝑳𝑭𝑷 𝒊𝒓. （𝟏）. 𝒓=𝟏. 其中 𝐿𝑆𝑃𝑟𝑖 代表的是為第 𝑖 條路徑上的第 𝑟 個連結成功傳輸的機率； 𝐿𝐹𝑃𝑟𝑖 則表示為第 𝑖 條路經上的第 𝑟 個連結失敗傳輸的機率。因此，我們便可以得知： 𝑳𝑺𝑷 𝒊𝒓 + 𝑳𝑭𝑷 𝒊𝒓 = 𝟏. （𝟐）. 在真實網路中有太多外在因素會對傳輸品質產生影響，故不可能可讓整個傳輸過程暢行無阻。所以，在進行傳輸時，可能會產生阻塞，於是我們必需去計算各路徑的阻塞機率。然後再根據阻塞機率的數值來選擇傳輸路徑。這裡我們假設 𝑃𝑏 𝑥𝑖 為在第 𝑖 條路徑上傳輸時產生的阻塞機率。我們可以藉由下列公式來求得阻塞機率： 𝑷𝒃 𝒙𝒊 = 𝟏 − 𝑷𝒔 𝒙𝒊. （𝟑）. 本文會使用二種不一樣的演算法去計算該路徑的阻塞機率。第一種為計算阻塞機率（blocking probability calculation, BPC）演算法，另一種則是從 BPC 演算法延伸出的另一種計算方式，稱之為阻塞機率立即回饋演算法（blocking probability calculation with instant feedback , BPCIF）。BPC 演算法計算路徑阻塞機率的方式，主要是當語音請求順利連結成功至 egress，再去往回累乘所經過每一個路由器連結成功傳輸的機率，然後在套用公式（3）。BPC-IF 演算法計算路徑阻塞機率的方式，則是每當一個路由器連結成功就立即更新機率值並進行計算，然後一樣再套用公式（3）。不論是使用哪一種演算法，ingress 都可由此得知各 26.

(27) path 的阻塞機率，並選擇一條阻塞機率最小的路徑為傳輸路徑。 3.3. 計算阻塞機率演算法（Blocking probability calculation, BPC）本演算法在計算第 𝑖 條路徑連結成功傳輸的機率方式是當連結傳輸. 成功抵達 egress 之後再去累乘所經過的每一個路由器連結成功傳輸的機率，如圖 3.2 所示。. Algorithm for calculating blocking probability（BPC） 𝑳𝑺𝑷𝒓𝒊 get from history , 𝑳𝑭𝑷𝒓𝒊 get from history initial count = 0 for path i = 1 to m for link r = 1 to 𝒙𝒊 if link connects with success { if r = 𝒙𝒊 { for ( count = r ; count >= 0 ; count -- ) // calculate success probability : 𝒊 𝑷𝒔 𝒙𝒊 = 𝑷𝒔 𝒙𝒊 ∗ 𝑳𝑺𝑷𝒄𝒐𝒖𝒏𝒕 end loop // calculate blocking probability : 𝑷𝒃 𝒙𝒊 = 𝟏 − 𝑷𝒔 𝒙𝒊 return }. } else { // calculate link failure probability : 𝑳𝑭𝑷𝒓𝒊 = 𝟏 − 𝑳𝑺𝑷𝒓𝒊 return } end loop end loop 圖 3.2 計算阻塞機率演算法. 27.

(28) 演算法一開始先取得 𝐿𝑆𝑃𝑟𝑖 及 𝐿𝐹𝑃𝑟𝑖 的歷史資訊，同時先將 count 初始值設為 0，然後去計算每一條路徑的成功及阻塞機率，在進入 link r 迴圈之後開始進行判斷目前連結的路由器是否連結成功且 r 是否等於 𝑥𝑖 ，若皆為真，則將 count 的變數指定為 r，然後進行計算本條路徑連 𝑖 結成功的機率 𝑃𝑠 𝑥𝑖 = 𝐿𝑆𝑃𝑟𝑖 ∙ 𝐿𝑆𝑃 𝑟−1 ∙ … ∙ 𝐿𝑆𝑃 1𝑖 ，在求得到 𝑃𝑠 𝑥𝑖 值之. 後，便可以去計算出此路徑的阻塞機率 𝑃𝑏 𝑥𝑖 = 1 − 𝑃𝑠 𝑥𝑖 ；若連結的路由器尚未抵達 𝑥𝑖 時，則再繼續進行下一個連結。如果在一開始進入 link r 迴圈之後，進行判斷目前連結的路由器是否連結成功時，連結失敗則進行計算此路由器的連結失敗機率 𝐿𝐹𝑃𝑟𝑖 = 1 − 𝐿𝑆𝑃𝑟𝑖 。 3.4. 阻塞機率立即回饋演算法（Blocking probability calculation with instant feedback, BPC-IF）本演算法在計算第 𝑖 條路徑連結成功傳輸的機率方式，是每當一個. 路由器連結成功或失敗就立即更新機率值並進行計算第 𝑖 條路徑連結成功傳輸的機率，如圖 3.3 所示。. 28.

(29) Algorithm for calculating blocking probability instant feedback（BPC-IF） 𝑳𝑺𝑷𝒓𝒊 get from history , 𝑳𝑭𝑷𝒓𝒊 get from history initial count = 1 for path i = 1 to m for link r = 1 to 𝒙𝒊 if link connects with success { for ( count ; count <= r ; count ++ ) // calculate success probability : 𝒊 𝑷𝒔 𝒙𝒊 = 𝑷𝒔 𝒙𝒊 ∗ 𝑳𝑺𝑷𝒄𝒐𝒖𝒏𝒕 end loop // calculate blocking probability : 𝑷𝒃 𝒙𝒊 = 𝟏 − 𝑷𝒔 𝒙𝒊 return. } else { // calculate link failure probability : 𝑳𝑭𝑷𝒓𝒊 = 𝟏 − 𝑳𝑺𝑷𝒓𝒊 return } end loop end loop 圖 3.3 阻塞機率立即回饋演算法. 演算法一開始先取得 𝐿𝑆𝑃𝑟𝑖 及 𝐿𝐹𝑃𝑟𝑖 的歷史資訊，同時先將 count 初始值設為 1，然後去計算每一條路徑的成功及阻塞機率，在進入 link r 迴圈之後開始進行判斷目前連結的路由器是否連結成功，若為真，我們便可將 r 設定為離開計算阻塞機率的迴圈的條件，然後計算本條路徑連結成功的機率，以達到立即更新連結成功的機率值，在求得到 𝑃𝑠 𝑥𝑖 值之後，便可以去計算出此路徑的阻塞機率 𝑃𝑏 𝑥𝑖 = 1 − 𝑃𝑠 𝑥𝑖 。如果在一開始進入 link r 迴圈之後，進行判斷目前連結的路由器是否連結成功時，連結失敗則進行計算此路由器的連結失敗機率 𝐿𝐹𝑃𝑟𝑖 = 1 − 𝐿𝑆𝑃𝑟𝑖 。. 29.

(30) 4 . 模擬分析. 實驗網路架構. 4.1. 本文的網路模擬架構，如圖 4.1。由於在 VoIP 的通訊中，為了獲得較好的服務品質，除了頻寬需求之外，選擇一個適當的語音編碼是不可或缺的。所以，本文中實驗模擬三組較為常用的語音編碼來進行模擬比較，主要實驗模擬的部份可分成為三個方案，分別去比較目前較廣泛被使用的標準語音編碼格式 G.711、G.729 及 G.723.1 在加入本文提出的允入控制機制之後，在效能上的差異。在模擬產生語音封包的部份則使用 ns2VoIP 語音模組以及使用 ns2measure 模組作為資料分析工具來進行模擬。最後，我們也會進行模擬比較計算阻塞機率演算法及阻塞機率立即回饋演算法在效能上的表現。. DiffServ domain. 10 Mbps. 10 Mbps 1 Mbps. 1 Mbps. app. 1. dest. 1. ingress. egress. app. 2. dest. 2. 圖 4.1 網路模擬架構. 30.

(31) 下列表 4.1 為目前一般較為常見的標準語音編碼格式的基本參數 [15]，更詳細資訊請參考附錄 A。. 表 4.1 標準語音編碼格式 Codec Information. Bandwidth Calculations Voice Packet per Bandwidth Payload second Ethernet Size （pps）. Codec & Bit Rate. Codec Sample Size. Codec Sample Interval. G.711 ( 64 Kbps ). 80 Bytes. 10 ms. 160 Bytes. 50. 87.2 Kbps. G.729 (8 Kbps). 10 Bytes. 10 ms. 020 Bytes. 50. 31.2 Kbps. G.723.1 (6.3 Kbps). 24 Bytes. 30 ms. 024 Bytes. 034. 21.9 Kbps. ** Code bit-rate is always maintained ** Bandwidth = total packet size * PPS. 本文為了使分析數據結果較為準確，假設第一次實驗 𝑆 1 ，第二次為 𝑆 2 ，本文重覆了 10 次之後，就有 𝑆 1 , 𝑆 2 , 𝑆 3 , … , 𝑆 10 個數據，再去求出全部數據的平均。因為 VoIP packet size 是由固定大小標頭（fixed size header）40 bytes 及可變動大小資料承載量（variable size payload）二個部份所組成，如圖 4.2。. IP 20 bytes. UDP 8 bytes. RTP 12 bytes. Payload variable size Depending on codec. header 40 bytes 圖 4.2. VoIP packet size. 因此，整個模擬除了語音封包大小可區分為三種不同的語音形態，其餘的模擬參數設定皆相同。在模擬實驗中，我們將 traffic density 定義 31.

(32) 為 erlang，即平均每分鐘 call 的持續時間，模擬參數匯整如表 4.2：表 4.2 模擬參數設定 Run time VoIP flow’s type VoIP flow’s send interval VoIP flow’s average hold duration Background load traffic density. 10 sec G.711, G.729, G.723.1 20 ms 180 sec. 20-30 erlang. 在實驗模擬結束之後，必頇去判斷語音服務的品質。因此，我們可以參考表 4.3 來當作模擬分析的觀察指標：. 表 4.3. 4.2. Quality of Service Metrics [16]. e2e delay. Packet loss rate. Mean Opinion Score. less than 150 ms （good）. less than 3 % （good）. MOS = 5 （imperceptible errors）. between 150 ms and 400 ms（average）. between 3 % and 5 % （average）. MOS = 4 （perceptible）. more than 400 ms （poor）. more than 5 %（poor）. MOS = 3 （slightly annoying）. 網路模擬器（Network Simulator, version-2）網路模擬器（Network Simulator, version-2）[17]是一套開放原始碼. （open source）物件導向的網路模擬器，主要是由 VINT project（UC Berkerly）所研發完成及維謢。ns2 它能模擬真實網路系統的架構及特性，在網路架構的方面，有網路路由器（router）、鏈結（link）及網路節點（end point）…等；網路特性的方面，則有封包延遲（packet delay）或封包丟棄（packet drop）…等模擬。模擬程式語言的部份，可以使用 C++ 或 TCL 來修改模組、網路參數設定及產生腳本（script）來進行網路情境模擬。ns2 主要還可以額外增加網路模組來增強模擬的功能。 32.

(33) 本文主要使用 ns2VoIP[18]模組來模擬產生語音封包，目前最新的版本為 ns2voip-2.31-070906.patch.gz，它包含了許多標準的語音格式編碼及分析工具 ns2measure 模組。本文為了使此 patch 可以順利在 ns2 上面執行，我們必頇修改它的程式碼 voip_decoder.cc 及 voip_encoder.cc 二個檔案，否則在 compile 的時候會出現錯誤訊息，詳細修改內容請參考附錄 B。 4.3. 模擬結果分析本文實驗模擬方案可分為三種量測方式，各實驗量測的 QoS 參數如. 表 4.4 所示：. 表 4.4 量測 QoS 參數 QoS 參數. blocking probability. average packet loss rate. e2e delay. utilization. 實驗一 traffic density 實驗二 number of nodes 實驗三 number of blocking nodes. 實驗模擬可藉由阻塞機率（blocking probability）、平均封包遺失率（average packet loss rate）及 end-to-end delay 來看出使用本文提出的允入控制方法是否能在傳輸過程中提供較好效能，一旦能有效的降低阻塞機率、平均封包遺失率及 end-to-end delay，便可以改善語音在傳輸過程時的效能。同時在可擴充性、網路利用率（utilization）及復原性的部份則分別使用節點數量（number of nodes）、流量密度（traffic density）及阻塞節點數量（number of blocking nodes）來進行觀察。我們會再去特 33.

(34) 別去觀察本文提出的計算阻塞機率演算法（BPC）及阻塞機率立即回饋演算法（BPC-IF）的模擬分析結果。 4 . 3 . 1 實驗一：使用不同流量密度（traffic density）量測圖 4.3 為 G.711 新連線的阻塞機率，圖中我們可以看到在 traffic density 一開始在四者之間並沒有明顯的差異，但是當 traffic density 到了 25 之後，本文提出的方法阻塞機率 BPC 及 BPC-IF 上升幅度變得較為趨緩，而探測式允入控制（PBAC）則在 traffic density 為 27 之後才逐漸趨緩。這可以表示為當 traffic density 愈大時，我們提出的主軸演算法愈能有效的降低新連線被阻塞的機會；換句話說，就是新連線通過連結傳輸成功的機會愈大。接著，我們再去觀察主軸演算法（BPC）及阻塞機率立即回饋演算法（BPC-IF）在阻塞機率的表現，由圖中可以看到 traffic density 在 27 之前，BPC-IF 能比 BPC 更有效的降低阻塞機率；反之，一旦 traffic density 在 27 之後，BPC 反而能比 BPC-IF 更有效的抑制阻塞. blocking probability (%). 機率上升。. 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0. BPC BPC-IF PBAC original. 20 22 23 24 25 26 27 28 29 30 traffic density (erlang) 圖 4.3 阻塞機率在不同流量密度的變化（G.711）. 34.

(35) 圖 4.4 及 4.5 分別表示為 G.729 和 G.723.1 新連線的阻塞機率。由圖上面顯示的數據結果，二個圖的整個走向幾乎與圖 4.3 類似，一旦 traffic density 到達了一定的數值，四者相較之下，BPC 及 BPC-IF 能已較趨緩的速度上升。接著再去觀察 BPC 及 BPC-IF 的差異，不難看出 traffic density 在 27 之前，BPC-IF 仍然能有效的降低阻塞機率；反之，一旦 traffic density 在 27 之後，就如圖 4.3 一樣上升幅度便開始增加，反而在 BPC 的部份上升幅度變得較為趨緩且更有效的降低阻塞機率，會造成這種現象的原因，是由於 BPC-IF 在計算阻塞機率時為了維持立即更新必頇一直反覆進行計算。因此，一旦 traffic density 過高時，它的計算效率將會逐漸下降。我們可以從上述的結果得知在網路負載較重及阻塞機率均偏高的情況下，BPC 依然可以優於 BPC-IF、PBAC 及 original，即使在使用不同標準的語音編碼，本文提出的方法仍可適用。這無疑也. blocking probability (%). 是使用機率方式的允入控制機制的優點之一。. 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0. BPC BPC-IF PBAC original. 20 22 23 24 25 26 27 28 29 30 traffic density (erlang) 圖 4.4 阻塞機率在不同流量密度的變化（G.729）. 35.

(36) blocking probability (%). 3.5 3 2.5 2. BPC BPC-IF PBAC original. 1.5 1 0.5 0 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.5 阻塞機率在不同流量密度的變化（G.723.1）. 從上述三組圖的結果顯示，本文提出的以計算阻塞機率為基礎的允入控制方法能有效得降低阻塞機率。接著再去比較本文提出的方法在成功連結傳輸的平均封包遺失率（average packet loss rate）、e2e delay 及網路利用率（utilization）是否也能有相對的成效。從圖 4.6 我們可以清楚的看到 BPC 及 BPC-IF 在語音編碼 G.711 的模擬分析結果顯示，成功連結傳輸的平均封包遺失率無論 traffic density 數值如何變化，它的平圴封包遺失率與 PBAC 及 original 相必較下，都維持在相對較低的值。另外，我們再觀察 BPC 及 BPC-IF 在平均封包遺失率的表現，圖中可以清楚的看到 BPC-IF 就如同上述的阻塞機率一樣， traffic density 在 27 之前它能有效的抑制平均封包遺失率升高，但是 traffic density 在 27 之後 BPC-IF 上升幅度則逐漸加大；反之，BPC 一開始雖然無法像 BPC-IF 那麼有效，但是 traffic density 在 27 之後 BPC 仍維持原先的上升幅度，因此表現的比 BPC-IF 來得更好。若呼應前面的阻塞機率分析出來的結果，我們可以解釋說，一旦路徑的阻塞機率可以有效降低，便可以改善語音在傳輸過程時的效能，因此便可以抑制語音在傳輸過程中所造成的封包遺失。 36.

(37) average packets loss rate (%). 2.5 2 1.5. BPC BPC-IF PBAC original. 1 0.5 0 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.6 平均封包遺失率在不同流量密度的變化（G.711）. 圖 4.7 及 4.8 分別為語音編碼 G.729 和 G.723.1 的模擬分析結果。由於語音封包的頻寬需求會因各標準語音編碼而有所不同，因此模擬顯示出來的結果除了在平均封包遺失率有些微的不同，三組圖的走向都呈現類似情況，值得一提的是無論採用何種標準語音編碼格式，本文主軸的 BPC 在平均封包遺失率的部份與 BPC-IF、PBAC 及 original 進行比較，能更有效的降低平均封包遺失率。. average packets loss rate (%). 2.5 2 1.5. BPC BPC-IF PBAC original. 1 0.5 0 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.7 平均封包遺失率在不同流量密度的變化（G.729） 37.

(38) average packets loss rate (%). 2.5 2 1.5. BPC BPC-IF PBAC original. 1 0.5 0 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.8 平均封包遺失率在不同流量密度的變化（G.723.1）. 圖 4.9 ~ 4.11 分別是三種不同語音編碼在不同流量密度上，end-toend delay 的變化及表現。由圖 4.9 來進行分析，我們可以看到四種方法在進行比較之後，BPC 及 BPC-IF 在 e2e delay 的表現上比另外二種方法要來得較佳。由 traffic density 來進行觀察，可以看到本文主軸的 BPC 上升幅度與另外三種方法相較之下，明顯比較趨緩。接著再去比較 BPC 與 BPC-IF 在 e2e delay 的表現上有什麼差異，圖中可以看到在 traffic density 為 24 之前 BPC-IF 能有效降低 e2e delay；反之，在 traffic density 為 24 之後 BPC-IF 上升幅度便開始加劇，而本文主軸的 BPC 則仍維持較趨緩上升幅度，因此在 e2e delay 的表現上是要比 BPC-IF 來得佳。. 38.

(39) 250. e2e delay (sec). 200 150 100. BPC BPC-IF PBAC original. 50 0. 20 22 23 24 25 26 27 28 29 30 traffic density (erlang) 圖 4.9 不同流量密度的 end-to-end delay（G.711）. 圖 4.10 及 4.11 分別表示為 G.729 和 G.723.1 在不同流量密度上 endto-end delay 的模擬分析結果。從二個圖中來進行觀察分析，可以看到除了在 end-to-end delay 的數值上有些微不同，從整個圖面走向來看，三組圖的走向都呈現類似情況。而在 BPC 及 BPC-IF 的部份，我們可以看到 G.729 及 G.723.1 與 G.711 不同的地方是在 traffic density 為 25 之後， BPC-IF 的上升幅度才會開始加劇，而一樣的結果是 BPC 還是能維持較趨緩的上升幅度上升，所以 BPC 在 end-to-end delay 表現上的最終結果是可以比 BPC-IF 要來得佳，也就是效能更好。. 39.

(40) 250. e2e delay (sec). 200 150 100. BPC BPC-IF PBAC original. 50 0. 20 22 23 24 25 26 27 28 29 30 traffic density (erlang) 圖 4.10 不同流量密度的 end-to-end delay（G.729）. 250. e2e delay (sec). 200 150 100. BPC BPC-IF PBAC original. 50 0. 20 22 23 24 25 26 27 28 29 30 traffic density (erlang) 圖 4.11 不同流量密度的 end-to-end delay（G.723.1）. 圖 4.12 ~ 4.14 分別是三種不同語音編碼在不同流量密度上，網路利用率（utilization）的變化及表現。由圖 4.12 來進行分析，除了網路利用率數值大小之外，還有幾個觀察指標。首先，我們先看在 traffic density 的值為多少時，網路利用率則會開始下降。其次，我們去計算從開始下降到 traffic density 為 30 時之間網路利用率的差距，來觀察下降幅度大小。因此，我們可以看到 BPC 及 BPC-IF 除了在網路利用率有著較好效 40.

(41) 能之外，它們的下降幅度都比 PBAC 及 original 要來得小。同時 BPC 在 traffic density 為 25 之後網路利用率才逐漸下降，這一點又比其它三種方. utilization (%). 法表現來得較佳。. 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.12 網路利用率在不同流量密度的變化（G.711）. 圖 4.13 及 4.14 分別為語音編碼 G.729 和 G.723.1 的模擬分析結果。從二個圖中來進行觀察分析，除了網路利用率大小、網路利用率何時下降及下降幅度大小在數值上有些微的不一樣，三組圖的走向大部份呈現類似情況。同時也發現在觀察指標中不同語音編碼效能表現也截然不同， BPC 在 G.711 模擬中 traffic density 為 25 之後才開始下降，這點是比另二種語音編碼要表現得較佳，而在下降幅度方面則是 G.723.1 為最小。. 41.

(42) utilization (%). 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). utilization (%). 圖 4.13 網路利用率在不同流量密度的變化（G.729）. 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original 20 22 23 24 25 26 27 28 29 30 traffic density (erlang). 圖 4.14 網路利用率在不同流量密度的變化（G.723.1）. 網路利用率在上述三種不同實驗模擬方案來看，BPC 除了在 G.711 模擬一開始網路利用率略小於 BPC-IF 之外，整體而言它在任何觀察指標中表現得都要比其它三種方法要來得佳。同時也注意到 PBAC 雖然在數值上表現得比 original 要來得佳，但它的下降幅度幾乎與 original 一樣大，這也就表示 PBAC 在網路利用率的表現不好。. 42.

(43) 4 . 3 . 2 實驗二：使用不同節點數目（number of nodes）量測圖 4.15 ~ 4.17 分別是分析不同語音編碼在當網域內的節點數量持續增加時，對於新連線的阻塞機率變化會是如何，且本文提出的方法是否能有效的降低阻塞機率。由圖 4.15 來進行分析，圖中在增加網域內節點數量時，我們可以看到阻塞機率相對的也會跟著上升，但有幾個觀察指標可以來說明。首先，我們要看阻塞機率上升的幅度，幅度的大小依序是 BPC、BPC-IF、PBAC 及 original，且 BPC 及 BPC-IF 直到節點數大於 25 之後，上升幅度才開始變得較為明顯。另一個觀察指標可以看到在節點數量為 45 時，四種方法的阻塞機率與一開始節點數量為 9 時的阻塞機率相較，差距已經有明顯的不同。根據上述二種觀察指標，可以表示為當節點數量愈大時，BPC 及 BPC-IF 可以有效的降低阻塞機率，. blocking probability (%). 也就是它的可擴充性較佳。. 9 8 7 6 5 4 3 2 1 0. BPC BPC-IF PBAC original 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.15 阻塞機率在不同節點數量的變化（G.711）. 圖 4.16 及 4.17 分別為語音編碼 G.729 和 G.723.1 的模擬分析結果。從二個圖中來進行觀察分析，除了新連線的阻塞機率大小在數值上有些 43.

(44) 微的不一樣，三組圖的走向大部份呈現類似情況。圖中的分析及說明結果就如同圖 4.15 一樣，BPC 及 BPC-IF 可以有效的降低阻塞機率且擁有. blocking probability (%). 較佳的可擴充性。. 9 8 7 6 5 4 3 2 1 0. BPC BPC-IF PBAC original 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.16 阻塞機率在不同節點數量的變化（G.729）. blocking probability (%). 8 7 6 5 4 3. BPC BPC-IF PBAC original. 2 1 0. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.17 阻塞機率在不同節點數量的變化（G.723.1）. 圖 4.18 ~ 4.20 分別是分析不同語音編碼在當網域內的節點數量持續增加時，對於平均封包遺失率的表現是否可符合一般人可接受的範圍以及內部節點數量要達到多少之後才會超過平均封包遺失率可接受範圍 44.

(45) （3%）。分析圖中平均封包遺失率的值是取自於該節點數量 traffic density 為 30 時。首先，從圖 4.18 顯示出來的結果，我們可以看到本文主軸的 BPC 在語音編碼（G.711）平均封包遺失率的成效表現比另外三種方法較佳，且一直到節點數量超過 25 之後，它的平均封包遺失率才超越 3%，也就代表此時語音品質為可接受但有雜音。若平均封包遺失率超過 5%，聽起來則會非常吵雜，且無法輕易判讀語音通訊內容，也就是代表此時語音品質為判讀因難及嚴重失真。. avergae packet loss rate (%). 8. 7 6 5. BPC BPC-IF PBAC original. 4 3 2 1 0 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.18 各節點數量的平均封包遺失率（G.711）. 接著我們再看圖 4.19 及 4.20 這二種不同語音編碼所呈現出來的結果，不難看出本文主軸的 BPC 與另外三種方法相較之下，的確可以有效的降低平均封包遺失率，且 G.729 及 G.723 它們在節點數量超過 29 之後，平均封包遺失率才會超過 3%，這一點來看是表現的比 G.711 要來的優秀。. 45.

(46) avergae packet loss rate (%). 8 7 6 5. BPC BPC-IF PBAC original. 4 3 2 1 0 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.19 各節點數量的平均封包遺失率（G.729）. avergae packet loss rate (%). 8 7 6 5. BPC BPC-IF PBAC original. 4 3 2 1 0. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.20 各節點數量的平均封包遺失率（G.723.1）. 圖 4.21 ~ 4.23 分別是比較不同語音編碼在當網域內的節點數持續增加時，每一條路徑 end-to-end delay 的表現是否能控制在 400 ms 內以及內部的節點數量達到多少之後才會超過 400 ms。若某路徑延遲時間超過 400 ms 時，則會使語音播放不順，嚴重影響語音品質。圖 4.21 有幾個觀察指標，從圖上面可以看出本文主軸 BPC 及 BPCIF 與 PBAC 及 original 相較之下有著較小的 end-to-end delay。接著，我 46.

(47) 們可以看到在節點數量的部份，本文主軸的 BPC 直到節點數量超過 29 之後，延遲時間才超過 400 ms，雖然 BPC-IF 也有著類似的結果，但就整體而言 BPC 表現得還是比 BPC-IF 較佳；反之，PBAC 及 original 與本文的方法相較之下，除了延遲時間較大，且在網域內部的節點數量為 25 時便開始超過 400 ms。. 1.4. e2e delay (sec). 1.2 1 0.8. BPC BPC-IF PBAC origianl. 0.6 0.4 0.2 0 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.21 各節點數量的 end-to-end delay（G.711）. 圖 4.22 及 4.23 顯示結果來說明，可以看出 G.729 及 G.723.1 這二種語音編碼格式與圖 4.21 比較，除了在整個 end-to-end delay 的時間有些微的不一樣，在圖走向的方面來看幾乎呈現類似情形。從網域內部的節點數量來看，本文提出的方法及都是在數量超過 29 之後才會超過 400 ms，也就是一般在語音服務品質上可接受的範圍。雖然 PBAC 在語音編碼 G.723.1 也是在節點數量為 29 之後才超過 400 ms，但綜合各模擬結果，本文提出的方法在整體效能上還是比 PBAC 較佳。. 47.

(48) 1.2. e2e delay (sec). 1. 0.8. BPC BPC-IF PBAC original. 0.6 0.4 0.2 0 9 13 17 21 25 29 33 37 41 45 number of nodes. 圖 4.22 各節點數量的 end-to-end delay（G.729）. 1.2. e2e delay (sec). 1 0.8. BPC BPC-IF PBAC original. 0.6 0.4 0.2 0. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.23 各節點數量的 end-to-end delay（G.723.1）. 圖 4.24 ~ 4.26 分別是三種不同語音編碼在各節點數量上網路利用率的變化及表現。分析圖中網路利用率的值是取自於該節點數量 traffic density 為 30 時。分析圖中觀察指標如同上一小節一樣，除了網路利用率值的大小之外，另一個觀察指標則是隨著節點數量增加，網路利用率下降幅度的大小。由圖 4.24 來進行分析，可以看到本文主軸的 BPC 在網路利用率部份有著較佳的表現且在下降幅度的部份也比另外三種方法 48.

(49) utilization (%). 要來得小。 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.24 各節點數量的網路利用率（G.711）. 圖 4.25 及 4.26 顯示結果來說明，除了在網路利用率大小有些微不一樣之外，二組圖的走向大部份都與圖 4.24 呈現類似情況。從三種不同的語音編碼模擬分析圖中，我們注意到在下降幅度愈小時，它愈不會受到節點數量增加而降低它的網路利用率，這也就表示網路利率不只對允. utilization (%). 入控制的方法有影響同時在語音編碼的部份也會有影響。. 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.25 各節點數量的網路利用率（G.729） 49.

(50) utilization (%). 100 95 90 85 80 75 70 65 60 55 50. BPC BPC-IF PBAC original. 9 13 17 21 25 29 33 37 41 45 number of nodes 圖 4.26 各節點數量的網路利用率（G.723.1）. 4 . 3 . 3 實驗三：使用不同阻塞節點（number of blocking nodes）量測本文使用 blocking node 來驗證本文主軸的 BPC 在復原性部份上面的表現。圖 4.27 ~ 4.30 分別是去比較各方法在不同數量的 blocking node 下新連線的阻塞機率、平均封包遺失率、e2e delay 及網路利用率的影響。本文在實驗模擬最大節點數為 45 個，但這邊我們將總節點數設為 29 個來進行實驗模擬，主要原因是本文提出的方法不論是平均封包遺失率或 e2e delay 都在節點數為 29 之後才會超過一般人在語音品質上所能接受的範圍。綜合上述模擬結果我們幾乎可以看到在不同的語音編碼，整個模擬結果除了數值上會有些微不同，在圖面的走向幾乎都是呈現類似，所以在 blocking nodes，本文只實驗模擬語音編碼為 G.711 的部份。. 50.

(51) 由圖 4.27 來進行分析說明，這裡只有一個觀察指標，我們可以清楚看到每一個方法在 blocking nodes 為 1 到 blocking nodes 為 10 時阻塞機率的差距。除了 BPC 及 BPC-IF 它們的阻塞機率差距沒有超過 1%，另. blocking probability (%). 外二種方法差距皆超過 1%，且在 original 的差距則高達 1.8%。. 9 8 7 6 5 4 3 2 1 0. BPC BPC-IF PBAC original 1. 2. 3 4 5 6 7 8 9 10 number of blocking nodes. 圖 4.27 不同阻塞節點數量的阻塞機率（G.711, 總節點數 = 29）. 圖 4.28 來進行分析說明，我們可以清楚看到每一個方法在 blocking nodes 為 1 到 blocking nodes 為 10 時平均封包遺失率的差距。結果就如同圖 4.27 一樣，除了 BPC 及 BPC-IF 它們的平均封包遺失率差距沒有超過 1%，另外二種方法差距皆超過 1%，特別是在 original 差距則高達 1.5%。接著，我們繼續觀察 blocking nodes 在 end-to-end delay 的部份。. 51.

(52) avergae packet loss rate (%). 6 5. 4 3 BPC BPC-IF PBAC original. 2 1 0 1. 2. 3 4 5 6 7 8 9 10 number of blocking nodes. 圖 4.28 不同阻塞節點數量的平均封包遺失率（G.711, 總節點數 = 29）. 圖 4.29 一樣使用上述的方法來觀察 end-to-end delay 在 blocking nodes 為 1 到 blocking nodes 為 10 時之間的差距。圖上面可以看到 BPC 的差距約 80 ms，其次為 BPC-IF 大約在 110 ms，再來是 PBAC 約為 140 ms，最後則為 original 大於 150 ms。. 0.8 0.7 e2e delay (sec). 0.6 0.5 0.4 0.3. BPC BPC-IF PBAC original. 0.2 0.1 0 1. 2. 3 4 5 6 7 8 9 10 number of blocking nodes. 圖 4.29 不同阻塞節點數量的 end-to-end delay（G.711, 總節點數 = 29）. 52.

(53) 最後，圖 4.30 來進行分析說明，在網路利用率的部份，也是使用上述的方法直接觀察 blocking nodes 從 1 到 10 之間的差距。分析結果顯示下降幅度的大小依序為 BPC、BPC-IF、PBAC 及 original。所以，綜合上述四組實驗模擬結果，我們可以得知 BPC 與另外三種方法進行比較. utilization (%). 有著較佳的復原性。. 90 80 70 60 50 40 30 20 10 0. BPC BPC-IF PBAC original 1. 2. 3 4 5 6 7 8 9 10 number of blocking nodes. 圖 4.30 不同阻塞節點數量的網路利用率（G.711, 總節點數 = 29）. 根據上面三個不同的實驗方案及十二組結果來說明，我們可以發現如果要維持語音連線的品質，不單只是依賴允入控制機制而已，針對不同的服務模式選擇一個適當的語音格式編碼是不可獲缺的。我們可以看到實驗中使用不同的量測方式進行阻塞機率、平均封包遺失率、e2e delay 及網路利用率模擬所產生的結果，在各數值方面表現，語音編碼 G.723.1 分析出來的值幾乎都比其它二種語音編碼要佳，主要原因是因為 G.723.1 採用較高的壓縮比來進行語音資料壓縮，也因為高壓縮的關係 G.723.1 必頇犧牲掉一些語音資料，所以並不代表 G.723.1 擁有最佳的通話品質。因此，如果要得知語音編碼確切語音品質，必頇進行一些有關於 VoIP 訊流在不同服務模式中的效能評估實驗及模擬。 53.

(54) 本文提出的方法在網路利用率的部份，無論是使用何種語音編碼，與其它方法相較之下表現都是最佳，原因是本方法在進行允入控制時是不設門檻值來拒絕連線請求，這樣的好處是當網路擁塞時，連線請求仍然可去選擇一條阻塞機率較小的路徑去進行傳送，因此便可以增加網路的利用率。相對的，這樣的原因若遇到另一種情況，當網路極度擁塞（幾乎無資源可分配時），可能會在傳送過程又產生阻塞，也就是阻塞機率上升幅度變大。. 54.

(55) 5 . 結論與未來研究方向. 本文提出一個以計算阻塞機率為基礎的允入控制方法，當有連線請求時，由 ingress 決定一條阻塞機率較低的路徑進行傳送。根據更新資訊的回饋，此法又可分為 BPC 及 BPC-IF。根據實驗模擬結果的顯示，本文提出的方法 BPC 及 BPC-IF 在 blocking probability、end-to-end delay、 packet loss rate 及 utilization 上面的表現皆能滿足在第一章所提出的三種基本需求：可擴性、網路利用率及復原性佳，且在網路負載比較高時仍然能有效的提升語音傳輸效能及降低阻塞機率。本文研究尚有許多可努力的方向：（1）網路拓樸及內部節點數規模較小，並不足以代表真實世界中的網路架構，但若加大拓樸的複雜度及節點數量，實驗中的變因，以及需要觀察的項目也會大幅增加，實驗也會更為複雜；（2）語音編碼的資料流不是真實產生的，且實驗中的資料流都是使用 ns2VoIP 模組所模擬產生的，與真實網路應用仍有差距；（3）增加更多標準的語音編碼來進行模擬，或是加入一個機制來搭配使用其它允入控制的方法。這些都是未來可研究的方向。. 55.

(56) 參考文獻 [1]. P. Ferguson and G. Huston, "Quality of Service-Delivering QoS on the internet and in corporate networks", Wiley Computer Publishing, 1998.. [2]. S. Shenker, C. Partridge and R. Guerin, "Specification of guaranteed quality of service", IETF RFC 2212, September 1997.. [3]. J. Wroclawski, "The Use of RSVP with IETF Integrated Services", IETF RFC 2210, September 1997.. [4]. S. Blake, D. Black and M. Carlson, E. Davies, Z. Wang, and W. Weiss, "An Architecture for Differentiated Service", IETF RFC 2475, December 1998.. [5]. K. Nichols, S. Blake and F. Baker, and D. Black, "Definition of the differentiated services field in the IPV4 and IPV6 headers", IETF RFC 2474, December 1998.. [6]. S. Crosby, "Statistical properties of a near-optimal measurement-based cac algorithm", In Proceedings of IEEE ATM ’97 Workshop, Lisboa, Portugal, 1997.. [7]. K. Mase and H. Kobayashi, "An efficient end-to-end measurement based admission control for VoIP networks", ICC 2004 - IEEE International Conference on Communications, no. 1, June 2004 pp. 1877-1881. [8]. M. Grossglauser and David N. C. Tse, "A framework for robust measurement-based admission control", IEEE/ACM Transactions on Networking, vol. 7, no. 3, Jun 1999 pp. 293-309. [9]. M. Grossglauser and David N. C. Tse, "A time-scale decomposition approach to measurement-based admission control", IEEE/ACM Transactions on Networking, vol. 11, no. 4, Aug 2003 pp. 550-563. [10] K. Nichols, V. Jacobson and L. Zhang, "A two-bit differentiated services architecture for the internet", IETF RFC 2638, July 1999 56.

(57) [11] I. Más Ivars and G. Karlsson, "PBAC : Probe-Based Admission Control", in Proceeding of QofIS 2001, vol. 2156 of LNCS,（Coimbra, Portugal）, pp. 97-109, Springer, September 2001. [12] S. Bakiras and Victor O. K. Li, "Efficient resource management for end-to-end QoS guarantees in DiffServ networks", ICC 2002 - IEEE International Conference on Communications, no. 1, April 2002 pp. 1220-1224 [13] H. Sandström, U. Bodin and O. Schelén, "Adaptive threshold-based admission control", ICC 2005 - IEEE International Conference on Communications, no. 1, May 2005 pp. 48-52 [14] S. Bhatnagar and B. Nath, "Distributed admission control to support guaranteed serivce in core-stateless networks", In Proceeding Of IEEE Infocom, May 2003. [15] CISCO Document ID : 7934, "Voice Over IP - Per Call Bandwidth Consumption", http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note0 9186a0080094ae2.shtml [16] CISCO - Internetworking Technology Handbook, "Chapter 49 : Quality of. Service. QoS)",. http://www.cisco.com/en/US/docs/internetworking/technology/handboo k/QoS.html [17] Information. Sciences. Institute,. "The Network. Simulator-ns-2",. http://www.isi.edu/nsnam/ns/ [18] A. Bacioccola, C. Cicconetti and G. Stea, "User level performance evaluation of VoIP using ns-2", Proceedings of NSTOOLS'07, First International Workshop on Network Simulation Tools, Nantes (FR), October 22, 2007 [19] H. Alshaer and E. Horlait, "Expedited forwarding end-to-end delay and 57.

(58) jitter in DiffServ", CCNC 2006 - IEEE Consumer Communications and Networking Conference, no. 1, Jan 2006 pp. 366-370 [20] "VoIP Bandwidth Utilization and Packet Handling", white paper, Network Equipment Technologies, Inc, May 25, 2004 pp. 2-4. 58.

(59) 附錄 A – Codec Information & Bandwidth Calculations Codec Information Codec & Bit Rate. Codec Sample Size. Codec Sample Interval. Bandwidth Calculations Mean Opinion Score. Voice Payload Size. Packet per second （pps）. Bandwidth Ethernet. G.711 10 ms 4.10 160 Bytes 50 87.2 Kbps (64 Kbps) 80 Bytes G.729 10 ms 3.92 20 Bytes 50 31.2 Kbps (8 Kbps) 10 Bytes G.723.1 30 ms 3.90 24 Bytes 34 21.9 Kbps (6.3 Kbps) 24 Bytes G.723.1 30 ms 3.80 20 Bytes 34 20.8 Kbps (5.3 Kbps) 20 Bytes G.726 5 ms 3.85 80 Bytes 50 55.2 Kbps (32 Kbps) 20 Bytes G.726 5 ms 60 Bytes 50 47.2 Kbps (24 Kbps) 15 Bytes G.728 10 Bytes 5 ms 3.61 60 Bytes 34 31.5 Kbps (16 Kbps) Bandwidth Calculation Formulas : ** Total packet size = (L2 header) + (IP/UDP/RTP header) + (voice payload size) ** PPS = (codec bit rate) / (voice payload size) ** Bandwidth = total packet size * PPS. 59.

(60) 附錄 B – The modifications of ns2voIP patch The modifications of voip_encoder.cc : VoipEncoder::command (int argc, const char*const* argv) { ………. ………. ………. } else if ( argc >= 3 && strcmp (argv[1], "codec") == 0 ) { ………. ………. ………. } else if ( argc == 3 && strcmp (argv[2], "G.729") == 0 ) { size_ = 10; inter_ = 0.01; initialized_ = true; return TCL_OK; ………. ………. ………. } The modifications of voip_decoder.cc : VoipDecoder::VoipDecoder () : functor_ (this, &VoipDecoder::collectEnd) { ………. ………. ………. // E-Model parameter for GSM AMR 12.2 Kb/s codec. emodel_Ie_ = 5; emodel_Bpl_ = 10; emodel_A_ = 5; emodel_Ro_ = 94.77; emodel_Is_ = 1.41; mosThreshold_ = 3.0; cellOutageThreshold_ = 0.10; ………. 60.

(61) ………. ………. } ………. ………. ………. VoipDecoder::command (int argc, const char*const* argv) { ………. ………. ………. // For more detail, please refer to ITU-T Recommendation G.113 else if ( argc == 3 && strcmp ( argv[1], "emodel" ) == 0 ) { if ( strcmp ( argv[2], "G.711" ) == 0 ) { emodel_Ie_ = 0; emodel_Bpl_ = 4.3; emodel_A_ = 0; return TCL_OK; } else if ( strcmp ( argv[2], "G.729" ) == 0 ) { emodel_Ie_ = 11.0; emodel_Bpl_ = 19.0; emodel_A_ = 0; return TCL_OK; } else if ( strcmp ( argv[2], "G.723.1" ) == 0 ) { emodel_Ie_ = 15.0; emodel_Bpl_ = 16.1; emodel_A_ = 0; return TCL_OK; } else if ( strcmp ( argv[2], "GSM.EFR" ) == 0 ) { emodel_Ie_ = 5.0; emodel_Bpl_ = 10.0; emodel_A_ = 5; return TCL_OK; } else if ( strcmp ( argv[2], "GSM.AMR" ) == 0 ) { 61.

(62) // GSM_AMR uses the same value of GSM_EFR emodel_Ie_ = 5.0; emodel_Bpl_ = 10.0; emodel_A_ = 5; return TCL_OK; ………. ………. ………. } ………. ………. ………. VoipDecoder::eModel (double delay, double loss) { ………. ………. ………. // Compute the R factor double Rfactor = emodel_Ro_ - emodel_Is_ - id - ie_eff + emodel_A_; ………. ………. ………. }. 62.

(63)