“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主要用于演示用途，因為現有平臺支持AMR 編解碼器，并且已經采用了DSP代碼。

　　系統架構

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

　　網絡傳輸服務提供商目前對用戶是透明的。

　　網絡傳輸引擎包括：RTP/RTCP堆棧、SIP堆棧、抖動控制堆棧等。SIP負責包括呼叫建立程序的呼叫控制協議。RTP/RTCP堆棧是實時流協議和實時流控制協議，通過網絡傳送實時數據。

　　抖動控制堆棧負責處理網絡延遲，確保接收數據包的正確順序。

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

　　網絡傳輸的數據流通過數據流服務提供商(DFSP)傳輸到GSM堆棧。在該堆棧中，子網相關收斂協議(SNDCP)處理分組交換數據。

　　藍色方塊表示現有平臺的新應用，包括網絡傳輸協議、核心控制VoIP應用。由于支持GPRS功能的每部移動電話都應該帶有TCP/UDP IP堆棧，因而只需重復使用現有堆棧，而無需重新實施。注意，所有新模塊都是軟件。不需要其它硬件。

　　在i.250 2.5G平臺中，基帶處理器帶有雙核，一個為ARM7 MCU，另一個為Onyx-lite DSP。GPRS L1活動和語音編解碼器計算工作都在DSP中完成，這有助于減少MCU的MIPS要求，在一個運行ARM7的平臺上實現 VoIP over GPRS功能。與此相反，一些現有解決方案通常需要至少一個ARM9 ，甚至ARM11 MCU。 

　　MDI是MCU DSP接口，可以實現雙方之間的通信。

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

　　1. Mic 檢測到語音，并將其轉換成電信號。

　　2. DSP對音頻信號進行編碼，轉換為AMR格式。

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

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

　　5. RTP堆棧添加RTP報頭，構建RTP凈負荷，然后發(fā)送到DFSP。

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

　　7. GSM堆棧控制GPRS信令和調度，通過DSP中的MDI、L1和空中接口將GPRS數據包發(fā)送到基站。

　　下行鏈路的運行方式與上述流程相反，但需要添加抖動控制模塊，以調節(jié)不可靠的數據包接收時間。

　　設計局限

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

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

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

　　原型的驗證

　　上述的RTOS系統是在i.250 2.5G 平臺上實施的。為了進行演示，這里的移動電話的IP地址固定不變。圖3介紹了設備設置和連接過程。