永远在线方案研究

赵文贤 刘小华 黄琳

摘要：通过分析永远在线业务对移动网络带来的问题，创新性地从网络系统角度提出了一种移动网络对永远在线业务的服务机制。该机制基于策略及计费控制（PCC）架构，由永远在线业务服务器通知PCC系统对该永远在线业务流进行网络地址转换（NAT）保活及承载通道保活控制，以此实现移动网络对永远在线业务的承载通道及NAT资源的有效保证，降低永远在线业务对网络负荷的影响，从而提高网络的利用率。

关键词： 永远在线；PCC；策略与计费规则功能；端口控制协议；NAT

Abstract： This paper discribes mobile network problems caused by always-online services. We propose a mechanism for implementing the always-online service in the mobile network， from a network point of view. The mechanism， based on the policy and charging control （PCC） architecture， allows the server to tell the PCC system to implement NAT keep-alive and bearer-channel keep-alive. These guarantee that the bearer channels and network address translation （NAT） resources are available for the always-online service. The mechanism reduces the effect of the service on network load and improves network use.

Key words： always online； PCC； policy and charging rules function（PCRF）； port control protocol （PCP）；NAT

智能终端在全球的快速普及，推动了移动互联网时代的真正到来。智能终端以其丰富多彩的应用/业务吸引了越来越多的用户加入移动宽带业务（MBB）使用者的行列，这给MBB运营商带来了丰厚收益，但同时也给移动网络带来了新的挑战。尤其智能终端上的QQ、微博等永远在线业务对MBB网络的资源容量、网元信令处理能力、数据转发带宽等都造成了极大的影响，MBB网络已经或正在面临着因永远在线业务产生的网络信令风暴以及网络拥塞的一系列问题。

如何解决永远在线业务带来的网络信令风暴及网络资源被长期占用的问题，已经成为运营商紧迫的研究课题。

1 永远在线问题分析

造成网络拥塞、信令风暴主要有下面几个方面的原因：

（1）PDP自动激活带来容量压力

绝大多数智能终端开机后自动激活分组报文协议（PDP），并保持PDP长期在线，以达到随时随地访问网络、获取实时信息的目的。智能终端的激活附着比、PDP在线时长等话务模型指标远高于普通终端。随着智能终端渗透率的提高，网络PDP数将快速增长，MBB网络将面临越来越大的容量压力。

（2）快速休眠产生大量信令需求

大屏幕、长时间连接、多任务等特性都会消耗大量电能，导致终端待机时间缩短。为了提供更长的待机时间，智能终端采用了快速休眠技术。短时间内（通常3 —10 s）没有数据传输，智能终端便会自动释放无线连接，从无线资源连接态转换到空闲态，以达到省电的目的。后续如有数据发送，必须再次建立无线连接，发送完毕后又再次释放。如此周而复始，则会产生了大量无线连接建立和释放信令。

（3）应用永远在线长期占用资源

随着智能终端的普及，即时通信（IM）、社交网络（SNS）等“永远在线”应用在MBB用户中迅速流行。应用永远在线不仅需要长期占用网络资源（如无线承载资源、PDP资源和IP资源），更严重的是，这类应用的客户端每隔几秒或几分钟就会向服务器发送“心跳消息”以维持其在线状态。这种行为将导致无线连接反复建立和释放，带来大量信令负荷。

为解决网络信令风暴及网络资源被长期占用的问题，目前很多运营商都通过施加压力促使手机操作系统如Android、iOS修改快速休眠时间，以及促使永远在线业务应用如QQ等减少“心跳”频率甚至是取消“心跳”检测消息，但同时会带来如下的两个问题：

（1）防火墙业务流映射表失效问题（NAT保活）

在运营商网络中，移动接入网络与业务网络之间存在一个防火墙系统，如图1所示。如果永远在线业务取消“心跳”消息，并且在防火墙系统中如果一个业务流的转换映射长时间不使用的情况下，防火墙系统则会释放该映射关系条目。此后如果业务产生下行报文，由于防火墙找不到业务流映射表则会丢弃该报文，从而导致业务中断情况。

