1 / 65

QoS Evaluation of Sender-Based Loss-Recovery Techniques for VoIP

QoS Evaluation of Sender-Based Loss-Recovery Techniques for VoIP. Teck-Kuen Chua and David C. Pheanis, Arizona State University. IEEE Network • November/December 2006. 大綱. 簡介 VoIP 架構 遺失復原技術 方法探討 模擬封包遺失的特性 Audio 品質探討 結論. 簡介. 透過 Internet 或其他使用 IP 技術的網路，來實現新型的電話通訊 通話方式 軟體的 SIP 電話程式

uri
Download Presentation

QoS Evaluation of Sender-Based Loss-Recovery Techniques for VoIP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. QoS Evaluation of Sender-BasedLoss-Recovery Techniques for VoIP Teck-Kuen Chua and David C. Pheanis, Arizona State University IEEE Network • November/December 2006

  2. 大綱 • 簡介 • VoIP架構 • 遺失復原技術 • 方法探討 • 模擬封包遺失的特性 • Audio 品質探討 • 結論

  3. 簡介 • 透過Internet或其他使用IP技術的網路，來實現新型的電話通訊 • 通話方式 • 軟體的SIP電話程式 • 硬體的VOIP網路電話 • IP電話通過把語音信號經過數位處理、壓縮編碼包裝、透過網路傳輸、然後解壓、把數位信號還原成聲音，讓通話對方聽到

  4. VoIP Diagram

  5. IP電話技術流程 • 聲電轉換：將類比聲波變換為電信號 • 量化採樣：將模擬電信號按照某種採樣方法（比如脈衝編碼調製，即PCM）轉換成數字信號 • 封包：將一定時長的數字化之後的語音信號組合為一Frame，隨後，按照ITU-T的標準，這些voice frame被封裝到一個RTP（Realtime Transport Protocol）中，並被進一步封裝到UDP message和IP message中。 • 傳輸：IP message在IP網路由發送端傳遞到目的端 • De-package • 電聲轉換

  6. Loss-Recovery Mechanism • Sender-based packet-loss recovery • 藉由傳送者(sender)擔任主動角色來幫助接收者恢復遺失的資料或改善QoS • Receiver-based packet-loss recovery • 封包遺失隱藏法(packet-loss concealment, PLC) • 設計人員可以同時採用兩種類型的packet-loss方法

  7. Audio Codec

  8. 常用類比信號轉數位信號Codec(1/2) • ITU G.711 - 64 Kbps, 基於樣本的，也叫alaw/ulaw • ITU G.722 - 48/56/64 Kbps • ITU G.723.1 - 5.3/6.3 Kbps, 30ms/frame尺寸 • ITU G.726 - 16/24/32/40 Kbps • ITU G.728 - 16 Kbps • ITU G.729 - 8 Kbps, 10ms/frame尺寸

  9. 常用類比信號轉數位信號Codec(2/2) • GSM - 13 Kbps (全速), 20ms/frame尺寸 • iLBC - 15Kbps,20ms/frame尺寸: 13.3 Kbps, 30ms/frame尺寸 • Speex - 2.15 to 44.2 Kbps • LPC10 - 2.5 Kbps • DoD CELP - 4.8 Kbps

  10. Internet Low Bitrate Codec(iLBC) • 設計給narrow band speech • 使用linear predictive coding (LPC)演算法 • 在封包遺失的控制回應方式類似於ITU-T標準G.711的脈衝編碼調變(pulse code modulation, PCM)結合封包遺失隱藏(packet-loss concealment, PLC) • 兩種模式 • 15Kbps,20ms/frame尺寸 • 13.3 Kbps, 30ms/frame尺寸

  11. ITU-T Standard G.729A Codec • 使用conjugate-structure algebraic code excited linear-prediction (CS-ACELP)演算法 • 非常少的bit rate，能夠提供接近語音電話品質的音訊 • 使用linear-prediction filter來模型化人類的聲帶 • G.729A是ITU-T標準G.729的簡化版 • 8 Kbps, 10ms/frame尺寸

  12. Loss-Recovery Techniques

  13. Loss-Recovery Techniques • 在VoIP系統裡，設計者處理封包遺失的技術通常不使用由傳送端決定(Sender-Base)的封包遺失技術。 • 但是當數據頻寬的使用率增加時，網路會變的更擁擠而遺失更多的封包，而這對VoIP 所要求的對話即時性和語音品質來說，是一個很大的問題。 • 因此，此研究考慮以下幾種Sender-Base的封包遺失技術方法。

  14. Plain Delivery • 直接傳輸(Plain Delivery)是一種不具任何由傳送瑞(sender-base)決定的封包遺失回復技術。 • 這種技術僅僅把每個數據音訊進行編碼成一個IP封包進行傳送。 • 為了要相互比較的目的，將Plain Delivery做為在這篇paper裡的基線。

  15. Interleaving • 不是一種封包遺失回復技術。 • Interleaving是將傳送資料的順序重新排列。 • 假如發生遺失，能使接收端損失驅散成幾個小部份，降低因為遺失而產生的音訊品低下的問題。

  16. Interleaving 圖例

  17. Forward Error Correction • 一種以傳送瑞來決定的封包遺失回復技術，利用額外附加的資料來達到更正錯誤的補償效果。 • 這裡將以Reed-Solomon和Parity encoding為例說明： • Reed-Solomon (RS碼) • Parity encoding (配位編碼)

  18. Forward Error Correction Reed-Solomon • RS碼是一種在數位通訊很常被使用的的錯誤更正機制。 • 當數據值發生遺失時，RS譯碼器能透過使用奇偶位驗位來重建初始數據。 • 但是在像VoIP這樣需要即時知覺的環境下，RS碼在計算與實現上會十分的耗費成本，因此在這裡將不選擇RS碼。

  19. Forward Error Correction Parity encoding • 配位編碼(Parity encoding)是使用傳送多餘的封包來更正錯誤。 • Ex：如果我們失去某n封包，則我們可以從前一個(n-1)封包中，重建所遺失的封包。 • 但是如果我們在(n+1)之外連續遺失不止一個封包，那這技術就不及格了。

  20. Forward Error Correction pFEC (piggyback FEC) • 在較小的n值上，我們可以利用一種pFEC技術來更正遺失封包。 • 而當n值越大時則代表的需要更多的時間來編解碼與錯誤更正。 • pFEC是利用遺失封包的下一個封包來更新回復資料。

  21. Forward Error Correction pFEC 圖例 • 如上圖，假如A遺失但B沒遺失，則當C到達的時候，可以利用B XOR (A XOR B)來回復A。

  22. Redundant Data Transmission (1/2) • RDT是藉由傳送一次以上的音頻數據(Audio data)來運作。這個技術是用一個單一封包把先前傳送的音頻數據和新的音頻數據，組合起來。 • 一旦失去了封包，仍然可以從另一個帶著多餘資料的IP數據封包恢復已失去的音頻數據 • 傳送兩倍的20毫秒／區塊的編碼數據

  23. Redundant Data Transmission (2/2) • 一個frame20毫秒，一個封包裡我們傳輸frame 1和2，然後在下一個數據封包傳送frame 2和3，之後再傳送frame 3和 4的封包。 • 當封包遺失，我們仍然可以恢復所有丟失的信息。但是，如果失去了兩個或兩個以上的連續數據封包，實際上我們就失去了音頻數據。

  24. Duplicate Packet (1/3) • Duplicate Packet遺失的回復技術 • Duplicate Packet這個方法與RDT很像，都會多傳送一次音頻數據。 • 這種技術是傳送多餘的數據在單獨IP數據封包，所以他需要額外的標頭，導致頻寬花費的增加。

  25. Duplicate Packet (2/3) • Duplicate Packet需要兩倍的頻寬直接傳輸方法，92.8 kb/s在iLBC和78.4 kb/s在 G.729A。 • 我們將需要兩倍的網路頻寬或減少一些其他頻寬來使用該技術，以取代直接傳輸技術。

  26. Duplicate Packet (3/3) • Duplicate Packet的封包方式，當我們封包20毫秒的音頻數據轉化為IP package，至少有20毫秒的延遲。 • 延遲傳輸重複的數據封包，我們可以減少兩個數據封包遺失的機會，但會增加總體的延遲時間

  27. 10 percent random loss.

  28. Retransmission • Retransmission可提供請求的Receiver重新恢復丟失數據的。 • Retransmission延遲時間過長 • 會話式的即時通信系統需要點對點延遲小於250毫秒。否則，該系統將引入令人不快的嚴重影響談話重疊，降低總體品質的會談。

  29. 方法探討

  30. QoS技術的選擇 • 選擇 sender-based 的 loss-recovery 技術 • Plain delivery和 RDT 皆可支援 RTP 而 Duplicate 也可以在不做任何改變下支援RTP • 只選擇可以適應於 real-time 之VOIP應用的 sender-based loss-recovery技術

  31. Duplicate-packets 的方法是一個耗費頻寬成本的一種方法，所以它並不實用或符合成本效益於真實世界的VOIP產品。 • Retransmission 技術在即時的IP通訊環境下，會潛在的帶來大量的delay和造成不能被接受的語音重疊。雖然，retransmission 方法在沒有麻煩的潛在限制應用下，可以是一個有效處理的遺失回覆的方法，但是，在我們的目的之下retransmission方法不是一個可行的解決方案。

  32. 量測使用者對於聲音品質的感覺 • Plain technique 結合iLBC • Plain technique 結合G.729A • RDT結合G.729A • pFEC (參數n=2) 結合G.729A • Two-frame interleaving結合G.729A

  33. 模擬封包遺失的特性

  34. Packet-Loss Characteristics • Random lost • Burst lost • Real-Network Loss

  35. Random lost • 在這個測試方法中我們簡單的隨機讓封包遺失。而Random lost最主要的目的是讓隨機遺失掉的封包為獨立的封包。 • Random lost是一個非常適合於很多sender-based loss-recovery 的技術，因為多重連封包遣失在隨機的情況下相對上較少發生。在隨機遺失的情境下遺失k個連續封包的機率會隨著k的增加而下降的很明顯。 (k代表所要測試的遺失封包量)

  36. RDT:是一個在非遺失多重連續封包的情況下不會有聲音遺失的技術。而在連續遺失的情況下，在RDT上遺失的資訊是比用plain delivery技術還要來的少的，因為RDT會補償部分的遺失。相同的，Duplicate packet 的方法也不造成任合的遺失，除非遺失了多重連續封包。

  37. pFEC技術在一群之(n+1)個封包間遺失1個以上的連續封包時會造成無法完成或全面遺失的情形。但是，這樣全面遺失的可能性在隨機的環境下是很低的。 pFEC技術在一群之(n+1)個封包間遺失1個以上的連續封包時會造成無法完成或全面遺失的情形。但是，這樣全面遺失的可能性在隨機的環境下是很低的。

  38. Interleaving technique與plain technique在各種遺失的特性下有著一樣的遺失量，所以這兩種方法的封包遺失量與封包遺失的特性無關。但是在Interleaving technique中多重連續封包遺失時會增加無法復原的情況，而也就是這個方法要去克服的問題。 因此，interleaving被認定為在沒有多重封包遺失的情況下為隨機的情況下能最有效的減少封包遺失量的方法。 相同的，網路遺失的特性也沒有影響retransmission technique的效能，因為接收端可以在遺失封包時請求重新傳送。

  39. 圖表1與2顯示出在隨機環境下實際資訊遺失的百分比(比較plain delivery, RDT, pFEC n=2 等三個情況下)。 • 這些表指出在pFEC n=2的情況下封包遺失遠低於plain delivery technique，而RDT永遠比pFEC好。

  40. plain delivery遺失率算法 plain delivery：k個連續封包遺失的比例公式為kpk(1-p)2 (k 所代表的是burst length而p是單一封包遺失的機率)。

  41. RDT遺失率算法 RDT：封包遺失的比率為跟plain delivery有點像(k-1) pk(1-p)2， k改成(k-1)是因為RDT本身的遺失率問題。

  42. pFEC遺失率算法 pFEC：在k=1，n=2的情況下，封包遺失率為[(k-1+p) pk(1-p)2]/2 或簡單一點為[pk+1(1-p)2]/2；而當k>1，n=2時為[(k+(k-1)+p) ]pk(1-p)2/2

  43. Burst lost • The RDT technique is not as effective in an environment with burst loss as it is in the random-loss scenario. • RDT compensates for the final lost packet in any burst of lost packets, so the portion of the loss that RDT eliminates for a burst loss of k consecutive packets is (1/k).

  44. When the network becomes congested and loses multiple consecutive voice packets, pFEC is very likely to lose more than one packet among (n + 1) packets. • A large transmission delay with the duplicate-packet method can help recover the corresponding lost data.

  45. 在Burst lost情況下，對Retransmission技術並沒有任何影響。 • Interleaving technique still achieves its goal of dispersing a long loss into several smaller losses in a burst-loss environment

  46. Plain delivery Interleaving technique

  47. Real-Network Loss • Accurately modeling the loss characteristics of a real IP network is a difficult task. • We collected information over a period of several months from a corporate LAN with a mix of VoIP and TCP/IP traffic, and we collected similar information by testing over the Internet.

  48. We injected a stream of VoIP packets at intervals of 20 ms and recorded packet losses in that stream so we could model the pattern of packet losses for a VoIP conversation in a real network. • Since a real network loses packets during periods of traffic congestion, a real network may have higher rates of multiple-packet loss than we see with a random-loss scenario.

More Related