移动设备管理(MDM)与OMA(OTA)DM协议向导(二)——WAP协议(2)

上接“移动设备管理(MDM)与OMA(OTA)DM协议向导(二)——WAP协议(1)”

8.WAP服务器与WAP网关
通过WAP服务器可以直接向移动终端提供WAP应用服务，许多人认为只有WAP Server才能提供WAP的内容，这不正确，WAP内容可以由任何普通的Web Server提供，但这个服务器必须包含一个WAP网关，因此可以跳过安装在移动运营商那边的第三方网关，并且主机上的应用程序对加密数据流有完全的控制能力。

9.WAP的数据传输（WAP PUSH）
WAP的数据传输使用WAP PUSH，WAP推送（PUSH）技术是一种建立在客户服务器上的机制，就是由服务器主动将信息发往客户端的技术。同传统的拉（PULL）技术相比，最主要的区别在于推送（PUSH）技术是由服务器主动向客户机发送信息，而拉（PULL）技术则是由客户机主动请求信息。PUSH技术的优势在于信息的主动性和及时性。
　PUSH技术在Internet中没能取得大的成功，原因是多方面的。主要原因在于固定网中计算机等固定设备为用户提供了足够的资源和能力去查找信息所以用户通常将它作为一个浏览信息的窗口，而不是被动的信息接收者。同时固定网用户对于信息准确性的要求远甚于对其及时性的要求，因此PUSH技术未能得到广泛的应用。
　而在移动网中，由于存在着网络带宽、移动终端能力以及自费标准高昂等诸多限制，使得用户查找信息受到了一定的限制，如果将重要的信息主动及时地推送到用户的移动设备上无疑会大大方便用户。移动通信的优点是移动设备能够随时随地接收信息因此PUSH技术在移动网中可以大展拳脚，WAP PUSH正是PUSH技术和移动通信两者扬长避短相结合的产物。WAP PUSH是在移动网络中应用的PUSH技术，它结合了一般PUSH技术和移动网络的特点。它的系统框架、使用协议和服务方式与固定网上的PUSH技术有很大不同。

10.WAP数据传输框架
整个WAP框架包括PI(Push Initiator，即互联网的服务器)、PPG(Push Proxy Gateway，一般为WAP网关)、移动终端三大部分。PI到PPG之间是基于HTTP的PAP(Push Access Protocol)协议（PPG和PI互为HTTP服务器），PPG到移动终端之间是PUSH OTA(PUSH Over-The-Air)协议。
基本流程是互联网的服务器将要发送的信息内容，采用XML表现形式，通过PAP协议发送给WAP网关。这里发生了很多细节过程后（计费、SP标识、访问控制、信息内容二进制压缩编码、终端发现、终端能力特性检查、终端地址解析），通过PUSH OTA协议将内容发送到手机上(2.0以下的规范用OTA-WSP，2.0以上的规范用OTA-HTTP)。
这是很理想的目标，可是在目前全球所有运营商部署的无线网络那里，实现这个基本都不现实。第二代无线网络GSM/CDMA95A是基于信令的电路交换的通信技术，并不支持IP协议，能进行WAP这样数据业务，需要先在信令协议栈上借用modem拨号机制封装成IP/PPP包。WAP网关通过信令网找到手机并建立WSP会话的连接是不可能实现的。第二代半过渡性的网络技术GPRS/CDMA1.x理论上是可以让手机永久在线，拥有固定的IP地址，可现实并不是如此。空中信道的有限容量、计费管理、网络容量等方面都不成熟，所以，移动终端要像一台服务器那样，接收并处理WAP网关随时发起的主动连接请求，只能等到第三代无线网络技术全面普及的那一天了。
正是由于上述局限，目前，在世界各地，所有运营商和所有方案供应商那里，都采用SMS（短消息）方式承载OTA侧的推送,因此在实际环境中更多的通过短消息（SMS）网关与移动终端交互。SMS是信令通道上传输的，处于网络覆盖中的手机通过BTS、BSC、MSC与短信中心随时随地可以相互通信。所以，作为这种服务器到终端的信息传输载体，SMS是最适合不过了。

