计费对于任何服务提供商而言都是必不可少的功能,电信运营商也不例外。因此,任何网络都需要包含一组节点来专门实现这一任务。计费可以通过预付费(Prepaid)和后付费(Postpaid)这两种方式实现。虽然预付费解决方案正在日趋盛行,不过后付费的解决方案仍然具有广泛的普及程度。因此,任何面向商业应用的电信网络都必须同时实现这两种方案。此外,随着以IT为基础的服务领域突飞猛进,电话通信之外的服务也如雨后春笋般涌出并不断发展演进。视频电话、无线接入和随需应变视频都是典型的例子。 所有这些服务都需要找到一种计费方式。本文将探讨如何使用各种IMS架构来实现计费功能。文章还将描述如何使用BEA WebLogic SIP Server和Diameter协议实现这些架构。 IMS计费架构IP多媒体子系统(IP Multimedia Subsystem,IMS)网络使用的是3GPP所定义的架构。图1显示了这一架构中的计费功能。 1. IMS计费架构(单击图片查看大图) 图1中的元素可以实现预付费和后付费这两种计费功能。这两种看上去类似的模式实际上从网络视角来说是不同的。其中最大的差异是:当用户想要使用预付费服务时,网络会根据用户的当前账户余额确定是否应该允许该操作。预付费系统具有以下几个要点:
由于预付费系统要求能够实时更新账号的信息,因此这种方式也被称作在线计费。后付费的方式则被称作离线计费。 离线计费离线计费的框架如图2所示。 图2. 离线计费架构(单击图片查看大图) 该架构由以下这些节点组成:
在这个架构中,BEA WebLogic SIP Server连同CFT的角色是服务元素。 在线计费图3显示了在线计费架构中所使用的节点。 图3.在线计费架构(单击图片查看大图) 以下是这些节点的描述:
在这个架构中,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插入的,并且包含以下参数(按规格描述):
此处是P-Charging-Vector头部的一个示例: P-Charging-Vector: icid-value="655Ayet773+7389088787e"; orig-ioi=bea.net 参考模型离线和在线计费程序都可以分为两种截然不同的类型:即基于事件的计费(Event-based Charging)和基于会话的计费(Session-based Charging)。
在离线计费的例子中,请求是通过Rf协议传输的。而在线计费系统使用的是Ro协议。这两种协议都基于Diameter。这两者之间存在一些差异,其中之一是对与计费会话相关的会话状态的维护。在事件模型中,由于只需处理单个应用程序的事件,因此没有必要维护会话。RFC3588中对会话的定义是“一系列致力于某个特定活动的相关事件”。 离线计费:Rf接口CTF和CDF之间的事件和会话的离线计费的执行使用了3GPPTS 32.240中所定义的Rf引用点。Rf接口用于非实时的操作,在这些操作中用户所使用的单元不会计入账户。WebLogic SIP Server负责从CTF向CDF发送Diameter请求来实现这点。 这些消息用于向CCF报告账户信息,跟随在DIAMETER方法后面(一个请求,一个应答):
根据之前公开的一个模型,基于会话的计费中的Accounting-Record-Type AVP可以含有以下这些值:
在基于会话的计费系统中,WebLogic SIP Server会自动将Diameter Session链接到当前活动的呼叫状态。这表示Call-id编码在Diameter Session Id中。 图4.离线计费:基于会话的模型(单击图片查看大图) 对于一次性计费事件,Event-Type的值为EVENT_RECORD。 图5.离线计费:基于事件的模型(单击图片查看大图) 在线计费:Ro接口在线计费的目的是将计费信息提供给OCS,从而能够在许可使用网络资源之前执行存款控制。为此,预付费的订阅者必须存在于OCS中,资源使用要根据这情况记入账单。因此,所有的活动(包括访问被请求的资源使用、确定货币数额或其他单位的数额,以及将这些数额从订阅者的账户中扣除)必须发生在使用资源之前,或至少是在使用资源的过程——即使用资源时必须处于在线状态。根据情况的不同,资源使用结束时必须执行最终评估。因此:必须区分以下两种情况:
根据以上分类,OCS会识别以下三种场景:
基于事件的计费的发生可以保留或不保留订阅者的账户,并且可以将其识别为具有单位保留的事件计费(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具有以下这些值:
如图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域进行适当的配置。配置过程由以下几个步骤组成:
BEA文档页面的 参考资料 部分详述了这些步骤。 初始化部署好的应用程序使用Diameter Rf或Ro功能之前,需要分别获取RfApplication或RoApplication对象。这可以通过以下代码实现,假定使用的是SIP或HTTP servlet类: ServletContext sc = getServletConfig().getServletContext(); 会话处理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:
可以通过调用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。
可以使用与前面相同的方法添加其他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 带有监听程序的实现还可以允许我们接收当前会话内的服务器所发送的请求(比如说,当服务器决定马上关闭会话时所发送的Abort-Session-Request)。请求和应答都以同样的方式传递给监听程序的rcvMessage()方法。由应用程序负责为请求和应答提供不同的行为。 错误和超时处理在设定时间内未收到请求的应答时,WebLogic SIP Server会自动检测超时条件。diameter.xml中配置了超时的默认值。还可以使用带参数的send(...)或sendAndWait(...)为各个请求分别指定超时的时间。 WebLogic SIP Server通过创建一个带有结果代码DIAMETER_UNABLE_TO_DELIVER的响应来处理超时。实际上,并不会在网络上发送响应,但是会将其传递给发送请求的应用程序。这种处理超时的方法类似于SIP中所使用的方法。 同样,WebLogic SIP Server可抛出以下两种异常:
调试应用程序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。 这两种模拟的命令行选项如下所示:
以下示例演示了如何运行一个独立的BEA Rf模拟程序: java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator -r -h simulator -p 3900 -d -m 我们也可以运行多个模拟程序,比如使用以下脚本运行HSS模拟程序: java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator,com.bea.wcp.diameter.sh.HssSimulator -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计费解决方案具有以下优点:
结束语已经证实,Diameter成功克服了RADIUS的局限。它如今已成为IMS标准的一部分。基于IP和电话技术的新服务的开发现正在迅速发展,每一项服务都需要计费功能。因此,基于Diameter计费的普及指日可待。 通过阅读本文,您应该了解了Ro和Rf接口的基本概念,并知道如何使用BEA WebLogic SIP Server处理它们。现在,您已经可以借助所学的知识着手开发自己的应用程序 致谢作者感谢 Rafi Kretchmer,Amdocs的Revenue Management Product & Solutions Marketing部门的产品营销总监。Rafi负责为Amdocs的产品收益管理制订IMS业务战略,包括行业领先的Amdocs Billing产品组合。 参考资料
术语表3GPP - 3rd Generation Partnership Project 原文出处:http://dev2dev./pub/a/2007/07/IMC-charging-architecture.html
|
|