無線區域網路語音擴展VoIP應用

隨著WiFi標準的改善、802.11晶片體積不斷減小而功能 不斷擴充,無線區域網路語音(VoWLAN)電話系統的可行性也逐漸提昇。雙頻行動電話可使用WLAN連線提供可靠的屋內話音服務,而寬頻電話服務則透過 WLAN連結筆記電腦。另一方面,架構於WLAN的網路電話手機,由於只需一台WLAN基地站便能輕易支援多個手機,與具備低成本優勢的傳統無線電話機相 比毫不遜色。

 802.11標準建立了提供可靠、高效能的WiFi網路電話系統所需之基本機制。其中顯著的例子為安全性(802.11i/WPA)與QoS(802.11e/Wi-Fi多媒體)。此外,諸如Atheros開放程式碼的JumpStart
for Wireless這類單鍵安全設定法,可讓所有使用者即使在手機無法顯示英文字母與數字的狀況下,仍能快速設定WLAN網路電話手機的組態。

 WLAN網路電話系統中其中一項尚未標準化的項目為輪詢方法(polling
method)。因此本文就現有的兩種輪詢方法,分別討論其不同的優點和缺點,並且特別著墨於行動裝置中最關鍵的要素──耗電量。

 所有降低耗電量的方法,均必須儘可能讓用戶裝置使用低功耗的睡眠模式,而802.11晶片必需以睡眠模式中最低的耗電量以支援此作法802.11晶片必須以睡眠模式的最低可能耗電量支援此種作法。例如,Atheros
