GPRS网络的附加业务：VoIP over GPRS(06-100)

　　“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系统的核心控制部分。它包含了一个状态机，用于控制不同模块流和初始化流程。通过人机界面 (MMI)通信，用户能够向对等实体发出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语音帧，然后执行一定类型的流量控制和缓冲。MDI报头删除，传送到RTP堆栈中。

　　5. RTP堆栈添加RTP报头，构建RTP净负荷，然后发送到DFSP。

　　6. DFSP触发UDP/IP堆栈，添加IP报头，并传送到GSM堆栈。

　　7. GSM堆栈控制GPRS信令和调度，通过DSP中的MDI、L1和空中接口将GPRS数据包发送到基站。

　　下行链路的运行方式与上述流程相反，但需要添加抖动控制模块，以调节不可靠的数据包接收时间。

　　设计局限

　　在运行RTOS的低成本平台上实施VoIP over GPRS是非常困难的。智能电话通常运行开放式操作系统，例如Linux、Window CE 或 Symbian OS，而低成本的 i.250 2.5G 平台则在专有RTOS系统上运行，所需的内存容量较低。坦白地说，它的软件开发支持不及那些开放式操作系统。我们可以很容易地在网络上找到开放式操作系统的技术论坛和知识中心，进行技术共享。而互联网上提供的代码样品通常只在开放式操作系统上运行，我们不能将这些代码直接移植到专有RTOS系统上。此外，我们还需要耗费大量精力来重新编写代码，以提高内存使用效率，最大程度地缩短代码，由此增加了编写代码的难度和时间。

　　此外，在 i.250 2.5G平台上的 RTOS系统中，我们使用的多任务机制与开放式操作系统中的多任务机制是完全不同的。Linux 或Window CE使用“线程”概念来处理多个任务，而专有RTOS则使用“任务切换”概念。在多线程环境中，当需要新应用程序时，用户只需创建一个线程，运行该应用程序的代码。不同线程同时运行，各自完成自己的任务，但彼此能够看到对方。所有资源共享机制都由操作系统管理。而在任务切换RTOS机制中，代码开发人员需要牢记一点：有很多其它任务也在同时运行。任务切换只能在功能进入点/退出点或中断时进行。因此，他们必须将代码划分成更小片断，以防止应用程序长期占用资源。在编写嵌入式RTOS系统上的代码时，应该使用特殊的技术。

　　另一个限制是双方传输的延迟。我们知道，GPRS和互联网是为数据传输设计的，数据包传输路径是随意选择的。不能保证数据包能够成功地传送到目的地，并按照发送端的顺序接收。要将收到的数据包重新排列成正确顺序，应在接收端实施抖动控制。实现方式是：将接收到的一些数据包保存在缓冲区中，然后根据它们的时间戳重新排列序。缓冲区容量越大，抖动控制性能就越好。但是，该过程会导致音频路径的延迟，再加上GPRS和互联网的固有延迟，总延迟时间长达几秒。设计者应当优化电话软件中的音频延迟路径，或者实施某些类型的服务质量控制协议，以确保质量。  

　　原型的验证

　　上述的RTOS系统是在i.250 2.5G 平台上实施的。为了进行演示，这里的移动电话的IP地址固定不变。图3介绍了设备设置和连接过程。