理解 IMS 计费架构

作者:Stefano Gioia and Tomasz Radziszewski
07/25/2007

摘要

计费对于任何服务提供商而言都是必不可少的功能,电信运营商也不例外。因此,任何网络都需要包含一组节点来专门实现这一任务。计费可以通过预付费(Prepaid)和后付费(Postpaid)这两种方式实现。虽然预付费解决方案正在日趋盛行,不过后付费的解决方案仍然具有广泛的普及程度。因此,任何面向商业应用的电信网络都必须同时实现这两种方案。此外,随着以IT为基础的服务领域突飞猛进,电话通信之外的服务也如雨后春笋般涌出并不断发展演进。视频电话、无线接入和随需应变视频都是典型的例子。

所有这些服务都需要找到一种计费方式。本文将探讨如何使用各种IMS架构来实现计费功能。文章还将描述如何使用BEA WebLogic SIP Server和Diameter协议实现这些架构。

IMS计费架构

IP多媒体子系统(IP Multimedia Subsystem,IMS)网络使用的是3GPP所定义的架构。图1显示了这一架构中的计费功能。

IMS Charging Architecture
图1. IMS计费架构

图1中的元素可以实现预付费和后付费这两种计费功能。这两种看上去类似的模式实际上从网络视角来说是不同的。其中最大的差异是:当用户想要使用预付费服务时,网络会根据用户的当前账户余额确定是否应该允许该操作。预付费系统具有以下几个要点:

  • 在使用各服务之前,必须获得计费系统的许可(我们称之为交易准许[credit authorization])。
  • 要决定是否应该许可该服务,计费系统必须能够实时获取用户账户余额的信息。在后付费系统中,通常通过收集服务使用情况的数据并于月底处理(成批处理)这些数据来实现这一目的。不过在预付费系统中却不能采用这种方法。在预付费系统中,使用任何服务都必须立即扣除账户的交易金额。
  • 计费系统未在适当的时间内响应时,必须使用一种高效的方式来处理这种情况;不能让用户无限制地等待。
  • 用户必须能够查询账户的余额。

由于预付费系统要求能够实时更新账号的信息,因此这种方式也被称作在线计费。后付费的方式则被称作离线计费。

离线计费

离线计费的框架如图2所示。

IMS Offline Charging Architecture
图2. 离线计费架构

该架构由以下这些节点组成:

  • 计费触发函数(Charging Trigger Function,CTF)——服务元素(Service Element)的组成部分,负责监控服务使用并以此为依据生成计费事件。
  • 计费数据函数(Charging Data Function,CDF)——根据从CTF接收到的事件生成计费数据记录(Charging Data Record,CDR),并将它们传递给CGF。
  • 计费网关函数(Charging Gateway Function,CGF)——负责将CDR持久存储到数据库以及一些预处理和错误检查;它还负责从许多CDF收集CDR并将其发送给账单系统。
  • 账单系统(Billing System)——处理CDR并创建一些最终输出信息,比如可使用这些信息为用户开发票。

在这个架构中,BEA WebLogic SIP Server连同CFT的角色是服务元素。

在线计费

图3显示了在线计费架构中所使用的节点。

IMS Online Charging Architecture
图3.在线计费架构

以下是这些节点的描述:

  • 计费触发函数(Charging Trigger Function,CTF)——与离线计费架构中所使用的CTF类似,不过此处的CTF需要在用户账户余额不足时中断服务。
  • 在线计费系统(Online Charging System,OCS)——实现在线计费函数(Online Charging Function,OCF),它需要依赖以下这些函数:
  • 账户余额管理函数(Account Balance Management Function,ABMF)——存储和更新用户账户的存款信息。
  • 估价函数(Rating Function,RF)——根据网络运营商所定义的价目表确定使用服务的费用。

在这个架构中,BEA WebLogic SIP Server连同CTF的角色是服务元素(Service Element)。

IMS计费信息关联

如今出现了许多不同的架构和网络;为各个网络实体(如 SIP Proxy)提供正确的计费元素地址是一种明确的需求。3GPP定义了两种类型的计费元素,即CDF和OCS。因此,拥有这些元素的多个实例是可行的。识别这些元素的方法是在SIP消息中添加一个头部用于传递地址。

