gsm移动通信终端之wap研究与实现

《gsm移动通信终端之wap研究与实现》由会员分享，可在线阅读，更多相关《gsm移动通信终端之wap研究与实现（72页珍藏版）》请在金锄头文库上搜索。

1、华中科技大学 硕士学位论文 GSM移动通信终端之WAP研究与实现 姓名：向伟 申请学位级别：硕士 专业：通信与信息系统 指导教师：韩涛 20070207 I 摘摘 要要 无线应用协议（Wireless Application Protocol，WAP）是 WAP 论坛经过不断努 力得到的成果，它提供了一个技术规范，以便开发出适用于各种无线通信网络的应 用程序和业务。本课题的任务就是在 TI 的移动终端平台上实现 WAP 的基本应用， 并解决 PC 仿真开发环境中，无法对 WAP 网络功能进行模拟的难题。 本文首先对 WAP 的协议体系和 TI 移动终端平台的软硬件体系架构进行了详细 的介绍。接

2、着分析了 TI 平台中协议栈的实现方法，在此基础上着重阐述了 WAP 应 用框架中最为关键的“中间层模块”的设计思路及方法。此中间层抽象了平台的特 性， 隔离上层人机接口 （MMI） 和下层系统间的直接交互， 从而便于 WAP 模块 MMI 的开发；同时也具有将函数调用进行远程传递的能力，使运行于 PC 的仿真程序直接 与目标平台进行交互成为可能。 接下来对具体 WAP 模块中间层的实现进行了详细的叙述。 最后通过在目标机和 PC 仿真环境中的实现和测试，验证了此 WAP 应用框架的可行性，实现了 WAP 浏 览应用，并解决了在 PC 仿真平台下对 WAP 网络功能进行仿真的难题。 此外本文提

3、出的“中间层”的设计与实现，使 MMI 的可移植性大大提高。这对 于其他应用平台的软件框架的设计也提供了一个很好的思路。 关键词：关键词：无线应用协议 协议栈 个人电脑仿真 中间层 人机接口 II Abstract The Wireless Application Protocol (WAP) is a result of continuous work to define an industry wide specification for developing applications that operate over wireless communication networks. T

4、he target of this project is to implement the application of WAP on the TI mobile terminal platform, and settle the difficulty that WAP network function can not be simulated in PC simulator development environment. Firstly, WAP protocol, the hardware if size 0; True else False 图图 4-5 执行控制图执行控制图 图 4-

5、5 显示了 MICc_wantsToRun 和 MICc_run 的配合使用使内部消息队列中的 消息得到处理。 ? 用户代理用户代理 在浏览器能够开始使用 Obigo MIC 之前，它必须先在 Obigo MIC 中启动一个用 户代理。每个用户代理实例都有其自己的一套配置变量。启动一个用户代理的函数 原型为： void MICc_startUserAgent (int objectId, int uaType) 参数说明 26 objectId ：用户代理 ID uaType：用户代理的类型 类型如表 41 所示： 表表 41 用户代理类型常量用户代理类型常量 常量常量 描述描述 UA_TYP

6、E_BROWSER 普通浏览功能 UA_TYPE_HTTP_CLIENT 内容处理功能 UA_TYPE_PUSH PUSH应用处理功能 UA_TYPE_XML_PARSER XML解释处理功能 配合它，有一个关闭用户代理的函数，原型为： void MICc_terminateUserAgent (int objectId, int uaType) ? 数据连接管理数据连接管理 为了管理不用的承载任务，提出了一个叫做“数据通道”的概念并定义了一套 函数。这个通道能够让一个用户代理使用多个现成的承载，而且可以使一个承载提 供多个接入点。如图 4-6 所示： 对象一 无线标记语言 用户代理 对象一

7、无线标记语言 用户代理 对象三 无线电话应用 用户代理 对象三 无线电话应用 用户代理 对象二 无线电话应用 用户代理 对象二 无线电话应用 用户代理 蓝牙设备蓝牙设备GPRS短消息短消息电路交换电路交换蓝牙设备蓝牙设备 DC1DC2DC1DC3DC2DC1数据通道数据通道 DC：数据通道 GPRS：通用无线分组业务 图图 4-6 数据管道连接数据管道连接 “数据通道”包含了一个特定连接的信息和特征，一个典型的数据通道存储的 27 信息包括使用的承载类型，使用的网关，网关的用户名和密码，初始化的连接状态， 本地端口号以及其他相关信息。 定义的函数有： void MICa_requestConn

8、ection (int objectId) 当一个用户代理作出请求且没有已定义的数据通道来服务请求时，Obigo MIC 会调用此函数请求建立一个数据通道。 void MICc_requestConnectionDone (int objectId, int success) 当通道被建立后，WAP 应用程序会调用此函数作为 MICa_requestConnection 的 回应，接着用户代理会继续发送数据请求。 4.1.4.2. LE API LE(Layout Engine)是浏览器的标记化语言的渲染引擎。LE 工作在解释/显示模块 和浏览器之间。它的主要功能是计算显示元素在文档中的位置并

