摘要：為了解決準實時計費系統(tǒng)有較高的欠費風險，智能網系統(tǒng)數(shù)據業(yè)務支持能力及靈活性不足等問題，提出了一種實時融合計費系統(tǒng)的設計實現(xiàn)方法。采用了可定制規(guī)則分揀的預處理引擎、基于適配器模式的批價引擎和嵌入式腳本等方法，滿足了靈活的多種業(yè)務融合計費需求；同時，還采用了多級消息分發(fā)、共享內存數(shù)據庫等方法，保證了系統(tǒng)的實時性。經過測試實驗獲得系統(tǒng)消息平均響應時間99．9％小于400 ms，系統(tǒng)單節(jié)點支持用戶數(shù)由現(xiàn)在的300萬提升到2 000萬，混合呼叫處理能力由現(xiàn)在的2 400 Caps提升到4 000 Caps；解決了現(xiàn)有計費系統(tǒng)實時性差、對數(shù)據業(yè)務支持能力不足、不能處理海量數(shù)據等問題；具有高實時性、高可擴展性、高靈活性等特點。
關鍵詞：運營支撐系統(tǒng)；實時融合計費；適配器模式；共享內存數(shù)據庫；嵌入式腳本

0 引言
    隨著國內運營商紛紛進入全網運營一體化時代，對于具備固話、寬帶、移動通信等多種網絡業(yè)務的運營商來說，融合各種業(yè)務為用戶提供具有個性化、多樣化以及差異化的服務是取得競爭優(yōu)勢的關鍵。計費系統(tǒng)是全業(yè)務運營支撐系統(tǒng)之中的核心系統(tǒng)，必須滿足實時性、全業(yè)務融合、高擴展性和統(tǒng)一客戶視圖等需求。目前國內外各大電信運營商均在使用傳統(tǒng)的準實時計費系統(tǒng)以及智能網系統(tǒng)，兩套系統(tǒng)獨立運行。準實時計費系統(tǒng)是離線計費系統(tǒng)的一種，其特點是計費系統(tǒng)以聯(lián)機方式得到使用記錄后，馬上進行計費，以盡可能縮短用戶使用與計費之間的時間差，但計費系統(tǒng)不參與服務使用過程，而是在服務使用過程結束后根據使用記錄進行計費。經過多年的實踐證明，越來越高的欠費風險是傳統(tǒng)準實時計費系統(tǒng)的致命弱點。智能網系統(tǒng)具備實時計費能力，但業(yè)務資費靈活性不夠，對數(shù)據業(yè)務支持能力不足，新業(yè)務開發(fā)速度慢，又無法適應市場復雜靈活的變化要求。
    為了滿足新一代計費系統(tǒng)的需求，3GPP組織提出了在線計費系統(tǒng)(OCS)的參考結構，給出了具有開放性和通用性的實時計費系統(tǒng)框架，支持承載層、會話層和應用層的統(tǒng)一計費。在此參考結構基礎上，本文基于SOA架構，采用可定制規(guī)則分揀的預處理引擎、高擴展性的批價引擎以及共享內存數(shù)據庫等技術設計實現(xiàn)了一種具有高實時性、高可擴展性和高靈活性的新一代實時融合在線計費系統(tǒng)。

