前 言:
　　近10年以来，移动通信（包括数据和语音）和Internet几乎成为了在全世界范围内发展最快，最具活力的两项技术。而Internet上大量的信息资源和移动通信的漫游特性正是人们对它们情有独钟的原因。如何结合它们的技术优势，在不受信息源的限制和用户访问时位置限制的同时，以统一的标准向用户提供无处不在的多媒体信息网络服务，日益成为网络界和电信界共同关注的一个焦点问题。
　　无线的网络环境由于受到有效频率、移动性、功率限制等因素的影响，与固定网络差距很大。同时，移动通信的终端设备的设计受到体积、电池和网络环境的限制，其CPU主频及计算能力，存储器容量、显示屏和输入设备都较小。如果直接将PC上网技术移植到移动数据通信上，则会由于移动终端设计的种种限制，而使最终的业务和产品无法使用户满意。
　　WAP技术的出现实际上正是为了解决这一矛盾。在1998年4月WAP论坛推出其第一个标准版本WAP1.0。随后又相继推出了WAP1.1和WAP1.2版本，增加了PUSH（推）、UAP（用户个人定制），以及 WTA（无线电话应用）技术细节等内容。在2001年8月，WAP论坛又推出了经过全新变革的WAP2.0版本。WAP2.0是在以前一系列版本的基础上制定的，在WAP2.0中WAP论坛对WAP协议的结构作了重大变革，采用了一些最新的标准和协议，以适应无线环境的变化和预期的市场需求。
　　本标准主要参考了国际上修改技术规定以及我国移动通信网络的实际业务和功能需要而制定的。主要内容包括：网络协议要求、PUSH技术要求、用户代理定制、WTA、预配置要求、WAP网关性能要求和WAP设备要求等。
　　本技术体制由中国联合通信有限公司提出并归口。
　　本技术体制主要起草单位：信息产业部电信传输研究所。
　　本技术体制主要起草人：辛伟、谢玮、孙元宁、董越、梁鹏。
　　
　　1 WAP 2.0网络协议要求
　　1.1 网络协议栈要求
　　1.1.1 可选的双WAP栈支持
　　WAP2.0代理应支持两种协议栈，两种协议栈的操作是独立的。
　　
　　图1　可选的双WAP栈支持
　　
　　如上图所示，WAP2.0代理／网关的通用应用环境可以在任何一个协议栈上运行。网关设备应能够支持并辨别使用不同协议栈的手持设备，自动适应。
　　
　　1.1.2 WAP 2.0协议栈
　　WAP2.0代理／网关应当支持WAP2.0协议栈，即：
　　· WP-HTTP协议；
　　· WP-TCP协议；
　　· IP协议。
　　1.1.3 WAP1.x协议栈
　　WAP2.0代理／网关应当向下兼容WAP1.X协议栈，即支持：
　　· WSP协议；
　　· WTP协议；
　　· WTLS协议；
　　· WDP协议。
　　
　　1.2 WP-HTTP协议要求
　　1.2.1 完全兼容HTTP/1.1（RFC2616）
　　WP-HTTP的核心即HTTP/1.1（RFC2616）。
　　
　　1.2.2 支持PULL和PUSH两种业务应用
　　PULL使用HTTP/1.1的请求／响应机制来实现。而PUSH功能则由WAP终端承担HTTP 服务器的角色。
　　
　　1.2.3 WP-HTTP支持响应消息体压缩
　　这样做可以使空中传输效率增加。WAP代理至少支持在RFC1951中规定的deflate压缩编码方式。
　　gizp（RFC1952）、compress（出自通用UNIX文件压缩程序）这两种压缩方式可选。
　　1.2.4 支持安全隧道建立
　　WP-HTTP还应支持使用CONNECT方式建立安全隧道，已用于端到端安全问题的解决。
　　
　　1.2.5 WAP2.0代理必须支持HTTP客户端功能
　　WAP代理中的HTTP客户端必须支持以下HTTP定义的方法[RFC2616]：
　　· GET
　　· POST
　　· OPTIONS
　　
　　1.2.6 WAP2.0代理必须支持HTTP服务器功能
　　WAP代理中的HTTP服务器必须支持以下HTTP定义的方法[RFC2616]：
　　· GET
　　· HEAD
　　· POST
　　· CONNECT
　　WAP代理中的HTTP服务器可以支持以下HTTP定义的方法[RFC2616]：（可选的）
　　· OPTIONS
　　
　　1.2.7 支持标准的HTTP特性
　　WAP代理应当支持内容编码。内容编码机制应遵循 [RFC2616]中 14.11 节的规定。如果WAP代理支持内容编码，则必须至少提供在RFC1951中规定的deflate编码，以供与终端协商。
　　HTTP服务器应当支持对HTTP响应中的消息体进行内容编码。
　　
　　1.2.8 支持扩展的HTTP特性
　　HTTP服务器必须支持使用CONNECT方式（RFC2817 中第5节中规定）建立隧道。
　　HTTP客户端必须支持使用CONNECT方式（RFC2817 中第5节中规定）建立隧道，如果它支持TLS协议的话。
　　1.3 WP-TCP协议要求
　　1.3.1 WAP代理必须支持TCP相关协议
　　WAP代理必须支持TCP相关协议，包括［RFC0792、RFC2211、RFC2581］。
　　
　　1.3.2 WAP代理必须支持无线优化TCP（WP-TCP）的要求
　　WAP代理应当支持下表所列项目，支持程度参照表中要求。
　　表1 无线优化TCP（WP-TCP）的要求

