理解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。