的AR6000行動型射頻單晶片(radio-on-a-chip mobile;ROCm)裝置,實現了極低耗能量的睡眠模式,以及自動省電模式(Automatic
Power-Save Delivery;APSD)技術。ROCm同時提供絕佳的效能,能啟用高速傳輸以縮短髮送/接收的時間,而晶片上的嵌入式處理器之自給式驅動程式,可分 攤處理主機處理器上的經常性的網路維護作業。透過以上的做法與其他省電策略,ROCm晶片能改善WLAN作業的耗電效率,效果可比傳統WLAN晶片的高達 六倍,因此能改善電池壽命。現時可實現各種VoIP應用的新一代802.11裝置,就包含這類的晶片。



 將語音導入WLAN

 802.11 WLAN可利用高效能的元件以提供可靠的整體性能,然而,此媒體的特性在處理語音流量時,仍面對相當嚴苛的挑戰。由於WLAN使用免執照頻譜,因此必須容 忍來自不同外部裝置與其他WLAN的大量干擾。此外,如同其他IP網路,WLAN並不支援同步作業(synchronous operation)。因此,通常無法在微秒級下做預測。由於VoIP是以固定時間間隔產生VoIP封包(即訊框)的固定數碼速率(CBR)應用,因此WLAN的CSMA競爭法明顯缺乏中央同步時序(centralized synchronous timing)。

 此現象與行動電話系統所實作的標準電話機制形成更大的對比。行動電話系統使用授權頻譜與小心規劃的基地站部署,務求將無線電干擾減至最低。行動電話系統 從電話到骨幹線路都保持同步,於是能掌握微秒層級的時序而且永不偏離,亦因此能預知容量的大小,且容量提供給單一類別服務設計應用:語音。

 這些行動電話系統的特性令它能輕易符合ITU-T建議的G.114標準,此標準指定端點對端點延遲預算不得大於150微秒。由於行動電話系統整體的架構 採用可決定的方式應用時脈語音封包,因此不需因為要確保低延遲,而對語音封包以特殊的服務品質(QoS)機制排定優先順序。行動電話系統利用現有時槽、多 工與語音服務管理加入資料服務。

 WLAN則剛好相反,語音服務必須借助於原本針對資料而設計的功能。WLAN僅能用到端點對端點延遲預算150微秒的一部份,如果兩端都使用WLAN進 行對話,那麼延遲預算還要更進一步縮限。此外,若語音封包必須跨越網際網路或忙碌的企業網路,那麼封包將無法避免延遲抵達,有時甚至無法抵達。遲到的封包 可能成群抵達。

 只要使用過舊式轉碼器在網際網路或通用WLAN中以語音通訊的人,都會熟悉這些問題。建立高品質VoWLAN的作法之一是改變WLAN以符合傳統編碼器的需要。事實上,無論是全時或分時,專屬實作均顯示802.11 MAC可改變為使用同步、時槽式的TDMA作法;此作法能有效解決以WLAN傳輸話音問題,不過這類系統通常與現有的WiFi裝置與網路不相容。

 雖然完全同步的網路頗具吸引力,但缺乏嚴格同步卻也正是802.11的主要強項。這些年來,我們可在以太網路和ATM網路之間的競爭中看到這類IP網路 的優點。當可靠而具適應式(夠好)之通道存取對上嚴格時(完美)序式作法時,夠令人滿意的作法通常因更具多樣性而較受歡迎。

 在設計VoWLAN系統時避免使用同步作法的另一個原因,是這些系統並非在封閉環境下運作。使用WLAN傳輸語音的主要賣點,是讓雙模行動電話與其他語音裝置能利用現有的WLAN基礎結構



 新一代的解碼器

 改善現有802.11基礎結構的方法之一,是利用針對網際網路應用而開發的較新語音解碼器。這些解碼器大幅簡化VoWLAN的設計。效率不彰的網際網路電話環境,促成解碼器的開發,能以極低位元的速度達到良好的語音品質。

 例如:廣受歡迎的Skype網路電話系統核心之iLBC 解碼器,能提供相當於高階ITU G.729解碼器的特性;ITU解碼器只以8kbps,能提供公用電話般的語音品質;而來自Global IP Sound的iLBC解碼器,所需的位元速率稍高-13.3kbps。Global IP Sound稱他們的編碼器語音品質優於PSTN,而且能忍受高達30%的封包損失。網際網路工程研究團隊(Internet Engineering Task Force;IETF)已對此解碼器制定標準。CableLabs應用於多媒體終端配接器與媒體閘道的PacketCable影音解碼器規格以被指定其為必要的解碼器。

 有了此類解碼器,必要的VoWLAN語音品質就更易於實現,而且也能解決網際網路所造成的延遲與抖動現象,故此特別適合如802.11這種非同步開放系統使用。既然解碼器如此靈活,為何還要發展複雜的時序與同步方法呢?



 挑戰耗電量

 儘管現今的解碼器如此靈活,時序仍然是十分重要的,因為它對耗電量影響重大。行動電話系統的同步特性,使它能輕易而直接地實現手機睡眠/喚醒排程。手機 能在封包之間知道能安全地進入睡眠模式。然而,802.11的裝置就永遠不知道何時可能接收突發的流量,或因其他理由而必須回應存取點。

 雖然行動電話與VoWLAN系統之間有此差異,後者還是必須讓它的電池壽命能媲美行動電話手機。雙模行動電話手機的兩種類型功能都使用同一顆電池,因此勢必會互相比較。

 說到這裡,我們不禁又會想令WLAN同步作業。若存取點知道手機於何時進入睡眠模式,只在它準備好時進行傳輸,此時手機就可類似行動電話,定期進入睡眠模式。存取點不必在VoIP訊框抵達時立刻傳輸至手機,必要時可先將這些訊框置於緩衝區。

 目前有兩種作業模式,能以足夠的同步在802.11 WLAN中實作良好的省電時序技術,因此不需完全同步作業。這些模式包括以「混合控制功能(Hybrid Control Function;HCF)」控制的通道存取(HCF Controlled Channel Access;HCCA)以及增強分散式通道存取(Enhanced Distributed Channel Access;EDCA)。此兩種模式都是IEEE 802.11e標準當中,服務品質(QoS)規定的一環,而兩者皆可用於發展中的省電傳訊方法,於存取點和站台之間以同步固定數碼速率傳輸,而不需對整個WLAN進行同步。



 以HCCA進行同步

 HCCA模式就如同N-body同步機制,由存取點為N個站台設定CBR輪詢排程。儘管典型的802.11系統無規律性,站台還是儘可能地按排程同步。 將這樣的配置描述為N-body系統是相當合理的,因為對輪詢排程上任一站的時序干擾,都會影響到其他N-1個站的時序。

 當AP透過流量規格(TSPEC)接收到來自站台的CBR要求時,HCCA機制便發揮作用,然後AP與該站進行CBR排程的通訊。一旦AP接受站台作為 輪詢的用戶,此站台通常會進入睡眠狀態,直到來自AP預期的下行輪詢或輪詢加VoIP訊框抵達為止(圖一)。在規定的時間內(架構於OFDM的 802.11a/g為9μs,802.11b則會更久),站台以上行VoIP資料(或QoS-NULL)訊框回應。若站台發送上行資料,AP就以ACK回 應。

 要知道此機制的耗電效率,讓我們先考量站台需保持喚醒狀態的時間比例。HCCA機制如需正確運作,在AP的下行輪詢前,站台必須從睡眠模式中喚醒。根據 硬體設計而定,喚醒的程序約需0.1到1.0微秒。然後站台必須等到下行輪詢抵達,而輪詢可能在站台預期的抵達時間到時仍未抵達。不同的原因如干擾、通道 上長持續時間的訊框、AP中內部排程衝突(輪詢其他站台)、更高優先順序的作業(AP必須傳輸一Beacon)、前一訊框超出預期的交換時間或是AP與站 台之間的相對時脈偏移,均會造成延遲。不過一旦下行輪詢抵達,排程就會變得可預測。根據所選的解碼器與PHY速率,上行/下行訊框交換應在不到1微秒的時 間內發生。

 在HCCA機制中,時序的不確定性主要來自CBR輪詢排程的延遲、失敗後可能的重試以及使用可變PHY速率時,造成傳輸時間的變化。根據這些不確定性,站台喚醒時間的約為2~5微秒。以20微秒的解碼器週期,此喚醒睡眠比所達成之效率比值為75%以上。



 HCCA的固定位元率排程 




