实现wap 业务透明代理的方法、wap 网关和系统的制作方法
【专利摘要】本发明公开一种实现WAP业务透明代理的方法、WAP网关和系统。其中在实现WAP业务透明代理的方法中，当接收到分组数据服务节点PDSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从远程用户拨号认证Radius消息单元中获取与业务流的源IP地址相关联的移动用户电话号码MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
【专利说明】实现WAP业务透明代理的方法、WAP网关和系统
【技术领域】
[0001]本发明涉及通信领域，特别涉及一种实现WAP业务透明代理的方法、WAP网关和系统。
【背景技术】
[0002]一直以来，用户使用CTWAP (互联星空，中国电信自有门户业务的接入渠道)拨号之后，现有WAP (Wireless Applicat1n Protocol,无线应用协议)业务主要包括如下三种类型业务流，如图1描述的现有技术中CTWAP业务流程所示:
[0003]I)采用非代理的方式，通过融合防火墙NAT后直接访问VPN P1-O互联网业务，如图1中第I条业务流所示。
[0004]2)通过WAP网关代理访问自营业务或者互联网业务，如图1中第2条业务流所示。
[0005]3)直接访问 VPN P1-1 中的自营业务平台，如 BREW(Binary Runtime Environmentfor Wireless,无线二进制执行环境)、定位、天翼视讯流媒体等业务,如图1中第3条业务流所示。
[0006]随着智能机和非代理客户端应用的发展，上述背景中第一种直接通过融合防火墙的业务流越来越大。由于融合防火墙并不支持前传MDN (Mobile Directory Number,移动用户电话号码)，因此导致诸如iPhone浏览器的非代理客户端无法在访问电信业务时前传MDN。
【发明内容】
[0007]本发明要解决的技术问题是提供一种实现WAP业务透明代理的方法、WAP网关和系统。通过使用透明代理为来自非代理客户端的业务流添加MDN，从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
[0008]根据本发明的一个方面，提供一种实现无线应用协议WAP业务透明代理的方法，包括:
[0009]当接收到分组数据服务节点roSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理；
[0010]若判断业务流没有设置代理，进一步判断业务流是否能够直接透传；
[0011]若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址；
[0012]从远程用户拨号认证Radius消息单元中获取与业务流的源IP地址相关联的移动用户电话号码MDN;
[0013]将MDN添加到业务流的HTTP报头中；
[0014]将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0015]优选的，若判断业务流设置代理，则提取业务流中的URL信息和源IP地址；
[0016]将URL信息转换为相对应的目的IP地址；
[0017]从Radius消息单元中获取与业务流的源IP地址相关联的MDN ；
[0018]将MDN添加到业务流的HTTP报头中；
[0019]将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0020]优选的，若业务流能够直接透传，则从业务流中提取出目的IP地址；
[0021]将业务流转发给与目的IP地址相关联的业务平台。
[0022]根据本发明的另一方面，提供一种实现无线应用协议WAP业务透明代理的WAP网关，包括接收单元、深度包检测单元、透明代理单元和远程用户拨号认证Radius消息单元，其中:
[0023]接收单元，用于接收分组数据服务节点roSN发送的业务流；
[0024]深度包检测单元，用于当接收单元接收到roSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理；若判断业务流没有设置代理，进一步判断业务流是否能够直接透传；
[0025]透明代理单元，用于根据深度包检测单元的检测结果，若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从Radius消息单元中获取与业务流的源IP地址相关联的移动用户电话号码MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台；
[0026]Radius消息单元，用于存储源IP地址与相对应MDN的关联关系。
[0027]优选的，WAP网关还包括显式代理单元，其中:
[0028]显式代理单元，用于根据深度包检测单元的检测结果，若判断业务流设置代理，则提取业务流中的URL信息和源IP地址，将URL信息转换为相对应的目的IP地址，从Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0029]优选的，WAP网关还包括透传单元，其中:
[0030]透传单元，用于根据深度包检测单元的检测结果，若业务流能够直接透传，则从业务流中提取出目的IP地址，将业务流转发给与目的IP地址相关联的业务平台。
[0031]根据本发明的另一方面，提供一种实现无线应用协议WAP业务透明代理的系统，包括分组数据服务节点roSN、WAP网关，其中:
[0032]PDSN，用于当接收到用户终端发送的业务流时，判断业务流是否与自营业务平台相关联；若业务流与自营业务平台不相关联，则将业务流转发到WAP网关；
[0033]WAP网关，用于当接收到I3DSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理，若判断业务流没有设置代理，进一步判断业务流是否能够直接透传，若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从远程用户拨号认证Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0034]优选的，PDSN还用于在业务流与自营业务平台相关联时，将业务流转发到自营业务平台。
[0035]优选的，WAP网关为上述任一实施例涉及的WAP网关。
[0036]本发明通过当接收到分组数据服务节点H)SN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从远程用户拨号认证Radius消息单元中获取与业务流的源IP地址相关联的移动用户电话号码MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
【专利附图】
【附图说明】
[0037]为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
[0038]图1为现有技术中CTWAP业务流程示意图。
[0039]图2为本发明实现WAP业务透明代理方法一个实施例的示意图。
[0040]图3为本发明实现WAP业务显式代理方法一个实施例的示意图。
[0041]图4为本发明WAP网关一个实施例的示意图。
[0042]图5为本发明WAP网关另一实施例的不意图。
[0043]图6为本发明实现WAP业务透明代理系统一个实施例的示意图。
[0044]图7为本发明WAP业务流程示意图。
【具体实施方式】
[0045]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0046]除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。
[0047]同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。
[0048]对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。
[0049]在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。
[0050]应注意到:相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
[0051]图2为本发明实现WAP业务透明代理方法一个实施例的示意图。优选的，本实施例的方法步骤可由WAP网关执行。
[0052]步骤201,当接收到F1DSN (Packet Data Serving Node,分组数据服务节点)发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。
[0053]由于深度包检测(Deep Packet Inspect1n,简称:DPI)是本领域技术人员所了解的，因此这里不展开描述。
[0054]步骤202，若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。
[0055]步骤203,若业务流不能直接透传，则从业务流中提取出源IP (InternetProtocol,互联网协议)地址和目的IP地址。
[0056]步骤204,从 Radius (Remote Authenticat1n Dial In User Service,远程用户拨号认证)消息单元中获取与业务流的源IP地址相关联的MDN。
[0057]步骤205,将 MDN 添加到业务流的 HTTP (Hypertext transfer protocol,超文本传输协议)报头中。
[0058]步骤206，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0059]基于本发明上述实施例提供的实现WAP业务透明代理的方法，通过当接收到I3DSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
[0060]图3为本发明实现WAP业务显式代理一个实施例的示意图。其中，若判断业务流设置代理，则WAP网关可进行如下处理。
[0061]步骤301,若判断业务流设置代理，贝U提取业务流中的URL (Uniform ResourceLocator,统一资源定位符)信息和源IP地址。
[0062]步骤302，将URL信息转换为相对应的目的IP地址。
[0063]在一个实施例中，可通过DNS (Domain Name System,域名系统)服务器进行相应的转换。由于这是本领域技术人员所了解的，因此这里不展开描述。
[0064]步骤303，从Radius消息单元中获取与业务流的源IP地址相关联的MDN。
[0065]步骤304，将MDN添加到业务流的HTTP报头中。
[0066]步骤305，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0067]由此，WAP网关可作为与业务流相对应的透明代理或显式代理。
[0068]此外，若判断业务流能够直接透传，则从业务流中提取出目的IP地址，并将业务流转发给与目的IP地址相关联的业务平台。
[0069]即在直接透传情况下，WAP网关无需对业务流进行任何处理。
[0070]图4为本发明WAP网关一个实施例的示意图。如图4所示，WAP网关包括接收单元401、深度包检测单元402、透明代理单元403和Radius消息单元404。其中:
[0071]接收单元401，用于接收I3DSN发送的业务流。
[0072]深度包检测单元402，用于当接收单元401接收到H)SN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理；若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。
[0073]透明代理单元403，用于根据深度包检测单元402的检测结果，若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从Radius消息单元404中获取与业务流的源IP地址相关联的移动用户电话号码MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0074]Radius消息单元404，用于存储源IP地址与相对应MDN的关联关系。
[0075]基于本发明上述实施例提供的WAP网关，通过当接收到I3DSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
[0076]图5为本发明WAP网关另一实施例的示意图。与图4所示实施例相比，在图5所示实施例中，还包括显式代理单元501。其中:
[0077]显式代理单元501，用于根据深度包检测单元402的检测结果，若判断业务流设置代理，则提取业务流中的URL信息和源IP地址，将URL信息转换为相对应的目的IP地址，从Radius消息单元404中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0078]优选的，WAP网关还包括透传单元502。其中:
[0079]透传单元502，用于根据深度包检测单元402的检测结果，若业务流能够直接透传，则从业务流中提取出目的IP地址，将业务流转发给与目的IP地址相关联的业务平台。
[0080]由此，WAP网关可实现透明代理、显式代理和直接透传。
[0081]图6为本发明实现WAP业务透明代理的系统一个实施例的示意图。如图6所示，该系统包括PDSN601、WAP网关602。其中:
[0082]PDSN601，用于当接收到用户终端发送的业务流时，判断业务流是否与自营业务平台相关联；若业务流与自营业务平台不相关联，则将业务流转发到WAP网关602。
[0083]WAP网关602，用于当接收到H)SN601发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理，若判断业务流没有设置代理，进一步判断业务流是否能够直接透传，若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从远程用户拨号认证Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。
[0084]基于本发明上述实施例提供的实现WAP业务透明代理的系统，通过当接收到I3DSN发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理。若判断业务流没有设置代理，进一步判断业务流是否能够直接透传。若业务流不能直接透传，则从业务流中提取出源IP地址和目的IP地址，从Radius消息单元中获取与业务流的源IP地址相关联的MDN，将MDN添加到业务流的HTTP报头中，将添加MDN的业务流转发给与目的IP地址相关联的业务平台。从而在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题。
[0085]优选的，PDSN601还用于在业务流与自营业务平台相关联时，将业务流转发到自营业务平台。
[0086]优选的，WAP网关为图4或图5中任一实施例涉及的WAP网关。
[0087]图7为本发明WAP业务流程示意图。与现有技术相比，在图7所示的示意图中，取消了 WAP融合防火墙，对原有的WAP网关进行了升级改造，实现了对业务流的透明代理、显式代理或直接透传。在网络侧解决了非定制浏览器访问相关业务时无法前传MDN和WAP代理的问题，使得原来没有设置WAP代理的浏览器也能够在访问电信基地业务同时实现MDN传送，拓宽计费管道。其中，图7中的第1-3条业务流与图1中的第1-3条业务流的含义相同。
[0088]本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
[0089]本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。
【权利要求】
1.一种实现无线应用协议I八？业务透明代理的方法，其特征在于，包括: 当接收到分组数据服务节点发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理； 若判断业务流没有设置代理，进一步判断业务流是否能够直接透传； 若业务流不能直接透传，则从业务流中提取出源I？地址和目的I？地址； 从远程用户拨号认证此也仍消息单元中获取与业务流的源I？地址相关联的移动用户电话号码108 ； 将添加到业务流的肌1？报头中； 将添加的业务流转发给与目的I？地址相关联的业务平台。
2.根据权利要求1所述的方法，其特征在于， 若判断业务流设置代理，则提取业务流中的信息和源I？地址； 将口此信息转换为相对应的目的I？地址； 从1^(11118消息单元中获取与业务流的源I？地址相关联的； 将添加到业务流的肌1？报头中； 将添加的业务流转发给与目的I？地址相关联的业务平台。
3.根据权利要求1或2所述的方法，其特征在于， 若业务流能够直接透传，则从业务流中提取出目的I？地址； 将业务流转发给与目的I？地址相关联的业务平台。
4.一种实现无线应用协议I八？业务透明代理的I八？网关，其特征在于，包括接收单元、深度包检测单元、透明代理单元和远程用户拨号认证此也仍消息单元，其中: 接收单元，用于接收分组数据服务节点发送的业务流； 深度包检测单元，用于当接收单元接收到发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理；若判断业务流没有设置代理，进一步判断业务流是否能够直接透传； 透明代理单元，用于根据深度包检测单元的检测结果，若业务流不能直接透传，则从业务流中提取出源I？地址和目的I？地址，从此也仍消息单元中获取与业务流的源I？地址相关联的移动用户电话号码101将10^添加到业务流的肌1？报头中，将添加10^的业务流转发给与目的I？地址相关联的业务平台； 尺8(11118消息单元，用于存储源I？地址与相对应10^的关联关系。
5.根据权利要求4所述的I八？网关，其特征在于，还包括显式代理单元，其中: 显式代理单元，用于根据深度包检测单元的检测结果，若判断业务流设置代理，则提取业务流中的信息和源I？地址，将信息转换为相对应的目的I？地址，从1^(11118消息单元中获取与业务流的源I？地址相关联的101将10^添加到业务流的肌1？报头中，将添加11^的业务流转发给与目的I？地址相关联的业务平台。
6.根据权利要求4或5所述的爾网关，其特征在于，还包括透传单元，其中: 透传单元，用于根据深度包检测单元的检测结果，若业务流能够直接透传，则从业务流中提取出目的I？地址，将业务流转发给与目的I？地址相关联的业务平台。
7.一种实现无线应用协议爾业务透明代理的系统，其特征在于，包括分组数据服务节点？0%、歡？网关，其中: ？0%，用于当接收到用户终端发送的业务流时，判断业务流是否与自营业务平台相关联；若业务流与自营业务平台不相关联，则将业务流转发到I八？网关；爾网关，用于当接收到发送的业务流时，对业务流进行深度包检测，以判断业务流是否设置代理，若判断业务流没有设置代理，进一步判断业务流是否能够直接透传，若业务流不能直接透传，则从业务流中提取出源I？地址和目的I？地址，从远程用户拨号认证消息单元中获取与业务流的源I？地址相关联的101将10^添加到业务流的肌丁？报头中，将添加11^的业务流转发给与目的I？地址相关联的业务平台。
8.根据权利要求7所述的系统，其特征在于， 还用于在业务流与自营业务平台相关联时，将业务流转发到自营业务平台。
9.根据权利要求7或8所述的系统，其特征在于， I八？网关为权利要求4-6中任一项涉及的I八？网关。
【文档编号】H04L29/12GK104349307SQ201310326646
【公开日】2015年2月11日 申请日期:2013年7月31日 优先权日:2013年7月31日
【发明者】梁朝军, 宫云平, 刁益辉, 李涛, 陈喜洲, 杨剑, 谭志远, 雷多萍 申请人:中国电信股份有限公司