SIP信令中传送的离线和在线函数地址被编码到P-Charging-Function-Addresses中。P-Charging-Function-Addresses头部含有CCF和ECF参数。此处是头部的一个示例:

P-Charging-Function-Addresses:ccf=192.168.100.1;ecf=192.168.100.2

识别和关联计费信息也是有必要的。IMS计费标识符(IMS Charging Identifier,ICID)可以解决这个问题。ICID在同一会话或事务的IMS元素之间共享。ICID参数存储在SIP消息的P-Charging-Vector头部中,以在网络上传输。这个头部是由P-CSCF插入的,并且包含以下参数(按规格描述):

  • IMS计费标识符(IMS Charging Identifier,ICID)——必需。
  • 访问网络计费标识符——用于使用IBM计费数据关联访问网络计费数据。
  • Inter Operator Identifier (IOI)——识别会话或事务中的发信(orig-ioi)网络和收信网络(term-ioi)。该参数由S-CSCF插入,当请求离开网络时会被P-CSCF移除。

此处是P-Charging-Vector头部的一个示例:

P-Charging-Vector: icid-value="655Ayet773+7389088787e"; orig-ioi=bea.net

参考模型

离线和在线计费程序都可以分为两种截然不同的类型:即基于事件的计费(Event-based Charging)和基于会话的计费(Session-based Charging)。

  • 基于会话的计费——需要在整个服务中维持会话的情况下使用这种方式。通常,账单系统中至少有两个请求:
  • 发起请求(Initial Request)——用于发起计费活动。该请求包含与用户使用的会话相关的数据。
  • 中间请求(Intermediary Request)——用于更新当前会话(比如说,在某个语音呼叫中添加一个视频)。当然,这个请求是可选的。
  • 最终请求(Final Request)——用于关闭一个会话。
  • 基于事件的计费——用于在某个特定的事件(比如,充当Redirect Server的SIP AS事件)之后发起一次性账单活动。

在离线计费的例子中,请求是通过Rf协议传输的。而在线计费系统使用的是Ro协议。这两种协议都基于Diameter。这两者之间存在一些差异,其中之一是对与计费会话相关的会话状态的维护。在事件模型中,由于只需处理单个应用程序的事件,因此没有必要维护会话。RFC3588中对会话的定义是“一系列致力于某个特定活动的相关事件”。

离线计费:Rf接口

CTF和CDF之间的事件和会话的离线计费的执行使用了3GPPTS 32.240中所定义的Rf引用点。Rf接口用于非实时的操作,在这些操作中用户所使用的单元不会计入账户。WebLogic SIP Server负责从CTF向CDF发送Diameter请求来实现这点。

这些消息用于向CCF报告账户信息,跟随在DIAMETER方法后面(一个请求,一个应答):

  • 计费请求(Accounting Request,ACR)
  • 计费应答(Accounting Answer,ACA)

根据之前公开的一个模型,基于会话的计费中的Accounting-Record-Type AVP可以含有以下这些值:

  • START_RECORD,用于启动计费会话,通常当应用程序接收到确认初始SIP INVITE的SIP 200 OK消息时。
  • INTERIM_RECORD,用于更新会话,比如,当前SIP对话中的SIP RE-INVITE和/或UPDATE的例子。
  • STOP_RECORD,用于停止账号计费会话,比如,当应用程序接收到一个SIP BYE消息时。

在基于会话的计费系统中,WebLogic SIP Server会自动将Diameter Session链接到当前活动的呼叫状态。这表示Call-id编码在Diameter Session Id中。

Offline Charging - Session-based model
图4.离线计费:基于会话的模型

对于一次性计费事件,Event-Type的值为EVENT_RECORD。

Offline Charging - Event-based model
图5.离线计费:基于事件的模型

在线计费:Ro接口

