計費對于任何服務(wù)提供商而言都是必不可少的功能，電信運營(yíng)商也不例外。因此，任何網(wǎng)絡(luò )都需要包含一組節點(diǎn)來(lái)專(zhuān)門(mén)實(shí)現這一任務(wù)。計費可以通過(guò)預付費（Prepaid）和后付費（Postpaid）這兩種方式實(shí)現。雖然預付費解決方案正在日趨盛行，不過(guò)后付費的解決方案仍然具有廣泛的普及程度。因此，任何面向商業(yè)應用的電信網(wǎng)絡(luò )都必須同時(shí)實(shí)現這兩種方案。此外，隨著(zhù)以IT為基礎的服務(wù)領(lǐng)域突飛猛進(jìn)，電話(huà)通信之外的服務(wù)也如雨后春筍般涌出并不斷發(fā)展演進(jìn)。視頻電話(huà)、無(wú)線(xiàn)接入和隨需應變視頻都是典型的例子。
所有這些服務(wù)都需要找到一種計費方式。本文將探討如何使用各種IMS架構來(lái)實(shí)現計費功能。文章還將描述如何使用BEA WebLogic SIP Server和Diameter協(xié)議實(shí)現這些架構。
IP多媒體子系統（IP Multimedia Subsystem，IMS）網(wǎng)絡(luò )使用的是3GPP所定義的架構。圖1顯示了這一架構中的計費功能。
1. IMS計費架構（單擊圖片查看大圖）
圖1中的元素可以實(shí)現預付費和后付費這兩種計費功能。這兩種看上去類(lèi)似的模式實(shí)際上從網(wǎng)絡(luò )視角來(lái)說(shuō)是不同的。其中最大的差異是：當用戶(hù)想要使用預付費服務(wù)時(shí)，網(wǎng)絡(luò )會(huì )根據用戶(hù)的當前賬戶(hù)余額確定是否應該允許該操作。預付費系統具有以下幾個(gè)要點(diǎn)：
由于預付費系統要求能夠實(shí)時(shí)更新賬號的信息，因此這種方式也被稱(chēng)作在線(xiàn)計費。后付費的方式則被稱(chēng)作離線(xiàn)計費。
離線(xiàn)計費的框架如圖2所示。
圖2. 離線(xiàn)計費架構（單擊圖片查看大圖）
該架構由以下這些節點(diǎn)組成：
在這個(gè)架構中，BEA WebLogic SIP Server連同CFT的角色是服務(wù)元素。
圖3顯示了在線(xiàn)計費架構中所使用的節點(diǎn)。
圖3.在線(xiàn)計費架構（單擊圖片查看大圖）
以下是這些節點(diǎn)的描述：
在這個(gè)架構中，BEA WebLogic SIP Server連同CTF的角色是服務(wù)元素（Service Element）。
如今出現了許多不同的架構和網(wǎng)絡(luò )；為各個(gè)網(wǎng)絡(luò )實(shí)體（如 SIP Proxy）提供正確的計費元素地址是一種明確的需求。3GPP定義了兩種類(lèi)型的計費元素，即CDF和OCS。因此，擁有這些元素的多個(gè)實(shí)例是可行的。識別這些元素的方法是在SIP消息中添加一個(gè)頭部用于傳遞地址。
SIP信令中傳送的離線(xiàn)和在線(xiàn)函數地址被編碼到P-Charging-Function-Addresses中。P-Charging-Function-Addresses頭部含有CCF和ECF參數。此處是頭部的一個(gè)示例：
P-Charging-Function-Addresses：ccf=192.168.100.1；ecf=192.168.100.2
識別和關(guān)聯(lián)計費信息也是有必要的。IMS計費標識符（IMS Charging Identifier，ICID）可以解決這個(gè)問(wèn)題。ICID在同一會(huì )話(huà)或事務(wù)的IMS元素之間共享。ICID參數存儲在SIP消息的P-Charging-Vector頭部中，以在網(wǎng)絡(luò )上傳輸。這個(gè)頭部是由P-CSCF插入的，并且包含以下參數（按規格描述）：
此處是P-Charging-Vector頭部的一個(gè)示例：
P-Charging-Vector: icid-value="655Ayet773+7389088787e"; orig-ioi=bea.net
離線(xiàn)和在線(xiàn)計費程序都可以分為兩種截然不同的類(lèi)型：即基于事件的計費（Event-based Charging）和基于會(huì )話(huà)的計費（Session-based Charging）。
在離線(xiàn)計費的例子中，請求是通過(guò)Rf協(xié)議傳輸的。而在線(xiàn)計費系統使用的是Ro協(xié)議。這兩種協(xié)議都基于Diameter。這兩者之間存在一些差異，其中之一是對與計費會(huì )話(huà)相關(guān)的會(huì )話(huà)狀態(tài)的維護。在事件模型中，由于只需處理單個(gè)應用程序的事件，因此沒(méi)有必要維護會(huì )話(huà)。RFC3588中對會(huì )話(huà)的定義是“一系列致力于某個(gè)特定活動(dòng)的相關(guān)事件”。
CTF和CDF之間的事件和會(huì )話(huà)的離線(xiàn)計費的執行使用了3GPPTS 32.240中所定義的Rf引用點(diǎn)。Rf接口用于非實(shí)時(shí)的操作，在這些操作中用戶(hù)所使用的單元不會(huì )計入賬戶(hù)。WebLogic SIP Server負責從CTF向CDF發(fā)送Diameter請求來(lái)實(shí)現這點(diǎn)。
這些消息用于向CCF報告賬戶(hù)信息，跟隨在DIAMETER方法后面（一個(gè)請求，一個(gè)應答）：
根據之前公開(kāi)的一個(gè)模型，基于會(huì )話(huà)的計費中的Accounting-Record-Type AVP可以含有以下這些值：
在基于會(huì )話(huà)的計費系統中，WebLogic SIP Server會(huì )自動(dòng)將Diameter Session鏈接到當前活動(dòng)的呼叫狀態(tài)。這表示Call-id編碼在Diameter Session Id中。
圖4.離線(xiàn)計費：基于會(huì )話(huà)的模型（單擊圖片查看大圖）
對于一次性計費事件，Event-Type的值為EVENT_RECORD。
圖5.離線(xiàn)計費：基于事件的模型（單擊圖片查看大圖）
在線(xiàn)計費的目的是將計費信息提供給OCS，從而能夠在許可使用網(wǎng)絡(luò )資源之前執行存款控制。為此，預付費的訂閱者必須存在于OCS中，資源使用要根據這情況記入賬單。因此，所有的活動(dòng)（包括訪(fǎng)問(wèn)被請求的資源使用、確定貨幣數額或其他單位的數額，以及將這些數額從訂閱者的賬戶(hù)中扣除）必須發(fā)生在使用資源之前，或至少是在使用資源的過(guò)程——即使用資源時(shí)必須處于在線(xiàn)狀態(tài)。根據情況的不同，資源使用結束時(shí)必須執行最終評估。因此：必須區分以下兩種情況：
根據以上分類(lèi)，OCS會(huì )識別以下三種場(chǎng)景：
基于事件的計費的發(fā)生可以保留或不保留訂閱者的賬戶(hù)，并且可以將其識別為具有單位保留的事件計費（ECUR）或即時(shí)事件計費（IEC）。CC-Request-Type將具有一個(gè)EVENT REQUEST值。圖6顯示了相關(guān)的IEC呼叫流。
圖6.在線(xiàn)計費：事件模型（IEC）（單擊圖片查看大圖）
圖7顯示了與ECUR相關(guān)的呼叫流。
圖7.事件計費模型（ECUR）（單擊圖片查看大圖）
對于具有單位保留的會(huì )話(huà)計費（SCRU），需要大量的詢(xún)問(wèn)，而且直接付款（Direct Debiting）情況下的WebLogic SIP Server（或者SIP-AS之類(lèi)的普通網(wǎng)絡(luò )元素）的行為如下所示：提供服務(wù)之前，必須向OCS發(fā)送一個(gè)請求。接收到準許的肯定應答之后，WebLogic SIP Server能夠最后支持這個(gè)服務(wù)。作為任何其他的Diameter請求，存款控制請求被Command-Code字段識別；在本例中，代碼設置為272。CC-Request-Type AVP用于識別請求的類(lèi)型，并且必須出現在所有的CCR消息中。根據RFC4006，CC-Request-Type具有以下這些值：
如圖8所示。
圖8.基于會(huì )話(huà)的模型（SCUR）（單擊圖片查看大圖）
圖9和圖10所顯示的IMS網(wǎng)絡(luò )就是一個(gè)在線(xiàn)計費場(chǎng)景的示例。當用戶(hù)A發(fā)起呼叫時(shí)，用戶(hù)的電話(huà)會(huì )向P-CSCF發(fā)送一個(gè)SIP INVITE請求。P-CSCF是運營(yíng)商網(wǎng)絡(luò )的入口點(diǎn)。它將INVITE消息轉發(fā)到分配給用戶(hù)的S-CSCF。網(wǎng)絡(luò )假定P-CSCF知道S-CSCF的地址，因為該信息在用戶(hù)注冊（圖中未顯示出來(lái)）時(shí)就從HSS中檢索出來(lái)了。然后，S-CSCF檢測到這個(gè)呼叫要求在線(xiàn)計費并將INVITE轉發(fā)給IMS-GWF（IMS網(wǎng)關(guān)函數）。
圖9. IMS示例場(chǎng)景：呼叫設置（單擊圖片查看大圖）
可以將IMS-GWF看作一種特殊的SIP應用服務(wù)器，其作用是提供與OCS的通信。接收到INVITE消息后，IMS-GWF會(huì )向OCS發(fā)送一個(gè)類(lèi)型INITIAL的CCR，從而為呼叫保留一些存款。OCS使用CCA作為應答，其中含有結果代碼DIAMETER_SUCCESS，指示呼叫是允許的。CCA還含有關(guān)于準許“服務(wù)單位”數量的信息。比如，這些單位可以是呼叫持續時(shí)間的秒數。
接收到CCA后，IMS-GWF將之前接收到的INVITE消息轉發(fā)回給CSCF，然后CSCF再將其傳遞給網(wǎng)絡(luò )的被叫方（I-CSCF，S-CSCF，P-CSCF，用戶(hù)B的電話(huà)）。IMS-GWF還通過(guò)設置計時(shí)器來(lái)監控準許單位的使用情況。
然后，用戶(hù)B的電話(huà)開(kāi)始響鈴并使用180 Ringing消息應答INVITE?？紤]到簡(jiǎn)單性，這個(gè)圖中并未包含這個(gè)應答，以及任何100 Trying應答消息。當被叫方應答電話(huà)時(shí)，將會(huì )發(fā)送200 OK消息。這個(gè)OK消息通過(guò)各種不同的網(wǎng)絡(luò )元素到達用戶(hù)A的電話(huà)，如下圖所示。然后，A話(huà)機將ACK轉發(fā)到B端。這樣一個(gè)呼叫就建立起來(lái)了。
圖10. IMS示例場(chǎng)景：呼叫終止（單擊圖片查看大圖）
當所有準許單位都被使用后（也就是IMS-GWF中的計時(shí)器到期），將發(fā)送一個(gè)CCR保留這些單位的另一部分。這次的請求類(lèi)型是UPDATE。OCS發(fā)送含有結果代碼DIAMETER_SUCCESS的CCA，以許可呼叫繼續。如果準許單位是用戶(hù)賬戶(hù)上最后可用的存款，則OCS應答會(huì )含有Final-Unit-Indication AVP。這表示使用完當前準許的單位之后，呼叫會(huì )斷開(kāi)連接（或者采用另一種特殊的動(dòng)作）。但是，在本例中沒(méi)有出現這個(gè)AVP。
在這之后，用戶(hù)A決定關(guān)閉呼叫并發(fā)送BYE。BYE將通過(guò)P-和S-CSCF轉發(fā)給網(wǎng)絡(luò )的呼叫方和IMS-GWF，IMS-GWF會(huì )發(fā)送類(lèi)型TERMINATION的CCR給計費系統。這個(gè)CCR中包含與使用過(guò)的“服務(wù)單位”有關(guān)的信息（在本例中為呼叫持續時(shí)間）。OCS使用CCA作為應答并釋放與該會(huì )話(huà)相關(guān)的內部資源（比如說(shuō)內存、計時(shí)器）。用戶(hù)B的電話(huà)使用200 OK消息應答BYE，該消息將傳回呼叫方。最后呼叫關(guān)閉。
BEA WebLogic SIP Server含有一個(gè)簡(jiǎn)單的支持Diameter協(xié)議的API，包括Diameter Base Accounting和Diameter Credit-Control應用程序。本節介紹如何配置和使用Diameter功能。
要使用Diameter功能，需要對WebLogic域進(jìn)行適當的配置。配置過(guò)程由以下幾個(gè)步驟組成：
BEA文檔頁(yè)面的 參考資料 部分詳述了這些步驟。
部署好的應用程序使用Diameter Rf或Ro功能之前，需要分別獲取RfApplication或RoApplication對象。這可以通過(guò)以下代碼實(shí)現，假定使用的是SIP或HTTP servlet類(lèi)：
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有一個(gè)會(huì )話(huà)的概念。RFC3588中對會(huì )話(huà)的正式定義是“一系列致力于某個(gè)特定活動(dòng)的相關(guān)事件”。實(shí)際上，會(huì )話(huà)使用ACR（START）或CCR（INITIAL）表示開(kāi)始，并以ACA（STOP）或CCA（TERMINATION）表示結束。在一次性事件的例子中，會(huì )話(huà)只包含請求和應答。所有消息都屬于一個(gè)與Session-Id AVP公共值相關(guān)的會(huì )話(huà)。
在WebLogic SIP Server API中，Diameter會(huì )話(huà)是與com.bea.wcp.diameter.Session對象映射在一起的。Session類(lèi)處理Session-Id AVP。Rf和Ro接口有兩個(gè)特殊的子類(lèi)，即RfSession和RoSession。這兩個(gè)類(lèi)只處理特定于Diameter計費的請求和應答?？梢允褂肦f/RoApplication創(chuàng )建會(huì )話(huà)對象：
RfApplication rfApp = ...
RfSession rfSes = rfApp.createSession();
RoApplication roApp = ...
RoSession roSes = roApp.createSession();
此外，DIAMETER會(huì )話(huà)是可序列化的，您可以將其作為屬性存儲于SipApplicationSession中，反之亦然。WebLogic Sip Server會(huì )自動(dòng)將會(huì )話(huà)鏈接到活動(dòng)的呼叫狀態(tài)。接收到消息之后，容器將自動(dòng)檢索呼叫狀態(tài)，并找出Diameter會(huì )話(huà)。
創(chuàng )建Rf請求相當簡(jiǎn)單。讓我們從一個(gè)基于會(huì )話(huà)的請求入手。如前所述，獲得RfApplication和RfSession之后，我們使用RfSession對象創(chuàng )建一個(gè)新Accounting-Request。由于這是第一個(gè)請求，requestType將以值的形式出現：
ACR acr = session.createACR(RecordType.START);
創(chuàng )建Event請求的代碼為：
ACR acr = session.createACR(RecordType.INTERIM);
創(chuàng )建一個(gè)新Accounting-Request時(shí)，將會(huì )自動(dòng)填充以下AVP：
| 屬性 | 值 |
| Session-Id | 自動(dòng)生成 |
| Origin-Host | 根據diameter.xml中的節點(diǎn)設置 |
| Origin-Realm | 根據diameter.xml中的節點(diǎn)設置 |
| Acct-Application-Id | 3，表示Diameter Base Accounting |
| Destination-Host | RfApplication中cdf.host參數的值，設置在diameter.xml中 |
| Destination-Realm | RfApplication中cdf.realm參數的值，設置在diameter.xml中 |
可以通過(guò)調用addAvp方法添加其他AVP：
Acr.addAvp(Attribute.EVENT_TIMESTAMP, new Integer(timestamp));
對Ro接口的請求（比如說(shuō)Credit-Control-Requests）的創(chuàng )建方式非常類(lèi)似于創(chuàng )建Accounting-Requests的方式。以下這個(gè)示例可以說(shuō)明一切：
CCR ccr = roSes.createCCR(RequestType.INITIAL);
注意，Credit Control的請求類(lèi)型與賬戶(hù)的記錄類(lèi)型有所不同——比如，START和INITIAL。事件請求可直接通過(guò)RoApplication創(chuàng )建，而不需要明確地創(chuàng )建一個(gè)會(huì )話(huà)：
CCR eventCcr = roApp.createEventCCR();
在兩種情況下，WebLogic SIP Server都會(huì )自動(dòng)設置以下表格中的AVP。
| 屬性 | 值 |
| Session-Id | 根據diameter.xml中的節點(diǎn)設置 |
| Origin-Realm | 根據diameter.xml中的節點(diǎn)設置 |
| 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 | 會(huì )話(huà)每創(chuàng )建一個(gè)CCR該數字就自增1 |
可以使用與前面相同的方法添加其他AVP。
Diameter Base屬性是Attribute類(lèi)中的靜態(tài)字段。此外，與計費相關(guān)的屬性可以在Charging類(lèi)和CreditControl類(lèi)中找到。WebLogic SIP Server并未限制用戶(hù)使用這些預先定義的屬性?？梢允褂肁ttribute.define()方法之一來(lái)創(chuàng )建新屬性。Attribute類(lèi)包含為所有基本屬性預先定義的常量。以下示例展示了如何添加一個(gè)AVP：
public static final Attribute SUBSCRIPTION_ID_TYPE = Attribute.define(666, "Subscription-Id-Type", Type.INTEGER);
添加一個(gè)已經(jīng)由用戶(hù)或容器定義過(guò)的AVP時(shí)，WebLogic Sip Server會(huì )拋出一個(gè)異常。添加完所有必要的AVP后，我們最后還要發(fā)送CCR?？梢允褂靡韵聝煞N方法完成這一操作：
ccr.send();
// - or -
CCA answer = (CCA)ccr.sendAndWait();
第二種方法會(huì )發(fā)送CCR并阻塞執行，直到接收到應答或發(fā)生超時(shí)。
WebLogic SIP Server Diameter API中有兩種接收應答的方法。第一種是異步方式，以Request.sendAndWait()方法為基礎。這個(gè)方法會(huì )發(fā)送請求并阻塞呼叫線(xiàn)程直到接收到應答或請求超時(shí)。它會(huì )返回接收到的應答。發(fā)送請求的異步方式適用于阻塞線(xiàn)程不會(huì )造成問(wèn)題的應用程序。
第二種方法是異步分離發(fā)送動(dòng)作和接收動(dòng)作。請求是通過(guò)調用Request.send()發(fā)送的。這個(gè)方法會(huì )立刻返回。接收到應答時(shí)，該方法會(huì )調用其rcvMessage()方法通知監聽(tīng)程序。這個(gè)監聽(tīng)程序必須要實(shí)現SessionListener接口，而且必須要在接收到應答之前建立在會(huì )話(huà)中。以下示例演示了這種方法：
//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(CreditControl.CCA)) {
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()
帶有監聽(tīng)程序的實(shí)現還可以允許我們接收當前會(huì )話(huà)內的服務(wù)器所發(fā)送的請求（比如說(shuō)，當服務(wù)器決定馬上關(guān)閉會(huì )話(huà)時(shí)所發(fā)送的Abort-Session-Request）。請求和應答都以同樣的方式傳遞給監聽(tīng)程序的rcvMessage()方法。由應用程序負責為請求和應答提供不同的行為。
在設定時(shí)間內未收到請求的應答時(shí)，WebLogic SIP Server會(huì )自動(dòng)檢測超時(shí)條件。diameter.xml中配置了超時(shí)的默認值。還可以使用帶參數的send(...)或sendAndWait(...)為各個(gè)請求分別指定超時(shí)的時(shí)間。
WebLogic SIP Server通過(guò)創(chuàng )建一個(gè)帶有結果代碼DIAMETER_UNABLE_TO_DELIVER的響應來(lái)處理超時(shí)。實(shí)際上，并不會(huì )在網(wǎng)絡(luò )上發(fā)送響應，但是會(huì )將其傳遞給發(fā)送請求的應用程序。這種處理超時(shí)的方法類(lèi)似于SIP中所使用的方法。
同樣，WebLogic SIP Server可拋出以下兩種異常：
WebLogic SIP Server中的日志記錄工具可用于跟蹤傳入和傳出消息。您可以使用控制臺配置消息調試。此外，也可以通過(guò)在腳本文件（類(lèi)Unix的機器中為sh文件，Windows平臺中則為cmd）中的-Ddiameter.Debug=true選項來(lái)設置消息調試。調試消息將直接發(fā)送給控制臺。
除了在WLSS中設置調試之外，使用網(wǎng)絡(luò )嗅探程序也是大有幫助。這種類(lèi)型的程序可以顯示在網(wǎng)絡(luò )中傳輸的報文。Wireshark（原來(lái)稱(chēng)作Ethereal）可能是最受歡迎的嗅探程序，它是一款免費軟件。
Ro和Rf接口的示例應用程序可以從 此處 下載。這個(gè)應用程序為一個(gè)SIP會(huì )話(huà)提供了Diameter Ro/Rf計費功能。接收到一個(gè)INVITE時(shí)請求，應用程序會(huì )通過(guò)發(fā)送一個(gè)類(lèi)型INITIAL的CCR來(lái)啟動(dòng)會(huì )話(huà)。然后，用完所有準許的存款后，應用程序會(huì )通過(guò)發(fā)送UPDATE CCR來(lái)請求新的存款。接收到BYE消息時(shí)，應用程序會(huì )通過(guò)發(fā)送TERMINATION CCR來(lái)關(guān)閉計費會(huì )話(huà)。
在存款用完的情況下，應用程序也會(huì )關(guān)閉會(huì )話(huà)。如果CCA中接收到一個(gè)Final-Unit-Indication AVP，并且所有準許額度都已用完，則應用程序會(huì )通過(guò)發(fā)送BYE消息來(lái)斷開(kāi)SIP會(huì )話(huà)。應用程序還會(huì )發(fā)送一個(gè)TERMINATION CCR來(lái)關(guān)閉Diameter會(huì )話(huà)。
BEA WebLogic Sip Server提供了一種簡(jiǎn)單的測試方法，可以使用一個(gè)Rf接口的獨立的模擬程序測試自己的應用程序。模擬程序可以作為獨立的應用程序運行，模擬程序的離線(xiàn)計費接口為com.bea.wcp.diameter.charging.RfSimulator。
此外，BEA還提供了一個(gè)HSS模擬程序用于存儲與服務(wù)相關(guān)的數據，可以使用相同的方式運行該模擬程序。注意，這個(gè)模擬程序是用于測試目的的，并且只支持RepositoryData和PSI。HSS模擬程序為com.bea.wcp.diameter.sh.HSSSimulator。
這兩種模擬的命令行選項如下所示：
以下示例演示了如何運行一個(gè)獨立的BEA Rf模擬程序：
java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator -r bea.com -h simulator -p 3900 -d -m
我們也可以運行多個(gè)模擬程序，比如使用以下腳本運行HSS模擬程序：
java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator,com.bea.wcp.diameter.sh.HssSimulator -h simulator -r bea.com -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預付費解決方案通過(guò)其各組件的集成和相互協(xié)作提供了一種具有豐富特性的、兼容IMS的、可互操作的、電信級的解決方案。在這種集成場(chǎng)景中，IMS預付費解決方案通過(guò)Rf和Ro接口與Amdocs IMS計費解決方案相互通信。其網(wǎng)絡(luò )結構如下所示：
圖11. BEA-Ericpol-Amdocs IOT的網(wǎng)絡(luò )架構（單擊圖片查看大圖）
BEA-Ericpol IMS Prepaid和Amdocs Charging之間的互操作性測試（interoperability testing，IOT）包含以下兩個(gè)階段：離線(xiàn)和在線(xiàn)計費。各個(gè)場(chǎng)景的消息流包含在本文結尾的附加文件中。
IOT已經(jīng)證實(shí)WebLogic SIP Server中的Diameter實(shí)現符合協(xié)議規范。它還顯示對Java API的完全編程控制使得Diameter實(shí)現極具靈活性。在PoC過(guò)程中需要進(jìn)行幾次小更改。這些更改的實(shí)現快速而簡(jiǎn)單。
IOT中所使用的Amdocs IMS計費解決方案基于A(yíng)mdocs在線(xiàn)計費（Amdocs Online Charging）系統。與3GPP標準一致，這種在線(xiàn)計費功能通過(guò)Diameter接口與核心IMS網(wǎng)絡(luò )進(jìn)行交互（在線(xiàn)計費系統接口的Diameter引用點(diǎn)）。此外，Amdocs IMS計費解決方案中的兩種關(guān)鍵組件是Amdocs Rating和Amdocs Balance Manager。要與IMS呼叫會(huì )話(huà)控制函數進(jìn)行交互（以實(shí)現離線(xiàn)計費），針對IMS的3GPP標準定義了以下兩個(gè)組件：計費數據函數（charging data function，CDF）和計費網(wǎng)關(guān)函數（charging gateway function，CGF）。這些函數可以構造、關(guān)聯(lián)和格式化與計費事件相關(guān)的信息，并將這些信息傳遞給賬單系統。Amdocs Service Mediation Manager是Amdocs IMS計費解決方案的一部分，它經(jīng)過(guò)改進(jìn)后符合3GPP標準并且其本身可以提供CDF和CGF功能。
如今，服務(wù)提供商開(kāi)始爭先實(shí)現IMS架構并提供越來(lái)越多的復雜服務(wù)，與此同時(shí)，他們也不得不開(kāi)始面對各種問(wèn)題：如收益率、定價(jià)、資本回報率和服務(wù)質(zhì)量等等。Amdocs使用了一套橫向的、統一的、模塊化的IMS就緒計費產(chǎn)品，實(shí)現了一種完善的IMS計費方式，并且很好地解決了上述問(wèn)題。如Ericpol和BEA的IOT測試所示，Amdocs計費解決方案具有以下優(yōu)點(diǎn)：
已經(jīng)證實(shí)，Diameter成功克服了RADIUS的局限。它如今已成為IMS標準的一部分?；贗P和電話(huà)技術(shù)的新服務(wù)的開(kāi)發(fā)現正在迅速發(fā)展，每一項服務(wù)都需要計費功能。因此，基于Diameter計費的普及指日可待。
通過(guò)閱讀本文，您應該了解了Ro和Rf接口的基本概念，并知道如何使用BEA WebLogic SIP Server處理它們?，F在，您已經(jīng)可以借助所學(xué)的知識著(zhù)手開(kāi)發(fā)自己的應用程序
作者感謝 Rafi Kretchmer，Amdocs的Revenue Management Product & Solutions Marketing部門(mén)的產(chǎn)品營(yíng)銷(xiāo)總監。Rafi負責為Amdocs的產(chǎn)品收益管理制訂IMS業(yè)務(wù)戰略，包括行業(yè)領(lǐng)先的Amdocs Billing產(chǎn)品組合。
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
原文出處：http://dev2dev.bea.com/pub/a/2007/07/IMC-charging-architecture.html
| 作者簡(jiǎn)介 | |
Stefano Gioia | Stefano Gioia 是EMEA的BEA WebLogic Sip Server 技術(shù)專(zhuān)家。他把主要精力都放在讓IMS及其工作人員和合作伙伴能夠跨越歐洲、中東和非洲的努力上。 |
| Tomasz Radziszewski是Ericpol Telecom的軟件研發(fā)工作師。 | |
聯(lián)系客服
