專利名稱：基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法和系統(tǒng)，屬于網(wǎng)絡通信技術領域。
背景技術：
業(yè)務代理義1^化6 Broker (以下簡稱SB)是3GPP SA2工作組研究和定義的一個網(wǎng)元，其目的是為了解決現(xiàn)實網(wǎng)絡中普遍存在的業(yè)務交互問題。
SB位于核心網(wǎng)網(wǎng)元與業(yè)務平臺之間，與核心網(wǎng)網(wǎng)元以及業(yè)務平臺進行信令交互， 通過靈活的策略配置將各業(yè)務平臺上的多種業(yè)務關聯(lián)起來，在對原有業(yè)務邏輯不做修改的前提下，僅需要通過可視化的簡單配置即可使得用戶可以同時申請多個業(yè)務，完成完整的業(yè)務交互流程，從而大大簡化運營商在推出新的業(yè)務時對已有業(yè)務的改動和一系列配套工作。SB不僅能夠通過多業(yè)務之間的關聯(lián)解決用戶同時申請多個業(yè)務時的業(yè)務交互問題，還可以在多個原子業(yè)務的基礎上提供復雜的融合業(yè)務。SB既可以支持IMS域，也可以支持CS 域智能網(wǎng)，所述業(yè)務平臺既可以是應用服務器AS，也可以是業(yè)務控制點SCP。
由于每個呼叫流程中SB會與多個業(yè)務平臺交互，同時每個業(yè)務平臺都會對其控制的呼叫產(chǎn)生話單，因此存在有多話單計費問題。
IMS域的計費解決方案是所有業(yè)務平臺與計費網(wǎng)元CG連接，實時將計費信息傳給CG，由CG生成話單，CG本身具備話單關聯(lián)和合并能力，因此對于經(jīng)過SB的呼叫，多個業(yè)務平臺產(chǎn)生的多張話單，最后可以由CG合并為一張話單，不存在多話單問題。
CS域智能網(wǎng)的計費方案是SCP產(chǎn)生話單，BOSS采集SCP的話單進行批價和扣費。 引入SB后，經(jīng)過SB的呼叫，多個SCP會產(chǎn)生多張話單，由于電路域中沒有類似CG的網(wǎng)元， 因此就出現(xiàn)了多話單的問題。
目前，如何解決智能網(wǎng)中SB所支持融合的多個業(yè)務平臺在交互時產(chǎn)生的多話單計費問題？是一個急需要解決的技術難題。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的是提供一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法和系統(tǒng)，能解決智能網(wǎng)中SB所支持融合的多個業(yè)務平臺在交互時所產(chǎn)生的多話單計費問題。
為了達到上述目的，本發(fā)明提供了一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，包括有 步驟一、移動交換中心MSC將呼叫觸發(fā)到業(yè)務代理％1^化6 Broker，當呼叫接通后，Service Broker從本次呼叫所觸發(fā)的若干個業(yè)務控制點SCP業(yè)務中選擇計費優(yōu)先級最高的SCP為話單SCP，并向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，接收所述剔單消息的 SCP不產(chǎn)生話單； 步驟二、當通話結(jié)束后，Service Broker將通話時長發(fā)送給話單SCP，并由所述話單SCP產(chǎn)生話單。
4 為了達到上述目的，本發(fā)明還提供了一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費系統(tǒng)， 包括有移動交換中心MSC、業(yè)務代理Service Broker和若干個Service Broker所支持融合業(yè)務的業(yè)務控制點SCP，所述krvice Broker進一步包括有 話單管理裝置，用于從呼叫所觸發(fā)的若干個SCP業(yè)務中選擇計費優(yōu)先級最高的 SCP為話單SCP，向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，并向話單SCP發(fā)送通話時長。
與現(xiàn)有技術相比，本發(fā)明的有益效果是本發(fā)明根據(jù)SB所支持融合業(yè)務的計費優(yōu)先級，將通話時長為0的ACR消息或者不帶成分的TC_END消息發(fā)送給計費優(yōu)先級低的SCP， 并將實際的通話時長發(fā)送給計費優(yōu)先級最高的SCP，由于SCP收到通話時長為0的ACR消息或者不帶成分的TC_END時不產(chǎn)生話單，所以只有計費優(yōu)先級最高的SCP根據(jù)通話時長產(chǎn)生話單，從而解決了智能網(wǎng)中SB所支持融合的多個業(yè)務平臺在交互時產(chǎn)生的多話單計費問題，并且不涉及現(xiàn)網(wǎng)SCP的配合改造，方案簡單，工作可靠，便于推廣和普及應用。