　　1.4 其它协议要求
　　WAP网关必须支持IP协议，参见RFC791。
　　WAP网关必须支持UDP协议，参见RFC758。
　　WAP网关必须支持TCP协议，参见RFC793。
　　WAP网关必须支持ICMP协议，参见RFC792。
　　WAP网关必须支持IGMP协议，参见RFC1112。
　　WAP网关必须支持SMTP协议，参见RFC821。
　　WAP网关必须支持MIME协议，参见RFC1521。
　　WAP网关必须支持POP3协议，参见RFC1725。
　　WAP网关必须实现相关MIB：RFC1213，RFC1229，RFC1398中相关部分。
　　1.5 WSP协议要求
　　WAP网关必须支持WSP协议。
　　WSP协议应具有以下基本特性：
　　· 建立一个从客户（WAP终端）到服务器的可靠的会话，并释放该会话；
　　· 允许会话能力协商（包括会话服务的具体功能、协议参数、内容头的编码页等）；
　　· 使用压缩编码在客户与服务器之间交换内容；
　　· 挂起、恢复一个会话。
　　除去以上基本特性，WSP还应具备以下扩展特性：
　　· 支持HTTP/1.1功能：
　　· 可扩展的请求-应答方法；
　　· 对象聚合（composite objects）；
　　· 内容类型协商；
　　· 交换客户和服务器会话头；
　　· 中途打断正在进行的事务；
　　· 以非同步方式将内容从服务器推（push）给客户；
　　· 协商支持多个、同时的异步事务。
　　1.6 WTP协议要求
　　WAP网关必须支持WTP协议。
　　WTP协议应具有以下基本特性：
　　· WTP应实现3种不同事务类别：类别0，类别1和类别2。
　　- 0类：不可靠的消息传输，无结果消息。换句话说就是，不可靠的单向数据报服务。通常它用在不可靠的PUSH业务中。该事务只有一个动作就是，发起者发送请求消息。它不是发送数据报的主要手段。如果应用程序需要发送大量的数据报，应使用WDP。
　　- 1类：可靠的消息传输，无结果消息。它主要用于可靠的PUSH业务中。它与0类的区别在于，在发起者发送请求消息后，响应者会确认该消息。
　　- 2类：可靠的消息传输，无结果消息。它提供基本的请求/回应事务服务。一个WSP会话可能包含多个该服务类的事务。实际上它是一个二次握手过程，即发起者发送请求，响应者对该请求发结果确认，发起者发送结果确认的确认。
　　· 可靠性通过唯一的事务标识、确认、重传及删除重复消息获得。
　　· 没有明显的连接建立或拆除阶段。
　　· 用户到用户可靠性支持，即WTP用户确认每一个接收的消息。（可选）
　　· 事务的最后确认可以包含与本事务有关的带外信息。例如，性能测量。（可选）
　　· 在适合的情况下，可以使用串联的方式，在数据报传输的一个服务数据单元（Service Data Unit）中运送多个协议数据单元（Protocol Data Units）。
　　· 面向消息。交换的基本单元是一个完整的消息而不是字节流。
　　· 协议提供机制以保证最小化被重传的事务的数量。
　　· 支持显式的事务退出，包括冲掉客户端和服务器中的未发送的数据。该退出可以由用户取消一个其请求的服务来触发。
　　· 为了可靠地调用消息，无论成功失败都有相应报告。如果一个调用未被响应者处理，应返回给初始者一个异常中断消息。
　　· 协议允许异步事务。如果数据有效，响应者应返回结果。
　　
　　1.7 WTLS协议要求（可选）
　　网关应支持WTLS协议。
　　WTLS的主要功能应包括：保证数据传输一致性，数据传输保密性、提供鉴权机制，丢弃未经证实的数据，加密运算等。
　　WTLS定义3种类别，下列功能必须由不同类别提供：
　　· 1类服务能使用交换的公共密钥建立安全传输，使用对称算法加密解密数据，使用消息授权编码算法、协商算法和安全性参数检查数据完整性。（必选）
　　· 2类服务除完成1类服务的功能外，能交换服务器确认。服务器确认用于对服务器授权。（可选）
　　· 3类服务除完成2类服务的功能外，能交换客户确认。客户确认用于对客户授权。（可选）
　　表1给出了三种WTLS类别所提供的具体功能特性。
　　表1　WTLS类别

