业务识别规则集中管理解决方案研究

杨 军，孙志猛（中国联合网络通信集团有限公司，北京100033）

0 引言

随着移动互联网的高速发展，移动数据流量呈现爆炸式增长，运营商正逐步从语音、短信经营转变为多元化、全方位、深层次的数据流量经营。为了能够实现对用户移动数据流量的精细化运营，避免成为管道工具，运营商积极引入业务识别技术，能够对不同种类的业务进行检测与区分，从而为用户提供有针对性的差异化服务，提升用户业务体验的同时提高运营商的收益。

1 移动网络中的业务识别技术

1.1 移动网络业务识别方式

目前在移动网络运营商中使用的业务识别方式包括以下几种。

a）深度流检测（DFI）。采用基于流量行为的应用识别技术，即不同的应用类型体现在会话连接或数据流上的状态不同，通过识别数据包的大小、速率、时延、持续时间、发送频率以及IP 地址连接方式等内容进行检测，从而获取用户访问业务种类。

b）浅层包检测（SPI）。采用数据包头分析技术，通过对OSI七层协议中的传输层与协议层内容进行检测，从而获取用户访问业务种类，主要识别数据包的源IP 地址、目的IP 地址、源端口号、目的端口号、传输协议类型等。

c）深层包检测（DPI）。采用数据包内容分析技术，通过对OSI七层协议中的应用层内容进行检测，从而获取用户访问业务种类，主要识别数据包的内容、应用层协议等。

可以看出DFI与SPI识别方式主要是针对三/四层进行分析，DPI需要对七层内容进行分析，一般情况下DFI、SPI采用内置部署方式，DPI既可采用内置部署方式，也可采用外置部署方式。

1.2 业务识别规则配置方式

移动网络运营商业务识别技术中包括业务流特征提取模块和业务种类匹配模块2部分。业务流特征提取模块将用户业务的特性信息（例如数据包大小、时延、源IP地址、源端口号、URL、应用层协议类型等）提取出来，发送给业务种类匹配模块，业务种类匹配模块将特征信息与目的业务的特征信息进行匹配，识别出用户访问业务种类。移动运营商在开启业务识别功能后，需要在PGW 或PCRF 上配置业务识别规则。

a）采用静态业务识别方式时，在PGW 上通过设备网管手工配置业务识别规则具体内容，由PGW进行业务识别。

b）采用动态业务识别方式时，在PCRF 上通过设备网管手工配置业务识别规则具体内容，由PCRF 将业务识别规则动态下发给PGW，由PGW 进行业务识别。

目前现网中采用通过设备网管的方式手工在设备上进行配置，这种配置方式存在以下问题。

a）业务识别规则管理节点分散。由于PGW/PCRF 配置节点分散，需要运维人员在全网PGW/PCRF 上对业务识别规则进行动态维护，尤其针对第三方OTT 业务服务器频繁变更的场景，管理复杂度高。

b）业务识别规则容量有限。由于PGW/PCRF 设备中仅有部分硬件资源用来配置业务识别规则，因此支持的业务识别规则解析条目数量有限，仅能达到万级条目，不能满足大数据量级业务识别需求。

c）与第三方OTT 交互性较差。由于缺少与第三方OTT之间的自动化数据同步接口，只能采用人工工单的方式对业务识别规则进行配置，业务开通周期长，不能满足合作业务快速开通与上线的需求。

为了能够有效地解决以上问题，提出了业务识别规则集中管理方案。

2 业务识别规则集中管理方案

2.1 集中管理方案特点

业务识别规则集中管理方案通过引入业务识别规则集中管理网元实现对用户业务识别规则的集中管理，同时开通与第三方OTT 之间的数据同步接口，提高与第三方OTT交互实时性，实现业务识别规则管理的集中化、自动化。采用业务识别规则集中管理方案可以有效解决在现网业务识别规则配置中存在的问题。

a）由于采用业务识别规则集中管理网元，运维人员只需要在全网一点进行业务识别规则管理维护，可有效提高业务识别规则管理效率，降低管理复杂度。