1 系統(tǒng)架構
    在線計費指計費信息可以實時影響業(yè)務的提供、帳戶余額可以實時更新的計費機制，可分為基于事件型和基于會話型的在線計費。會話型的典型例子是用戶打電話，需要持續(xù)一段時間；事件型的典型例子是發(fā)短信，一次消息觸發(fā)一次計費。以會話型計費在線計費為例，用戶通話過程中消息可分為三種：初始化消息，更新消息和結束消息。用戶通話一開始發(fā)送初始化消息，然后系統(tǒng)根據事先設定的預留策略(比如3min)，定時發(fā)送更新消息直至用戶通話結束，之后向在線計費系統(tǒng)發(fā)送結束消息，在線計費系統(tǒng)則在線實時采集這些消息進行鑒權、預留、計費、扣費，一旦用戶余額不夠一次預留量，則根據余額反算時長，將時長通知網元，網元在用戶達到指定時長后停止用戶通話。
    在線計費系統(tǒng)架構圖如圖1所示。

    由在線采集模塊負責采集話單文件及在線消息，并轉化為統(tǒng)一格式消息進行主機級消息分發(fā)。計費消息調度模塊負責消息的接收與發(fā)送以及消息的進程級分發(fā)。計費控制模塊接收到計費消息后進行協(xié)議解析，生成計費事件，并根據計費事件類型及數(shù)據庫數(shù)據分別由預處理引擎、批價引擎、余額管理和會話管理處理，實現(xiàn)基于會話承載的計費、基于內容事件的計費以及用戶賬戶管理。最后，系統(tǒng)通過話單生成程序將業(yè)務使用記錄和計費結果保存到CDR文件中。

    為了滿足未來海量數(shù)據處理的需要以及系統(tǒng)擴容的需求，系統(tǒng)采用主機級消息分發(fā)和進程級消息分發(fā)兩級分發(fā)策略。其中主機級消息分發(fā)由運行于IMPDiameter Server上的在線采集模塊負責。如圖2所示，IMP Diameter Server在收到信用控制請求包(CCR)后，會根據CCR中的用戶標識信息以及共享內存數(shù)據庫中的路由策略(如用戶、地域、號段、網絡設備等)來決定將這個CCR分發(fā)給那一個在線計費系統(tǒng)(OCS)主機進行處理。在OCS主機收到CCR后，計費消息調度模塊中的分發(fā)進程會根據CCR的業(yè)務類型和OCS進程的負載情況將CCR包指派給某個具體的OCS進程進行處理。

2 在線計費控制
2．1 預處理引擎
    隨著電信業(yè)務的發(fā)展，需要越來越靈活的資費套餐，這就需要多種多樣、可靈活配置的擴展計費信息。另一方面，通信網元的多樣化，使得原始計費信息變化較大。怎樣把原始信息靈活轉換成擴展計費信息就成為預處理引擎設計的關鍵。傳統(tǒng)的預處理方法對于新的業(yè)務和規(guī)則，一般都是通過修改程序代碼來實現(xiàn)的，這樣給程序的管理和維護帶來了很大的困難，而且風險比較高。
    本文提出了一種基于可定制規(guī)則分揀的預處理引擎，該引擎可以根據不同網元的業(yè)務需求，靈活地配置并驗證邏輯，規(guī)整統(tǒng)一的批價接口，從而實現(xiàn)了全業(yè)務的融合。同時，由于不需要修改程序，系統(tǒng)維護方便且風險極小。
2．2 批價引擎
    批價引擎是在線計費的核心組件。隨著資費策略越來越復雜，傳統(tǒng)的基于參數(shù)表驅動或簡單規(guī)則驅動的計費引擎表達起來越來越困難，計費引擎越做越復雜，擴展性也越來越差，維護代價越來越高。為了解決這一問題，采用適配器(Adapter)的設計模式以及嵌入腳本技術實現(xiàn)了一種高可擴展性的通用批價引擎?；谶m配器模式的批價引擎分為三層，分別是核心層、適配器層和原始數(shù)據層，如圖3所示。

    對一次性費用計算、使用費計算、周期費用計算和優(yōu)惠計算等提供統(tǒng)一的屬性訪問接口，使得費用計算和數(shù)據源的變化無關，實現(xiàn)通用的費用計算引擎。當增加新的業(yè)務(新的格式、內容)時，只要增加實現(xiàn)一個適配器就可以被批價引擎接受。傳統(tǒng)的資費模型通常通過用戶資料中的多個屬性，組合運算后得到若干條資費規(guī)則，資費規(guī)則只有在程序運行時才知道用戶適用的資費。資費配置后是否正確生效具有不確定性?；谶m配器模式的批價引擎采用了資費規(guī)則包的資費模型，形成可供用戶選擇的資費計劃，這樣用戶所匹配的資費規(guī)則可以從用戶資料中直接查詢出來，可靠性更能得到保證。通過對各種話單、事件進行分析，資費配置和對抽象的“事件屬性”進行定義，對新的網絡(業(yè)務)計費只要在基礎數(shù)據配置表中增加相應的事件屬性描述即可。
    為了解決基于C／C++語言實現(xiàn)的批價引擎可擴展性差的問題，批價引擎還創(chuàng)新性的采用了嵌入Python腳本技術，利用C++程序運行時的動態(tài)解析Python腳本和Python本身強大的表達能力，可以使計費規(guī)則的表達無限靈活。Python語言是面向對象的腳本語言，同時也支持傳統(tǒng)的結構化編程，具有很好的動態(tài)解釋性。復雜的資費策略可以通過腳本實現(xiàn)。腳本就像插件一樣，可以根據需要任意配置，極大地提高系統(tǒng)的表達能力和擴展性。為運營商提供強大的運營支撐能力，方便運營商的業(yè)務快速推出和開展。
