理解IMS计费架构

理解IMS计费架构

文章工

时间：2007-11-22

具

作者：Stefano Gioia, Tomasz Radziszewski

推荐

浏览次数： 1399

给朋友

本文关键字：sip, WebLogic Communications Platform, WebLogic Server, BEA Workshop, BridgeWater Systems, WebLogic 打印Communications Platform, 计费, 交易, 控制, 电信

文章

摘要

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

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

IMS计费架构

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

1. IMS计费架构（单击图片查看大图）

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

在使用各服务之前，必须获得计费系统的许可（我们称之为交易准许[credit authorization]）。

? 要 决定是否应该许可该服务，计费系统必须能够实时获取用户账户余额的信息。在后付费系统中，通常通过收集服务使用情况的数据并于月底处理（成批处理）这些数 据来实现这一目的。不过在预付费系统中却不能采用这种方法。在预付费系统中，使用任何服务都必须立即扣除账户的交易金额。

? 计费系统未在适当的时间内响应时，必须使用一种高效的方式来处理这种情况；不能让用户无限制地等待。 ? 用户必须能够查询账户的余额。

?

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

离线计费

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

图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显示了在线计费架构中所使用的节点。

图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=\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中。

图4.离线计费：基于会话的模型（单击图片查看大图） 对于一次性计费事件，Event-Type的值为EVENT_RECORD。

图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呼叫流。

图6.在线计费：事件模型（IEC）（单击图片查看大图） 图7显示了与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所示。

图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网关函数）。

图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端。这样一个呼叫就建立起来了。

图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(\

if(node == null) {

throw new ServletException(\ }

RfApplication rfApp = (RfApplication)

node.getApplication(Charging.RF_APPLICATION_ID);

if(rfApp == null) {

throw new ServletException(\diameter.xml\ }

RoApplication roApp = (RoApplication)

node.getApplication(Charging.RO_APPLICATION_ID);

if(roApp == null) {

throw new ServletException(\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会话。

创建Rf请求

创建Rf请求相当简单。让我们从一个基于会话的请求入手。如前所述，获得RfApplication和RfSession之后，我们使用 RfSession对象创建一个新Accounting-Request。由于这是第一个请求，requestType将以值的形式出现： ACR acr = session.createACR(RecordType.START); 创建Event请求的代码为：

ACR acr = session.createACR(RecordType.INTERIM); 创建一个新Accounting-Request时，将会自动填充以下AVP：

属性

值

Session-Id Origin-Host Origin-Realm

自动生成

根据diameter.xml中的节点设置 根据diameter.xml中的节点设置

RfApplication中cdf.host参数的值，设置在diameter.xml中

RfApplication中cdf.realm参数的值，设置在diameter.xml中

Acct-Application-Id 3，表示Diameter Base Accounting Destination-Host Destination-Realm

可以通过调用addAvp方法添加其他AVP：

Acr.addAvp(Attribute.EVENT_TIMESTAMP, new Integer(timestamp));

创建Ro请求

对Ro接口的请求（比如说Credit-Control-Requests）的创建方式非常类似于创建Accounting-Requests的方式。以下这个示例可以说明一切： CCR ccr = roSes.createCCR(RequestType.INITIAL);

注意，Credit Control的请求类型与账户的记录类型有所不同——比如，START和INITIAL。事件请求可直接通过RoApplication创建，而不需要明确地创建一个会话：

CCR eventCcr = roApp.createEventCCR();

在两种情况下，WebLogic SIP Server都会自动设置以下表格中的AVP。

属性 Session-Id Origin-Realm

值

根据diameter.xml中的节点设置 根据diameter.xml中的节点设置

RoApplication中ocs.host参数的值，设置在diameter.xml中

RoApplication中ocs.realm参数的值，设置在diameter.xml中

由createCCR()的参数指示；对于createEventCCR()其值为EVENT_REQUEST (4)

Auth-Application-Id 4，表示Diameter Credit-Control Destination-Host Destination-Realm CC-Request-Type

CC-Request-Number 会话每创建一个CCR该数字就自增1

可以使用与前面相同的方法添加其他AVP。

Diameter Base属性是Attribute类中的静态字段。此外，与计费相关的属性可以在Charging类和CreditControl类中找到。 WebLogic SIP Server并未限制用户使用这些预先定义的属性。可以使用Attribute.define()方法之一来创建新属性。Attribute类包含为所有 基本属性预先定义的常量。以下示例展示了如何添加一个AVP：

public static final Attribute SUBSCRIPTION_ID_TYPE =

Attribute.define(666, \

添加一个已经由用户或容器定义过的AVP时，WebLogic Sip Server会抛出一个异常。添加完所有必要的AVP后，我们最后还要发送CCR。可以使用以下两种方法完成这一操作： ccr.send(); // - or -

CCA answer = (CCA)ccr.sendAndWait();

第二种方法会发送CCR并阻塞执行，直到接收到应答或发生超时。

接收应答

WebLogic SIP Server Diameter API中有两种接收应答的方法。第一种是异步方式，以Request.sendAndWait()方法为基础。这个方法会发送请求并阻塞呼叫线程直到接收 到应答或请求超时。它会返回接收到的应答。发送请求的异步方式适用于阻塞线程不会造成问题的应用程序。

第二种方法是异步分离发送动作和 接收动作。请求是通过调用

Request.send()发送的。这个方法会立刻返回。接收到应答时，该方法会调用其rcvMessage()方法通知监听 程序。这个监听程序必须要实现SessionListener接口，而且必须要在接收到应答之前建立在会话中。以下示例演示了这种方法： //This is a listener class

class MyListener implements SessionListener {

public void rcvMessage(Message message) {

System.out.println(\

if(message.getCommand().equals(CreditControl.CCA)) {

System.out.println(\ } } }

//This code is inside some other (or the same) class, in a method

//responsible for sending the request

//Create session and listener

RoSession roSes = roApp.createSession();

MyListener myListener = new MyListener();

//Set the listener on the session

roSes.setListener(myListener);

//Now create and send a request

CCR ccr = roSes.createCCR(RequestType.INITIAL);

ccr.addAvp(...);

ccr.send();

//send() returns immediately. Answer will be received in

//myListener.rcvMessage()

带有监听程序的实现还可以允许我们接收当前会话内的服务器所发送的请求（比如说，当服务器决定马上关闭会话时所发送的Abort- Session-Request）。请求和应答都以同样的方式传递给监听程序的rcvMessage()方法。由应用程序负责为请求和应答提供不同的行 为。

本文来源：https://www.bwwdw.com/article/zbk.html