GPRS網(wǎng)絡的附加業(yè)務:VoIP
over GPRS
2008/04/07
導言
近年來,IP語音(VoIP)變得越來越普及。與傳統(tǒng)的匯接解決方案相比,VoIP能夠降低初始部署成本和長途費用。互聯(lián)網(wǎng)工程任務組(IETF)制定的會話發(fā)起協(xié)議(SIP)是使用最廣泛的信令協(xié)議之一,該協(xié)議凝聚了互聯(lián)網(wǎng)行業(yè)的很大努力,適用于互聯(lián)網(wǎng)會議、電話、在線狀態(tài)、事件通知和即時信息處理。過去,人們無法以合理的低成本來實施這些附加功能,但現(xiàn)在使用會話發(fā)起協(xié)議(SIP),只需向對方發(fā)送一些數(shù)據(jù)包,然后建立一個具有所需功能的會話,即可實現(xiàn)這些功能。因而,相對于傳統(tǒng)電話網(wǎng)絡來說,VoIP具備了一些優(yōu)勢。
接下來,人們可能會提出如何連接互聯(lián)網(wǎng)的問題。無線局域網(wǎng)(WLAN)是一種可行方法。無線局域網(wǎng)提供了一定的移動性,用戶能在WLAN接入點的附近區(qū)域內(nèi)移動,從而實現(xiàn)VoIP
over WiFi應用。但是,由于WLAN屬于局域網(wǎng),只限于室內(nèi)應用,一旦用戶離開接入點的覆蓋范圍,VoIP呼叫就會掉線。盡管GSM和VoIP之間可以切換,但這些機制和協(xié)議又增加了額外成本。
WiMax 和 GPRS 是提供移動性的兩種可能解決方案。WiMax是城域網(wǎng),覆蓋范圍長達數(shù)英里。但是,它需要引入802.16e標準,才能支持移動。雖然與GPRS相比,WiMax的數(shù)據(jù)速率快得多,但它目前仍然是一種正在演進的技術,尚未確定最終標準。幾家公司提供的現(xiàn)有芯片組沒有遵循一定的標準,因而無法進行互操作。此外,這種芯片組的成本也比較高。因此,VoIP
over WiMax可能是未來的發(fā)展趨勢,但就目前而言,這種技術還沒有推廣。
相反,GPRS現(xiàn)在已經(jīng)成為最常見的無線數(shù)據(jù)業(yè)務,在幾乎所有GSM網(wǎng)絡上部署。它通過互聯(lián)網(wǎng)協(xié)議(IP)接入互聯(lián)網(wǎng)網(wǎng)關。其吞吐速率高達40KB/秒,用戶可以獲得適當?shù)慕尤胨俾剩軌蚍浅1憷貜娜魏蔚胤竭B接到互聯(lián)網(wǎng)。目前,全球有1/5以上的人口使用GSM技術,截至2006年3月中旬,GSM用戶人數(shù)超過17億,占據(jù)全球手機市場的77%左右。GSM的滲透率如此之高,使得GPRS成為連接互聯(lián)網(wǎng)、提供VoIP業(yè)務的合適物理移動媒介。
早期模擬表明,在GSM網(wǎng)絡中,VoIP over GPRS比電路切換語音的容量更大。在本文中,我們將重點介紹VoIP
over GPRS在運行實時操作系統(tǒng)(RTOS)的低成本GSM移動電話上的實施。我們還將介紹VoIP over GPRS的系統(tǒng)和架構,以及它的設計局限。接下來,我們將介紹在飛思卡爾i.250
2.5G 平臺上實施的概念驗證原型。
概況
IP語音(VoIP)是利用IP網(wǎng)絡來傳送語音信息的一系列新技術。在發(fā)送端,語音首先進行數(shù)字化、壓縮、打包,然后通過IP網(wǎng)絡,將這些數(shù)據(jù)包發(fā)送到目的地。一旦在遠端收到這些語音數(shù)據(jù)包,它們就會被記錄、解壓,然后重新生成語音。由于IP網(wǎng)絡的帶寬遠高于傳統(tǒng)的固話匯接網(wǎng)絡,VoIP的呼叫費用也遠低于傳統(tǒng)呼叫。然而,IP網(wǎng)絡最初設計用于傳輸非實時數(shù)據(jù),因此,對于VoIP而言,如何實時傳輸語音服務,確保語音服務質量就成為一種挑戰(zhàn)。隨著IP技術和寬帶互聯(lián)網(wǎng)業(yè)務的發(fā)展,這些問題已經(jīng)部分地得到解決,VoIP進入實際應用階段。ITU(國際電信聯(lián)盟)和IETF(互聯(lián)網(wǎng)工程任務組)是制定VoIP協(xié)議的兩個主要標準機構,負責確保VoIP的更好質量和互操作性。
與非實時通信不同,VoIP要求對等方在實際語音傳輸之前建立會話。會話的功能包括:位置搜索、功能協(xié)調、呼叫建立和資源預留等。當前,人們單獨使用
H.323 (ITU) 和SIP (IETF)來實施呼叫控制功能。就簡單性而言,SIP優(yōu)于H.323,因此這個VoIP項目選擇了SIP。
圖1顯示了典型的VoIP協(xié)議堆棧。呼叫控制協(xié)議包括兩個選項:H.323 和SIP。H.323只能通過TCP接入IP網(wǎng)絡,而SIP可以同時通過TCP或UDP接入IP網(wǎng)絡。綠色方塊表示支持實時語音會話的媒介引擎和IP協(xié)議。黃色方塊表示用于數(shù)據(jù)包傳輸?shù)腗AC/PHY層。我們的重點將放在
SIP、 RTP、 RTCP、 UDP、 TCP、 IP和 GPRS上。
會話發(fā)起協(xié)議(SIP)是一種信令協(xié)議,用于初始化、管理和終止分組網(wǎng)絡之間的語音和視頻會話。與HTTP 或SMTP類似,SIP也屬于文本編碼,具有很強的可擴展性。SIP能夠進行擴展,以支持各種功能和服務,例如移動服務、與現(xiàn)有電話系統(tǒng)的互操作。SIP網(wǎng)絡包括5類邏輯實體。每類實體都具有特定功能,作為客戶端(發(fā)起請求)或服務器(響應請求)參與SIP通信,或者同時以兩種身份參與通信。這5類實體是:用戶代理、代理服務器、重定向服務器、注冊服務器和背靠背用戶代理(B2BUA)。VoIP電話應該是用戶代理,因為它是端點實體。
注意,在呼叫過程中,SIP不參與語音/視頻編碼/解碼,而只是為語音/視頻談話建立/終止一次會話。一旦建立會話,語音就由適當類型的編解碼器(如GSM
AMR)進行編碼,然后在RTP/UDP/IP中打包。在這里,RTP代表Real Time Protocol(實時協(xié)議),UDP代表User
Datagram Protocol(用戶數(shù)據(jù)報協(xié)議),IP代表Internet Protocol(互聯(lián)網(wǎng)協(xié)議)。如需了解更多信息,請咨詢IETF。
該協(xié)議的公布名稱為RFC3261。所有SIP消息分為3個部分:
所有SIP消息的開頭都是起始行。起始行說明了消息類型(在請求情況下,消息為方法類型,在響應情況下,消息為響應代碼)和協(xié)議版本。報頭字段包含了信息屬性,這些屬性可以提供更多信息。報頭的格式為::。報頭可以橫跨多行。一些SIP報頭,例如Via、Contact、
Route 和 Record Route可能在一條消息中出現(xiàn)多次,或者也可能在一個報頭中提供多個值,以逗號分隔。
消息本體用于描述將要發(fā)起的會話,它可能出現(xiàn)在請求和響應消息中。
一旦在網(wǎng)絡上建立會話,實時語音數(shù)據(jù)就會通過RTP/RTCP、UDP 和 IP發(fā)送。 這些協(xié)議分別在RFC 3550、768和
791 中進行了定義。
RFC 3550指定了為具有實時特征的數(shù)據(jù)(例如互動音頻和視頻)提供端到端傳送服務的實時傳輸協(xié)議(RTP)。這些服務包括:凈負荷類型識別、順序編號、時間戳和傳送監(jiān)控。這些應用通常在UDP的頂層上運行RTP,以利用它的多路復用和校驗和服務。注意,RTP本身不提供任何機制來確保實時傳送,也不提供其它服務質量保證,而是依靠較低層的服務來實現(xiàn)這些目標。它不能保證傳送和防止無序傳送,也不能確保底層是可靠的,能夠按照順序傳送數(shù)據(jù)包。根據(jù)RTP中包含的序列號,接收方能夠重建發(fā)送者的數(shù)據(jù)包順序。
RFC3550還規(guī)定,RTP控制協(xié)議(RTCP)應該監(jiān)控服務質量,并傳輸關于當前會話參與者的信息。
UDP (RFC768) 代表用戶數(shù)據(jù)報協(xié)議(User Datagram Protocol),假定使用互聯(lián)網(wǎng)協(xié)議作為底層協(xié)議。該協(xié)議為應用程序提供了一個將消息傳送到其它程序的流程,只需很少的協(xié)議機制。該協(xié)議是面向事務處理的,不保證提供傳送和復制保護。如果應用需要可靠、有序的數(shù)據(jù)流傳送,應使用傳輸控制協(xié)議(TCP)。
互聯(lián)網(wǎng)協(xié)議(RFC791、IPv4)實施兩種基本功能:尋址和分割。IP使用報頭中的地址,將互聯(lián)網(wǎng)數(shù)據(jù)報傳送到目的地。選擇傳輸路徑的過程稱為路由。當需要通過“小數(shù)據(jù)包”網(wǎng)絡傳輸時,它還使用報頭中的字段,對互聯(lián)網(wǎng)數(shù)據(jù)報進行分割和重組。此外,這些IP模塊(特別是網(wǎng)關中的模塊)擁有執(zhí)行路由決策和其它功能的程序。
互聯(lián)網(wǎng)協(xié)議將互聯(lián)網(wǎng)數(shù)據(jù)報當作一個獨立實體處理,與其它任何互聯(lián)網(wǎng)數(shù)據(jù)報無關。沒有連接或邏輯電路。在提供服務時,它使用四種主要機制:服務類型、生存時間、選項、報頭校驗和。
“MOS”列為“Mean Opinion Score”(主觀平均得分),用于度量語音質量。得分越高,表明質量越好。
本項目的目的是在飛思卡爾i.250 2.5G 平臺上增加VoIP over GPRS功能。該平臺上的基帶處理器Neptune
LTE 帶有雙核,ARM7運行VRTXmc OS 和 16 位Onyx DSP。時鐘頻率分別為52MHz 和130MHz。與通常在
200MHz頻率下運行的其它應用處理器相比, Neptune LTE 的處理功率是一個限制因素,影響我們對支持的編解碼器的選擇。在本項目中,我們實施的GSM-AMR主要用于演示用途,因為現(xiàn)有平臺支持AMR
編解碼器,并且已經(jīng)采用了DSP代碼。
系統(tǒng)架構
圖2顯示了飛思卡爾 i.250 2.5G 平臺上的VoIP over GPRS模塊圖。VoIP 應用是整個VoIP
over GPRS系統(tǒng)的核心控制部分。它包含了一個狀態(tài)機,用于控制不同模塊流和初始化流程。通過人機界面 (MMI)通信,用戶能夠向對等實體發(fā)出VoIP呼叫。
網(wǎng)絡傳輸服務提供商目前對用戶是透明的。
網(wǎng)絡傳輸引擎包括:RTP/RTCP堆棧、SIP堆棧、抖動控制堆棧等。SIP負責包括呼叫建立程序的呼叫控制協(xié)議。RTP/RTCP堆棧是實時流協(xié)議和實時流控制協(xié)議,通過網(wǎng)絡傳送實時數(shù)據(jù)。
抖動控制堆棧負責處理網(wǎng)絡延遲,確保接收數(shù)據(jù)包的正確順序。
多媒體引擎(MME)經(jīng)過修改,用于管理VoIP的全雙工語音信道。
網(wǎng)絡傳輸?shù)臄?shù)據(jù)流通過數(shù)據(jù)流服務提供商(DFSP)傳輸?shù)紾SM堆棧。在該堆棧中,子網(wǎng)相關收斂協(xié)議(SNDCP)處理分組交換數(shù)據(jù)。
藍色方塊表示現(xiàn)有平臺的新應用,包括網(wǎng)絡傳輸協(xié)議、核心控制VoIP應用。由于支持GPRS功能的每部移動電話都應該帶有TCP/UDP
IP堆棧,因而只需重復使用現(xiàn)有堆棧,而無需重新實施。注意,所有新模塊都是軟件。不需要其它硬件。
在i.250 2.5G平臺中,基帶處理器帶有雙核,一個為ARM7 MCU,另一個為Onyx-lite DSP。GPRS
L1活動和語音編解碼器計算工作都在DSP中完成,這有助于減少MCU的MIPS要求,在一個運行ARM7的平臺上實現(xiàn) VoIP
over GPRS功能。與此相反,一些現(xiàn)有解決方案通常需要至少一個ARM9 ,甚至ARM11 MCU。
MDI是MCU DSP接口,可以實現(xiàn)雙方之間的通信。
一旦與對方建立了呼叫,上行鏈路的運行方式如下:
- Mic 檢測到語音,并將其轉換成電信號。
- DSP對音頻信號進行編碼,轉換為AMR格式。
- DSP將編碼后的ARM語音幀放入MDI音頻隊列中。
- MME從MDI音頻隊列提取編碼的ARM語音幀,然后執(zhí)行一定類型的流量控制和緩沖。MDI報頭刪除,傳送到RTP堆棧中。
- RTP堆棧添加RTP報頭,構建RTP凈負荷,然后發(fā)送到DFSP。
- DFSP觸發(fā)UDP/IP堆棧,添加IP報頭,并傳送到GSM堆棧。
- GSM堆棧控制GPRS信令和調度,通過DSP中的MDI、L1和空中接口將GPRS數(shù)據(jù)包發(fā)送到基站。
下行鏈路的運行方式與上述流程相反,但需要添加抖動控制模塊,以調節(jié)不可靠的數(shù)據(jù)包接收時間。
設計局限
在運行RTOS的低成本平臺上實施VoIP over GPRS是非常困難的。智能電話通常運行開放式操作系統(tǒng),例如Linux、Window
CE 或 Symbian OS,而低成本的 i.250 2.5G 平臺則在專有RTOS系統(tǒng)上運行,所需的內(nèi)存容量較低。坦白地說,它的軟件開發(fā)支持不及那些開放式操作系統(tǒng)。我們可以很容易地在網(wǎng)絡上找到開放式操作系統(tǒng)的技術論壇和知識中心,進行技術共享。而互聯(lián)網(wǎng)上提供的代碼樣品通常只在開放式操作系統(tǒng)上運行,我們不能將這些代碼直接移植到專有RTOS系統(tǒng)上。此外,我們還需要耗費大量精力來重新編寫代碼,以提高內(nèi)存使用效率,最大程度地縮短代碼,由此增加了編寫代碼的難度和時間。
此外,在 i.250 2.5G平臺上的 RTOS系統(tǒng)中,我們使用的多任務機制與開放式操作系統(tǒng)中的多任務機制是完全不同的。Linux
或Window CE使用“線程”概念來處理多個任務,而專有RTOS則使用“任務切換”概念。在多線程環(huán)境中,當需要新應用程序時,用戶只需創(chuàng)建一個線程,運行該應用程序的代碼。不同線程同時運行,各自完成自己的任務,但彼此能夠看到對方。所有資源共享機制都由操作系統(tǒng)管理。而在任務切換RTOS機制中,代碼開發(fā)人員需要牢記一點:有很多其它任務也在同時運行。任務切換只能在功能進入點/退出點或中斷時進行。因此,他們必須將代碼劃分成更小片斷,以防止應用程序長期占用資源。在編寫嵌入式RTOS系統(tǒng)上的代碼時,應該使用特殊的技術。
另一個限制是雙方傳輸?shù)难舆t。我們知道,GPRS和互聯(lián)網(wǎng)是為數(shù)據(jù)傳輸設計的,數(shù)據(jù)包傳輸路徑是隨意選擇的。不能保證數(shù)據(jù)包能夠成功地傳送到目的地,并按照發(fā)送端的順序接收。要將收到的數(shù)據(jù)包重新排列成正確順序,應在接收端實施抖動控制。實現(xiàn)方式是:將接收到的一些數(shù)據(jù)包保存在緩沖區(qū)中,然后根據(jù)它們的時間戳重新排列序。緩沖區(qū)容量越大,抖動控制性能就越好。但是,該過程會導致音頻路徑的延遲,再加上GPRS和互聯(lián)網(wǎng)的固有延遲,總延遲時間長達幾秒。設計者應當優(yōu)化電話軟件中的音頻延遲路徑,或者實施某些類型的服務質量控制協(xié)議,以確保質量。
原型的驗證
上述的RTOS系統(tǒng)是在i.250 2.5G 平臺上實施的。為了進行演示,這里的移動電話的IP地址固定不變。圖3介紹了設備設置和連接過程。
首先,在接通電源后,用戶只需按下“**”就能注冊登錄到代理服務器。代理服務器維持一個數(shù)據(jù)庫,列出所有用戶名和內(nèi)容信息。只需通過GPRS網(wǎng)絡將SIP注冊消息發(fā)送到服務器,即可完成注冊。同時,電話軟件激活GPRS連接,獲取GPRS網(wǎng)絡分配的IP地址,并且打開傳輸和接收數(shù)據(jù)的邏輯路徑。如果不激活GPRS連接,DUT身份對公用網(wǎng)絡就是不可知的,因而不能接到來電。代理服務器只存在于設置過程。
由于代理服務器被用作中間代理,主叫人應向代理服務器IP發(fā)送呼叫請求。然后,服務器將查詢數(shù)據(jù)庫,獲得被叫方位置,再將請求轉發(fā)到被叫方。本演示利用兩個Agilent
8960 ,將GRPS實驗室應用測試集用作媒介,將 i.250 2.5G 開發(fā)板卡 (ADS板卡)連接到互聯(lián)網(wǎng)。ADS板卡在接通電源時,注冊登錄到GPRS網(wǎng)絡,測試集然后通過路由器連接到互聯(lián)網(wǎng)。測試集充當連接到GPRS的DUT的橋梁,讓它們接入互聯(lián)網(wǎng)。一旦GPRS上下文激活,測試集將為ADS分配一個固定IP地址。此外,在PC上運行的代理服務器也連接到同一個路由器。通過這種安排,確保三個實體都能在同一網(wǎng)段內(nèi)運行。這樣就能對同一個網(wǎng)段內(nèi)的分組流量進行監(jiān)控,用于開發(fā)目的。
按照圖3的設置過程,2個i.250 2.5G 開發(fā)板之間能夠成功建立VoIP呼叫連接。圖4對詳細的呼叫流程進行了介紹。
結語
VoIP變得日益普及,通常與以太網(wǎng)或WLAN集成。在本文中,我們介紹了GPRS的使用和優(yōu)勢,并將其與其它無線技術進行了比較。經(jīng)濟高效的VoIP
over GPRS 解決方案的設計會受到大量限制,包括MIPS和RTOS的局限。但是,通過VoIP over GPRS
解決方案的詳細設計,我們在低成本的飛思卡爾 i.250 2.5G平臺上建立了概念驗證原型,并在實驗室進行了驗證。
電子產(chǎn)品世界
相關鏈接:
通辽市|
静海县|
博兴县|
东台市|
清徐县|
专栏|
广安市|
宁国市|
德保县|
宁城县|
兴城市|
塔河县|
石河子市|
无为县|
盐源县|
七台河市|
车致|
资溪县|
莎车县|
财经|
桐乡市|
本溪市|
方山县|
桦南县|
彭水|
云林县|
天祝|
博湖县|
南汇区|
自治县|
道真|
韶山市|
乌审旗|
车险|
乌恰县|
汝南县|
虎林市|
宜州市|
北宁市|
西乡县|
宁强县|