11.推送访问协议(PAP)(Push Access Protocol)
PAP是PI(服务器)与PPG（网关）间的通信协议，它使用XML作为消息的描述语言，通过简单的请求响应机制完成数据的传输。PAP可以实现在多种通信协议之上，包括HTTP，SMTP等。目前的WAP版本仅给出了利用HTTP机制的PAP的规范。

12.推送空间传输协议(PUSH OTA)
PUSH OTA是运行于WSP之上的一层较为简单的协议层，负责从PPG（网关）到移动设备的数据传输。PUSH OTA可使用面向连接的会话（Confirmed Push）和无连接会话(Connectionless Push)两种WSP层服务，对于使用连接会话的推送，需要在PPG和客户端间预先存在一个激活的会话,即需要对方回送接收确认信息的Push；对于无连接的推送，则通过预留的端口完成通信。即发送出去后，是否收到就不管了。

13.WAP网关
PPG(Push Proxy Gateway，一般为WAP网关)完成推送体系结构中的大部分工作，包括从Internet到移动网的访问接入，以及与其有关的认证、安全、客户端控制等所有工作。PPG所提供的主要服务包括：
1)PI的标识、鉴权和访问控制；
2)对推送内容进行语法分析，并依据数据类型定义（DTD）检错纠错；
3)客户寻址与信息传输；
4)PAP与PUSH OTA间的协议转换；
5)为提高无线信道中的传输效率，对信息进行压缩、编译等处理。
　 另外，PPG还可以通过别名机制实现组播和广播，即将某些特定的地址别名映射到组播或广播的操作中，具体方案可以由系统实现者决定。不同的客户端，其能力是不同的，PPG还要负责响应PI的客户能力查询请求，以便于PI针对不同的客户端构造合适的内容格式。

14.建立WAP网关
商用WAP网关价格昂贵，我们可以使用开源软件Kannel。Kannel不仅是一个WAP网关，同时也可作为SMS网关，它完整实现了WAP传输协议。Kannel的WAP传输协议代码在wap目录下。WAP传输协议并不是对等的，Kannel作为网关，其实它只需要实现服务器的代码即可，但kannel即实现了服务器的代码也实现了客户端的代码，所以这部分代码完全可以拿到手机中使用。
Kannel状态机和协议数据单元的实现很巧妙。里面有很多def文件，这些文件主要用于实现状态机和协议数据单元PDU的打包/解包，这种方法的巧妙之处在于：def文件里面的宏是根据上下文定义的，不同的上下文从def文件中抽取不同的数据，从而把重复(类似)的代码降到最低。
Kannel对于每层协议的实现也很巧妙。在初始化时，一般每个协议层都需要两个函数指针，这些函数用来衔接上下两个相邻的协议层： 一个函数接收来自上层的数据包并放到队列中，另一个函数接收来自下层的数据包并放到队列中。这样，上下两层是完全独立的，可以单独测试。每一层都有一个工作线程，它异步的处理来自上下两层的数据包，让各层的调用不会阻塞。
(1)kannel安装
目前最新的Kannel稳定版版本为1.4.3，可以在http://www.kannel.org下载。下载后进行安装：
解压后进入源文件所在目录如：cd /usr/local/gateway-1.4.3，依次执行以下命令：
apt-get install libxml2 libxml2-dev
　　 ./configure
　　 make
　　 make bindir=/usr/local/bin install
编译后在源文件中的gw目录下将看到两个可执行文件：bearerbox、wapbox