b）由于采用了专门的软、硬件设备配置业务识别规则，因此支持的业务识别规则解析条目数量较高，能达到百万级要求，可以满足大数据量级业务识别规则需求。

c）由于开通了与第三方OTT 之间的自动化数据同步接口，第三方合作业务的开通与管理可以做到自动化，极大程度地缩短第三方合作业务开通部署周期，简化流量经营类业务配置步骤，满足合作业务快速开通与上线的需求。

2.2 网络架构与接口

如图1 所示，业务识别规则集中管理方案新建1套业务识别规则集中管理网元，开通与现网PGW之间的ICAP/SOAP 接口、与现网PCRF 之间的SOAP 接口、与第三方OTT之间的Restful接口。

图1 业务识别规则集中管理方案

a）ICAP 接口。为业务识别规则集中管理网元与PGW 之间的接口，PGW 提供业务识别规则，发送给业务识别规则集中管理网元，业务识别规则集中管理网元查询本地数据库得到业务标识，将业务标识返回给PGW。

b）SOAP接口。为业务识别规则集中管理网元与PGW/PCRF 之间的接口，业务识别规则集中管理网元提供业务识别规则给PGW/PCRF，PGW/PCRF对SOAP接口消息进行处理，将其转换为网元内部配置。

c）Restful 接口。为业务识别规则集中管理网元与第三方OTT之间接口，第三方OTT提供业务识别规则以及业务属性的相关描述，发送给业务识别规则集中管理网元，业务识别规则集中管理网元对Restful接口消息进行处理，鉴权第三方OTT的合法性并获得业务识别规则的定义等其他属性信息。

业务识别规则集中管理方案采用动态查询与静态查询相结合的方式，用户初始查询通过ICAP接口采用动态查询方式查询业务识别规则与业务标识之间的关系；业务识别规则集中管理网元存储业务识别规则查询频次等信息，依据筛选条件对业务识别规则进行条件筛选，将筛选后的业务识别规则通过SOAP 接口下发给PGW/PCRF，PGW/PCRF 转换成内部网元配置文件；用户后续查询时采用静态查询方式查询PGW/PCRF本地配置的业务识别规则与业务标识之间的关系。

在移动运营商网络中部署集中管理方案需新建业务识别规则集中管理网元；对现网PGW/PCRF 进行软硬件升级改造，增加SOAP 接口机，能够将SOAP 协议转换成内部配置文件；需要对PGW的内部业务识别逻辑进行改动，将业务匹配模块外置到业务识别规则集中管理网元中。

2.3 主要业务流程

业务识别规则集中管理方案主要包括业务识别规则生成、业务标识动态查询和业务识别规则下发3个流程。

2.3.1 业务识别规则生成流程

第三方OTT 通过Restful 接口向业务识别规则集中管理网元同步业务的业务识别规则信息，包括新增/修改/删除业务识别规则（见图2）。

a）运营商针对第三方OTT 业务规划业务标识信息。

图2 业务识别规则与业务标识生成流程

b）第三方OTT根据不同场景针对业务进行新增、修改、删除业务识别规则信息操作。

c）第三方OTT 向业务识别规则集中管理网元发送HTTP请求消息，消息头中携带Username、Password、Operation、Seq 等参数，消息体中携带业务识别规则及业务属性等信息，包括L3/4RuleContent、L7RuleContent等。

d）业务识别规则集中管理网元对第三方OTT 合法性进行认证与鉴权，同时更新数据库内部业务识别规则信息，并根据业务属性信息决定后续对业务识别规则采取的动作。

e）业务识别规则集中管理网元向第三方OTT 发送HTTP响应消息，其中携带返回结果，成功返回200，失败返回500。

2.3.2 业务标识动态查询流程

PGW提取业务识别规则特性信息，发送给业务识别规则集中管理网元，业务识别规则集中管理网元进行业务标识查询（见图3）。

图3 业务标识查询流程

a）用户使用数据业务，PGW进行数据流解析获取流描述信息，例如源IP 地址、源端口号、目的IP 地址、目的端口号、URL等L3/4或L7层协议特征。

