了解 IMS 计费架构

作者：Stefano Gioia 和 Tomasz Radziszewski
2007 年 7 月 25 日

摘要

计费对于每个服务提供商而言都是必不可少的功能，电信运营商也不例外。因此，任何网络都必须包含一组节点来专门实现这一任务。计费可以采用预付费或后付费的方式实现。虽然预付费解决方案日趋盛行，但后付费解决方案仍在广泛使用。因此，任何面向商业应用的电信网络都必须同时实现这两种解决方案。此外，基于 IT 的服务领域发展迅速，电话通信之外的服务也不断涌现。视频电话、无线接入和视频点播便是几个示例。

所有这些服务都需要一种计费方式。本文将介绍各种可用于计费的 IMS 架构。本文还将介绍如何使用 BEA WebLogic SIP Server 和 Diameter 协议实现这些架构。

IMS 计费架构

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

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

图 1 中的元素可以实现预付费和后付费这两种计费功能。这两种看上去类似的模式实际上从网络角度看截然不同。最重要的差别是：当用户想要使用预付费服务时，网络必须根据用户的当前账户余额确定是否应该允许此操作。预付费系统具有以下特点：

  • 在使用每个服务之前，必须获得计费系统的许可（这称为信用授权）。
  • 要决定是否应许可服务，计费系统必须实时了解用户的账户余额。在后付费系统中，通常通过收集服务使用情况的数据并于月底处理（批处理）这些数据来实现这一目的。不过在预付费系统中却不能采用这种方法。对于预付费服务，每次使用事件都必须立即从账户中扣除消费金额。
  • 计费系统未在适当的时间内响应时，必须有高效的方法来处理这种情况；用户不能无限制地等待。
  • 用户必须能够查询账户余额。

由于预付费方案需要实时更新账户信息，因此这种方式也称为在线计费。后付费则称为离线计费。

离线计费

图 2 显示了离线计费的框架。

IMS 离线计费架构
图 2. 离线计费架构（单击图像查看大图）

此类型的计费架构由以下节点组成：

  • 计费触发功能 (CTF) — 服务元素的一部分，负责监视服务使用并据此生成计费事件。
  • 计费数据功能 (CDF) — 负责根据从 CTF 接收的事件生成 CDR（计费数据记录），并将它们传输给 CGF。
  • 计费网关功能 (CGF) — 负责 CDR 的持久存储以及一些预处理和错误检查；它还从许多 CDF 中收集 CDR 并将它们发送到账单系统。
  • 账单系统 — 处理 CDR 以产生一些最终输出，例如可以使用这些输出为客户开具发票。

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

在线计费

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

IMS 在线计费架构
图 3. 在线计费架构（单击图像查看大图）

以下是这些节点的说明：

  • 计费触发功能 (CTF) — 类似于离线计费中使用的 CTF，但此处的 CTF 必须能够在用户账户余额不足时中断服务。
  • 在线计费系统 (OCS) — 实现在线计费功能 (OCF)，它依赖于以下功能：
    • 账户余额管理功能 (ABMF) — 存储和更新用户账户的存款余额。
    • 换算功能 (RF) — 根据网络运营商定义的价目表确定使用服务的费用。

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

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 计费标识符 (ICID) 可以解决此问题，同一会话/事务的 IMS 元素之间共享 ICID。ICID 参数存储在 SIP 消息的 P-Charging-Vector 头中，通过网络进行传输。此头由 P-CSCF 插入，并且包含以下参数（按规范描述）：

  • IMS 计费标识符 (ICID) — 必需。
  • 接入网络计费标识符 — 用于将接入网络计费数据与 IMS 计费数据相关联。
  • 运营商间标识符 (IOI) — 标识会话/事务中的发端 (orig-ioi) 网络和终端 (term-ioi) 网络。此参数由 S-CSCF 插入，当请求离开网络时将由 P-CSCF 删除。

以下是此类头的一个示例：

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

参考模型

在线和离线计费过程都可以分为两种截然不同的类型：基于事件的计费和基于会话的计费。

  • 基于会话的计费 — 需要在整个服务中维护会话时使用。通常，至少向账单系统发送两个请求：
    • 初始请求 — 用于发送计费活动开始的信号。此请求类型包含与用户使用的会话相关的数据。
    • 中间请求 — 用于更新当前会话（例如，向语音呼叫中添加视频）。当然，此请求是可选的。
    • 最终请求 — 用于关闭会话。
  • 基于事件的计费 — 用于在某个特定事件（例如，SIP AS 充当重定向服务器）之后发送一次性账单活动的信号。