(2)bearerbox、wapbox
1）bearerbox
　 　Bearerbox模块连接到CSD router，提供了对Wapbox的接口，实现了WAP协议栈的WDP层。
　　 Bearerbox记录当前运行的wapbox，从CSD router接收UDP包，把从同一个终端接收到的包路由到同一个wapbox，收到wapbox的处理结果后发到相应的用
户终端。
2）wapbox
　　 wapbox模块实现了WAP协议栈的上层部分，属于同一个事务的会话和事务由同一个wapbox处理。wapbox实现了WTLS、WTP和WSP层。Wapbox从电话接收到
类似HTTP的请求，把实际的HTTP请求发到内容服务器，压缩响应数据，发回到终端。
　　
bearerbox和wapbox之间通过TCP建立连接。 bearerbox充当server等待wapbox进行连接。这样， bearerbox就不需要保留静态的wapbox列表。它以一个空的列表开始，等待wapbox进行注册，这种设计使得动态的加入新的wapbox变得非常方便：只须安装一个，配置好，连接到相应的bearerbox。
　 　如果bearerbox和wapbox之间的TCP连接断开了，bearerbox会得到通知把它从自己的clients列表中去掉。当崩溃的 wapbox从bearerbox的clients列表中 去掉之后，从应该路由到此wapbox的终端收到的数据包被看作从一个新的终端收到。这意味着 wapbox必须能处理在一个会话当中的包。
　　 也可能出现这样的情况，wapbox还存活着，但已经不能处理任何消息了。为了检测这种情况，wapbox要定期向bearerbox发送心跳（heartbeat）包，如果bearerbox未能收到heartbeat消息，它认为存在问题的wapbox崩溃了，但是未能断开TCP连接。 bearerbox会断开连接，把它从clients列表种去掉。当wapbox恢复 后，会重新打开连接。Heartbeat消息还包含wapbox的负载，bearerbox据此进行负载平衡。

(3)配置网关
安装后还可以自定义网关参数。打造个性化WAP网关。
　　 观察其中一个配置文件，执行命令：vi gw/wapkannel.conf

　　 # KANNLE WAP示例配置文档
　　 # Created by Nanu
　　 # http://nanu.8866.org
　　 # 这是一个必须变量core
　　 group = core
　　 # 用于bearerbox侦听HTTP管理命令的端口号。可以设定为高于1023的任何端口
　　 admin-port = 13333
　　 # 指定是否启用SSL
　　 admin-port-ssl = false
　　 # HTTP 管理命令的密码
　　 admin-passWord = yourpasswd
　　 # 请求Kannel状态的密码。如果没有设置，则无需密码。
　　 status-password = rose123
　　 # 拒绝来自该IP地址的连接
　　 admin-deny-ip = "123.123.123.123"
　　 # 允许这些IP的连接，可以使用通配符
　　 admin-allow-ip = "*.*.*.*"
　　 # 用于wapbox连接的端口。如果没有设置，则Kannel不能处理WAP传输
　　 wapbox-port = 13002
　　 # 拒绝来自该IP地址的连接
　　 box-deny-ip = "123.123.123.123"
　　 # 允许这些IP对WAP单元的连接，可以使用通配符
　　 box-allow-ip = "*.*.*.*"
　　 # 拒绝来自该IP的UDP数据包
　　 udp-deny-ip = "123.123.123.123"
　　 # 允许来自该IP的UDP数据包，可以使用通配符
　　 udp-allow-ip = "*.*.*.*"
　　 # 如果设置了这个参数，Kannel就会侦听指定IP的9200到9208端口的WAP UDP数据包。
　　 # 如果不需要具体限定，可以只用一个星号
　　 wdp-interface-name = "*"
　　 # 日志文件
　　 log-file = "kannel.log"
　　 # 日志级别
　　 # 0 调度
　　 # 1 信息
　　 # 2 警告
　　 # 3 错误
　　 # 4 致命问题
　　 log-level = 1
　　 # WAPBOX 组配置信息
　　 # 必选变量
　　 group = wapbox
　　 # 运行bearerbox的计算机
　　 bearerbox-host = localhost
　　 # 计时器的较验频率
　　 timer-freq = 1
　　 # 日志文件
　　 log-file = "wap.log"
　　 # 日志级别
　　 # 0 调度
　　 # 1 信息
　　 # 2 警告
　　 # 3 错误
　　 # 4 致命问题
　　 log-level = 1

(4)启动网关
　　必须先启动bearerbox，然后再启动 wapbox。由于bearerbox是网关的基本部分，所以必须要先启动。
进入源代码目录下的gw文件夹：cd gw/
　 　启动bearerbox：
　 　./bearerbox -v 1 pushkannel.conf &
　 　启动wapbox：
　 　./wapbox -v 1 pushkannel.conf &

pushkannel.conf为软件包自带的配置文件