在线计费的目的是将计费信息提供给OCS,从而能够在许可使用网络资源之前执行存款控制。为此,预付费的订阅者必须存在于OCS中,资源使用要根据这情况记入账单。因此,所有的活动(包括访问被请求的资源使用、确定货币数额或其他单位的数额,以及将这些数额从订阅者的账户中扣除)必须发生在使用资源之前,或至少是在使用资源的过程——即使用资源时必须处于在线状态。根据情况的不同,资源使用结束时必须执行最终评估。因此:必须区分以下两种情况:

  • 直接付款(Direct Debiting)——在这种情况下,交易单位会在单个事务中直接从用户账户中扣除。
  • 单位保留(Unit Reservation)——在这种情况下,OCS会将交易单位保留在用户账户中,这主要是因为OCS不知道所提供的服务需要多少单位。服务终止之后,已用存款金额会从用户账户中扣除,并用最后任何保留和未使用的单位会释放并添加到用户账户中去。

根据以上分类,OCS会识别以下三种场景:

  • 即时事件计费(Immediate Event Charging,IEC)(基于事件的计费)
  • 具有单位保留的事件计费(Event Charging with Unit Reservation,ECUR)(基于事件的计费)
  • 具有单位保留的会话计费(Session Charging with Unit Reservation,SCUR)(基于会话的计费)

基于事件的计费的发生可以保留或不保留订阅者的账户,并且可以将其识别为具有单位保留的事件计费(ECUR)或即时事件计费(IEC)。CC-Request-Type将具有一个EVENT REQUEST值。图6显示了相关的IEC呼叫流。

Online Charging - Event Model (IEC)
图6.在线计费:事件模型(IEC)

图7显示了与ECUR相关的呼叫流。

Event-charging model (ECUR)
图7.事件计费模型(ECUR)

对于具有单位保留的会话计费(SCRU),需要大量的询问,而且直接付款(Direct Debiting)情况下的WebLogic SIP Server(或者SIP-AS之类的普通网络元素)的行为如下所示:提供服务之前,必须向OCS发送一个请求。接收到准许的肯定应答之后,WebLogic SIP Server能够最后支持这个服务。作为任何其他的Diameter请求,存款控制请求被Command-Code字段识别;在本例中,代码设置为272。CC-Request-Type AVP用于识别请求的类型,并且必须出现在所有的CCR消息中。根据RFC4006,CC-Request-Type具有以下这些值:

  • INITIAL_REQUEST——用于启动一个会话,触发SIP方法有INVITE (SCUR)、NOTIFY (ECUR)、MESSAGE (ECUR)、REGISTER (ECUR)、SUBSCRIBE (ECUR)、REFER (ECUR)和PUBLISH (ECUR)。
  • UPDATE REQUEST——用于为已有会话更新信息。通常,当SIP 200 OK消息对SIP INVITE、RE-INVITE或UPDATE确认时,或者当保留配额到期时,有效时间触发或其他事件触发时使用。
  • TERMINATION REQUEST——用于终止一个会话,当我们接收到SIP最终应答(4xx,5xx,6xx),异常中止SIP会话和SIP BYE时使用。
  • EVENT REQUEST——无需维护会话时使用。

如图8所示。

Session-based model (SCUR)
图8.基于会话的模型(SCUR)

示例IMS场景

图9和图10所显示的IMS网络就是一个在线计费场景的示例。当用户A发起呼叫时,用户的电话会向P-CSCF发送一个SIP INVITE请求。P-CSCF是运营商网络的入口点。它将INVITE消息转发到分配给用户的S-CSCF。网络假定P-CSCF知道S-CSCF的地址,因为该信息在用户注册(图中未显示出来)时就从HSS中检索出来了。然后,S-CSCF检测到这个呼叫要求在线计费并将INVITE转发给IMS-GWF(IMS网关函数)。

IMS Example Scenario - Call Set-Up
图9. IMS示例场景:呼叫设置

可以将IMS-GWF看作一种特殊的SIP应用服务器,其作用是提供与OCS的通信。接收到INVITE消息后,IMS-GWF会向OCS发送一个类型INITIAL的CCR,从而为呼叫保留一些存款。OCS使用CCA作为应答,其中含有结果代码DIAMETER_SUCCESS,指示呼叫是允许的。CCA还含有关于准许“服务单位”数量的信息。比如,这些单位可以是呼叫持续时间的秒数。

接收到CCA后,IMS-GWF将之前接收到的INVITE消息转发回给CSCF,然后CSCF再将其传递给网络的被叫方(I-CSCF,S-CSCF,P-CSCF,用户B的电话)。IMS-GWF还通过设置计时器来监控准许单位的使用情况。

