VoWLAN：實(shí)現VoIP技術(shù)應用
將語(yǔ)音導入WLAN
2008/10/20
隨著(zhù)WiFi標準的改善、802.11芯片體積不斷減小而功能不斷擴充，無(wú)線(xiàn)區域網(wǎng)絡(luò )語(yǔ)音(VoWLAN)電話(huà)系統的可行性也逐漸提升。雙頻移動(dòng)電話(huà)可使用WLAN連線(xiàn)提供可靠的屋內話(huà)音服務(wù)，而寬帶電話(huà)服務(wù)則通過(guò)WLAN連結筆記電腦。另一方面，架構于WLAN的網(wǎng)絡(luò )電話(huà)手機，由于只需一臺WLAN基地站便能輕易支持多個(gè)手機，與具備低成本優(yōu)勢的傳統無(wú)線(xiàn)電話(huà)機相比毫不遜色。
802.11標準建立了提供可靠、高性能的WiFi網(wǎng)絡(luò )電話(huà)系統所需之基本機制。其中顯著(zhù)的例子為安全性(802.11i/WPA)與QoS(802.11e/Wi-Fi多媒體)。此外，諸如Atheros開(kāi)放程序碼的JumpStartforWireless這類(lèi)單鍵安全設定法，可讓所有使用者即使在手機無(wú)法顯示英文字母與數字的狀況下，仍能快速設定WLAN網(wǎng)絡(luò )電話(huà)手機的組態(tài)。
WLAN網(wǎng)絡(luò )電話(huà)系統中其中一項尚未標準化的項目為輪詢(xún)方法(pollingmethod)。因此本文就現有的兩種輪詢(xún)方法，分別討論其不同的優(yōu)點(diǎn)和缺點(diǎn)，并且特別著(zhù)墨于移動(dòng)裝置中最關(guān)鍵的要素──耗電量。
所有降低耗電量的方法，均必須盡可能讓用戶(hù)裝置使用低功耗的睡眠模式，而802.11芯片必需以睡眠模式中最低的耗電量以支持此作法802.11芯片必須以睡眠模式的最低可能耗電量支持此種作法。例如，Atheros的AR6000移動(dòng)型射頻單芯片(radio-on-a-chipmobile;ROCm)裝置，實(shí)現了極低耗能量的睡眠模式，以及自動(dòng)省電模式(AutomaticPower-Save Delivery;APSD)技術(shù)。ROCm同時(shí)提供絕佳的性能，能啟用高速傳輸以縮短發(fā)送/接收的時(shí)間，而芯片上的嵌入式處理器之自給式驅動(dòng)程序，可分攤處理主機處理器上的經(jīng)常性的網(wǎng)絡(luò )維護操作。通過(guò)以上的做法與其他省電策略，ROCm芯片能改善WLAN操作的耗電效率，效果可比傳統WLAN芯片的高達六倍，因此能改善電池壽命。現時(shí)可實(shí)現各種VoIP應用的新一代802.11裝置，就包含這類(lèi)的芯片。
將語(yǔ)音導入WLAN
802.11WLAN可利用高性能的元件以提供可靠的整體性能，然而，此媒體的特性在處理語(yǔ)音流量時(shí)，仍面對相當嚴苛的挑戰。由于WLAN使用免執照頻譜，因此必須容忍來(lái)自不同外部裝置與其他WLAN的大量干擾。此外，如同其他IP網(wǎng)絡(luò )，WLAN并不支持同步操作(synchronousoperation)。因此，通常無(wú)法在微秒級下做預測。由于VoIP是以固定時(shí)間間隔產(chǎn)生VoIP封包(即訊框)的固定數碼速率(CBR)應用，因此WLAN的CSMA競爭法明顯缺乏中央同步時(shí)序(centralizedsynchronous timing)。
此現象與移動(dòng)電話(huà)系統所實(shí)作的標準電話(huà)機制形成更大的對比。移動(dòng)電話(huà)系統使用授權頻譜與小心規劃的基地站部署，務(wù)求將無(wú)線(xiàn)電干擾減至最低。移動(dòng)電話(huà)系統從電話(huà)到骨干線(xiàn)路都保持同步，于是能掌握微秒層級的時(shí)序而且永不偏離，也因此能預知容量的大小，且容量提供給單一類(lèi)別服務(wù)設計應用:語(yǔ)音。
這些移動(dòng)電話(huà)系統的特性令它能輕易符合ITU-T建議的G.114標準，此標準指定端點(diǎn)對端點(diǎn)延遲預算不得大于150微秒。由于移動(dòng)電話(huà)系統整體的架構采用可決定的方式應用時(shí)脈語(yǔ)音封包，因此不需因為要確保低延遲，而對語(yǔ)音封包以特殊的服務(wù)品質(zhì)(QoS)機制排定優(yōu)先順序。移動(dòng)電話(huà)系統利用現有時(shí)槽、多工與語(yǔ)音服務(wù)管理加入資料服務(wù)。
WLAN則剛好相反，語(yǔ)音服務(wù)必須借助于原本針對資料而設計的功能。WLAN僅能用到端點(diǎn)對端點(diǎn)延遲預算150微秒的一部份，如果兩端都使用WLAN進(jìn)行對話(huà)，那么延遲預算還要更進(jìn)一步縮限。此外，若語(yǔ)音封包必須跨越網(wǎng)際網(wǎng)絡(luò )或忙碌的企業(yè)網(wǎng)絡(luò )，那么封包將無(wú)法避免延遲抵達，有時(shí)甚至無(wú)法抵達。遲到的封包可能成群抵達。
只要使用過(guò)舊式轉碼器在網(wǎng)際網(wǎng)絡(luò )或通用WLAN中以語(yǔ)音通信的人，都會(huì )熟悉這些問(wèn)題。建立高品質(zhì)VoWLAN的作法之一是改變WLAN以符合傳統編碼器的需要。事實(shí)上，無(wú)論是全時(shí)或分時(shí)，
雖然完全同步的網(wǎng)絡(luò )頗具吸引力，但缺乏嚴格同步卻也正是802.11的主要強項。這些年來(lái)，我們可在以太網(wǎng)絡(luò )和ATM網(wǎng)絡(luò )之間的競爭中看到這類(lèi)IP網(wǎng)絡(luò )的優(yōu)點(diǎn)。當可靠而具適應式(夠好)之通道存取對上嚴格時(shí)(完美)序式作法時(shí)，夠令人滿(mǎn)意的作法通常因更具多樣性而比受歡迎。
在設計VoWLAN系統時(shí)避免使用同步作法的另一個(gè)原因，是這些系統并非在封閉環(huán)境下運作。使用WLAN傳輸語(yǔ)音的主要賣(mài)點(diǎn)，是讓雙模移動(dòng)電話(huà)與其他語(yǔ)音裝置能利用現有的WLAN基礎結構。
新一代的解碼器
改善現有802.11基礎結構的方法之一，是利用針對網(wǎng)際網(wǎng)絡(luò )應用而開(kāi)發(fā)的比新語(yǔ)音解碼器。這些解碼器大幅簡(jiǎn)化VoWLAN的設計。效率不彰的網(wǎng)際網(wǎng)絡(luò )電話(huà)環(huán)境，促成解碼器的開(kāi)發(fā)，能以極低位的速度達到良好的語(yǔ)音品質(zhì)。
例如:廣受歡迎的Skype網(wǎng)絡(luò )電話(huà)系統核心之iLBC解碼器，能提供相當于高端ITUG.729解碼器的特性;ITU解碼器只以8kbps，能提供公用電話(huà)般的語(yǔ)音品質(zhì);而來(lái)自GlobalIPSound的iLBC解碼器，所需的位速率稍高-13.3kbps。Global IP Sound稱(chēng)他們的編碼器語(yǔ)音品質(zhì)優(yōu)于PSTN，而且能忍受高達30%的封包損失。網(wǎng)際網(wǎng)絡(luò )工程研究團隊(Internet Engineering Task Force;IETF)已對此解碼器制定標準。CableLabs應用于多媒體終端配接器與媒體閘道的PacketCable影音解碼器規格以被指定其為必要的解碼器。
有了此類(lèi)解碼器，必要的VoWLAN語(yǔ)音品質(zhì)就更易于實(shí)現，而且也能解決網(wǎng)際網(wǎng)絡(luò )所造成的延遲與抖動(dòng)現象，故此特別適合如802.11這種非同步開(kāi)放系統使用。既然解碼器如此靈活，為何還要發(fā)展復雜的時(shí)序與同步方法呢?
挑戰耗電量
盡管現今的解碼器如此靈活，時(shí)序仍然是十分重要的，因為它對耗電量影響重大。移動(dòng)電話(huà)系統的同步特性，使它能輕易而直接地實(shí)現手機睡眠/喚醒排程。手機能在封包之間知道能安全地進(jìn)入睡眠模式。然而，802.11的裝置就永遠不知道何時(shí)可能接收突發(fā)的流量，或因其他理由而必須回應存取點(diǎn)。
雖然移動(dòng)電話(huà)與VoWLAN系統之間有此差異，后者還是必須讓它的電池壽命能媲美移動(dòng)電話(huà)手機。雙模移動(dòng)電話(huà)手機的兩種類(lèi)型功能都使用同一顆電池，因此勢必會(huì )互相比比。
說(shuō)到這里，我們不禁又會(huì )想令WLAN同步操作。若存取點(diǎn)知道手機于何時(shí)進(jìn)入睡眠模式，只在它準備好時(shí)進(jìn)行傳輸，此時(shí)手機就可類(lèi)似移動(dòng)電話(huà)，定期進(jìn)入睡眠模式。存取點(diǎn)不必在VoIP訊框抵達時(shí)立刻傳輸至手機，必要時(shí)可先將這些訊框置于緩沖區。
目前有兩種操作模式，能以足夠的同步在802.11WLAN中實(shí)作良好的省電時(shí)序技術(shù)，因此不需完全同步操作。這些模式包括以‘混合控制功能(HybridControlFunction;HCF)’控制的通道存取(HCF Controlled Channel Access;HCCA)以及增強分散式通道存取(Enhanced Distributed Channel Access;EDCA)。此兩種模式都是IEEE 802.11e標準當中，服務(wù)品質(zhì)(QoS)規定的一環(huán)，而兩者皆可用于發(fā)展中的省電傳訊方法，于存取點(diǎn)和站臺之間以同步固定數碼速率傳輸，而不需對整個(gè)WLAN進(jìn)行同步。
以HCCA進(jìn)行同步
HCCA模式就如同N-body同步機制，由存取點(diǎn)為N個(gè)站臺設定CBR輪詢(xún)排程。盡管典型的802.11系統無(wú)規律性，站臺還是盡可能地按排程同步。將這樣的配置描述為N-body系統是相當合理的，因為對輪詢(xún)排程上任一站的時(shí)序干擾，都會(huì )影響到其他N-1個(gè)站的時(shí)序。
當AP通過(guò)流量規格(TSPEC)接收到來(lái)自站臺的CBR要求時(shí)，HCCA機制便發(fā)揮作用，然后AP與該站進(jìn)行CBR排程的通信。一旦AP接受站臺作為輪詢(xún)的用戶(hù)，此站臺通常會(huì )進(jìn)入睡眠狀態(tài)，直到來(lái)自AP預期的下行輪詢(xún)或輪詢(xún)加VoIP訊框抵達為止(圖一)。在規定的時(shí)間內(架構于OFDM的802.11a/g為9μs，802.11b則會(huì )更久)，站臺以上行VoIP資料(或QoS-NULL)訊框回應。若站臺發(fā)送上行資料，AP就以ACK回應。
要知道此機制的耗電效率，讓我們先考慮站臺需保持喚醒狀態(tài)的時(shí)間比例。HCCA機制如需正確運作，在A(yíng)P的下行輪詢(xún)前，站臺必須從睡眠模式中喚醒。根據硬件設計而定，喚醒的程序約需0.1到1.0微秒。然后站臺必須等到下行輪詢(xún)抵達，而輪詢(xún)可能在站臺預期的抵達時(shí)間到時(shí)仍未抵達。不同的原因如干擾、通道上長(cháng)持續時(shí)間的訊框、AP中內部排程沖突(輪詢(xún)其他站臺)、更高優(yōu)先順序的操作(AP必須傳輸一Beacon)、前一訊框超出預期的交換時(shí)間或是AP與站臺之間的相對時(shí)脈偏移，均會(huì )造成延遲。不過(guò)一旦下行輪詢(xún)抵達，排程就會(huì )變得可預測。根據所選的解碼器與PHY速率，上行/下行訊框交換應在不到1微秒的時(shí)間內發(fā)生。
在HCCA機制中，時(shí)序的不確定性主要來(lái)自CBR輪詢(xún)排程的延遲、失敗后可能的重試以及使用可變PHY速率時(shí)，造成傳輸時(shí)間的變化。根據這些不確定性，站臺喚醒時(shí)間的約為2～5微秒。以20微秒的解碼器周期，此喚醒睡眠比所達成之效率比值為75%以上。HCCA的固定位率排程
存取站可實(shí)作802.11e標準中指定的HCCA操作模式，提供可預測時(shí)間的VoIP輪詢(xún)排程，以在WLAN站臺能以睡眠模式減少耗電量時(shí)進(jìn)行管理。
假設平均通話(huà)時(shí)間約為100秒(以移動(dòng)電話(huà)系統平均而言)而AP同時(shí)提供20通電話(huà)應用，WLAN可能每5秒就必須執行通話(huà)設定/解除。即使在各站臺經(jīng)常進(jìn)入與離開(kāi)輪詢(xún)清單的狀況下，AP仍必須與每個(gè)站臺維持已發(fā)布的CBR排程。因此，AP也必須維持固定時(shí)槽的排程。
這里所說(shuō)的時(shí)槽，為針對特定站臺之輪詢(xún)訊框交換序列而指定的通道時(shí)段。除非所有訊框都使用相同的PHY速率，使每次交換都占用相同的通道時(shí)間量，否則時(shí)槽的持續時(shí)間也會(huì )隨之變化。在時(shí)槽持續時(shí)間變化的情況下，無(wú)法達成效率佳的省電同步。
ZDnet (www.zdnet.com.cn)
相關(guān)鏈接:
亚洲精品网站在线观看不卡无广告,国产a不卡片精品免费观看,欧美亚洲一区二区三区在线,国产一区二区三区日韩
巴青县|
上蔡县|
神农架林区|
阳谷县|
无极县|
柳州市|
崇信县|
赣州市|
康定县|
雷山县|
读书|
滦平县|
东乌珠穆沁旗|
花莲县|
万荣县|
集安市|
天长市|
淅川县|
临朐县|
永泰县|
茌平县|
福州市|
宁武县|
永宁县|
城口县|
齐齐哈尔市|
涡阳县|
青铜峡市|
陆川县|
故城县|
秭归县|
宁强县|
信阳市|
五华县|
乌苏市|
通州区|
阿拉善左旗|
水城县|
中西区|
红桥区|
论坛|
http://444
http://444
http://444
http://444
http://444
http://444