2．3 虛擬余額技術
    傳統(tǒng)的計費系統(tǒng)沒有虛擬余額的概念，只支持一種余額類型，即金額。其他類型的消費都要轉換為金額才能實現(xiàn)。隨著電信業(yè)務的發(fā)展，各種各樣的基于時長、次數(shù)、流量等消費的方式越來越多，都轉成金額也是一種方式，但不靈活。在余額管理模塊設計中，系統(tǒng)引入了虛擬余額的概念。系統(tǒng)支持用戶的余額可以是除了金額外的其他類型“余額”，如時長、次數(shù)、流量等。同時支持虛擬類型的擴充，有效增加用戶消費的方式，方便電信業(yè)務的拓展。

3 共享內存數(shù)據庫
    計費系統(tǒng)中各種業(yè)務程序需要對數(shù)據庫中的數(shù)據進行頻繁的查詢操作，涉及的數(shù)據量非常巨大，訪問數(shù)據庫的頻率很高，由此產生過多的數(shù)據庫交互導致程序性能降低。使用共享內存技術將數(shù)據庫待查詢的數(shù)據上載到業(yè)務程序所在的系統(tǒng)內存中，結合業(yè)務需求建立快速有效的查詢方式，提高查詢速度，減少對數(shù)據庫性能的依賴。
    根據需要查詢的數(shù)據量，在系統(tǒng)內存中開辟足夠的共享內存段，用于存放數(shù)據記錄。同時根據數(shù)據查詢的需求建立對應的查詢方式(即建立索引)，創(chuàng)建對應的共享內存段，用于存放索引及輔助維護數(shù)據。共享內存數(shù)據庫框架如圖4所示。

    守護進程根據預先定義，查詢并獲取數(shù)據庫中的原始數(shù)據，經過處理形成需要存放的記錄并插入共享內存的數(shù)據段，同時根據查詢方式形成對應的索引記錄，插入共享內存的索引段。在數(shù)據被批量上載后，業(yè)務進程可以連接共享內存，先訪問索引段，然后獲取對應的數(shù)據記
錄。數(shù)據庫數(shù)據發(fā)生變動時，守護進程根據相應的機制獲取變動的數(shù)據，依照前面業(yè)務進程查詢數(shù)據的方法，如果找到指定數(shù)據就更新，如果沒找到就插入新記錄。

4 結語
    隨著電信技術的不斷發(fā)展，傳統(tǒng)的準實時計費系統(tǒng)已不能滿足電信運營商的需求。本文設計了一種實時融合認證在線計費系統(tǒng)，該系統(tǒng)采用可定制規(guī)則分揀的預處理引擎、基于適配器模式的批價引擎和嵌入式腳本等技術滿足了靈活的多種業(yè)務融合計費需求。同時，該系統(tǒng)還采用了多級消息分發(fā)、共享內存數(shù)據庫等技術，保證了系統(tǒng)的實時性。該系統(tǒng)消息平均響應時間99．9％小于400 ms。系統(tǒng)單節(jié)點支持用戶數(shù)由現(xiàn)在的300萬提升到2 000萬，系統(tǒng)容量提升后，一般的電信企業(yè)部署單節(jié)點，最多兩個節(jié)點即可滿足容量要求。系統(tǒng)的單節(jié)點混合呼叫處理能力由現(xiàn)在的2 400 CaPs提升到4 000 Caps。數(shù)據處理性能提升后，將能滿足未來海量數(shù)據處理的需要。