(5)通过HTTP管理网关
　 　在浏览器下输入：
　　 http://localhost:13000/shutdown?password=bar （关闭网关）
　　 http://localhost:13000/status?password=bar （获取网关状态）
　　 http://localhost:13000/resume?password=bar （继续运行网关）

　　 13000：为配置文件中admin-port指定的端口
　　 password：为配置文件中admin-password指定的密码

15.WAP PUSH应用实例
为了观察WAP消息的传输过程，我们做一个通过WAP网关发送WAP PUSH消息的应用实例。
进入源代码目录下的TEST文件夹：cd test/
1）新建文件：iptestpap.txt,定义PAP消息，文件内容如下：

<?xml version="1.0"?>
<!DOCTYPE pap PUBLIC "-//WAPFORUM//DTD PAP//EN"
"http://www.wapforum.org/DTD/pap_1.0.dtd">
<pap>
<push-message push-id="9fjeo39jf084@pi.com"
deliver-after-timestamp="2001-02-28T06:45:00Z"
progress-notes-requested="false">
<address address-value="WAPPUSH=127.0.0.1/TYPE=IPv4">
</address>
</push-message>
</pap>

其中“WAPPUSH=127.0.0.1”定义了消息发送的目的地，这里定义为发送到本地。

2）新建文件：contentfile.txt，定义消息的具体内容，文件内容如下：

<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://wap.iobox.fi"
si-id="1@wiral.com"
action="signal-high"
created="1999-06-25T15:23:15Z"
si-expires="2006-06-30T00:00:00Z">
Want to test a fetch?
</indication>
</si>

3）准备好抓包工具
LINUX桌面环境下可以使用“WIRESHARK”，在配置窗口“Capture Options”中
“Interface”选项：选择“Pseudo-device that captures on all interfaces: any”
“Capture Filter”选项：输入“host 127.0.0.1”
点击“Start”按钮开始抓包

4）发送WAP PUSH信息
进入源文件目录下的test文件夹，执行命令：
./test_ppg "http://127.0.0.1:8080/cgi-bin/wap-push.cgi?username=foo&password=bar" contentfile.txt iptestpap.txt
其中参数“username”和“password”为启动KANNEL时使用的配置文件“pushkannel.conf”中定义的“ppg-username=foo”和“ppg-password=bar”


抓包结果如见图1：

图1

观察图1：
（A）前面两个“HTTP”协议包的交互处在应用服务器与WAP网关间的PAP协议侧，第一个包为服务器向WAP网关发送的PAP请求，第2个包“HTTP/1.1 202 ACCE
PTED”表明前面提交的请求已经被WAP网关接受并正在处理。
（B）后面两个“SMPP”，“WSP”协议包处在WAP/SMS网关与移动终端的OTA协议侧，观察第2个包（如图1）“WAP PUSH(0X06)”传输层使用的是UDP协议。

16.OTA侧的数据传输（SMS网关与SMPP协议）
如前第10章“WAP数据传输框架”所述，目前在世界各地，所有运营商和所有方案供应商那里，都采用SMS（短消息）方式承载OTA侧的推送，SMS是在信令通道上传输的，因此在实际环境中更多的通过短消息（SMS）网关与移动终端交互，Kannel也实现了SMS网关功能。
短消息网关（ISMG）是处于短消息中心（SMSC）和业务提供商（SP）之间的设备，它为这两个实体的数据交换提供安全、快捷的通道。短消息网关与短消息中心之间使用SMPP协议（SHORT MESSAGE PEER TO PEER,短消息点对点协议），如同WAP网关一样，短消息网关需要完成协议的转换、计费、路由、安全和网络管理等功能。具体说，SMPP通信代理系统主要实现网关和GSM网中短消息中心（SMSC）的连接，确保准确接收和发送数据，实现高效、可靠的数据传输。为了达到规范要求的不超过0.001%的数据丢包率，SMPP通信代理需要支持流量控制。
SMPP是一个基本协议，在中国主要有三个由其派生的协议：中国移动的CMPP协议，中国联通的SGIP（在CDMA上是ETIP），以及小灵通的SMGP。
例如通过中国移动的WAP网关发送WAP PUSH有着开发周期长，调测流程较复杂等不足，而使用CMPP协议即基于SMS网关来进行WAP PUSH发送灵活性比较高，相对比较简单。