圖1是本發(fā)明基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法的流程圖。
圖2是圖1步驟一的具體操作流程圖。
圖3是本發(fā)明采用通話時長為0的ACR消息作為剔單消息的實施例的信令流程圖。
圖4是本發(fā)明采用不帶成分的TC_END消息作為剔單消息的實施例的信令流程圖。
圖5是本發(fā)明基于業(yè)務代理的智能網(wǎng)業(yè)務計費系統(tǒng)的實施例的組成結(jié)構(gòu)示意圖。
圖6是話單管理裝置的組成結(jié)構(gòu)示意圖。
具體實施例方式為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結(jié)合附圖好實施例對本發(fā)明作進一步的詳細描述。
如圖1所示，本發(fā)明基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法如下 步驟一、MSC將呼叫觸發(fā)到SB，當呼叫接通后，SB從本次呼叫所觸發(fā)的若干個SCP 業(yè)務中選擇計費優(yōu)先級最高的SCP為話單SCP，并向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，接收所述剔單消息的SCP不產(chǎn)生話單。
步驟二、當通話結(jié)束后，SB將通話時長發(fā)送給話單SCP，并由所述話單SCP產(chǎn)生話 為了實現(xiàn)本發(fā)明的技術方案，需要預先對SB所支持融合的業(yè)務的計費優(yōu)先級進行排序，并將所述計費優(yōu)先級信息配置到SB的計費優(yōu)先級表中。
本發(fā)明可以按照計費優(yōu)惠不能疊加的原則，將SB所支持融合的業(yè)務根據(jù)計費優(yōu)惠情況進行排序，優(yōu)惠最多的業(yè)務的計費優(yōu)先級最高。由于針對不同的業(yè)務流程，SB所支持融合的業(yè)務的計費優(yōu)先級可能不同，因此，本發(fā)明還需按照不同的業(yè)務流程，分別對SB 所支持融合的業(yè)務的計費優(yōu)先級進行排序，所述業(yè)務流程包含主叫流程、被叫流程、前轉(zhuǎn)流程。
例如SB支持業(yè)務A、業(yè)務B、業(yè)務C的融合，所述三個業(yè)務(A、B、C)都包含有主叫流程、被叫流程、前轉(zhuǎn)流程，按照不同業(yè)務流程的計費優(yōu)先級如下表所示，其中計費優(yōu)先級數(shù)字越低則表示級別越高。

