專利名稱：智能網在線計費交互系統(tǒng)及方法
技術領域：
本發(fā)明涉及電信技術領域，尤其是一種智能網在線計費交互系統(tǒng)及方法。
背景技術：
目前電信技術領域有兩種計費體系架構， 一種是業(yè)務運營支撐系統(tǒng)
(Business and Operation Support System,以下簡稱BOSS )采用的基于計 費數(shù)據(jù)記錄(Charging Data Record,以下簡稱CDR)的離線計費， 一種是 基于信令消息的在線計費。
BOSS采用的離線計費是運營商提供給用戶的服務結束后，由交換 服務設備產生話單，BOSS根據(jù)話單進行批價計費。這種方式在服務過程 中，BOSS對服務沒有實時控制能力，容易產生透支和欠費。為了降低欠 費風險，運營商采用欠費風險控制系統(tǒng)實現(xiàn)低信譽度用戶的實時欠費風險 控制。欠費風險控制系統(tǒng)可以對被監(jiān)控用戶進行實時計費，并通過業(yè)務控 制設備發(fā)送實時控制指令，其主要用于監(jiān)控運營商認為的低信譽度用戶， 幫助運營商降低欠費風險，但是這些用戶真正的計費(收費依據(jù))還是通 過話單由BOSS實現(xiàn)，因此，采用欠費風險控制系統(tǒng)雖基本上具備在線計 費系統(tǒng)(Online Charging System,以下簡稱OCS )的雛形，但是還不屬于 真正的OCS。
在線計費是用戶使用服務時，交換服務設備觸發(fā)信令消息給業(yè)務控 制設備，由業(yè)務控制設備對用戶使用的服務進行鑒權、預算、實時計費、 實時費用監(jiān)控和服務控制能力。采用這種方式能夠根據(jù)用戶帳戶余額精確
地控制服務使用量，避免用戶透支和欠費。公開號為CN1773920的專利 申請"一種在線計費的處理方法"公開了一種采用OCS實現(xiàn)在線計費的 方法，可以實現(xiàn)對用戶的實時信用控制，但是該申請存在如下缺點只涉 及數(shù)據(jù)流業(yè)務的信用控制；用戶只有金額帳戶，而當運營商獎勵用戶免費 資源時，如50條免費短信、IOM免費流量的情況下，無法對這些以獎勵 積分形式存在的資源進行實時使用；OCS是新的設備，單獨引入，耗費大 量的成本。
目前還有一種是通過智能網實現(xiàn)在線計費。智能網實際上是一個業(yè)務提
供平臺，并不應該將其看做一個計費系統(tǒng)，但是由于智能網定義了預付費業(yè)
務，所以智能網也被認為是一種在線計費的實現(xiàn)方法。智能網能夠提供非常
好的實時控制，而且具有比較完善的國際標準，智能網的標準主要是針對傳
統(tǒng)話音業(yè)務的需求發(fā)展起來的，在傳統(tǒng)話音領域發(fā)展的非常好；預付費業(yè)務
也成為運營商比較認可的一種業(yè)務形式，尤其是在移動通信網絡中。但是，
由于智能網將預付費作為一種業(yè)務而不是一種業(yè)務支撐手段來定義，所以其
業(yè)務模式的靈活性受到極大的限制，同時由于智能網主要應用在話音業(yè)務域， 所以其對融合計費的支持能力也不容樂觀。

發(fā)明內容
本發(fā)明的目的是提供一種智能網在線計費交互系統(tǒng)及方法，用以解決現(xiàn) 有技術存在的問題，實現(xiàn)多業(yè)務計費、多賬戶計費，并且經濟實用且擴展性 強。
本發(fā)明第 一個方面智能網在線計費交互系統(tǒng)通過一些實施例4是供了如下 的技術方案
一種智能網在線計費交互系統(tǒng)，包括
計費觸發(fā)網元，根據(jù)用戶所使用的業(yè)務，向業(yè)務平臺發(fā)送計費請求并 接收業(yè)務平臺的響應；
業(yè)務平臺，根據(jù)接收到的計費請求，對用戶所使用的業(yè)務進行實時批
價，并與智能網進行信用控制交互；
智能網，通過直徑信用控制應用協(xié)議接口與所述業(yè)務平臺通信連接，對 與用戶所使用的業(yè)務相應的信用額度進行處理。
本發(fā)明第二個方面智能網在線計費交互方法通過另一些實施例提供了如 下的技術方案
一種智能網在線計費交互方法，包括
業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息， 所述信用額度消,！ 用的業(yè)務量；
根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網，所述信用控制請求通過 直徑信用控制應用協(xié)議接口指示智能網進行相應的信用額度處理。
本發(fā)明通過業(yè)務平臺與智能網的交互實現(xiàn)在線計費，與單獨引入OCS相 比，可以降低成本和復雜度；通過在智能網中建立資源帳戶和資金帳戶，可 以實現(xiàn)多賬戶計費，資源賬戶可以用來存儲運營商提供給用戶的免費資源， 因此可以對用戶實施多種優(yōu)惠策略，有利于擴大市場及提高用戶的忠誠度； 業(yè)務平臺和智能網之間采用直徑信用控制應用協(xié)議進行交互，實現(xiàn)強的可擴展性。