9、且告诉浏览器将他 们绘制在什么地方。为了做到这一点，LE 要询问浏览器的各种尺寸信息，并根据需 要显示的文档内容和风格来最后确定。这使浏览器能够选择文档元素该如何显示。 4.1.4.3. MMI API MMI API 提供最为基本的用户界面，对于已经用较完善图形 API，能够提供高 等级的 GUI 元素的目标设备来说，MMI API 会非常的“薄”，相反对于低端设备 MMI API 较为“厚”。 需要注意的是：如果上面的提到的 LE API 已经被启用，那么 MMI API 中的主 要 API 在编辑阶段都会被排除， 因为 LE API 会实现大部分 MMI API 的功能。 LE API

10、和 MMI API 之间的关系可以被看成高层API(LE API)同底层API(MMI API)之间的关 系 4.1.5 Obigo MIC 的使用的使用 Obigo MIC 模块，它完成 WAP 协议栈的具体功能，在 riviera 系统中，MMI 和 28 ObigoMIC 不是同一个任务，为了便于之间的交互，我们对 riviera 的任务间通信接口 进行了封装，提供了一个 MMI 于 WAP 协议栈之间的通信接口，主要包括如下几个 接口函数： 1) mmi_coder，MMI 向 WAP 发送编码消息 2) mmi_decode，MMI 接收解码 WAP 上发的消息 3) wap_cod

11、er，WAP 向 MMI 发送编码消息 4) wap_decoder，WAP 接收解码 MMI 发送的消息 通过这些接口来进行 MMI 同 WAP 协议栈之间的交互。 4.2 中间层框架设计中间层框架设计 由于和 TI 方案绑定的 Condat 公司提供的 MMI 软件框架的缺陷，导致 MMI 与 底层系统关系过于紧密，导致层次模糊。并且 PC 的仿真程序无法直接与目标平台进 行交互，使基于网络的应用，比如：WAP，SMS，SIM 卡操作等，无法进行在线的 调试， 给开发工作带来很多的不便。 于是在 MMI 层和底层之间添加一个中间层模块， 如图 4-7 所示： 人机界面人机界面 中间层中间层

12、 底层程序及系统底层程序及系统 图图 4-7 新的应用框架新的应用框架 4.2.1 中间层概述中间层概述 中间层有点类似中间件293031的概念，我们这里的中间层用于抽象平台的特性， 29 隔离上层 MMI 和下层系统间的直接交互。以方便 MMI 系统在不同平台间的移植。 同时，在制订中间层接口的工作中，也有助于并加强应用程序员对平台服务的理解。 中间层也提供将函数调用进行远程传递的能力， 使运行于 PC 的仿真程序直接与 目标平台进行交互成为可能。 从技术本质上来讲，中间层无非是进行间接的函数调用。但中间层的采用，会 对系统的开发过程产生较大的影响。会将开发应用功能前，先进行接口设计变成必

13、然的工作，而非制度上的规定。使上/下层间的访问接口设计，变得更加慎重。从而 规范和强化应用模块的设计工作。 4.2.2 中间层基本原理中间层基本原理 4.2.2.1. 本地调用本地调用 中间层的本地调用原理较简单，仅仅是进行了间接地函数调用。 中间层的定义者定义接口函数的名称和参数原型，然后通过中间层生成器自动 产生该接口的入口函数的声明和实现以及实现函数的声明。 如 GetTickCount 函数，中间层可能为其生成如下入口函数： EILResult TMGetTickCount(int *count) return TMGetTickCount_Imp(count); 同时生成如下实现函数

14、的声明。 EILResult TMGetTickCount_Imp(int *count)； 入口函数是该接口的入口，供接口的使用者调用。 实现函数必须由接口的实现者实现。实现者可以在不同的平台上以不同的方式 来实现该接口。 如在 Win32 平台，用户可以直接调用 Win32 API 中的 GetTickCount 函数。 30 EILResult TMGetTickCount_Imp(int *count) count = GetTickCount(); return IL_OK; 而在 TI 的 Calypso 平台， 系统提供的 rvf_get_tick_count 函数并不以毫秒为单

15、位。 则 GetTickCount 函数可以如下实现： EILResult TMGetTickCount_Imp(int *count) count = rvf_get_tick_count() * 5; return IL_OK; 这样，当 MMI 层应用程序在运行于不同平台时，仍然可以使用统一原型、统一 行为的 GetTickCount 函数。 4.2.2.2. 远程调用远程调用 ? 远程调用的过程远程调用的过程 远程调用的过程较为复杂。当开启远程调用功能后，中间层的远程调用机制将 函数的调用重定向到另一个平台，实现跨平台的远程调用。在本项目中，中间层具 体提供了 PC 仿真平台和 TI

16、的目标平台之间的双向远程调用功能。 中间层远程调用的基本过程如图 4-8 所示： 31 入口函数 远程调用框架 （发起方） 远程调用框架 （接收方） 实现函数 参数打包函数结果解包函数结果打包函数参数解包函数 发起远程调用 参数打包 （return） 发送数据帧 解包 (return) (return) 返回值和参数打包 (return) 发送数据帧 等待返回数据 解包 (return) (return) 返回给调用者 发起调用 调用实现函数 图图 4-8 远程调用过程远程调用过程 详细步骤为： 1) 当调用者发起一个远程调用时，远程调用机制首先会对需要传递给被调 用者的参数（即具有“in”方向的参数）打包成适于网络传递数据帧。 32 然后将数据帧发送给被调用方。