理解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="655Ayet773+7389088787e";
orig-ioi=
参考模型
离线和在线计费程序都可以分为两种截然不同的类型：即基于事件的计费（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("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会话。

创建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 根据diameter.xml中的节点设置Origin-Realm 根据diameter.xml中的节点设置Acct-Application-Id 3，表示Diameter Base Accounting
Destination-Host RfApplication中cdf.host参数的值，设置在diameter.xml中
Destination-Realm RfApplication中cdf.realm参数的值，设置在diameter.xml中
可以通过调用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 根据diameter.xml中的节点设置
Origin-Realm 根据diameter.xml中的节点设置
Auth-Application-Id 4，表示Diameter Credit-Control
Destination-Host RoApplication中ocs.host参数的值，设置在diameter.xml中
Destination-Realm RoApplication中ocs.realm参数的值，设置在diameter.xml中
CC-Request-Type 由createCCR()的参数指示；对于createEventCCR()其值为EVENT_REQUEST (4)
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, "Subscription-Id-Type", Type.INTEGER);
添加一个已经由用户或容器定义过的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("Received a message: " + message);
if(message.getCommand().equals(A)) {
System.out.println("The message is a Credit-Control-Answer");
}
}
}
//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()方法。

由应用程序负责为请求和应答提供不同的行为。

错误和超时处理
在设定时间内未收到请求的应答时，WebLogic SIP Server会自动检测超时条件。

diameter.xml中配置了超时的默认值。

还可以使用带参数的send(...)或sendAndWait(...)为各个请求分别指定超时的时间。

WebLogic SIP Server通过创建一个带有结果代码
DIAMETER_UNABLE_TO_DELIVER的响应来处理超时。

实际上，并不会在网络上发送响应，但是会将其传递给发送请求的应用程序。

这种处理超时的方法类似于SIP中所使用的方法。

同样，WebLogic SIP Server可抛出以下两种异常：
∙协议错误时会抛出MessageException异常，比如说无效的消息格式
∙AVP无效和/或丢失时会抛出AvpException异常
调试应用程序
WebLogic SIP Server中的日志记录工具可用于跟踪传入和传出消息。

您可以使用控制台配置消息调试。

此外，也可以通过在脚本文件（类Unix的机器中为sh文件， Windows平台中则为cmd）中的-Ddiameter.Debug=true选项来设置消息调试。

调试消息将直接发送给控制台。

除了在WLSS中设置调试之外，使用网络嗅探程序也是大有帮助。

这种类型的程序可以显示在网络中传输的报文。

Wireshark（原来称作Ethereal）可能是最受欢迎的嗅探程序，它是一款免费软件。

示例应用程序
Ro和Rf接口的示例应用程序可以从此处下载。

这个应用程序为一个SIP 会话提供了Diameter Ro/Rf计费功能。

接收到一个INVITE时请求，应用程序会通过发送一个类型INITIAL的CCR来启动会话。

然后，用完所有准许的存款后，应用程序会通过发送UPDATE CCR来请求新的存款。

接收到BYE消息时，应用程序会通过发送TERMINATION CCR来关闭计费会话。

在存款用完的情况下，应用程序也会关闭会话。

如果CCA中接收到一个Final-Unit-Indication AVP，并且所有准许额度都已用完，则应用程序会通过发送BYE消息来断开SIP会话。

应用程序还会发送一个TERMINATION CCR来关闭Diameter会话。

BEA模拟程序和Rf接口
BEA WebLogic Sip Server提供了一种简单的测试方法，可以使用一个Rf 接口的独立的模拟程序测试自己的应用程序。

模拟程序可以作为独立的应用程序运行，模拟程序的离线计费接口为
com.bea.wcp.diameter.charging.RfSimulator。

此外，BEA还提供了一个HSS模拟程序用于存储与服务相关的数据，可以使用相同的方式运行该模拟程序。

注意，这个模拟程序是用于测试目的的，并且只支持RepositoryData和 PSI。

HSS模拟程序为
com.bea.wcp.diameter.sh.HSSSimulator。

这两种模拟的命令行选项如下所示：
∙-r, -real 节点实际名称
∙-h, -host 主机身份
∙-a, -address 节点监听地址
∙-p, -port 节点监听端口
∙-d, -debug 启用调试
∙-m, -mdebug 启用消息调试
以下示例演示了如何运行一个独立的BEA Rf模拟程序：
java uncher -apps
com.bea.wcp.diameter.charging.RfSimulator -r -h simulator -p 3900 -d -m
我们也可以运行多个模拟程序，比如使用以下脚本运行HSS模拟程序：
java uncher -apps
com.bea.wcp.diameter.charging.RfSimulator,com.bea.wcp.diameter.sh.Hss Simulator -h simulator -r -p 3900 -d -m
记住要先运行\sipserver30\server\bin\ directory目录下的setWLSEnv 脚本。

业已证实的互操作性
Ericpol Telecom已成功将其运行于BEA WLSS 3.0之上的IMS预付费解决方案（IMS Prepaid Solution）与Amdocs IMS计费解决方案（Amdocs IMS Charging Solution）集成在一起。

IMS预付费解决方案通过其各组件的集成和相互协作提供了一种具有丰富特性的、兼容IMS的、可互操作的、电信级的解决方案。

在这种集成场景中，IMS预付费解决方案通过Rf和Ro接口与Amdocs IMS计费解决方案相互通信。