業(yè)務流程業(yè)務A業(yè)務B業(yè)務C主叫流程123被叫流程213前轉(zhuǎn)流程132 如圖2所示，所述步驟一進一步包括有 步驟11、MSC將呼叫觸發(fā)到SB，SB根據(jù)用戶簽約業(yè)務和規(guī)則，選擇相應的SCP業(yè)務進行觸發(fā)后，指示MSC呼叫接續(xù)； 步驟12、當呼叫接通后，SB根據(jù)用戶所對應的業(yè)務流程，從計費優(yōu)先級表中讀取被觸發(fā)的若干個SCP業(yè)務的計費優(yōu)先級信息，并從中選擇計費優(yōu)先級最高的SCP為話單 SCP，然后向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息。
所述剔單消息可以采用基于CAP協(xié)議的ACR消息，或者基于TCAP協(xié)議的TC_END 消息。當采用ACR消息作為剔單消息時，所述ACR消息的通話時長為0 ；當采用TC_END消息作為剔單消息時，所述TC_END消息不帶成分。這樣，當SCP接收到通話時長為0的ACR消息或者不帶成分的TC_END后將不產(chǎn)生話單，所以本發(fā)明不需涉及現(xiàn)網(wǎng)SCP的配合改造。
所述步驟二中，SB通過ACR消息將實際的通話時長發(fā)送給話單SCP。
為進一步清楚解釋本發(fā)明方法，圖3和圖4分別示出了本發(fā)明方法采用通話時長為0的ACR消息和不帶成分的TC_END消息作為剔單消息的實施例的信令流程圖。其中，用戶A申請了業(yè)務A、業(yè)務B、業(yè)務C，三個業(yè)務的被叫流程的計費優(yōu)先級從高到低為業(yè)務A、 業(yè)務B、業(yè)務C。當用戶A作為被叫用戶時 (1)、如圖3所示，采用通話時長為0的ACR消息作為剔單消息的實施例的信令交互流程如下 步驟al-a3、MSC將呼叫觸發(fā)至SB，SB根據(jù)用戶A的簽約業(yè)務和規(guī)則，選擇要觸發(fā)的SCP 業(yè)務A的SCP、業(yè)務B的SCP和業(yè)務C的SCP。
步驟a4_a9、SB分別觸發(fā)業(yè)務A、業(yè)務B和業(yè)務C對應的SCP。
步驟alO、SB指示MSC接續(xù)。
步驟all、SB根據(jù)計費優(yōu)先級表中被叫流程所對應的業(yè)務A、業(yè)務B和業(yè)務C的計費優(yōu)先級，選擇業(yè)務A的SCP為話單SCP。
步驟al2_al5、SB向業(yè)務B的SCP發(fā)送通話時長為O的ACR消息，業(yè)務B流程結(jié)束，未產(chǎn)生話單。
步驟al6_al9、SB向業(yè)務C的SCP發(fā)送通話時長為O的ACR消息，業(yè)務C流程結(jié)束，未產(chǎn)生話單。
步驟a20-a27、用戶A通話結(jié)束后，SB通過ACR消息將實際的通話時長發(fā)送給業(yè)務 A的SCP，業(yè)務A的SCP根據(jù)所述通話時長產(chǎn)生話單。
(2)、如圖4所示，采用不帶成分的TC_END消息作為剔單消息的實施例的信令交互流程如下 步驟bl_b3、MSC將呼叫觸發(fā)至SB，SB根據(jù)用戶A的簽約業(yè)務和規(guī)則，選擇要觸發(fā)的SCP 業(yè)務A的SCP、業(yè)務B的SCP和業(yè)務C的SCP。
步驟b4_b9、SB分別觸發(fā)業(yè)務A、業(yè)務B和業(yè)務C對應的SCP。
步驟blO、SB指示MSC接續(xù)。
步驟bll、SB根據(jù)計費優(yōu)先級表中被叫流程所對應的業(yè)務A、業(yè)務B和業(yè)務C的計費優(yōu)先級，選擇業(yè)務A的SCP為話單SCP。
步驟bl2_bl3、SB向業(yè)務B的SCP發(fā)送不帶成分的TC_END消息，業(yè)務B流程結(jié)束，
未產(chǎn)生話單。
步驟bl4_bl5、SB向業(yè)務C的SCP發(fā)送不帶成分的TC_END消息，業(yè)務C流程結(jié)束，
未產(chǎn)生話單。
步驟bl6_b23、用戶A通話結(jié)束后，SB通過ACR消息將實際的通話時長發(fā)送給業(yè)務 A的SCP，業(yè)務A的SCP根據(jù)所述通話時長產(chǎn)生話單。
如圖5所示，本發(fā)明基于業(yè)務代理的智能網(wǎng)業(yè)務計費系統(tǒng)包括有MSC、SB和若干個 SB所支持融合業(yè)務的SCP，其中SB進一步包括有 話單管理裝置，用于從呼叫所觸發(fā)的若干個SCP業(yè)務中選擇計費優(yōu)先級最高的 SCP為話單SCP，向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，并向話單SCP發(fā)送通話時長。
如圖6所示，話單管理裝置進一步包括有優(yōu)先級管理部件和話單SCP選擇部件 優(yōu)先級管理部件，用于對SB的計費優(yōu)先級表進行配置，并將業(yè)務的計費優(yōu)先級信息發(fā)送給話單SCP選擇部件。計費優(yōu)先級可根據(jù)業(yè)務的變化進行調(diào)整，并通過優(yōu)先級管理部件配置到計費優(yōu)先級表中。
話單SCP選擇部件，用于根據(jù)SB發(fā)來的呼叫通知指令、以及優(yōu)先級管理部件發(fā)送來的業(yè)務的計費優(yōu)先級信息，在呼叫接通時選擇計費優(yōu)先級最高的SCP為話單SCP，并通知 SB向計費優(yōu)先級較低的SCP發(fā)送通話時長為0的ACR消息或者不帶成分的TC_END消息，然后在通話結(jié)束后通知SB向話單SCP發(fā)送攜帶有實際的通話時長的ACR消息。
權(quán)利要求
1.一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，包括有步驟一、移動交換中心MSC將呼叫觸發(fā)到業(yè)務代理krvice Broker，當呼叫接通后， Service Broker從本次呼叫所觸發(fā)的若干個業(yè)務控制點SCP業(yè)務中選擇計費優(yōu)先級最高的SCP為話單SCP，并向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，接收所述剔單消息的 SCP不產(chǎn)生話單；步驟二、當通話結(jié)束后，Service Broker將通話時長發(fā)送給話單SCP，并由所述話單 SCP產(chǎn)生話單。
2.如權(quán)利要求1所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，還包括有 預先對krvice Broker所支持融合的業(yè)務的計費優(yōu)先級進行排序，并將所述計費優(yōu)先級信息配置到krvice Broker的計費優(yōu)先級表中。
3.如權(quán)利要求2所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，還包括有 按照計費優(yōu)惠不能疊加的原則，并針對不同的業(yè)務流程分別對^^“⑶Broker所支持融合的業(yè)務的計費優(yōu)先級進行排序，所述業(yè)務流程包含主叫流程、被叫流程、前轉(zhuǎn)流程。
4.如權(quán)利要求1所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，所述步驟一進一步包括有步驟11、MSC將呼叫觸發(fā)到krvice Broker, Service Broker根據(jù)用戶簽約業(yè)務和規(guī)則，選擇相應的SCP業(yè)務進行觸發(fā)后，指示MSC呼叫接續(xù)；步驟12、當呼叫接通后，Service Broker根據(jù)用戶所對應的業(yè)務流程，從計費優(yōu)先級表中讀取被觸發(fā)的若干個SCP業(yè)務的計費優(yōu)先級信息，并從中選擇計費優(yōu)先級最高的SCP為話單SCP，然后向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息。
5.如權(quán)利要求1所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，所述步驟一中的剔單消息可以是基于CAP協(xié)議的ACR消息，或基于TCAP協(xié)議的TC_END消息。
6.如權(quán)利要求5所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，當采用ACR 消息作為剔單消息時，所述ACR消息的通話時長為0 ；當采用TC_END消息作為剔單消息時， 所述TC_END消息不帶成分。
7.如權(quán)利要求1所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法，其特征在于，所述步驟二中，Service Broker通過ACR消息將通話時長發(fā)送給話單SCP。
8.一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費系統(tǒng)，包括有移動交換中心MSC、業(yè)務代理 Service Broker和若干個krvice Broker支持融合業(yè)務的業(yè)務控制點SCP，其特征在于， 所述Service Broker進一步包括有話單管理裝置，用于從呼叫所觸發(fā)的若干個SCP業(yè)務中選擇計費優(yōu)先級最高的SCP為話單SCP，向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，并向話單SCP發(fā)送通話時長。
9.如權(quán)利要求8所述的基于業(yè)務代理的智能網(wǎng)業(yè)務計費系統(tǒng)，其特征在于，所述話單管理裝置進一步包括有優(yōu)先級管理部件，用于對krvice Broker的計費優(yōu)先級表進行配置，并將業(yè)務的計費優(yōu)先級信息發(fā)送給話單SCP選擇部件；話單SCP選擇部件，用于根據(jù)krvice Broker發(fā)來的呼叫通知指令、以及優(yōu)先級管理部件發(fā)送來的業(yè)務的計費優(yōu)先級信息，在呼叫接通時選擇計費優(yōu)先級最高的SCP為話單 SCP,并通知krvice Broker向計費優(yōu)先級較低的SCP發(fā)送通話時長為0的ACR消息或者不帶成分的TC_END消息，然后在通話結(jié)束后通知krvice Broker向話單SCP發(fā)送攜帶有實際的通話時長的ACR消息。
全文摘要
一種基于業(yè)務代理的智能網(wǎng)業(yè)務計費方法和系統(tǒng)，所述方法包括步驟一、移動交換中心MSC將呼叫觸發(fā)到業(yè)務代理Service Broker，當呼叫接通后，Service Broker從本次呼叫所觸發(fā)的若干個業(yè)務控制點SCP業(yè)務中選擇計費優(yōu)先級最高的SCP為話單SCP，并向其他計費優(yōu)先級較低的SCP發(fā)送剔單消息，接收所述剔單消息的SCP不產(chǎn)生話單；步驟二、當通話結(jié)束后，Service Broker將通話時長發(fā)送給話單SCP，并由所述話單SCP產(chǎn)生話單。本發(fā)明屬于網(wǎng)絡通信技術領域，能解決智能網(wǎng)中SB所支持融合的多個業(yè)務平臺在交互時產(chǎn)生的多話單計費問題，且不涉及現(xiàn)網(wǎng)SCP的配合改造，便于推廣和普及應用。
文檔編號H04W88/18GK102186156SQ20111014303
公開日2011年9月14日 申請日期2011年5月30日 優(yōu)先權(quán)日2011年5月30日
發(fā)明者廖建新, 王晶, 王純, 李煒, 植東梧, 劉國輝, 武杰, 朱曉民, 張磊, 徐童, 張樂劍, 沈奇威, 樊利民, 程莉 申請人:杭州東信北郵信息技術有限公司