b）PGW 向业务识别规则集中管理网元发送ICAP REQMOD Request 消息，消息中携带L3/4Rule⁃Content、L7RuleContent。

c）业务识别规则集中管理网元查询本地数据库对业务识别规则进行匹配。

d）业务识别规则集中管理网元向PGW 发送ICAP REQMOD Response 消息，匹配成功时，消息中携带Service_ID；匹配不成功时，消息中携带结果码。

2.3.3 业务识别规则下发流程

由业务识别规则集中管理网元下发业务识别规则的静态配置信息给PGW/PCRF，PGW/PCRF 对业务识别规则进行配置转换（见图4）。

图4 业务识别规则下发流程

a）业务识别规则集中管理网元判断满足业务识别规则推送条件，例如立即推送、业务识别规则变化时推送、查询频次满足一定条件时推送，发起向PGW/PCRF的业务识别规则动态推送流程。

b）业务识别规则集中管理网元向PGW/PCRF 发送业务识别规则推送请求消息，消息中携带业务识别规则及动作类型等信息，包括L3/4RuleContent、L7Ru⁃leContent、Action_Type等。

c）PGW/PCRF 向业务识别规则集中管理网元返回SOAP 响应消息，消息中携带返回结果，成功返回200，失败返回500。

d）PGW/PCRF 对SOAP 消息进行处理，将业务识别规则转换成内部配置文件。

e）业务识别规则集中管理网元向PGW/PCRF 发送处理结果响应请求消息，消息中携带Message ID、Is⁃Success、ErrorDesc等参数。

f）PGW/PCRF向业务识别规则集中管理网元返回SOAP响应消息，消息中携带返回结果，成功返回200，失败返回500。

3 业务识别规则集中管理应用

3.1 应用了C D N技术的移动互联网业务

随着CDN技术的成熟，越来越多的第三方OTT业务商都通过使用CDN技术来提高业务服务质量，但由于用户访问内容经过CDN 调度后对原始URL 进行了重定向，改变了用户访问服务器的IP 地址或URL，从而为网关精确识别第三方OTT 业务以及用户精准计费带来一定影响。

采用业务识别规则集中管理方案，第三方OTT通过Restful 接口将自营业务的业务识别规则发送到业务识别规则集中管理平台，CDN服务提供商将CDN的服务器IP地址、重定向后的URL与第三方OTT的映射关系通过Restful 接口发送到业务识别规则集中管理平台，业务识别规则集中管理平台将CDN的服务器IP地址、重定向后的URL与第三方OTT的原始URL进行绑定；当用户使用第三方OTT 业务时，将CDN 重定向后的服务器IP地址或URL发送给业务集中管理平台，业务识别规则集中管理平台将其与第三方OTT 的URL 进行关联，将业务流量进行合并处理，从而做到精准计费。

与网关静态配置方式相比，集中管理方案具有一定优势，由于现网部署的CDN 业务服务器较多，重定向后的URL也较分散，通过在网关上手工静态配置第三方OTT 业务与CDN 重定向后的服务器IP 地址或URL的匹配关系十分复杂与繁琐；业务集中管理平台支持的业务识别规则容量大，同时具备Restful数据同步接口，同步第三方OTT业务与CDN重定向后的服务器IP地址或URL的匹配关系简单与且匹配快速。

3.2 后向流量统付业务

随着移动运营商从传统的语、短信经营转变为数据流量经营，越来越多的移动互联网企业提出了定向流量经营类业务产品需求，例如用户免费访问某团购网站以此增加网站点击率，通过广告或第三方商家分成的方式盈利；某游戏网站为游戏用户提供免费游戏流量，通过游戏中的增值业务盈利，此类商业模式的特点是后向流量统付，终端用户不必顾虑费用，第三方OTT为流量付费，可以获得更多增值业务回报。为了能够有效支撑流量经营类业务产品需求，要求移动运营商的网络支持大批量互联网业务的精确识别功能。

采用业务识别规则集中管理解决方案，第三方OTT 通过Restful 接口将自营业务的业务识别规则及订购的统付业务发送给业务识别规则集中管理平台；用户在使用业务过程中，PGW将自营业务的业务特征信息发送给业务识别规则集中管理平台，业务识别规则集中管理平台匹配内部数据库完成业务识别，并下发统付业务所用计费标识；PGW 使用下发的RG 为用户统付类业务计费。

