传统电信里的内容主要就是语音，而随着IT与电信的融合，数 据业务得到快速发展，业务种类越来越丰富。丰富的业务种类向承 载网络提出了新的问题，如何感知、区分这些报文，并根据不同的 内容应用不同的计费方式，实现按内容计费，已经成为当今研究的 热点。
通用分组无线业务(General Packet Radio Service，简称GPRS) 业务中，计费对象已远远超出了语音的范围，如何区分各种业务流， 是成功计费的关键。
3GPP中关于内容计费的协议主要是23125R6和23203R7。 3GPP R7协议23203提出了流计费的概念。相对于传统的按照接入 点名称(Access Point Name，简称APN)或按照包数据协议(Packet Data Protocol，简称PDP)进行流量计费，23203提出了基于流的计 费概念，这种计费方式将对于不同的业务进行不同的费率计费，并 且对于相同的业务，按照QOS的不同采用不同的费率计费。
基于流的计费框架如图1所示。其中，策略和计费实施功能 (Policy and Charging Enforcement Function，简称PCEF)是GPRS 中的网关GPRS支持节点(Gateway GPRS Support Node，简称 GGSN)需要实现的逻辑功能，用来进行报文的分析和过滤。策略 和计费规则功能(Policy and Charging Rules Function，简称PCRF) 用来实现规则的选择；应用功能(Application Function，简称AF) 用来下发实现应用层的信息，供PCRF选择计费规则。
3GPP R7中关于流基础的计费中对流计费进行了详细描述，但 是没有对流感知和区分方法进行详细的描述，因此无法时限真正意 义上的基于流的计费。

鉴于以上所述的一个或多个问题，本发明提供了一种报文深度 过滤方法。
根据本发明的报文深度过滤方法包括以下步骤：S202，当网关 设备接收到报文连接请求时，创建用于存储报文深度过滤结果的流 上下文；S204，网关设备根据报文连接请求的请求方式，查找与报 文连接请求的请求方式对应的报文过滤规则；以及S206，如果网关 设备没有查找到与报文连接请求的请求方式对应的报文过滤规则， 则利用默认的报文过滤规则对通过报文连接请求建立的连接中的上 行请求报文进行深度过滤，并将报文深度过滤结果存储在流上下文 中。
其中，步骤S206包括以下步骤：S2062，网关设备通过报文连 接请求建立的连接接收报文，并根据所接收报文的IP五元组和包数 据协议上下文查找用于存储所接收报文的报文深度过滤结果的流上 下文；S2064，如果查找到了流上下文，则网关设备判断所接收报 文是否为上行请求报文；S2066，如果是，则网关设备根据上行请 求报文的统一资源定位符，过滤出上行请求报文所访问的资源，进 而过滤出上行请求报文所访问的关键字段。
其中，上行请求报文是超文本传输协议报文。流上下文是传输 控制协议流上下文。上行请求报文也可以是无线应用协议报文。流 上下文也可以是无线传输协议流上下文。
其中，IP五元组包括源IP地址、目的IP地址、源端口、目的 端口和IP协议类型。
通过本发明，可以有效地区分出业务深层信息。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申 请的一部分，本发明的示意性实施例及其说明用于解释本发明，并 不构成对本发明的不当限定。在附图中：
图1是相关技术中的基于流计费的框架的示意图；
图2是根据本发明实施例的报文深度过滤方法的流程图；
图3是根据本发明实施例的报文深度过滤过程中的交互过程示 意图；以及
图4是根据本发明实施例的HTTP/WAP报文过滤方法的示意 图。

