GPRS网络的附加业务：VoIP over GPRS

IPS要求，在一个运行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介绍了设备设置和连接过程。

　　首先，在接通电源后，用户只需按下“**”就能注册登录到代理服务器。代理服务器维持一个数据库，列出所有用户名和内容信息。只需通过GPRS网络将SIP注册消息发送到服务器，即可完成注册。同时，电话软件激活GPRS连接，获取GPRS网络分配的IP地址，并且打开传输和接收数据的逻辑路径。如果不激活GPRS连接，DUT身份对公用网络就是不可知的，因而不能接到来电。代理服务器只存在于设置过程。

　　由于代理服务器被用作中间代理，主叫人应向代理服务器IP发送呼叫请求。然后，服务器将查询数据库，获得被叫方位置，再将请求转发到被叫方。本演示利用两个Agilent 8960 ，将GRPS实验室应用测试集用作媒介，将 i.250 2.5G 开发板卡 (ADS板卡)连接到互联网。ADS板卡在接通电源时，注册登录到GPRS网络，测试集然后通过路由器连接到互联网。测试集充当连接到GPRS的DUT的桥梁，让它们接入互联网。一旦GPRS上下文激活，测试集将为ADS分配一个固定IP地址。此外，在PC上运行的代理服务器也连接到同一个路由器。通过这种安排，确保三个实体都能在同一网段内运行。这样就能对同一个网段内的分组流量进行监控，用于开发目的。 

　　按照图3的设置过程，2个i.250 2.5G 开发板之间能够成功建立VoIP呼叫连接。图4对详细的呼叫流程进行了介绍。