与采用PCRF 针对用户级别的解决方案相比，集中管理方案具有一定优势，由于不区分用户，因此不需要PCRF参与，合作业务开通部署周期较快，第三方OTT只需要通过自动化配置接口将业务识别规则信息与业务订购能力信息发送给业务识别规则集中管理平台，运营商在业务集中管理平台上对第三方OTT的申请进行审批开通即可，一般情况下几天时间即可完成全网业务开通与应用，极大地缩短了业务开通部署周期。

4 总结

面对着互联网业务的迅猛发展，现网涌现出各种各样不同种类的互联网业务，如何做到互联网内容与运营商管道能力的紧密结合是目前运营商关注的一个重点。在对互联网业务进行有针对性的增值处理之前，首先要做的就是对互联网业务的精确识别，如何让这个识别过程更加智能化、简单化、自动化是研究的重点。

与现网业务识别规则配置方式相比，业务识别规则集中管理方案新增了Restful接口，增强了与第三方OTT 之间的交互性，OTT 能够实时地将变化的业务识别规则同步给业务识别集中管理网元，提高了合作业务开通效率、规避了业务识别规则频繁变化带来的计费风险。同时业务识别规则集中管理方案新建了一套业务识别规则集中管理网元，集中一点维护全网业务识别规则，有效降低了业务识别规则管理复杂度，大幅度提高了业务识别规则容量，可满足百万级业务经营需求。

业务识别规则集中管理方案仅仅是运营商智能管道开放的一个基础功能，后续还需要在识别互联网业务的基础上，紧密结合第三方OTT丰富多样的互联网业务内容，为其有针对性地提供定制化服务，在提升用户体验的同时深入挖掘运营商的管道价值能力。

［1］ 3GPP TS 23.203 Policy and charging control architecture［S/OL］.［2015-07-22］.http：//www.3gpp.org/DynaReport/23203.htm.

［2］ 3GPP TS 29.212 Policy and Charging Control（PCC）over Gx refer?ence point［S/OL］.［2015-07-22］.http：//www.3gpp.org/DynaReport/29212.htm.

［3］ 3GPP TS 29.213 Policy and charging control signalling flows andQuality of Service（QoS）parameter mapping［S/OL］.［2015-07-22］. http：//www.3gpp.org/DynaReport/29213.htm.

［4］ 3GPP TS 29.214 Policy and charging control over Rx reference point［S/OL］.［2015- 07- 22］. http：//www.3gpp.org/DynaReport/29214.htm.

［5］ 高翔，武斌，俞学浩，等. 一种基于ICAP 的实时数据防泄露方案［J］.信息网络安全，2013（11）：30-36.

［6］ 汤吴，李之棠. 基于DPI 的P2P 流量控制系统的设计与实现［J］.信息安全与通信保密，2007（6）：94-96.

［7］ 李芸. P2P 流量识别与管理技术应用研究［J］. 信息通信技术，2008（6）：18-24.

［8］ 黄韬，张智江，刘韵洁.PCC 策略控制机制研究［J］.现代电信科技，2008（9）：2-5.

［9］ 朱永庆.DPI技术应用场景探讨［J］.广东通信技术，2007（7）：27-29.

［10］于化龙.移动运营商DPI 应用策略分析［J］.电信技术，2012（6）：42-45.

［11］郭恩阳.DPI 在移动分组域中的应用与展望［J］.移动通信，2012（18）：85-89.

［12］乔治.基于DPI 的内容缓存技术及应用［J］.信息通信技术，2011（3）：65-69.

［13］穆佳，高功应，周晓敏.DPI 在WCDMA 中的应用分析［J］.邮电设计技术，2015（2）：78-82.

［14］张玎.端到端的QoS 服务保障分析［J］.邮电设计技术，2013（8）：26-29.

［15］朱亚楠.基于DPI 技术的P2P 业务的识别和控制［D］.上海：上海交通大学，2008.