其网络结构如下所示：
图11. BEA-Ericpol-Amdocs IOT的网络架构（单击图片查看大图）
BEA-Ericpol IMS Prepaid和Amdocs Charging之间的互操作性测试（interoperability testing，IOT）包含以下两个阶段：离线和在线计费。

各个场景的消息流包含在本文结尾的附加文件中。

IOT已经证实WebLogic SIP Server中的Diameter实现符合协议规范。

它还显示对Java API的完全编程控制使得Diameter实现极具灵活性。

在PoC过程中需要进行几次小更改。

这些更改的实现快速而简单。

IOT中所使用的Amdocs IMS计费解决方案基于Amdocs在线计费（Amdocs Online Charging）系统。

与3GPP标准一致，这种在线计费功能通过Diameter 接口与核心IMS网络进行交互（在线计费系统接口的Diameter 引用点）。

此外，Amdocs IMS计费解决方案中的两种关键组件是Amdocs Rating和Amdocs Balance Manager。

要与IMS呼叫会话控制函数进行交互（以实现离线计费），针对IMS 的3GPP标准定义了以下两个组件：计费数据函数（charging data function，CDF）和计费网关函数（charging gateway function，CGF）。

这些函数可以构造、关联和格式化与计费事件相关的信息，并将这些信息传递给账单系统。

Amdocs Service Mediation Manager是Amdocs IMS计费解决方案的一部分，它经过改进后符合3GPP标准并且其本身可以提供CDF和CGF功能。

如今，服务提供商开始争先实现IMS架构并提供越来越多的复杂服务，与此同时，他们也不得不开始面对各种问题：如收益率、定价、资本回报率和服务质量等等。

Amdocs使用了一套横向的、统一的、模块化的IMS就绪计费产品，实现了一种完善的IMS计费方式，并且很好地解决了上述问题。

如Ericpol 和BEA的IOT测试所示，Amdocs计费解决方案具有以下优点：
∙正确地将任何业务线实时地聚合在一起
∙复杂IMS服务和产品快速投放市场
∙灵活地提供创新和多合一的服务
∙聚合调解（Converged mediation）
∙严格遵从IMS标准
下载
∙下载Chargi计费示例——使用Ro和Rf接口构建示例计费应用程序的源代码演示。

∙Ericpol和Amdocs之间的用例——IOT中使用的示例用例。

结束语
已经证实，Diameter成功克服了RADIUS的局限。

它如今已成为IMS标准的一部分。

基于IP和电话技术的新服务的开发现正在迅速发展，每一项服务都需要计费功能。

因此，基于Diameter计费的普及指日可待。

通过阅读本文，您应该了解了Ro和Rf接口的基本概念，并知道如何使用BEA WebLogic SIP Server处理它们。

现在，您已经可以借助所学的知识着手开发自己的应用程序
致谢
作者感谢Rafi Kretchmer，Amdocs的Revenue Management Product & Solutions Marketing部门的产品营销总监。

Rafi负责为Amdocs的产品收益管理制订IMS业务战略，包括行业领先的Amdocs Billing产品组合。

参考资料
∙WLSS 3.0 Doc——官方WebLogic Sip Server 3.0文档
∙WLSS 3.0 Doc——Diameter配置
∙WLSS 3.0 Doc——配置和使用Rf应用程序
∙WLSS 3.0 Doc——配置和使用Ro应用程序
∙WLSS 3.0 Doc——群集环境中的Diameter处理
∙3GPP TS 32.240——计费架构和基本原理
∙3GPP TS 32.260——IMS计费
∙RFC 3588——Diameter基本协议
∙RFC 4006——Diameter Credit-Control应用程序
∙Wireshark——开源的网络协议分析程序
∙WLSS 3.0 Doc——Dev2Dev网站上的WebLogic Communications Platform 开发人员中心
术语表
3GPP - 3rd Generation Partnership Project
AAA - Authentication, Authorization, and Accounting
ABMF - Account Balance Management Function
ACA - Accounting Answer
ACR - Accounting Request
API - Application Programming Interface
AS - Application Server
AVP - Attribute-Value Pair
BGCF - Breakout Gateway Control Function
CCA - Credit-Control Answer
CCR - Credit-Control Request
CDF - Charging Data Function
CDR - Charging Data Record
CGF - Charging Gateway Function
CSCF - Call Session Control Function
CTF - Charging Trigger Function
DCC - Diameter Credit-Control application
GGSN - Gateway GPRS Support Node
GPRS - General Packet Radio Service
HSS - Home Subscriber Server
HTTP - HyperText Transfer Protocol
ICID - IMS Charging Identifier
I-CSCF - Interrogating-CSCF
IMS - IP Multimedia Subsystem
IMS-GWF - IMS Gateway Function
MGCF - Media Gateway Control Function
MRFC - Media Resource Function Controller
OCF - Online Charging Function
OCS - Online Charging System
P-CSCF - Proxy-CSCF
RF - Rating Function
RFC - Request For Comments
S-CSCF - Serving-CSCF
SGSN - Serving GPRS Support Node
SIP - Session Initiation Protocol
WLSS - BEA WebLogic SIP Server
原文出处：/pub/a/2007/07/IMC-charging-architecture.html
作者简介
Stefano Gioia Stefano Gioia 是EMEA 的BEA WebLogic Sip Server 技术专家。

他把主要精力都放在让IMS 及其工作人员和合作伙伴能够跨越欧洲、中东和非洲的努力上。

Tomasz Radziszewski 是Ericpol Telecom 的软件研发工作师。