▲圖一:存取站可實作802.11e標準中指定的HCCA作業模式,提供可預測時間的VoIP輪詢排程,以在WLAN站台能以睡眠模式減少耗電量時進行管理。

   假設平均通話時間約為100秒(以行動電話系統平均而言)而AP同時提供20通電話應用,WLAN可能每5秒就必須執行通 話設定/解除。即使在各站台經 常進入與離開輪詢清單的狀況下,AP仍必須與每個站台維持已發佈的CBR排程。因此,AP也必須維持固定時槽的排程。

 這裡所說的時槽,為針對特定站台之輪詢訊框交換序列而指定的通道時段。除非所有訊框都使用相同的PHY速率,使每次交換都佔用相同的通道時間量,否則時槽的持續時間也會隨之變化。在時槽持續時間變化的情況下,無法達成效率佳的省電同步。

 可選擇的方法之一,是讓所有站台都以固定的PHY速度(6Mbps)作業,一次性避免不同持續時間造成的問題。儘管此選項會浪費許多潛在的網路容量,但覆蓋範圍卻極佳而且容量良好,能容納約15個站台。

 若希望在使用不同PHY速率時也能降低耗電量,AP設計師可選擇另外兩種方法。其中一個方法是變更排程,令AP能可靠地與每個相關站台通訊。此作法會導 致額外的負擔與可靠性的問題。至於另一個方法,則是讓AP利用每個時槽中未使用的時間中傳輸,如此非輪詢站台就不會以Wi-Fi封包填入空置的空中。此作 法可維持同步排程。

 輪詢排程面臨更嚴峻的挑戰,是它必須支援使用不同解碼器間隔時間的各種手機。在此狀況下,通常所建立的輪詢排程,經常發生CBR用戶間的時序衝突。先前所估算的75%最低效率,並未將這種排程衝突列入考量,這也會消耗部份站台睡眠時間預算。

 理想的HCCA排程,也會因偶爾需發送多份下行VoIP訊框至站台而受到干擾。當封包因網際網路或路由佇列行為而成群抵達AP時,就需要多份訊框。除非 所有概念時槽都有足夠的額外時間預算,否則多份下行訊框會延遲CBR排程。若需上行重新傳輸時,也會發生此類排程延遲。為所有站台在每個時槽都保留額外的 時槽時間是一種浪費通道時間的作法,因此排程延遲通常會以延長所有受影響的下行站台之開機時間加以解決。

 通常工程師會把AP組態設定為避免長期猝發或其他可能增加CBR排程延遲的情況發生。此組態對HCCA與EDCA同樣適用。



 EDCA的簡單性

 HCCA輪詢的時序相互依賴性與另一種802.11e作業模式EDCA所應用的省電法時序獨立形成對比。在HCCA中,AP管理所有時序並解決所有排程 衝突。而在EDCA中,所有站台自行管理其時序(因此時序管理為分散式),排程衝突則在空中以通道存取協定解決。

 因此,EDCA站台不像HCCA的站台必須卑微地配合AP之輪詢排程,EDCA站台可使用非排程APSD(Unscheduled APSD;UPSD)的特殊省電模式作業。此模式以站台和AP之間的訊號交握開始,因此AP知道站台將進入睡眠模式,直到站台準備好傳輸VoIP訊框為止 (圖二)。

 站台的喚醒程序可在無排程延遲、輪詢等待或因其他站台或衝突排程而造成的時序效應下發生。站台喚醒並以可使用的最高優先順序參數傳輸VoIP訊框。上行 訊框通常在小於2微秒的耗電量延遲下啟動。然後AP以ACK回應上行訊框。若有必要,站台可重新傳輸並且保持在喚醒狀態,直到AP發送一VoIP訊框或 null指示(表示無可用VoIP封包可傳送)。傳統的AP硬體之AP回應時間小於100?s,而改良後還可能縮短回應時間。

 由於一次性為一站台管理時序,遠比解決HCCA的N-body同步問題簡單得多,因此在現成的AP上新增EDCA功能,也相對容易許多。此外,EDCA如同HCCA機制,在20-ms
