“MOS”列為“Mean Opinion Score”(主觀平均得分)，用于度量語音質(zhì)量。得分越高，表明質(zhì)量越好。

　　本項(xiàng)目的目的是在飛思卡爾i.250 2.5G 平臺(tái)上增加VoIP over GPRS功能。該平臺(tái)上的基帶處理器Neptune LTE 帶有雙核，ARM7運(yùn)行VRTXmc OS 和 16 位Onyx DSP。時(shí)鐘頻率分別為52MHz 和130MHz。與通常在 200MHz頻率下運(yùn)行的其它應(yīng)用處理器相比， Neptune LTE 的處理功率是一個(gè)限制因素，影響我們對支持的編解碼器的選擇。在本項(xiàng)目中，我們實(shí)施的GSM-AMR主要用于演示用途，因?yàn)楝F(xiàn)有平臺(tái)支持AMR 編解碼器，并且已經(jīng)采用了DSP代碼。

　　系統(tǒng)架構(gòu)

　　圖2顯示了飛思卡爾 i.250 2.5G 平臺(tái)上的VoIP over GPRS模塊圖。VoIP 應(yīng)用是整個(gè)VoIP over GPRS系統(tǒng)的核心控制部分。它包含了一個(gè)狀態(tài)機(jī)，用于控制不同模塊流和初始化流程。通過人機(jī)界面 (MMI)通信，用戶能夠向?qū)Φ葘?shí)體發(fā)出VoIP呼叫。

　　網(wǎng)絡(luò)傳輸服務(wù)提供商目前對用戶是透明的。

　　網(wǎng)絡(luò)傳輸引擎包括：RTP/RTCP堆棧、SIP堆棧、抖動(dòng)控制堆棧等。SIP負(fù)責(zé)包括呼叫建立程序的呼叫控制協(xié)議。RTP/RTCP堆棧是實(shí)時(shí)流協(xié)議和實(shí)時(shí)流控制協(xié)議，通過網(wǎng)絡(luò)傳送實(shí)時(shí)數(shù)據(jù)。

　　抖動(dòng)控制堆棧負(fù)責(zé)處理網(wǎng)絡(luò)延遲，確保接收數(shù)據(jù)包的正確順序。

　　多媒體引擎(MME)經(jīng)過修改，用于管理VoIP的全雙工語音信道。

　　網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)流通過數(shù)據(jù)流服務(wù)提供商(DFSP)傳輸?shù)紾SM堆棧。在該堆棧中，子網(wǎng)相關(guān)收斂協(xié)議(SNDCP)處理分組交換數(shù)據(jù)。

　　藍(lán)色方塊表示現(xiàn)有平臺(tái)的新應(yīng)用，包括網(wǎng)絡(luò)傳輸協(xié)議、核心控制VoIP應(yīng)用。由于支持GPRS功能的每部移動(dòng)電話都應(yīng)該帶有TCP/UDP IP堆棧，因而只需重復(fù)使用現(xiàn)有堆棧，而無需重新實(shí)施。注意，所有新模塊都是軟件。不需要其它硬件。

　　在i.250 2.5G平臺(tái)中，基帶處理器帶有雙核，一個(gè)為ARM7 MCU，另一個(gè)為Onyx-lite DSP。GPRS L1活動(dòng)和語音編解碼器計(jì)算工作都在DSP中完成，這有助于減少M(fèi)CU的MIPS要求，在一個(gè)運(yùn)行ARM7的平臺(tái)上實(shí)現(xiàn) VoIP over GPRS功能。與此相反，一些現(xiàn)有解決方案通常需要至少一個(gè)ARM9 ，甚至ARM11 MCU。 

　　MDI是MCU DSP接口，可以實(shí)現(xiàn)雙方之間的通信。

　　一旦與對方建立了呼叫，上行鏈路的運(yùn)行方式如下：

　　1. Mic 檢測到語音，并將其轉(zhuǎn)換成電信號(hào)。

　　2. DSP對音頻信號(hào)進(jìn)行編碼，轉(zhuǎn)換為AMR格式。

　　3. DSP將編碼后的ARM語音幀放入MDI音頻隊(duì)列中。

　　4. MME從MDI音頻隊(duì)列提取編碼的ARM語音幀，然后執(zhí)行一定類型的流量控制和緩沖。MDI報(bào)頭刪除，傳送到RTP堆棧中。

　　5. RTP堆棧添加RTP報(bào)頭，構(gòu)建RTP凈負(fù)荷，然后發(fā)送到DFSP。