（2）承载管道长时间无数据时释放问题（承载通道保活）

无线网络会为业务流建立承载通道，比如W3G的 PDP上下文，这些承载自身也有一些保护措施，比如承载通道中长时间无业务流的时候，也会释放承载通道。同样，此后如果业务产生下行报文时，由于防火墙找不到业务流映射表则会丢弃该报文，从而导致业务中断情况。

2 永远在线方案分析

通过分析可以发现，解决网络信令风暴及网络资源被长期占用的问题的关键是解决防火墙业务流映射表失效问题（NAT保活）和承载管道长时间无数据时释放问题（承载通道保活），下面将重点分析研究如何解决两个问题。

（1）防火墙业务流映射表失效问题（NAT保活）应对分析

系统需要控制防火墙业务流映射表条目是否失效。当前，Internet工程任务组（IETF）正在制订的一个叫端口控制协议（PCP）的协议[1]。对于经过网络地址转换（NAT）或防火墙系统的外部报文，该协议能够让一个IPv4或IPv6主机控制如何寻找到本机，以及优化NAT映射保持。

在移动网络中，移动网关（GW）如网关 GPRS支持节点（GGSN）、P-GW在防火墙后面，我们可以通过GW支持PCP客户端协议，发送RCP请求通知NAT设备或防火墙完成对用户永远在线业务流的映射并对该映射保持一定的时长，从而解决防火墙业务流映射表失效问题。

（2）承载管道长时间无数据时释放问题（承载通道保活）应对分析

系统需要能够控制业务承载通道长时间无数据报文而释放的问题。此时要求控制业务流承载通道的GW能够除维持一个系统的定义时长。

在此时长内，GW必须保持承载管道不被释放。同时这个时长也应该与该业务流的NAT映射时长相匹配或者相等。

第三代合作伙伴计划（3GPP）定义了策略及计费控制（PCC）[2]。图2所示为非漫游场景的PCC网络架构图。

在此架构中，应用功能（AF）提供业务流信息，并通过Rx接口要求PCC系统对该业务流提供业务承载网络的资源授权，PCC接收到Rx口的业务流承载授权请求后通过本地规则生成承载网资源授权决策并通过Gx口下发给GW网元进行控制。

在永远在线业务控制中，我们借鉴此架构，由AF网络感知永远在线业务，并由AF通知PCC系统对该永远在线业务流进行NAT保活及承载通道保活控制，PCC则根据本地保活策略生成保活决策并通过Gx口通告GW，最后再由GW完成前述的PCP NAT及承载管道的保活控制。

3永远在线方案及原理

GW支持PCP客户端控制NAT设备或者防火墙，对永远在线业务流所对应的IP转换映射关系保持一定时间，同时GW保持永远在线业务流所对应的承载通道如GTP PDP上下文在对应时间内不释放，就可以解决网络信令风暴及网络资源被长期占用的问题。在此基础上，我们提出了如图3的架构，实现对永远在线业务的管控。

永远在线业务的服务器充当AF，当此类应用服务器发现用户建立永远在线业务连接时，将通过Rx接口向策略与计费规则功能（PCRF）请求该业务流的承载网络的NAT及承载通道的保活。

考虑到Rx接口非常复杂，永远在线类业务服务器提供Rx接口的可行性不高，同时永远在线业务服务器如何寻找用户所在的接入网络中的PCRF设备也是一个难题，所以可以在永远在线类应用及PCRF设备间引入专门的应用功能设备，用于完成简单对象访问协议（SOAP）接口到Rx接口协议的一系列转换，从而降低永远在线业务服务器的实现难度。优化的永远在线业务控制的方案结构如图4所示。

3.1 网元说明

·移动网关

GW指3G核心网中的GGSN，4G核心网中的分组数据网络网关（P-GW）。在永远在线控制中，GW主要支持PCP客户端控制NAT设备或者防火墙对永远在线业务流所对应的IP转换映射关系保持一定时间；同时GW控制永远在线业务流所对应的承载通道如GTP PDP上下文保持对应时间不释放。