　　M 表示该参数是必备的
　　O 表示该参数是用户可选的
　　要求安全层必须至少支持密钥交换算法（Diffie-Hellman、RSA、ECDH等），以及批量加密算法（包括DES、RC5、IDEA等）和MAC（消息验证码）算法（包括SHA、MD5等）。
　　
　　1.8 WDP协议要求
　　WAP网关必须支持WDP协议。
　　无线数据报协议运行于不同网络类型支持的数据承载能力上。WDP是一般数据报服务，使用下层承载能力为上层提供一致的服务。
　　WDP为上层协议提供通用接口，使上层协议可以与下层承载网络无关。WDP使传输层适配到指定的下层承载网络中。
　　WDP必须支持：
　　· 基于IP的承载网络，如CDMA1X、GSM的CSD（必选）
　　· GSM的SMS（必选）
　　其他下层承载网络WDP均可选支持。
　　WDP的主要功能包括：
　　· 根据端口号访问应用；
　　· 数据包分段和重组（可选）；
　　· 错误检测（可选）。
　　· WDP能够同时传输几个来自高层，面向单一低层承载的业务。端口号负责识别高层实体。
　　
　　2 WAP 2.0 PUSH技术要求
　　2.1 PUSH总体要求
　　在WAP环境中，PUSH的结构分为三大部分：PUSH代理网关（PPG）、PUSH发起者（PI）和WAP终端。PPG采用PAP（PUSH访问协议）协议从PUSH服务器上得到信息内容，再通过Push-OTA（Over-the-air）协议在一个可设置的超时（timeout） 时间内将信息转发给WAP客户，见图2。
　　
　　
　　
　　图2　PUSH结构
　　PUSH发起者可以和PUSH代理网关PPG合设。
　　2.2 PUSH网关功能要求
　　PPG可以是一个独立的物理实体，也可以作为一个功能模块放在WAP网关中。
　　PPG必须支持Push访问协议（Push Access Protocol）以便与Push发起者交换Push信息；必须支持Push空中协议（Push Over-the-Air Protocol），以便与WAP客户交换Push信息。
　　PUSH业务的核心任务均由PPG来完成。它所能够提供的服务包括：
　　· PUSH发起者（PI）的识别和认证；访问控制
　　· 对Push的内容以及控制信息进行分析并检测错误
　　· 客户（包括客户的能力）发现服务
　　· Push内容接受者的地址解析；
　　· 对特定类型内容进行二进制编码或编译（WAP1.x），或进行一般压缩(WAP2.0)，以提高OTA协议传输的有效性
　　· 协议转换
　　· PPG还应支持向服务器提供客户机性能参数的功能，使服务器能够根据特定WAP设备的具体能力创建更为适合该客户机的内容格式。
　　2.3 PAP协议要求
　　PAP协议是PI与PPG之间通信协议。PAP可以利用隧道方式在任何Internet协议上运行。目前HTTP协议是必选支持，其他如SMTP协议等为可选支持。
　　PAP支持以下操作：
　　· Push提交（PI到PPG）；
　　· 结果通知（PPG到PI）；
　　· Push取消（PI到PPG）；
　　· Push代替（PI到PPG）；
　　· 状态查询（PI到PPG）；
　　· 客户机性能查询（PI到PPG）。
　　以上所有操作都是基于请求/响应模式的。
　　
　　2.4 OTA协议要求
　　而在面向WAP终端一侧，PPG所使用的协议为POTA。POTA运行在WSP（OTA-WSP）或HTTP（OTA-HTTP）之上。PPG必须支持OTA-WSP和OTA－HTTP。
　　当PPG收到内容信息后会尝试查找正确的目的设备，将WAP内容编译成二进制编码后（该工作也可在PI预先完成），以POTA协议将内容发送给客户。
　　Push OTA-HTTP是一个轻量协议且无状态。它主要功能有：
　　· 利用WSP进行推送；
　　· 应用程序寻址，该功能在WAP客户端实现；
　　· 在空中交换Push控制信息；
　　· 承载选择和控制，PPG可以利用OTA源语中承载标识，提供本功能；
　　· 认证PI，PPG可以通过OTA协议告之客户机，PI已经经过认证。
　　
　　2.5 PUSH的媒体类型
　　2.5.1 已知的MIME媒体类型
　　PUSH业务必须支持已知的任何MIME媒体类型。
　　
　　2.5.2 业务指示（SI）
　　PUSH业务必须支持SI媒体类型。
　　除去SI的基本功能外，SI还应允许以下功能控制：
　　· 用户打扰级别（分配给SI一个特定优先级）；
　　· 代替（以新接收到的SI代替旧的）；
　　· 删除（删除一个已经处理过的SI）；
　　· 过期（分配给SI一个生存时间）。
　　
　　2.5.3 业务载入（SL）
　　PUSH业务应当支持SL媒体类型。
　　
　　2.5.4 Cache操作（CO）
　　PUSH业务应当支持CO媒体类型。
　　
　　3 用户代理定制（UAProf）
　　3.1 WAP网关要求
　　用户代理定制将终端设备硬软件信息、用户和应用优先选择以及网络的定制信息告诉服务器，以便服务器发出更适合用户和网络的业务内容。
　　支持WSP协议栈的网关要求：
　　2 正确响应终端发送的带有定制信息的WSP会话建立请求。
　　2 会话期间保存用户定制信息。
　　2 支持WSP会话暂停和恢复的网关可以在暂停WSP会话时保存用户的定制信息。
　　2 支持WSP会话暂停和恢复的网关可以在会话期间或恢复WSP会话时接收用户更新的定制信息，并正确响应。
　　2 用户业务请求（WSP请求）中带有定制信息时网关可以用覆盖或扩展网关内保存的定制信息向服务器发起业务请求（HTTP请求）。
　　2 网关可以附加网络定制信息到业务请求（HTTP请求）。
　　2 前转服务器的业务响应和内容给WAP终端，可以根据保存的用户需求修改业务响应。
　　2 支持WSP消息和HTTP消息间定制信息的转换，互换符合WAP2.0的UAProf规范第7章的定义。
　　2 支持WSP消息和HTTP消息间定制信息的编解码，编码格式应符合WAP2.0的UAProf规范第8章。
　　
　　支持W-HTTP协议栈的网关要求：
　　2 前转用户发起的带有定制信息的业务请求。
　　2 前转服务器返回的带有定制信息支持回答的响应。
　　
　　WAP网关应该支持的用户代理定制信息至少包括：
　　留待联通确定，可以参考WAP2.0的UAProf规范附件B。
　　
　　3.2 PUSH网关的要求
　　PPG能够正确响应PI的用户能力请求，将当前保存的用户定制信息送回PI。接收了Push消息中的用户能力要求，PPG分别与每个请求发送Push消息的用户当前的定制信息相匹配，前转Push消息给符合要求的用户。对于不符合要求的用户PPG可以改变Push消息内容以适应发送，也可以丢弃消息并向PI返回Push状态报告。
　　支持WSP承载Push消息的网关应在PUSH会话建立时接受并正确响应带有用户定制信息的Push会话请求，并在会话期间保存定制信息。定制信息符合WAP2.0的UAProf规范第7章的定义。采用WBXML编码，编码格式应符合WAP2.0的UAProf规范第8章。PUSH会话在WSP上的功能应符合WAP2.0的OTA-WSP规范。
　　支持HTTP承载Push消息的网关应能发送登记请求获得用户的定制信息。定制信息符合WAP2.0的UAProf规范第7章的定义。PUSH会话在HTTP上的功能应符合WAP2.0的OTA-HTTP规范。
　　PPG应该支持的用户代理定制信息至少包括：
　　留待联通确定，可以参考WAP2.0的UAProf规范附件B。
　　
　　3.3 支持用户代理定制的服务器的要求
　　用户代理定制将终端设备硬软件信息、用户和应用优先选择以及网络的定制信息告诉服务器，以便服务器发出更适合用户和网络的业务内容。
　　
　　3.4 PULL应用服务器的要求
　　支持用户代理定制的服务器应支持HTTP1.1、HTTP1.1扩展框架以及CC/PP交换协议。
　　服务器应该支持的用户代理定制信息至少包括：
　　留待联通确定，可以参考WAP2.0的UAProf规范附件B。
　　
　　3.5 Push Initiator的要求
　　PI通过WAP-PAP接口向PPG索要用户的定制信息。根据用户的定制信息PI可以优化Push内容。PI还可以向PPG提供用户能力要求，供PPG比较保存的用户定制信息，丢弃不符合的用户Push请求，不再发送Push消息。
　　PI应该支持的用户代理定制信息至少包括：
　　留待联通确定，可以参考WAP2.0的UAProf规范附件B。
　　
　　
　　4 WAP电话应用（WTA）（可选）
　　4.1 WTA网关的要求
　　WTA是WAP应用的扩展，支持WTA的终端可以通过WAP激活设备进行通信，比如拨打电话、接听电话、访问电话薄等。WTA终端通过WTA接口（WTAI）接收到电话相关的网络事件时产生WML页面，用户对页面中的内容作出选择，如果触发了电话应用时，WTA通过WTAI接通移动网络。
　　WAP网关必须支持WSP协议以建立会话。
　　WTA用户代理使用URL指向WTA服务器的内容。URL指向WTA服务器上的应用来创建和移动网络实体（例如智能网节点或话音邮件系统）互通的业务。WTA服务器还可以发送SI（业务指示）将网络消息PUSH到用户，这种业务要求WAP网关支持SI。
　　WTA业务可以由移动网络运营商或第三方提供。WAP网关通过WDP端口号区分WTA业务和其它WAE业务。
　　WTA的安全模型保证只使用可以信赖的网关，同时网关检验WTA推或拉的内容是经过批准的。使用WTLS，WTA业务可以通过安全管道经过网关传送到客户。网关到WTA服务器之间的安全性由SSL/TLS或其它方案解决。
　　
　　4.2 WTA服务器的要求
　　WTA是WAP应用的扩展，支持WTA的终端可以通过WAP激活设备进行通信，比如拨打电话、接听电话、访问电话薄等。WTA终端通过WTA接口（WTAI）接收到电话相关的网络事件时产生WML页面，用户对页面中的内容作出选择，如果触发了电话应用时，WTA通过WTAI接通移动网络。
　　WTA服务器要求：
　　WTA用户代理使用URL指向WTA服务器的内容。URL指向WTA服务器上的应用来创建和移动网络实体（例如智能网节点或话音邮件系统）互通的业务。WTA服务器还可以发送SI（业务指示）将网络消息PUSH到用户。
　　WTA的安全模型保证只使用可以信赖的网关，同时网关检验WTA推或拉的内容是经过批准的。使用WTLS，WTA业务可以通过安全管道经过网关传送到客户。网关到WTA服务器之间的安全性由SSL/TLS或其它方案解决。
　　
　　5 WAP 2.0 预配置（Provisioning）技术要求
　　5.1 预配置（Provisioning）总体要求
　　应符合WAP2.0规范要求（WAP-182-ProvArch）。
　　要求Bootstrap和Continuous Provisioning机制相互分离。Bootstrap Provisioning提供给用户足够的TPS配置信息，Continuous Provisioning用于配置信息的更新。
　　Bootstrap Provisioning的方式应符合联通公司相应要求。
　　要求支持用户请求的Continuous Provisioning和网络侧发起的Continuous Provisioning，以更新配置信息。
　　
　　5.2 TPS（可信赖预配置服务器）技术要求
　　5.2.1 预配置内容类型
　　应符合WAP2.0规范要求（WAP-183-ProvCont）。
　　要求支持WBXML。
　　要求支持预配置内容的文本形式和标记化形式之间的转化和编解码。
　　5.2.2 安全要求
　　TPS与客户端之间应建立相应的安全机制。安全机制的建立可以在Bootstrap Provisioning过程中完成。
　　采用的安全策略应符合联通公司相应要求。
　　
　　6 WAP网关性能要求
　　6.1 容量
　　WAP网关容量由根据话务模型计算出的可允许服务的用户数量决定。
　　
　　6.2 处理能力
　　WAP网关处理能力由每秒处理的事务Transaction与会话Session并发数衡量。
　　PULL处理能力：
　　当每事务为4k字节数据量时
　　? 每秒处理的事务数>500
　　? 并发会话数>7000
　　PUSH处理能力：
　　当每事务为4k字节数据量时
　　? 每秒处理的事务数>300
　　? 并发会话数>7000
　　
　　6.3 可靠性指标
　　? 系统故障恢复时间 < 1小时
　　? 无故障工作时间>26280小时。
　　
　　6.4 可扩展性
　　WAP网关应具有良好的可扩展性。要求既可支持增加CPU的方式进行扩容，也可支持多机集群（Cluster）的扩容方式。
　　要求单个WAP网关在进行最大扩展后应至少能支持64个CPU模块。
　　WAP网关应具有热扩容能力，即不需关机就可进行扩容的能力。
　　
　　7 WAP业务网设备要求
　　7.1 WAP网关
　　7.1.1 物理接口要求
　　WAP网关通常只与IP网有通信接口，与无线网络的接口功能由无线网中的网关设备（如接入服务器、PDSN、SMC等）完成。WAP网关与IP网的接口方式通常是LAN接口方式，其中可包括：
　　? 10Mbps以太网接口（符合IEEE802.3），10M以太网接口物理层接口上采用曼切斯特编码，用0.85V和－0.85V分别表示"1"和"0" 。可采用10Base-5,10Base-2, 10Base-T,10Base-F。
　　? 100Mbps快速以太网接口（符合IEEE802.3u），100Mbit/s 以太网接口和10M以太网接口的最大的区别在于物理层的差异和所用传输介质的不同，而在高层二者基本上是一致的。IEEE 802.3u(100Base-T)是100Mbps以太网的标准。100Base-T技术中可采用三类传输介质：100Base-T4、100Base-TX和100Base-FX。采用4B/5B编码方式。
　　? 千兆以太网接口（符合IEEE802.3ab），1000Mbps以太网接口支持1000BaseCX，1000BaseSX，1000BaseLX。在IEEE802.3ab中还规定了1000BaseT。
　　
　　7.1.2 基本功能要求
　　WAP网关应具备以下基本功能：
　　? WAP网关应同时支持两种不同的通信协议栈（WAP1.x和WAP2.0），对于应用环境来说网关提供的服务是一样的；
　　? 内容编/解码器：内容编码器将Web内容翻译成压缩编码的格式，以减少通过无线数据网络传输的数据分组的大小和数量；
　　? PULL功能；
　　? WAP2.0的PUSH功能；
　　? 支持UAProf：即用户代理特征值管理，用户代理特征值描述了终端能力和个人定制信息（UAProf），WAP网关应能管理，并为各种应用提供这些信息；（可选）
　　? 支持高速缓存代理：高速缓存代理可以通过保持经常访问资源的高速缓存，以提高性能和网络效率；
　　? 支持DNS查找功能；
　　? 支持WTA业务（可选）；
　　? 支持MMS（多媒体消息）业务（可选）。
　　
　　7.1.3 连接超时功能
　　WAP网关系统应具有在连接请求（包括URL连接请求、DNS查询请求等）没有应答的情况下，自动超时的功能。超时时间值应可以任意设置。
　　建议tiome-out<10s。
　　
　　7.1.4 认证授权功能（可选）
　　WAP网关系统应支持对来访的用户进行身份认证，以防止非授权用户的使用，并根据认证结果授权用户使用WAP业务，并启动计费服务器。WAP网关应支持以下两种认证方式：
　　? 主叫号码认证方式；
　　? 用户名+密码认证方式。
　　
　　7.1.5 计费功能（可选）
　　WAP网关必须支持按主叫号码和按用户帐号统计用户计费信息的两种不同方式，并能够将计费信息送往计费中心或综合管理和支撑平台生成帐单。
　　WAP网关的计费精度应为流量精确到1字节；时间精确到1秒。
　　WAP网关对于预付费用户的计费要求待定。
　　
　　7.1.6 业务管理功能（可选）
　　WAP网关的业务管理功能可以在WAP网关上实现，也可以独立在操作与维护终端上实现，另外还应允许用户利用WAP终端在线登录。业务管理必须至少提供下列功能：
　　? 用户管理功能，包括：新建、删除、更改、显示用户；
　　? 提供各种事件的记录（包括系统事件、WAP事务事件、用户行为事件等）；
　　? 提供各种业务限制功能（包括业务访问限制、用户接入限制等）。
　　WAP网关应当提供两种界面：
　　? 友好的人机界面，例如基于WWW的界面；
　　? 客户管理界面Customer Administrator Interface（CAI）。
　　WAP网关必须提供二次开发接口。
　　
　　7.1.7 网管功能
　　WAP网管系统应能实现对设备的配置管理、性能管理、故障管理和安全管理等功能。要求WAP网关提供相应信息源和标准的网管接口（SNMP通信协议），实现上述各项管理功能。
　　7.1.8 可扩展性要求
　　WAP网关应具有可扩展性，支持在负载分担技术模式下实现横向扩容，即通过增加服务器数量的方式进一步提高网关系统的处理能力。
　　WAP网关应支持多个物理以太网卡地址与一个IP地址进行映射对应的功能，在增加网关数量时，不需终端用户改变网关IP地址设置，即可对网关进行第二层的扩充。
　　WAP网关应能支持虚拟IP地址功能。
　　
　　7.1.9 可靠性和冗余备份
　　WAP网关设备必须采用冗余及容错技术设计,利用双备份、多级分散控制、多通道、互助及系统重组等方法实现最大限度的系统可靠性。当WAP网关设备出现故障时，应能在尽可能短的时间内得以维护而恢复功能。
　　
　　7.1.10 安全要求
　　WAP网关的安全主要包括以下几大部分：
　　? 物理设备安全；
　　? 内容数据传送的安全性和可靠性；
　　? 系统管理或用户数据传送的安全性和可靠性；
　　? 系统数据保存的安全性和可靠性。
　　WAP网关的物理设备安全只要是指关键设备或部件必须采用冗余设计。
　　系统管理或用户数据传送安全主要指WAP网关系统与其他网络设备（如网管系统、认证/计费系统等等）通信时的数据安全，通常可以采用完整性校验、数据加密等方式来保证。
　　WAP网关系统应能提供多重安全保护机制，以保证系统数据的安全保存。比如，利用防火墙防止来自网络的侵袭；建立合理的操作维护安全策略（包括用户验证、操作/访问权限设定，系统数据加密等）等手段。
　　
　　7.2 防火墙
　　7.2.1 防火墙功能
　　防火墙系统的功能应符合IETF相关规范（RFC2356和RFC2647）及中华人民共和国通信行业标准（防火墙设备规范）。
　　防火墙功能可以有二种方式来提供，分别称为IP Filter和IP Pool。防火墙应支持IP包过滤式防火墙。
　　防火墙应能根据IP地址、服务类型、时间等多种因素灵活配置。
　　卖方应给出其所提供的防火墙的性能参数如：时延、最大位转发率、并发连接数、每秒连接数等。
　　7.2.2 防火墙接口
　　防火墙的对内和对外接口应当采用快速以太网或千兆比以太网接口。