　　6. DFSP觸發(fā)UDP/IP堆棧，添加IP報(bào)頭，并傳送到GSM堆棧。

　　7. GSM堆?？刂艷PRS信令和調(diào)度，通過DSP中的MDI、L1和空中接口將GPRS數(shù)據(jù)包發(fā)送到基站。

　　下行鏈路的運(yùn)行方式與上述流程相反，但需要添加抖動(dòng)控制模塊，以調(diào)節(jié)不可靠的數(shù)據(jù)包接收時(shí)間。

　　設(shè)計(jì)局限

　　在運(yùn)行RTOS的低成本平臺(tái)上實(shí)施VoIP over GPRS是非常困難的。智能電話通常運(yùn)行開放式操作系統(tǒng)，例如Linux、Window CE 或 Symbian OS，而低成本的 i.250 2.5G 平臺(tái)則在專有RTOS系統(tǒng)上運(yùn)行，所需的內(nèi)存容量較低。坦白地說，它的軟件開發(fā)支持不及那些開放式操作系統(tǒng)。我們可以很容易地在網(wǎng)絡(luò)上找到開放式操作系統(tǒng)的技術(shù)論壇和知識(shí)中心，進(jìn)行技術(shù)共享。而互聯(lián)網(wǎng)上提供的代碼樣品通常只在開放式操作系統(tǒng)上運(yùn)行，我們不能將這些代碼直接移植到專有RTOS系統(tǒng)上。此外，我們還需要耗費(fèi)大量精力來重新編寫代碼，以提高內(nèi)存使用效率，最大程度地縮短代碼，由此增加了編寫代碼的難度和時(shí)間。

　　此外，在 i.250 2.5G平臺(tái)上的 RTOS系統(tǒng)中，我們使用的多任務(wù)機(jī)制與開放式操作系統(tǒng)中的多任務(wù)機(jī)制是完全不同的。Linux 或Window CE使用“線程”概念來處理多個(gè)任務(wù)，而專有RTOS則使用“任務(wù)切換”概念。在多線程環(huán)境中，當(dāng)需要新應(yīng)用程序時(shí)，用戶只需創(chuàng)建一個(gè)線程，運(yùn)行該應(yīng)用程序的代碼。不同線程同時(shí)運(yùn)行，各自完成自己的任務(wù)，但彼此能夠看到對方。所有資源共享機(jī)制都由操作系統(tǒng)管理。而在任務(wù)切換RTOS機(jī)制中，代碼開發(fā)人員需要牢記一點(diǎn)：有很多其它任務(wù)也在同時(shí)運(yùn)行。任務(wù)切換只能在功能進(jìn)入點(diǎn)/退出點(diǎn)或中斷時(shí)進(jìn)行。因此，他們必須將代碼劃分成更小片斷，以防止應(yīng)用程序長期占用資源。在編寫嵌入式RTOS系統(tǒng)上的代碼時(shí)，應(yīng)該使用特殊的技術(shù)。

　　另一個(gè)限制是雙方傳輸?shù)难舆t。我們知道，GPRS和互聯(lián)網(wǎng)是為數(shù)據(jù)傳輸設(shè)計(jì)的，數(shù)據(jù)包傳輸路徑是隨意選擇的。不能保證數(shù)據(jù)包能夠成功地傳送到目的地，并按照發(fā)送端的順序接收。要將收到的數(shù)據(jù)包重新排列成正確順序，應(yīng)在接收端實(shí)施抖動(dòng)控制。實(shí)現(xiàn)方式是：將接收到的一些數(shù)據(jù)包保存在緩沖區(qū)中，然后根據(jù)它們的時(shí)間戳重新排列序。緩沖區(qū)容量越大，抖動(dòng)控制性能就越好。但是，該過程會(huì)導(dǎo)致音頻路徑的延遲，再加上GPRS和互聯(lián)網(wǎng)的固有延遲，總延遲時(shí)間長達(dá)幾秒。設(shè)計(jì)者應(yīng)當(dāng)優(yōu)化電話軟件中的音頻延遲路徑，或者實(shí)施某些類型的服務(wù)質(zhì)量控制協(xié)議，以確保質(zhì)量。  

　　原型的驗(yàn)證

　　上述的RTOS系統(tǒng)是在i.250 2.5G 平臺(tái)上實(shí)施的。為了進(jìn)行演示，這里的移動(dòng)電話的IP地址固定不變。圖3介紹了設(shè)備設(shè)置和連接過程。