然后,用户B的电话开始响铃并使用180 Ringing消息应答INVITE。考虑到简单性,这个图中并未包含这个应答,以及任何100 Trying应答消息。当被叫方应答电话时,将会发送200 OK消息。这个OK消息通过各种不同的网络元素到达用户A的电话,如下图所示。然后,A话机将ACK转发到B端。这样一个呼叫就建立起来了。

IMS Example Scenario - Call tear down
图10. IMS示例场景:呼叫终止

当所有准许单位都被使用后(也就是IMS-GWF中的计时器到期),将发送一个CCR保留这些单位的另一部分。这次的请求类型是UPDATE。OCS发送含有结果代码DIAMETER_SUCCESS的CCA,以许可呼叫继续。如果准许单位是用户账户上最后可用的存款,则OCS应答会含有Final-Unit-Indication AVP。这表示使用完当前准许的单位之后,呼叫会断开连接(或者采用另一种特殊的动作)。但是,在本例中没有出现这个AVP。

在这之后,用户A决定关闭呼叫并发送BYE。BYE将通过P-和S-CSCF转发给网络的呼叫方和IMS-GWF,IMS-GWF会发送类型TERMINATION的CCR给计费系统。这个CCR中包含与使用过的“服务单位”有关的信息(在本例中为呼叫持续时间)。OCS使用CCA作为应答并释放与该会话相关的内部资源(比如说内存、计时器)。用户B的电话使用200 OK消息应答BYE,该消息将传回呼叫方。最后呼叫关闭。

如何在WebLogic SIP Server中实现这些功能

BEA WebLogic SIP Server含有一个简单的支持Diameter协议的API,包括Diameter Base Accounting和Diameter Credit-Control应用程序。本节介绍如何配置和使用Diameter功能。

配置

要使用Diameter功能,需要对WebLogic域进行适当的配置。配置过程由以下几个步骤组成:

  • 启用Diameter自定义资源。
  • 为Diameter创建一个网络通道。
  • 配置Diameter节点和应用程序。

BEA文档页面的参考资料部分详述了这些步骤。

初始化

部署好的应用程序使用Diameter Rf或Ro功能之前,需要分别获取RfApplication或RoApplication对象。这可以通过以下代码实现,假定使用的是SIP或HTTP servlet类:

ServletContext sc = getServletConfig().getServletContext();



Node node = (Node)sc.getAttribute("com.bea.wcp.diameter.Node");



if(node == null) {

    throw new ServletException("Can't get Node. Check diameter.xml");

}



RfApplication rfApp = (RfApplication)

node.getApplication(Charging.RF_APPLICATION_ID);



if(rfApp == null) {

    throw new ServletException("Can't get RfApplication. Check diameter.xml");

}



RoApplication roApp = (RoApplication)

node.getApplication(Charging.RO_APPLICATION_ID);



if(roApp == null) {

    throw new ServletException("Can't get RoApplication. Check diameter.xml");

}

会话处理

Diameter有一个会话的概念。RFC3588中对会话的正式定义是“一系列致力于某个特定活动的相关事件”。实际上,会话使用ACR(START)或CCR(INITIAL)表示开始,并以ACA(STOP)或CCA(TERMINATION)表示结束。在一次性事件的例子中,会话只包含请求和应答。所有消息都属于一个与Session-Id AVP公共值相关的会话。

在WebLogic SIP Server API中,Diameter会话是与com.bea.wcp.diameter.Session对象映射在一起的。Session类处理Session-Id AVP。Rf和Ro接口有两个特殊的子类,即RfSession和RoSession。这两个类只处理特定于Diameter计费的请求和应答。可以使用Rf/RoApplication创建会话对象:

RfApplication rfApp = ...

RfSession rfSes = rfApp.createSession();



RoApplication roApp = ...

RoSession roSes = roApp.createSession();

此外,DIAMETER会话是可序列化的,您可以将其作为属性存储于SipApplicationSession中,反之亦然。WebLogic Sip Server会自动将会话链接到活动的呼叫状态。接收到消息之后,容器将自动检索呼叫状态,并找出Diameter会话。

页面: 1, 2

下一页 »