圖l為本發(fā)明智能網在線計費交互系統(tǒng)實施例一示意圖； 圖2為本發(fā)明智能網在線計費交互系統(tǒng)實施例二示意圖； 圖3為本發(fā)明智能網在線計費交互方法實施例一流程圖； 圖4為本發(fā)明智能網在線計費交互方法實施例二流程圖； 圖5為本發(fā)明智能網在線計費交互方法實施例三流程圖； 圖6為本發(fā)明智能網在線計費交互方法實施例四流程圖。
具體實施例方式
下面結合附圖和具體實施例進一步說明本發(fā)明的技術方案。
直徑信用控制應用(Diameter Credit Control Application,以下簡稱DCCA ) 協(xié)議屬于直徑(diameter)協(xié)議的應用協(xié)議，是在直徑基礎協(xié)議(diameter base ) 基礎上新增了信用控制請求(Credit Control Request,以下簡稱CCR)和信用 控制響應消息(Credit Control Answer,以下簡稱CCA)。 DCCA協(xié)議是以對 等模式進行的，區(qū)別于目前認證、授權、計費領域普遍應用的遠程認證撥號 用戶服務(Remote Authentication Dial In User Service,以下簡稱RADIUS )協(xié) 議采用的客戶/服務器模式，由于每個節(jié)點(客戶端、服務器端)都可向對方 主動發(fā)起消息，因此提高了網絡性能，具有較強的可擴展性。DCCA協(xié)議具 有大的屬性數(shù)據(jù)空間，數(shù)據(jù)對象封裝在屬性值對(Attribute Value Pair,以下 簡稱AVP)中，通過AVP傳輸用戶的認證和授權信息、交互用以計費的資源 使用信息等參數(shù)。DCCA協(xié)議支持實時實時控制、支持會話計費和事件計費， 具有安全、高效的特點及很強的擴展性。
圖l為本發(fā)明智能網在線計費交互系統(tǒng)實施例一示意圖。如圖l所示，
該智能網在線計費交互系統(tǒng)包括計費觸發(fā)網元l、業(yè)務平臺2和智能 網3;計費觸發(fā)網元l根據(jù)用戶所使用的業(yè)務，向業(yè)務平臺發(fā)送計費請求并 接收業(yè)務平臺的響應；業(yè)務平臺2根據(jù)接收到的計費請求，對用戶所使用 的業(yè)務進行實時批價，并與智能網進行信用控制交互；智能網3通過DCCA 協(xié)議接口與所述業(yè)務平臺通信連接，對與用戶所使用的業(yè)務相應的信用額 度進行處理，包括信用額度的預扣、信用額度的扣除、信用額度的直接扣 除、信用額度的返還。
本實施例通過業(yè)務平臺與智能網的交互實現(xiàn)在線計費，與單獨引入 OCS相比，可以降低成本和復雜度；并且本實施例中的業(yè)務平臺和智能網 之間采用DCCA協(xié)議進行交互，具有很強的可擴展性。
圖2為本發(fā)明智能網在線計費交互系統(tǒng)實施例二示意圖。如圖2所示，
與實施例一相比，該智能網在線計費交互系統(tǒng)的業(yè)務平臺具體包括計費 信息模塊21、在線計費模塊22、用戶信息模塊23和信用監(jiān)控模塊24;計費 信息模塊21用于存儲業(yè)務的計費規(guī)則、計費方式；在線計費模塊22用于根 據(jù)所述計費規(guī)則對用戶所使用的業(yè)務進行實時批價；用戶信息模塊23用于 確定用戶是否為預付費用戶；信用監(jiān)控模塊24用于對用戶信息模塊23確定的 預付費用戶根據(jù)所述計費方式和批價，與所述智能網進行信用控制交互。其 中，資源賬戶存儲的資源是在用戶充值或消費累積時免費贈送給用戶，比 如可以是用戶充值時免費獲贈的M條短消息服務(Short Messaging Service,以下簡稱SMS )或/和N條多i某體短消息服務(Multimedia Messaging Service,以下簡稱MMS )或/和L兆通用分組無線業(yè)務(General Packet Radio Service,以下簡稱GPRS)流量或/和數(shù)據(jù)^吏用的時長。由 于智能網中存在資源帳戶和資金帳戶，因此，業(yè)務平臺和智能網交互的信 用額度包括資源和資金。
本實施例的智能網中建立有資源帳戶和資金帳戶，可以實現(xiàn)多賬戶計 費，資源賬戶可以用來存儲運營商提供給用戶的免費資源，因此可以對用 戶實施多種優(yōu)惠策略，有利于擴大市場及提高用戶的忠誠度。
圖3為本發(fā)明智能網在線計費交互方法實施例一流程圖。如圖3所示， 該智能網在線計費交互方法包括
步驟301:業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用 額度消息，所述信用額度消息用于表征用戶是否可以使用業(yè)務或者表征用 戶可以使用的業(yè)務量；
步驟302:根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網，所述信用 控制請求通過DCCA接口指示智能網進行相應的信用額度處理。
本實施例通過業(yè)務平臺與智能網的DCCA交互實現(xiàn)在線計費，業(yè)務平 臺作為DCCA的客戶端，智能網作為DCCA的服務器端，與單獨引入OCS 相比，可以降低成本和復雜度；并且本實施例中的業(yè)務平臺和智能網之間
采用DCCA協(xié)議進行交互，具有很強的可擴展性。
圖4為本發(fā)明智能網在線計費交互方法實施例二流程圖。本實施例是 針對事件計費，其中業(yè)務平臺可以是數(shù)據(jù)業(yè)務管理平臺(Data Service Management Plane,以下簡稱DSMP )，也可以是綜合業(yè)務管理平臺 (Integrated Service Management Plane,以下簡稱ISMP )或相類似的通 用計費子系統(tǒng)，智能網功能主要由業(yè)務控制點(Service Control Point, 以下簡稱SCP)完成，因此以下以SCP表示智能網。如圖4所示，針對事 件計費的交互流程包括
步驟401:計費觸發(fā)網元發(fā)送計費請求給業(yè)務平臺。
步驟402:業(yè)務平臺根據(jù)計費請求和用戶信息，對預付費用戶使用的
業(yè)務進行實時批價處理。
步驟403:批價后，業(yè)務平臺發(fā)送信用額度扣除請求給SCP，該信用 額度扣除請求中包括用戶使用的業(yè)務的業(yè)務類別、使用量及對應的批價金 額，用于使SCP直接扣費。
步驟404: SCP根據(jù)業(yè)務類別判斷是否存在與用戶使用的業(yè)務相應的 資源帳戶(如用戶使用的SMS，判斷資源帳戶里是否存在可以使用的SMS)， 若存在相應的資源帳戶，則執(zhí)行步驟405，否則執(zhí)行步驟406。
步驟405: SCP根據(jù)資源量判斷資源帳戶的余額是否充足，即判斷資 源帳戶的余額是否大于或等于信用額度扣除請求中使用量，若充足，執(zhí)行 步驟406;若不充足，執(zhí)行步驟407。
步驟406: SCP扣除與使用量相應的資源量，執(zhí)行步驟409
步驟407: SCP判斷資金帳戶的余額是否充足，即判斷資金帳戶的余 額是否大于等于信用額度扣除請求中的批價金額，若充足，執(zhí)行步驟408; 若不充足，執(zhí)行步驟414。
步驟408: SCP扣除與批價金額相應的資金，執(zhí)行步驟409。
步驟409: SCP發(fā)送扣除成功消息給業(yè)務平臺，執(zhí)行步驟410。
步驟410:業(yè)務平臺發(fā)送計費請求成功消息給計費觸發(fā)網元，指示計 費觸發(fā)網元允許用戶使用業(yè)務，若用戶成功使用業(yè)務，則結束。
步驟411:用戶未成功使用業(yè)務，計費觸發(fā)網元發(fā)送業(yè)務使用失敗消 息給業(yè)務平臺。
步驟412:業(yè)務平臺發(fā)送返還請求給SCP，執(zhí)行步驟413。
步驟413: SCP返還扣除的信用額度。
步驟414: SCP發(fā)送扣除失敗消息給業(yè)務平臺，執(zhí)行步驟415。
步驟415:業(yè)務平臺發(fā)送計費請求失敗消息給計費觸發(fā)網元，指示計 費觸發(fā)網元不允許用戶使用業(yè)務，結束。
本實施例中是應用于事件計費情形，實現(xiàn)業(yè)務平臺和SCP之間的直接 扣費這一信用額度直接扣除交互過程。
圖5為本發(fā)明智能網在線計費交互方法實施例三流程圖。本實施例是 針對會話計費且計費觸發(fā)網關是消息類觸發(fā)網關的情形。如圖5所示，本 實施例包括
步驟501:計費觸發(fā)網元發(fā)送計費請求給業(yè)務平臺。
步驟502:業(yè)務平臺根據(jù)計費請求和用戶信息，對預付費用戶使用的 業(yè)務進行實時批價處理。
步驟503:批價后，業(yè)務平臺發(fā)送信用額度預扣請求給SCP，該信用 額度預扣請求中包括用戶使用的業(yè)務的業(yè)務類別、申請量及對應的批價金 額，用于使SCP進行信用額度預扣。
步驟504: SCP根據(jù)所述業(yè)務類型，判斷是否存在與所述業(yè)務類型相應 的資源帳戶，若存在，則執(zhí)行步驟505;否則步驟508。
步驟505: SCP判斷所述資源帳戶的余額是否大于等于所述申請量，若 是，執(zhí)行步驟506;否則，執(zhí)行步驟508。
步驟506: SCP預扣與所述申請量相應的資源，執(zhí)行步驟511。
步驟507: SCP判斷資金帳戶的余額是否為零，若資金帳戶的余額不為
零，執(zhí)行步驟508，若資金帳戶的余額為零，執(zhí)行步驟521。
步驟508: SCP判斷所述資金帳戶的余額是否大于等于所述批價金額， 若所述資金帳戶的余額大于等于所述批價金額，執(zhí)行步驟509;否則執(zhí)行 步驟510。
步驟509: SCP預扣與所述批價金額相應的資金，執(zhí)行步驟511。 步驟510: SCP預扣資金帳戶的全部余額，執(zhí)行步驟511。 步驟511: SCP發(fā)送預扣成功消息給業(yè)務平臺，執(zhí)行步驟512。 步驟512:業(yè)務平臺判斷預扣的信用額度是否大于等于申請量或者批
價金額，若是，即只要資源充足或資金充足，執(zhí)行步驟513，否則，執(zhí)行
步驟516及步驟522。
步驟513:業(yè)務平臺發(fā)送計費請求成功消息給計費觸發(fā)網元，指示計
費觸發(fā)網元允許用戶使用業(yè)務，執(zhí)行步驟514。
步驟514:計費觸發(fā)網元監(jiān)控業(yè)務使用情況，判斷用戶是否成功使用
業(yè)務，若是，執(zhí)行步驟518;否則，執(zhí)行步驟515。
步驟515:計費觸發(fā)網元發(fā)送業(yè)務使用失敗消息給業(yè)務平臺，執(zhí)行
步驟516。
步驟516:業(yè)務平臺發(fā)送取消請求給SCP,執(zhí)行步驟517。 步驟517: SCP取消預扣的信用額度，結束。
步驟518:計費觸發(fā)網元發(fā)送計費確認請求給業(yè)務平臺，執(zhí)行步驟519。
步驟519:業(yè)務平臺發(fā)送扣費請求給SCP，執(zhí)行步驟520。
步驟520: SCP實際扣除預扣的信用額度，結束。
步驟521: SCP發(fā)送預扣失敗消息給業(yè)務平臺，執(zhí)行步驟522。
步驟522:業(yè)務平臺發(fā)送計費請求失敗消息給計費觸發(fā)網元，指示計
費觸發(fā)網元不允許用戶使用業(yè)務，結束。
圖6為本發(fā)明智能網在線計費交互方法實施例四流程圖。本實施例是
針對會話計費且計費觸發(fā)網關是分組數(shù)據(jù)類觸發(fā)網關的情形。如圖6所示，
本實施例包括
步驟601:計費觸發(fā)網元發(fā)送預使用量請求的計費請求給業(yè)務平臺， 執(zhí)行步驟602。
步驟602:業(yè)務平臺根據(jù)計費請求對用戶使用的業(yè)務進行實時批價處 理，^丸行步驟603。
步驟603:業(yè)務平臺發(fā)送信用額度預扣請求給SCP，該信用額度預扣 請求中包括用戶使用的業(yè)務的業(yè)務類別、申請量及對應的批價金額，用于 使SCP進行信用額度預扣。
步驟604: SCP根據(jù)所述業(yè)務類型，判斷是否存在與所述業(yè)務類型相應 的資源帳戶，若存在，則執(zhí)行步驟605;否則步驟607。
步驟605: SCP判斷所述資源帳戶的余額是否大于等于所述申請量，若 是，執(zhí)行步驟606;否則，執(zhí)行步驟607。
步驟606: SCP預扣與所述申請量相應的資源，執(zhí)行步驟611。
步驟607: SCP判斷資金帳戶的余額是否為零，若資金帳戶的余額不為 零，執(zhí)行步驟608，若資金帳戶的余額為零，執(zhí)行步驟620。
步驟608: SCP判斷所述資金帳戶的余額是否大于等于所述批價金額， 若所述資金帳戶的余額大于等于所述批價金額，執(zhí)行步驟609;否則執(zhí)行 步驟610。
步驟609: SCP預扣與所述批價金額相應的資金，執(zhí)行步驟611。 步驟609: SCP預扣資金帳戶的全部余額，執(zhí)行步驟611。 步驟611: SCP發(fā)送預扣成功消息給業(yè)務平臺，執(zhí)行步驟612。 步驟612:業(yè)務平臺根據(jù)預扣的信用額度確定用戶可使用的業(yè)務量， 并將所述業(yè)務量發(fā)送給計費觸發(fā)網元，執(zhí)行步驟613。
步驟613:計費觸發(fā)網元監(jiān)控業(yè)務的使用情況，判斷用戶是否終止使 用業(yè)務，間隔預先配置的時間間隔或在所述業(yè)務量耗盡之前或達到某一門 限值(QoS變化或費率切換的時間點)時將業(yè)務使用情況報告給業(yè)務平臺，
當用戶未終止使用業(yè)務，計費觸發(fā)網元報告給業(yè)務平臺的業(yè)務使用情況中
攜帶有已使用的業(yè)務量，執(zhí)行步驟614，并且重新執(zhí)行步驟601,用于請求 下一筆信用額度；當用戶終止使用業(yè)務后，計費觸發(fā)網元報告發(fā)送業(yè)務使 用情況給業(yè)務平臺，執(zhí)行步驟617。
步驟6M:計費觸發(fā)網元發(fā)送攜帶有用戶已使用的業(yè)務量的業(yè)務使用 情況給業(yè)務平臺，執(zhí)行步驟615。
步驟615:業(yè)務平臺根據(jù)已使用的業(yè)務量發(fā)送扣費請求給SCP，執(zhí)行步 驟616。
步驟616: SCP扣除預扣的用戶已使用的業(yè)務量，結束。 步驟61h計費觸發(fā)網元發(fā)送攜帶有用戶已使用的業(yè)務量的業(yè)務使用 情況給業(yè)務平臺，執(zhí)行步驟615。并且對于未使用的業(yè)務量，業(yè)務平臺發(fā) 送取消請求，指示SCP取消預扣的與未使用的業(yè)務量相應的信用額度。 步驟620: SCP發(fā)送預扣失敗消息給業(yè)務平臺。
步驟6n:業(yè)務平臺發(fā)送終止消息給計費觸發(fā)網元，指示計費觸發(fā)網 元不允許用戶使用業(yè)務，結束。
本實施例中，當用戶主動終止業(yè)務使用時，計費觸發(fā)網元發(fā)送業(yè)務終 止報告給業(yè)務平臺，業(yè)務終止報告中攜帶用戶未使用的業(yè)務量，業(yè)務平臺 發(fā)送取消請求，指示SCP取消預扣的用戶未使用的業(yè)務量。
上述圖3、圖4、圖5、圖6所示的實施例中的信用額度包括資源和資 金，業(yè)務平臺和SCP之間的接口是規(guī)范的CCR和CCA接口。在多業(yè)務計費 時，RFC4006直徑信用控制(diameter CC)規(guī)范中定義了多業(yè)務信用控制 (Multiple-Services-Credit-Control,以下簡稱MSCC )這個AVP，用于 多業(yè)務扣費時對每個業(yè)務做獨立的信用控制，所以MSCC提供了每個業(yè)務 的信用控制消息，該MSCC AVP為組AVP (即由多個AVP組成)，才各式如下
MSCC ::= < AVP Header: TBD >業(yè)務分酉己量[Reques ted-Service-Uni t ]業(yè)務申請量 *[ Used-Service-Unit ]業(yè)務使用量價格改變用法 業(yè)務標示符 計費組 *[ G-S-U-Pool-Reference ]有效時間結果碼 *[ AVP ]
在多業(yè)務計費場景下，有多少個業(yè)務同時計費，CCR/CCA(信用控制 請求/信用控制回答)消息中就有多少個MSCC AVP (多業(yè)務信用控制屬性 對)。
其中，Rating-Group表示計費組，用于區(qū)分不同的業(yè)務，根據(jù)需要開 展的業(yè)務制定取值。如
在業(yè)務平臺上預留0-50作為保留Rating-Group:
l:彩信
2: WAP
SCP需要并且僅需要識別保留的Rating-Group相應的含義，對非保留 范圍內的rating-group可以不作處理。
Result-code表示結果碼，只在CCA消息的MSCC里出現(xiàn)，每一個MSCC 里都必須有一個Result-Code,表示該次扣除與業(yè)務使用量相應的資源或 資金是否成功。
Requested-Service-Unit表示業(yè)務申請量，只在CCR中存在，用于 傳遞業(yè)務的申請量，具體語法如下Requested-Service-Unit : = < AVP Header: 437 > [CC-Time ]業(yè)務申請時長，對于時長計費業(yè)務 [CC-Money ]業(yè)務申請金額業(yè)務申請流量，對于流量計費業(yè)務 [CC-Input-Octets ]業(yè)務流入量 [CC-Output-Octets ]業(yè)務流出量業(yè)務申請次數(shù)，對于事件計費業(yè)務 其中，CC-Time、 CC-Total-Octets、 CC-Service-Specif ic-Uni ts表 示該次業(yè)務申請的量，在一次業(yè)務計費時只能出現(xiàn)一個；CC-Money表示該 次業(yè)務申請量批價后對應的金額，業(yè)務申請的量及其批價后的金額必須同 時報送給SCP。
圖4所示的智能網在線計費交互方法流程圖是針對事件計費和圖5、 圖6所示的智能網在線計費交互方法流程圖是針對會話計費的情況，由于 事件計費是單次計費，DCCA客戶端和DCCA服務器端無須保持會話狀態(tài)， 因此只需一次CCR/CCA;會話計費需要維持DCCA客戶端和DCCA服務器端 之間的會話狀態(tài)，因此存在多個CCR/CCA，其中初始CCR/CCA用于批價與 預扣，中間的CCR/CCA用于扣除、批價、預扣，最終的CCR/CCA用于批價、 扣除。
最后應說明的是以上實施例僅用以說明本發(fā)明的技術方案，而非對 其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通 技術人員應當理解其依然可以對前述各實施例所記載的技術方案進行修 改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不 使相應技術方案的本質脫離本發(fā)明各實施例技術方案的精神和范圍。
權利要求
1、一種智能網在線計費交互系統(tǒng)，其特征在于，包括計費觸發(fā)網元，根據(jù)用戶所使用的業(yè)務，向業(yè)務平臺發(fā)送計費請求并接收業(yè)務平臺的響應；業(yè)務平臺，根據(jù)接收到的計費請求，對用戶所使用的業(yè)務進行實時批價，并與智能網進行信用控制交互；智能網，通過直徑信用控制應用協(xié)議接口與所述業(yè)務平臺通信連接，對與用戶所使用的業(yè)務相應的信用額度進行處理。
2、 根據(jù)權利要求l所述的智能網在線計費交互系統(tǒng)，其特征在于，所 述業(yè)務平臺包括計費信息模塊，用于存儲業(yè)務的計費規(guī)則、計費方式； 在線計費模塊，用于根據(jù)所述計費規(guī)則對用戶所使用的業(yè)務進行實時 批價；用戶信息模塊，用于確定用戶是否為預付費用戶； 信用監(jiān)控模塊，用于根據(jù)所述計費方式、批價和用戶信息，與所述智能 網進行信用控制交互。
3、 根據(jù)權利要求l所述的智能網在線計費交互系統(tǒng)，其特征在于，所 述智能網包括資金帳戶和資源帳戶，所述資金帳戶用于存儲用戶可用的資 金，所述資源帳戶用于存儲用戶可用的資源。
4、 根據(jù)權利要求3所述的智能網在線計費交互系統(tǒng)，其特征在于，所 述資源包括短消息服務的數(shù)量或/和多媒體短消息服務的數(shù)量或/和數(shù)據(jù) 流的流量和/或數(shù)據(jù)的使用時長。
5、 根據(jù)權利要求l所述的智能網在線計費交互系統(tǒng)，其特征在于，所 述處理包括信用額度的預扣、信用額度的扣除、信用額度的直接扣除、 信用額度的返還。
6、 根據(jù)權利要求l所述的智能網在線計費交互系統(tǒng)，其特征在于，所述信用額度包括資源和資金。
7、 一種智能網在線計費交互方法，其特征在于，包括業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息，用的業(yè)務量；根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網，所述信用控制請求通 過直徑信用控制應用協(xié)議接口指示智能網進行相應的信用額度處理。
8、 根據(jù)權利要求7所述的智能網在線計費交互方法，其特征在于，所 述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息包 括業(yè)務平臺接收計費觸發(fā)網元發(fā)送的計費請求，并根據(jù)所述計費請求進 行實時批價；發(fā)送信用額度扣除請求給智能網，所述信用額度扣除請求中包括用戶 所使用的業(yè)務的業(yè)務類別、使用量和批價金額；智能網根據(jù)所述信用額度扣除請求判斷信用額度帳戶余額是否充足， 若充足，則扣除相應的信用額度并發(fā)送扣除成功消息給業(yè)務平臺；業(yè)務平臺發(fā)送計費請求成功消息給計費觸發(fā)網元。
9、 根據(jù)權利要求8所述的智能網在線計費交互方法，其特征在于，所 述智能網根據(jù)所述信用額度扣除請求判斷信用額度帳戶余額是否充足，若 充足，則扣除相應的信用額度并發(fā)送扣除成功消息給業(yè)務平臺包括智能網根據(jù)所述業(yè)務類型，判斷是否存在與所述業(yè)務類型相應的資源 帳戶，若存在，則判斷所述資源帳戶的余額是否大于等于所述使用量，若 是，則扣除與所述使用量相應的資源，并發(fā)送扣除成功消息給業(yè)務平臺； 若不是或資源帳戶不存在，則判斷資金帳戶的余額是否大于等于所述批價 金額，若是，則扣除與所述批價金額相應的資金，并發(fā)送扣除成功消息給 業(yè)務平臺。
10、 根據(jù)權利要求9所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息 還包括若所述資金帳戶余額小于所述批價金額，則發(fā)送扣除失敗消息給業(yè)務平臺；業(yè)務平臺發(fā)送計費請求失敗消息給計費觸發(fā)網元。
11、 根據(jù)權利要求8所述的智能網在線計費交互方法，其特征在于， 所述根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網具體包括當用戶未成功使用業(yè)務時，計費觸發(fā)網元發(fā)送業(yè)務使用失敗消息給業(yè)務平臺；業(yè)務平臺發(fā)送返還請求給智能網，指示智能網返還扣除的信用額度。
12、 根據(jù)權利要求7所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息 包括業(yè)務平臺接收計費觸發(fā)網元發(fā)送的計費請求，并根據(jù)所述計費請求進 行實時批價；發(fā)送信用額度預扣請求給智能網，所述信用額度預扣請求中包括用戶 所使用的業(yè)務的業(yè)務類別、申請量和批價金額；智能網根據(jù)所述信用額度預扣請求判斷信用額度帳戶余額是否為零， 若不為零，則預扣相應的信用額度并發(fā)送預扣成功消息給業(yè)務平臺；業(yè)務平臺判斷預扣的信用額度是否大于等于申請量或者批價金額，若 是，則發(fā)送計費請求成功消息給計費觸發(fā)網元。
13、 根據(jù)權利要求12所述的智能網在線計費交互方法，其特征在于， 所述智能網根據(jù)所述信用額度預扣請求判斷信用額度帳戶余額是否為零， 若不為零，則預扣相應的信用額度并發(fā)送預扣成功消息給業(yè)務平臺包括智能網根據(jù)所述業(yè)務類型，判斷是否存在與所述業(yè)務類型相應的資源帳戶，若存在，則判斷所述資源帳戶的余額是否大于等于所述申請量，若是，則預扣與所述申請量相應的資源，并發(fā)送預扣成功消息給業(yè)務平臺； 若不是或資源帳戶不存在，則判斷資金帳戶的余額是否為零，若資金帳戶 的余額不為零，則判斷所述資金帳戶的余額是否大于等于所述批價金額， 若所述資金帳戶的余額大于等于所述批價金額，則預扣與所迷批價金額相 應的資金，并發(fā)送預扣成功消息給業(yè)務平臺，若所述資金帳戶的余額小于 所述批價金額，則預扣所述資金帳戶的余額，并發(fā)送預扣成功消息給業(yè)務 平臺。
14、 根據(jù)權利要求12所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息 還包括若所述資金帳戶的余額為零，則發(fā)送預扣請求失敗消息給業(yè)務平臺； 業(yè)務平臺發(fā)送計費請求失敗消息給計費觸發(fā)網元。
15、 根據(jù)權利要求12所述的智能網在線計費交互方法，其特征在于， 所述根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網包括當用戶成功使用業(yè)務時，計費觸發(fā)網元發(fā)送計費確認請求給業(yè)務平 臺；業(yè)務平臺發(fā)送扣費請求給智能網，指示智能網扣除預扣的信用額度；當用戶未成功使用業(yè)務時，計費觸發(fā)網元發(fā)送業(yè)務使用失敗消息給業(yè) 務平臺；業(yè)務平臺發(fā)送取消請求給智能網，指示智能網取消預扣的信用額 度。
16、 根據(jù)權利要求12所述的智能網在線計費交互方法，其特征在于， 所述根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網包括當業(yè)務平臺判斷 出預扣的信用額度小于申請量或者批價金額，則發(fā)送計費請求失敗消息給 計費觸發(fā)網元，并發(fā)送取消請求給智能網，指示智能網取消預扣的信用額 度。
17、 根據(jù)權利要求7所述的智能網在線計費交互方法，其特征在于，所述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息包括業(yè)務平臺接收計費觸發(fā)網元發(fā)送的計費請求，并根據(jù)所述計費請求進 行實時批價；發(fā)送信用額度預扣請求給智能網，所述信用額度預扣請求中包括用戶所使用的業(yè)務的業(yè)務類別、申請量和批價金額；智能網根據(jù)所述信用額度預扣請求判斷信用額度帳戶余額是否為零， 若不為零，則預扣相應的信用額度并發(fā)送預扣成功消息給業(yè)務平臺；業(yè)務平臺根據(jù)預扣的信用額度確定用戶可使用的業(yè)務量，并將所述業(yè) 務量發(fā)送給計費觸發(fā)網元。
18、 根據(jù)權利要求17所述的智能網在線計費交互方法，其特征在于，所述智能網根據(jù)所述信用額度預扣請求判斷信用額度帳戶余額是否為零， 若不為零，則預扣相應的信用額度并發(fā)送預扣成功消息給業(yè)務平臺包括智能網根據(jù)所述業(yè)務類型，判斷是否存在與所述業(yè)務類型相應的資源 帳戶，若存在，則判斷所述資源帳戶的余額是否大于等于所述申請量，若 是，則預扣與所述申請量相應的資源，并發(fā)送預扣成功消息給業(yè)務平臺； 若不是或資源帳戶不存在，則判斷資金帳戶的余額是否為零，若資金帳戶 的余額不為零，則判斷所述資金帳戶的余額是否大于等于所述批價金額， 若所述資金帳戶的余額大于等于所述批價金額，則預扣與所述批價金額相 應的資金，并發(fā)送預扣成功消息給業(yè)務平臺，若所述資金帳戶的余額小于 所述批價金額，則預扣所述資金賬戶的余額，并發(fā)送預扣成功消息給業(yè)務 平臺。
19、 根據(jù)權利要求18所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息 還包括若所述資金帳戶的余額為零，則發(fā)送預扣失敗消息給業(yè)務平臺；業(yè)務平臺發(fā)送計費請求失敗消息給計費觸發(fā)網元。
20、 根據(jù)權利要求18所述的智能網在線計費交互方法，其特征在于， 所述根據(jù)業(yè)務使用情況發(fā)送信用控制請求給智能網包括計費觸發(fā)網元監(jiān)控業(yè)務的使用情況，間隔預先配置的時間間隔或在所 述業(yè)務量耗盡之前或達到門限值時將業(yè)務使用情況報告給業(yè)務平臺；業(yè)務平臺根據(jù)所述業(yè)務使用情況指示智能網進行相應的信用額度處理。
21、 根據(jù)權利要求20所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務平臺根據(jù)所述業(yè)務使用情況指示智能網進行相應的信用額度處 理包括當用戶未終止使用業(yè)務，則發(fā)送扣費請求和信用額度預扣請求，所述 扣費請求包括根據(jù)業(yè)務使用情況得到的已使用的業(yè)務量，指示智能網扣除 預扣的與所述已使用的業(yè)務量相應的信用額度。
22、 根據(jù)權利要求7所述的智能網在線計費交互方法，其特征在于， 所述信用控制請求通過直徑信用控制應用協(xié)議接口指示智能網進行相應 的信用額度處理包括業(yè)務平臺和智能網通過信用控制請求和信用控制響 應進行交互，所述信用控制請求包括第一多業(yè)務信用控制屬性值對，所述 信用控制響應包括第二多業(yè)務信用控制屬性值對，多業(yè)務信用控制屬性值 對用于對不同的業(yè)務進行計費，多業(yè)務信用控制屬性值對的個數(shù)與業(yè)務類 型對應。
23、 根據(jù)權利要求22所述的智能網在線計費交互方法，其特征在于， 所述第一多業(yè)務信用控制屬性值對包括計費組，用于區(qū)分不同的業(yè)務； 業(yè)務申請量，用于記錄業(yè)務的申請量。
24、 根據(jù)權利要求23所述的智能網在線計費交互方法，其特征在于， 所述業(yè)務申請量包括用于時長計費業(yè)務的業(yè)務申請時長或用于流量計費 業(yè)務的業(yè)務申請流量或用于事件計費業(yè)務的業(yè)務申請次數(shù)。
25、根據(jù)權利要求22所述的智能網在線計費交互方法，其特征在于，所述第二多業(yè)務信用控制屬性值對包括計費組，用于區(qū)分不同的業(yè)務；結果碼，用于記錄是否成功扣除信用額度。
全文摘要
本發(fā)明涉及一種智能網在線計費交互系統(tǒng)及方法。該智能網在線計費交互系統(tǒng)包括計費觸發(fā)網元、業(yè)務平臺和智能網，計費觸發(fā)網元根據(jù)用戶需要向業(yè)務平臺發(fā)送計費請求并接收業(yè)務平臺的響應；業(yè)務平臺對用戶所使用的業(yè)務進行實時批價，并與智能網進行信用控制交互；智能網通過直徑信用控制應用協(xié)議對用戶所使用的業(yè)務進行信用額度處理。該智能網在線計費交互方法包括業(yè)務平臺根據(jù)信用額度帳戶余額向計費觸發(fā)網元發(fā)送信用額度消息；并根據(jù)業(yè)務使用情況通過直徑信用控制應用協(xié)議指示智能網進行相應的信用額度處理。通過本發(fā)明智能網在線計費交互系統(tǒng)及方法，可以實現(xiàn)多業(yè)務計費、多賬戶計費，并且經濟實用且擴展性強。
文檔編號H04L12/14GK101183956SQ20071017999
公開日2008年5月21日 申請日期2007年12月20日 優(yōu)先權日2007年12月20日
發(fā)明者旭 楊, 蓉 王, 王志軍, 胡尼亞, 健 陳, 麗 馬 申請人:中國網絡通信集團公司