CBR的狀況下,可達到大致相同的75%省電效率。使用30-ms CBR間隔時間則可改善效率約83%。

 802.11技術的改良勢必將網路電話、網路電話加資料、視訊加資料、網路電話加視訊加資料等應用帶入主流。儘管802.11標準並未涵蓋所有網路電話 服務的各個層面,但仍有相當重要的標準。特別是HCCA與EDCA都能提供在相同無線通道中支援語音加資料的方法,同時能優化手機電池壽命。 




▲圖二:HCCA之外的選擇為EDCA作業模式,同樣也在802.11e中制定。EDCA可使用非排程自動省電模式(Unscheduled Automatic Power-Save Delivery;UPSD)機制,由站台管理省電輪詢排程而不是由存取點(AP)管理。(本文作者:Greg Chesson/Atheros Communications公司軟體通訊協定部門總監)

 





What is iLBC?

iLBC (internet Low Bitrate Codec) is a FREE speech codec suitable for robust voice communication over IP. The codec is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s with an encoding frame length of 30 ms and 15.20 kbps with an encoding length of 20 ms. The iLBC codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.

Features

  • Bitrate 13.33 kbps (399 bits, packetized in 50 bytes) for the frame size of 30 ms and 15.2 kbps (303 bits, packetized in 38 bytes) for the frame size of 20 ms

  • Basic quality higher then G.729A, high robustness to packet loss

  • Computational complexity in a range of G.729A

  • Royalty Free Codec

iLBC is free

Unlike the other low bitrate codecs, iLBC is available for free and comes with full source code. If you would like to try it out and use it, please see freeware license..

Contributing to the iLBCfreeware.org project

It is easy to contribute to the  iLBCfreeware.org project. All you need to do is find a part of iLBC that you think could be improved or extended and make those changes (carefully and cleanly) and submit that back to the Project, by contacting us via this email or through IETF Audio Video Transport (avt) Working Group mailing list avt@ietf.org. This could be anything from documentation, added functionality (such as Voice Activation Detection), to improvements on the source code. 

 

arrow
arrow
    全站熱搜

    Bluelove1968 發表在 痞客邦 留言(1) 人氣()