对于离线计费，请求通过 Rf 协议进行传输。对于在线计费，使用的协议为 Ro。这两种协议都基于 Diameter。这两者之间的一个差别就是对与计费会话关联的会话状态的维护。对于事件模型，由于一个事件只涉及单个应用程序，因此不需要维护会话。根据 RFC3588，会话的概念为“一系列致力于某个特定活动的相关事件”。

离线计费：Rf 接口

CTF 和 CDF 之间的事件和会话的离线计费均使用 3GPPTS 32.240 中定义的 Rf 参考点执行。Rf 接口用于非实时操作，其中用户使用的单位不会计入用户账户。这通过从 WebLogic SIP Server（用作 CTF）向 CDF 发送 Diameter 请求来实现。

这些消息用于向 CCF 报告账户信息，跟随在 Diameter 方法后面（一个请求，一个应答）：

  • 计费请求 (ACR)
  • 计费应答 (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 会话链接到当前活动的呼叫状态。这意味着呼叫 ID 编码在 Diameter 会话 ID 中。

离线计费 — 基于会话的模型
图 4. 离线计费：基于会话的模型（单击图像查看大图）

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

离线计费 — 基于事件的模型
图 5. 离线计费：基于事件的模型（单击图像查看大图）

在线计费：Ro 接口

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

  • 直接扣除 — 在单个事务中，计数单位额度直接从用户账户中扣除。
  • 单位保留 — 在这种情况下，OCS 在用户账户中保留计数单位额度，这主要是因为 OCS 不知道提供的服务需要多少个计数单位。服务终止之后，已用额度从用户账户中扣除，最后释放所有保留的和未使用的计数单位并将其添加到用户账户中。

根据以上分类，OCS 可识别以下三种场景：

  • 即时事件计费 (IEC)（属于基于事件的计费类型）
  • 具有单位保留的事件计费 (ECUR)（属于基于事件的计费类型）
  • 具有单位保留的会话计费 (SCUR)（属于基于会话的计费类型）

发生基于事件的计费过程时，可以在用户账户中保留或不保留计数单位数量，并且可以将计费过程标识为具有单位保留的事件计费 (ECUR) 或即时事件计费 (IEC)。CC-Request-Type 将具有 EVENT REQUEST 值。图 6 显示了相关的 IEC 呼叫流。

在线计费 — 事件模型 (IEC)
图 6. 在线计费：事件模型 (IEC)（单击图像查看大图）

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

事件计费模型 (ECUR)
图 7. 事件计费模型 (ECUR)（单击图像查看大图）

对于具有单位保留的会话计费 (SCUR)，需要大量查询，并且直接扣除情况下的 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 显示了 SCUR。

基于会话的模型 (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 示例场景 — 呼叫建立
图 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，此 ACK 转发到 B 端。现在就建立了呼叫。

IMS 示例场景 — 呼叫终止
图 10. IMS 示例终止：呼叫终止（单击图像查看大图）

当使用完所有准许单位后（即，IMS-GWF 中的计时器到期），将发送一个 CCR 以保留另一部分单位。此时，请求类型为 UPDATE。OCS 发送包含结果代码 DIAMETER_SUCCESS 的 CCA，以允许呼叫继续。如果准许的单位是用户账户上最后可用的余额，则 OCS 应答中将包含 Final-Unit-Indication AVP。这表示使用完当前准许的单位之后，呼叫必须断开（或者必须采取其他特定操作）。但是，在我们的示例中没有出现此 AVP。

此后，用户 A 决定关闭呼叫并发送 BYE。BYE 通过 P-CSCF 和 S-CSCF 转发到网络的主叫方及 IMS-GWF，IMS-GWF 将类型为 TERMINATION 的 CCR 发送到计费系统。此 CCR 包括有关使用的“服务单位”的信息（即，在本例中为有关呼叫持续时间的信息）。OCS 使用 CCA 进行响应并释放与此会话相关的内部资源（例如，内存、计时器）。用户 B 的电话使用 200 OK 响应 BYE，200 OK 将传递回主叫方。呼叫关闭。

如何在 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 有一个会话的概念。根据 RFC 3588，会话的正式定义为“一系列致力于某个特定活动的相关事件”。实际上，会话以 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

下一页 »