·策略与计费规则功能网元

PCRF主要接收AF下发的永远在线业务保活请求，并根据本地保活策略生成保活时长决策并通过Gx口通告GW，再由GW完成PCP NAT及承载管道的保活控制。

·应用功能

AF主要有两个功能：接收永远在线业务应用服务器通过SOAP接口下发的永远在线业务保活请求，并根据用户国际移动用户识别码（IMSI）或者业务源IP寻找PCRF；将SOAP接口转换为3GPP 标准Rx接口。

·永远在线应用服务器

主要包含QQ、新浪微博等应用服务器，主要完成用户永远在线业务会话管理，并通过SOAP接口向本地AF请求用户所在移动接入网络的业务保活处理。

3.2接口说明

·Rx接口

Rx接口是PCRF与AF之间的接口，用于实现AF将应用业务流信息发送给PCRF，以便针对该业务流进行相应的PCC控制。

Rx接口遵循3GPP PCC规范[3]，并进行永远在线能力增强。

·Gx接口

Gx接口是GW/PCEF （GGSN、SAE-GW等）与PCRF之间的PCC会话接口，用于实现策略的动态请求和下发[4]。

Gx接口遵循3GPP PCC规范[5]，并进行永远在线能力增强。

·PCP接口

PCP接口是GW与NAT/防火墙设备之间的接口，用于GW控制NAT设备或者防火墙对永远在线业务流所对应的IP转换映射关系保持一定的时间。

·SOAP接口

该SOAP接口是永远在线应用服务器与AF设备之间的接口，用于在线业务应用服务器请求永远在线业务保活请求。

3.3 实现原理

永远在线业务实现原理流程图如图5所示。

永远在线业务的相关实现流程说明如下：

（1）UE建立/修改承载。

（2）GW向PCRF请求初始控制的策略。

（3）用户访问永远在线业务服务器SP/CP，如果业务服务器SP/CP判断需要NAT保活，则通过SOAP接口通知PCRF该业务需要保活，PCRF完成业务保活时长策略后，将时长返回SP/CP。

（4）PCRF根据本地配置策略，生成该业务NAT及业务承载通道如GTP的保活策略，并根据移动用户识别号码（MSISDN）号码查询Gx会话实例，下发业务NAT及业务承载通道保活策略。

（5）GW 收到PCRF业务保活策略后向NAT发送地址为A的PCP NAT保活请求，请求NAT进行保活。

永远在线业务可能存在的流程为：业务服务器SP/CP在业务流保活时间将到期时，如判断业务流仍需要保活，则通知PCRF继续保活。

（6）业务结束时，业务服务器SP/CP通告PCRF业务结束。

（7）PCRF通知GW取消NAT及业务承载通道保活。

（8）GW 通知防火墙/NAT取消NAT保活。

4 结束语

随着智能的终端的快速普及，运营商解决在线业务对网络资源冲击的问题越来越迫切，从网络系统角度提出解决方案遵循标准架构及实现原理，为运营商解决问题提供了很好的思路，可以很好解决永远在线类应用在减少或取消“心跳”报文的情况下永远在线业务中断问题。

该方案有以下创新及亮点：

（1）从网络控制架构出发，相比其他永远在线方案产业链较短，易于推广。

（2）借助标准架构做少量增强，方案简单高效。

（3）永远在线业务所需移动网络资源授权由移动网络PCC统一决策，统一调度。

参考文献

[1] Wing D，Cheshire S， Boucadair M，et al.Port control protocol （PCP）[S].IETF RFC 6887.

[2] 3GPP TS 23.203. Policy and Charging Control Architecture[S].

[3] 3GPP TS 29.214. Policy and Charging Control over Rx Reference point[S].

[4] 3GPP TS 29.213. Policy and charging control signaling flows and QoS Parameter Mapping[S].

[5] 3GPP TS 29.212. Policy and Charging Control （PCC）； Reference Points[S].