首页 > 专利查询

理解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=bea

参考模型

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

∙ 基于会话的计费——需要在整个服务中维持会话的情况下使用这种方式。通常，账单系统中至少有两个请求：

∙ 发起请求（Initial Request）——用于发起计费活动。该请求包含与用户使用的会话相关的数据。

∙ 中间请求（Intermediary Request）——用于更新当前会话（比如说，在某个语音呼叫中

添加一个视频）。当然，这个请求是可选的。

∙ 最终请求（Final Request）——用于关闭一个会话。

∙ 基于事件的计费——用于在某个特定的事件（比如，充当Redirect Server的SIP AS事件）之后发起一次性账单活动。

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

离线计费：Rf接口