超文本传输协议(Hyper Text Transfer Protocol，简称HTTP)/ 无线应用协议(Wireless Application Protocol，简称WAP)报文的分 类，首先是从IP地址、传输控制协议(Transfer Control Protocol， 简称TCP)/用户数据报协议(User Datagram Protocol，简称UDP) 端口、IP协议类型进行初级分类，根据目的地址和目的端口提供的 HTTP/WAP应用类型定位到HTTP/WAP业务，通过HTTP/WAP报 文中的统一资源定位符(Uniform Resource Locator，简称URL)分 析，过滤出HTTP/WAP所访问资源，进而过滤出访问HTTP/WAP 的内容类型(content-type)以及一些关键字段(比如host字段、 x-online-host字段)的信息，以实现对HTTP报文的深度分类。比 如，相同的URL，host头有可能不同，而且携带的content-type也 有可能不同。
其中，HTTP/WAP报文分类引入了流上下文的概念。HTTP业 务基于TCP流进行业务交互；WAP报文基于WTP流进行交互。如 果要进行业务流的过滤、归类，需要建立流上下文，用来管理业务。 比如，HTTP/WAP业务一般包括请求、响应等交互，但是过滤信息 一般在请求报文中，这样，基于流的计费，就需要创建流上下文， 保存相应过滤结果，供后续响应等报文过滤归类。
为了支持深度HTTP/WAP探测，引入规则模板的概念，对报文 深度探测后采用不同模板进行过滤。比如，对报文URL进行模糊匹 配，满足URL相同的规则分为一组，这组规则再对报文host、 x-online-host、content-type等特定字段进行过滤。
对HTTP/WAP业务报文进行感知，对不同的请求进行不同的深 度探测处理，从而决定激活并使用什么样的模板进行过滤。比如， 对于不同的请求方式(例如，GET和POST)应用不同的过滤模板。
对于HTTP的代理情况进行感知，根据不同的代理使用情况决 定报文探测的方式。比如，报文经过代理访问HTTP/WAP服务器， 代理会将报文的host字段内容和URL进行拼接后传送给 HTTP/WAP服务器，PCEF(GPRS中的GGSN)在对HTTP/WAP 请求报文进行过滤时完成host和URL的拼接后进行过滤。
以上方法的特点在于符合流基础计费的特点。PCEF首先基于 流进行了计费，PCEF网元中本地创建、删除、管理流上下文，基 于流进行报文过滤结果的管理。HTTP/WAP是基于TCP/WTP流的 请求应答交互方式，IP五元组(源IP地址、目的IP地址、源端口、 目的端口、IP协议类型)决定了一个流上下文，对于GPRS应用中， 可以使用IP五元组+PDP上下文绑定索引流上下文。这中索引方法 和23203中的协议规定，23203协议中绑定分为三步，分别是实现 会话和策略和计费控制(Policy and Charging Control，简称PCC) 规则的绑定、PCC规则授权、PCC规则和承载(GPRS中的PDP上 下文)绑定。其中，会话和PCC规则的绑定，该深度过滤分类方法 中对应的是IP五元组为查找流上下文的键值之一；PCC规则和承载 的绑定，该深度过滤分类方法中对应的是包数据协议上下文作为索 引键值之一；在每个流中，HTTP是采用请求和应答方式进行交互， 所以，HTTP的报文过滤分类需要过滤报文的请求，并将过滤分类 结果保存在流上下文中，后续HTTP相应过滤结果归入流上下文对 应的过滤结果。流上下文保存HTTP/WAP的请求报文过滤信息供 HTTP/WAP响应报文读取过滤分类结果，对应3GPP中的PCC授权 和业务绑定。
对不同的HTTP/WAP业务定制了不同的规则模板，以达到深度 过滤分类能力。模板配置要素不但要包含URL配置，还要包括HTTP 请求方式、通信业务类型、接受类型、代理使用情况等等。
感知HTTP/WAP的请求方法，HTTP/WAP有不同种类的请求 方法，包括GET、POST、PUT等，PCEF感知这些报文的请求方式， 将这些请求方式提交PCRF，供PCRF进行规则的选择。
判断业务请求是否通过代理联结到HTTP/WAP服务器。根据判 断结果提取HOST信息和URL信息，进行规则请求以及过滤。
下面参考附图，详细说明本发明的具体实施方式。
参考图2，说明根据本发明实施例的报文深度过滤方法。如图1 所示，该报文深度过滤方法包括以下步骤：S202，当网关设备接收 到报文连接请求时，创建用于存储报文深度过滤结果的流上下文； S204，网关设备根据报文连接请求的请求方式，查找与报文连接请 求的请求方式对应的报文过滤规则；以及S206，如果网关设备没有 查找到与报文连接请求的请求方式对应的报文过滤规则，则利用默 认的报文过滤规则对通过报文连接请求建立的连接中的上行请求报 文进行深度过滤，并将报文深度过滤结果存储在流上下文中。
其中，步骤S206包括以下步骤：S2062，网关设备通过报文连 接请求建立的连接接收报文，并根据所接收报文的IP五元组和PDP 上下文查找用于存储所接收报文的报文深度过滤结果的流上下文； S2064，如果查找到了用于存储所接收报文的深度过滤结果的流上 下文，则网关设备判断所接收报文是否为上行请求报文；以及 S2066，如果是，则网关设备根据上行请求报文的统一资源定位符， 过滤出上行请求报文所访问的资源，进而过滤出上行请求报文所访 问的关键字段。
其中，上行请求报文可以是超文本传输协议报文，用于存储 HTTP报文的深度过滤结果的流上下文是传输控制协议流上下文。 可选地，上行请求报文可以是无线应用传输协议报文，用于存储 WAP报文的深度过滤结果的流上下文是无线传输协议(Wireless Transfer Protocol，简称WTP)流上下文。
下面参考图3和图4，对包括图2所示过程的针对3GPP R7协 议族中的流计费方法中的报文深度过滤过程进行描述。如图3所示， 业务激活后，进行报文深度过滤的过程包括以下步骤：
S302，激活后进行HTTP业务，PCEF区分承载类型，如果是 TCP的同步序列号(Synchronize Sequence Numbers，简称SYN)报 文建链请求或是WTP的连接(CONNECT)请求，则PCEF进行流 上下文的创建，供后续业务报文过滤分类使用。
S304，PCEF收到业务请求报文。
S306，PCEF感知报文的请求方式，按照请求方式区分报文的 种类，分为GET、PUT、POST、HEAD、TRACE、OPTION、CONNECT 等，然后根据不同的请求，寻找PCEF对应的过滤规则。这里PCRF 激活规则时应当下发相应的计费规则以及默认请求类型规则。如果 PCEF找不到对应的规则，则根据默认请求类型规则进行过滤分类。 如果过滤到了对应结果，则不需要再对响应报文提取关键信息深度 过滤分类，使用过滤分类结果更新流上下文。
S308，请求报文过滤后，过滤分类结果保存在流上下文中，请 求报文发往HTTP服务器。
S310、S312、S314是对响应报文的处理，响应报文到达PCEF。 根据请求方式不同对相应响应报文进行不同的处理。
S316、S318、S320是对continue报文的处理。PCEF根据报文 的5元组，如果是GGSN，再加上PDP索引号构成6元组，进行流 上下文的索引，并将continue报文归到流上下文中保存的过滤分类 结果。
S322，TCP或WTP DISCONNECT拆链，释放流上下文。
可以看出，在PCEF承载建立以后，用户面TCP/WTP建链报 文触发流上下文的创建，进行流交互触发计费方式的开始。对上行 请求报文进行深度探测过滤分类，得到过滤分类结果或部分过滤分 类结果，更新流上下文，如果有必要，对下行响应报文进行探测过 滤，同时更新流上下文，将过滤分类结果或阶段过滤分类结果保存 在流上下文中，其他不含有过滤分类信息的继续(continue)报文通 过访问流上下文得到过滤分裂结果。用户面业务TCP/WTP拆链报 文到达PCEF时，结束本计费方法，释放流上下文。
其中，用户面建链，为流基础的计费构建流上下文，为计费作 准备。流上下文存在于整个TCP/WTP流交互期间，用来记录和维 护过滤分类结果或过滤分类中间结果。流上下文索引方法包括应用 层IP五元组作键值和承载层PDP上下文ID作键值。可以支持同一 承载的不同TCP/WTP流进行计费。
步骤S302和步骤S322是建立和拆除流上下文的流程。这两部 分的报文对传输控制协议(Transfer Control Protocol，简称TCP)的 SYN报文建链、发送者无数据(No more data from sender，简称FIN) 报文拆链交互，这种报文的格式属于IP+TCP类型的，主要完成TCP 的建链工作，没有TCP承载业务信息；对于WTP是CONNECT交 互和DISCONNECT交互。这种报文属于IP+UDP+WTP类型，主要 完成WTP层的连接交互，没有WTP承载业务信息。由于没有 TCP/WTP承载业务信息，所以这两种报文流量记录为TCP/WTP承 载流量，进行单独计费。承载流量同时包括业务交互过程中的TCP ACK报文流量和WTP ACK报文流量。
相对于承载流量，步骤S306、步骤S312、步骤S318这几步记 录流量为七层业务流量。两种流量分别进行上报，采用不同的计费 键值(charging key)。两种流量过滤分类结果都保存在流上下文中。
对于步骤S304、步骤S308、步骤S310、步骤S314、步骤S316、 步骤S320这些报文，报文格式是IP+TCP+HTTP或 IP+UDP+WTP+WSP。承载层后有业务报文信息，采用业务信息过 滤，过滤方法将在步骤S306处理中介绍。
这类报文，对于HTTP和WAP20业务，报文格式是 IP+TCP+HTTP，存在TCP承载，过滤分类采用HTTP业务过滤分 类；对于WAP10业务，报文格式是IP+UDP+WTP+WSP格式，存 在WTP承载，采用WSP业务过滤分类。
这样设计的创新之处在于，将承载和业务过滤分类分离，对于 在线计费系统(Online Charging System，简称OCS)在线计费，可 以分别下发信贷(credit，其是OCS中下发的类似分值，有分值才 可以通过报文)，可以对基于承载的报文，也就是步骤S302和步骤 S322报文下发足够多的credit，或者下发免费，让手机和wap服务 器之间的承载报文先交互建链。这样可以保证建链成功，手机可以 发出HTTP的GET或POST请求报文，然后这些请求报文到达PCEF 后，PCEF感知业务请求报文后，才可以进行相关的OCS计费流程。 这样的设计方法是，对承载和业务分别过滤分类采用不同的 charging key，使承载能够建链成功，手机能够发出请求报文，PCEF 才能够感知业务，PCEF感知手机的业务请求信息后，便于采取相 应的动作，比如选择相应的计费方式、或给手机下发重定向报文、 或OCS余额不足给手机用户进行提示等。
当然，也可以配置建链报文，也就是步骤S302和步骤S322报 文配置非免费业务和业务报文，也就是步骤S304、步骤S308、步 骤S310、步骤S314、步骤S316、步骤S320报文费率相同，当建链 请求到达PCEF后就直接申请OCS credit。
针对不同的请求配置不同的过滤器，针对请求报文进行过滤分 类。首先提取报文的请求类型，然后按照不同的请求类项分别进行 过滤分类。在HTTP/WAP应用中，GET和POST请求比较多，占 HTTP/WAP业务的90％以上，它们的过滤方式参考图4所示。
对于GET报文，上行请求根据“目的IP地址、目的端口、IP 协议类型、和报文URL”(包括这些键值但不局限于这些键值，还 可以包括host代理、x-online-host等字段)，过滤到一类规则组。这 类规则组满足通用匹配条件“目的IP地址、目的端口、IP协议类型、 和URL请求”。PCEF将过滤组信息保存在流上下文中，供下行请 求相应报文过滤分类使用。
过滤规则组中配置默认规则，满足“目的IP地址、目的端口、 IP协议类型、和URL请求(如果有，还包括上述其他深度键值)” 相同，但是相应报文深度键值为通配。
GET上行请求报文流量保存在流上下文中，暂时不上报，这片 报文和对应响应报文一同上报，如果没有响应报文，上行GET请求 流量按照规则组默认规则上报。
GET报文的下行报文过滤分析范围限制在上行过滤组中，下行 报文提取深度键值，比如报文中的content-type关键字段或报文相应 码，可以分析到服务器对请求的响应情况及响应内容，在过滤组中 匹配能够满足的过滤器内容。
对于OCS处理，GET报文和对应响应报文共同上报申请credit。
对于上行POST报文，可以直接从报文中查找关键信息“目的 IP地址、目的端口、IP协议类型、请求URL、请求content-type” (包括这些键值但不局限于这些键值，还可以包括host代理、 x-online-host等字段)，利用这些信息匹配PCRF下发的规则。
GET报文和POST报文过滤后，进行流上下文的更新，请求方 式和过滤分类结果等信息保存在PCEF的流上下文中，对于除请求 和响应的其他continue报文，直接从流上下文中读过滤分类结果即 可。
在对WAP1x过滤时，存在WTP包串连的情况。23203提到对 报文进行过滤，没有提到关于WAP报文串连报文的过滤方式，这 种报文存在于WAP10报文中，这种报文允许WTP层的串连传送， 格式是IP+UDP+WTP1+WTP2。一般WTP1为WTP承载，类似于 IP+UDP+WTP的格式；WTP2为带承载业务WSP的报文，类似于 IP+UDP+WTP+WSP的格式。串连报文将这两种报文合为一个报文 进行发送。
PCEF可以对串连报文分别进行过滤分类，得到对应charging key。PCEF按照前述方法，将两种流量分别归到承载流量和业务流 量进行记录。如果需要在线处理，则PCEF可以将两个报文的过滤 charging key上报OCS，由OCS比较两个SI的credit，权衡计费信 息。
本发明已经在GPRS内容计费中实现，但这仅仅是这种深度过 滤的一个应用例子，本发明还可以适合在防火墙、网管监听等需要 对WAP报文或HTTP报文进行深度过滤的场景中。
以上所述仅为本发明的实施例而已，并不用于限制本发明，对 于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本 发明的精神和原则之内，所作的任何修改、等同替换、改进等，均 应包含在本发明的权利要求范围之内。