專利名稱：智能用戶補充業(yè)務計費的實現(xiàn)方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及網絡通信技術領域，尤其涉及一種智能用戶補充業(yè)務計費的實現(xiàn)方法及系統(tǒng)。
背景技術：
在GSM(全球移動通信系統(tǒng))和3GPP(The 3rd Generation PartnershipProject，第三代合作伙伴計劃)中定義ECT(Explicit Call Transfer，顯示呼叫轉移)、CD(Call Deflection，呼叫偏轉)、CCBS(Completion of Call toBusy Subscriber，遇忙呼叫完成)和MPTY(MultiParty，多方通話)補充業(yè)務，大大地豐富了移動用戶的生活和工作需要；其中ECT當前用戶從參與的兩個呼叫中退出，并接通剩下的兩方，可以靈活的實現(xiàn)呼叫轉接。此外CAMEL(Customised Applications for Mobile network Enhanced Logic，移動網絡增強邏輯的定制應用)，提出業(yè)務和交換分離的思想，提供了象PPS(Precision Positioning Service，精密定位業(yè)務)和MVPN(Mobile VirtualPrivate Number，移動私有編號計劃)等業(yè)務。
對于非智能用戶享受ECT、CD、CCBS和MPTY補充業(yè)務，話單由MSC(Mobile Switching Center，移動交換中心)產生，MSC可以知道是否發(fā)生了補充業(yè)務，以及補充業(yè)務的詳細信息，如不同階段的時長等信息；對于具備CAMEL簽約數據的智能用戶，其呼叫產生的話單由SCP(Service ControlPoint，業(yè)務控制點)產生，目前由于SSP(Service Switching Point，業(yè)務交換點)傳送給SCP的信息有限，因此SCP無法在產生的話單中記錄準確信息，這樣將導致智能用戶在享受ECT、CD、CCBS和MPTY補充業(yè)務時存在計費結算錯誤的困難。
在3GPP 22.091協(xié)議中針對ECT規(guī)定了計費要求發(fā)起ECT業(yè)務請求的用戶，在ECT成功之后依舊產生兩個呼叫的CDR(Call Detail Record，呼叫詳細信息記錄，即計費話單)。
假設發(fā)起ECT業(yè)務的用戶為A，與用戶A通話的另外兩個用戶為B和C，那么在ECT成功之后依舊產生呼叫A-B和呼叫A-C的CDR；且在CDR中表明已經成功發(fā)起ECT補充業(yè)務。在ECT成功之前，用戶A占用無線資源和網絡中繼資源，參與到兩個呼叫，ECT成功之后，用戶A不再占用無線資源和網絡中繼資源，不再參與呼叫，因此ECT成功前后應該實施不同的計費策略，ECT成功的時間戳也就成為了計費的分割點。
對于ECT補充業(yè)務的計費有三種實現(xiàn)方式月租計費方式，整體計費方式和獨立計費方式。
月租計費方式結算簡單，不能根據通話長短對用戶扣費，運營商無法確定計費策略。該方式對MSC沒有額外要求，因此可以不關心。
對于整體計費方式，不關心ECT成功的時間戳，在ECT成功之后，依舊按照A-B呼叫和A-C呼叫進行計費，即對用戶A產生兩張計費話單，話單中指示曾經發(fā)生過ECT補充業(yè)務，計費中心依據該標志進行折扣處理，但由于ECT前后時間長短比例不能確定，具體的折扣比例也無法確定，是一種近似的計費方式。
獨立計費方式是一種精確的計費方式，能夠對發(fā)起ECT補充業(yè)務的用戶在ECT成功前后分別產生不同計費話單，即最終產生四張話單，ECT成功之前的兩張話單與普通的A-B呼叫和A-C呼叫一樣，不帶ECT標志，ECT成功之后的兩張話單攜帶ECT標志。計費中心依賴后兩張話單，可以靈活的定義計費策略。
如果發(fā)起ECT補充業(yè)務的用戶是非智能用戶，計費話單由MSC產生，完全可以實現(xiàn)整體計費方式和獨立計費方式，具體應用采取哪種計費方式，由運營商確定。
但是如果發(fā)起ECT補充業(yè)務的用戶是智能用戶，智能用戶的計費話單由SCP產生，話單產生的信息受限于SSP提供給SCP的信息。目前在CAP(CAMEL Application Part，CAMEL應用部分)接口，只有在IDP(InitialDetection Point，初始檢測點)消息中攜帶Service Interaction Indicators Two(業(yè)務交互指示語2)參數，在該參數中存在ECT Treatment Indicator(ECT指示語)信息，SCP根據該信息可以知道當前用戶簽約了ECT補充業(yè)務，但是是否發(fā)起ECT補充業(yè)務，SCP無從得知；另外SCP也無法得知ECT補充業(yè)務調用成功的時間戳，以及ECT補充業(yè)務調用成功前后的通話時長。因此，對于智能用戶如果簽約ECT補充業(yè)務，要想實現(xiàn)整體計費或者獨立計費就非常的困難。
針對上述技術問題，在CAMEL2中定義了SS-CSI(Supplementary ServiceNotification CAMEL Subscription Information，補充業(yè)務CAMEL簽約數據)，當用戶發(fā)起ECT、CD、MPTY業(yè)務成功時，VLR(Visit Location Register，拜訪位置寄存器)檢查該用戶是否簽約了SS-CSI，如果有則檢查觸發(fā)準則，準則檢查通過之后，VLR會發(fā)送補充業(yè)務調用通知給SCP，對于CCBS業(yè)務，由HLR(Home Location Register，歸屬位置寄存器)發(fā)送補充業(yè)務調用通知，如圖1所示。
雖然SS-CSI能夠通知SCP用戶發(fā)起了ECT補充業(yè)務，但要是求用戶簽約時，SS-CSI中的gsmSCF地址必須與O-CSI(Originating CAMEL SubscriptionInformation，移動始發(fā)CAMEL簽約信息)/VT-CSI(VMSC TerminatingCAMEL Subscription Information，VMSC終結CAMEL簽約信息)中的gsmSCF地址一致，使得在同一個SCP中處理O-CSI/VT-CSI的業(yè)務邏輯與處理SS-CSI的業(yè)務邏輯能夠關聯(lián)起來，這樣才能生成相應的話單，如圖2所示。
對于SCP而言，O-CSI/VT-CSI業(yè)務邏輯和SS-CSI業(yè)務邏輯是兩個獨立的處理過程，SCP在接收補充業(yè)務調用通知的時候，需要根據用戶的MSISDN(Mobile Station ISDN(Integated Services Digital Network，綜合業(yè)務數字網)Number，移動臺ISDN號碼)或者IMSI(International Mobile SubscriberIdentifier，國際移動用戶標識)搜索所有O-CSI/VT-CSI處理任務，這樣的處理方式會影響SCP的處理性能。
由于在補充業(yè)務調用通知消息中并沒有攜帶ECT成功的時間戳，SCP也不能將收到補充業(yè)務調用通知的時刻確認為ECT成功的時間戳，即使攜帶時間戳，也是絕對時間，而MSC與SCP之間不可能做到絕對的時間同步，因此，SCP仍然無法準確獲得A-B和A-C呼叫中ECT調用成功前后的時間長度，所以，基于SS-CSI來實現(xiàn)智能用戶的ECT獨立計費是不可行的，即使能夠暫時實現(xiàn)獨立計費方式，但是會影響SCP運行性能，而且計費準確性不高。

發(fā)明內容
鑒于上述現(xiàn)有技術所存在的問題，本發(fā)明的目的是提供一種智能用戶補充業(yè)務計費的實現(xiàn)方法及系統(tǒng)，SCP能夠準確獲得ECT補充業(yè)務調用成功前后的時間長度，因此可以采用獨立計費方式對智能用戶發(fā)起的ECT補充業(yè)務進行精確計費，而且不會影響SCP運行性能。
本發(fā)明的目的是通過以下技術方案實現(xiàn)的本發(fā)明提供了一種的方法，包括如下步驟在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務后，業(yè)務控制點SCP根據業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長，根據補充業(yè)務調用成功前后的計費策略進行計費處理。
所述補充業(yè)務包括顯示呼叫轉移ECT、呼叫等待CW、呼叫保持CH、多方通話業(yè)務MPTY。
該方法具體包括A、當智能用戶發(fā)起呼叫請求后，SCP根據SSP上報的初始檢測點IDP消息確定智能用戶簽約了補充業(yè)務后，向SSP下發(fā)當補充業(yè)務調用成功后向SCP上報的命令；B、當所述補充業(yè)務調用成功后，SSP根據SCP的命令向SCP上報補充業(yè)務調用成功消息，并上報相應的計費信息；當呼叫結束后，SSP再次向SCP上報相應的計費信息；C、SCP根據SSP上報的補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長，并根據補充業(yè)務調用成功前后的計費策略進行計費處理。
所述步驟A具體包括當智能用戶發(fā)起呼叫請求后，SCP根據SSP上報的初始探測點消息中的業(yè)務交互指示語2參數確定智能用戶簽約了補充業(yè)務后，向SSP下發(fā)請求報告基本呼叫狀態(tài)模型事件RRBE消息，并且在該消息中配置補充業(yè)務調用通知事件SSNotifyEvent，且該SSNotifyEvent包括檢測點DP指定準則參數、事件類型參數、呼叫方參數以及監(jiān)視模式參數。
所述步驟B具體包括B1、當所述補充業(yè)務調用成功后，SSP向SCP上報基本呼叫狀態(tài)模型事件報告ERB消息，該消息中承載有SSNotifyEvent，且該SSNotifyEvent包括的DP指定準則參數、事件類型參數以及監(jiān)視模式參數與SCP下發(fā)的SSNotifyEvent的相應參數相同；并且在DP指定準則參數中還攜帶有參與補充業(yè)務的用戶數，以及相應的用戶號碼；
B2、SSP向SCP上報ERB消息的同時上報申請計費報告ACR消息，該消息中承載有智能用戶已經通話的時長信息；B3、當呼叫結束后，SSP再次向SCP上報ACR消息，該消息中承載有智能用戶已經通話的時長信息。
所述步驟C具體包括C1、SCP收到所述SSNotifyEvent后根據補充業(yè)務類型、參與補充業(yè)務的用戶數以及用戶號碼信息確定計費策略，并將SSP同時上報的ACR消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長，根據所述補充業(yè)務成功前的計費策略進行計費處理，并生成所述補充業(yè)務成功前的計費話單；C2、當呼叫結束后，SCP根據SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長，根據所述補充業(yè)務成功后的計費策略進行計費處理，并生成所述補充業(yè)務成功后的計費話單。
當所述補充業(yè)務為CW、CH、MPTY時，SCP通過RRBE配置所述SSNotifyEvent時，采用自動重配置方式。
在一個SSNotifyEvent中配置多個DP指定準則參數。
該方法具體包括D、當補充業(yè)務調用成功后，SSP向SCP上報ACR消息，該消息中承載有補充業(yè)務調用成功標志和補充業(yè)務類型，以及智能用戶已經通話的時長信息；E、SCP收到所述ACR消息后根據ACR中承載的補充業(yè)務調用成功標志和補充業(yè)務類型確定計費策略，將該消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長，根據補充業(yè)務調用成功前的計費策略進行計費處理，并生成所述補充業(yè)務成功前的計費話單；F、當呼叫結束后，SCP根據SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長，根據所述補充業(yè)務成功后的計費策略行計費處理，并生成所述補充業(yè)務成功后的計費話單。
步驟C2或步驟F中所述補充業(yè)務成功后的計費話單中攜帶所述補充業(yè)務的標志。
本發(fā)明還提供一種實現(xiàn)智能用戶補充業(yè)務計費的系統(tǒng)，該系統(tǒng)包括補充業(yè)務調用成功通知模塊，設置于SSP中，用于在呼叫過程中當智能用戶成功調用補充業(yè)務后，向補充業(yè)務計費處理模塊上報相應補充業(yè)務調用成功消息；計費信息上報模塊，設置于SSP中，用于向補充業(yè)務計費處理模塊上報智能用戶的計費信息；補充業(yè)務計費處理模塊，設置于SCP，用于根據補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長，并根據補充業(yè)務調用成功前后的計費策略進行計費處理。
由上述本發(fā)明提供的技術方案可以看出，本發(fā)明所述的方法及系統(tǒng)具有如下優(yōu)點1、SCP中的O-CSI/VT-CSI業(yè)務邏輯能夠很容易獲知智能用戶是否發(fā)生ECT補充業(yè)務，而且能夠準確獲得ECT成功前后的通話時長，因此對于智能用戶發(fā)起ECT補充業(yè)務，不但可以采用月租計費方式、整體計費方式，還可以選擇獨立計費方式進行精確計費，計費手段靈活多樣；2、對于智能用戶發(fā)起的MPTY、CW、CH等補充業(yè)務，同樣可以選擇整體計費方式、獨立計費方式或者月租計費方式，計費手段靈活多樣；3、本發(fā)明技術方案簡單易行，無需增加硬件設備，能夠很好地兼容現(xiàn)有設備。


圖1為SS-CSI業(yè)務邏輯示意圖；圖2為SCP中O-CSI/VT-CSI和SS-CSI協(xié)同工作示意圖；圖3為本發(fā)明所述的增加補充業(yè)務通知事件實現(xiàn)智能用戶補充業(yè)務的計費方法的流程圖；圖4為本發(fā)明的擴展ACR實現(xiàn)智能用戶補充業(yè)務的計費方法的流程圖；圖5為本發(fā)明所述系統(tǒng)的結構示意圖。
具體實施例方式
本發(fā)明的核心思想是在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務(比如ECT、MPTY、CW、CH等)后，SCP根據SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后通話時長，并根據相應補充業(yè)務調用成功前后的計費策略進行計費處理。
在實際應用中，可以針對ECT、MPTY、CW、CH等補充業(yè)務增加SSNotifyEvent(Supplementary Service Notify Event，補充業(yè)務調用通知事件)來實現(xiàn)向SCP上報相應補充業(yè)務調用成功的消息。補充業(yè)務調用成功事件是在移動始發(fā)CAMEL簽約信息O-CSI、移動終結CAMEL簽約數據VT-CSI所觸發(fā)的MO(移動始發(fā))、MVT(移動VMSC終結)流程中上報的。
SSNotifyEvent的具體參數如下

其中，當補充業(yè)務發(fā)生在MO端時，事件類型為O-SSNotifyEvent，當補充業(yè)務發(fā)生在MVT端時，事件類型為T-SSNotifyEvent；當呼叫方為主叫方時，呼叫方參數為Leg1，當呼叫方為被叫方時，呼叫方參數為Leg2；EDP(英文，中文)-N(NotifyAndContinue)表示通知類型事件，EDP-R(Request)表示請求類型事件。
為了對本發(fā)明有進一步的了解，下面以ECT補充業(yè)務為例并結合附圖對本發(fā)明進行詳細的說明。
本發(fā)明的具體實施方式
如圖3所示，包括如下步驟步驟31當智能用戶發(fā)起呼叫請求后，SSP向SCP上報IDP消息。
該IDP消息中承載有Service Interaction Indicators Two參數，如果智能用戶簽約了ECT補充業(yè)務，在該參數中應攜帶ECT Treatment Indicator信息。
如果ECT補充業(yè)務將發(fā)生在MO端時，SSP在O-CSI智能流程中向SCP上報IDP消息；如果ECT補充業(yè)務將發(fā)生在MVT端時，SSP在VT-CSI智能流程中向SCP上報IDP消息。
步驟32SCP收到IDP消息后，檢查Service Interaction Indicators Two參數，如果該參數中攜帶了ECT Treatment Indicator信息，則確定該智能用戶屬于ECT簽約用戶，在向SSP下發(fā)的RRBE(Request Report BCSM(Basic CallState Model，基本呼叫狀態(tài)模型)Event，請求報告BCSM事件)中配置SSNotifyEvent。
該事件的DP指定準則參數為ECT，監(jiān)視模式參數可以根據需要確定，一般的情況下配置為EDP-N；如果ECT業(yè)務將發(fā)生在MO端，事件類型參數為O-SSNotifyEvent，呼叫方參數為Leg1；如果ECT業(yè)務將發(fā)生在MVT端，事件類型參數為T-SSNotifyEvent，呼叫方參數為Leg2。
SCP向SSP下發(fā)RRBE消息的同時，還向SSP下發(fā)AC(Apply Charging，申請計費)和Continue(業(yè)務繼續(xù))消息。
步驟33SSP收到SCP下發(fā)的RRBE消息以及AC和Continue消息后，SSP繼續(xù)進行呼叫處理，當被叫應答時開始收集計費信息(通常是智能用戶的通話時長)，并向SCP上報ERB(Event Report BCSM，BCSM事件報告)應答消息。
其中，SSP向SCP上報ERB應答消息不是必需的步驟，是可選的。
步驟34在呼叫過程中，如果智能用戶成功調用ECT，則SSP向SCP上報ERB，同時上報ACR(Apply Charging Report，申請計費報告)。
其中，ERB消息中承載有O-SSNotifyEvent/T-SSNotifyEvent信息且該信息中包括事件類型、監(jiān)視模式以及DP指定準則參數，這些參數與SCP下發(fā)的RRBE消息中承載的SSNotifyEvent的相應參數相同，其中DP指定準則參數除了包括ECT業(yè)務類型外，還包括參與此次補充業(yè)務的用戶數，以及相應的用戶號碼。
ACR消息中承載有智能用戶的通話時長信息，該通話時長為從應答開始計費到SSP上報該ACR消息期間智能用戶總的通話時長。
步驟35SCP收到所述SSNotifyEvent后根據補充業(yè)務類型、參與補充業(yè)務的用戶數以及用戶號碼信息確定計費策略，并將ACR消息中智能用戶的通話時長作為ECT調用成功之前的通話時長，根據ECT調用成功前的計費策略進行計費處理，并為智能用戶生成ECT調用成功之前的話單，該話單中沒有ECT標志。
然后SCP向SSP繼續(xù)下發(fā)AC消息，通話繼續(xù)。
步驟36當呼叫結束時，SSP向SCP上報ERB消息，該消息中承載的事件類型為O-Disconnect/T-Diconnect，通知SCP呼叫拆線；同時上報ACR消息。
ACR消息中承載有智能用戶的通話時長信息，該通話時長為智能用戶總的通話時長(即自開始計費至呼叫結束止)。
步驟37SCP收到ERB消息以及ACR消息后，將從該ACR消息中獲取的通話時長減去從上次ACR消息中獲取的通話時長作為ECT成功之后的通話時長，根據ECT調用成功后的計費策略進行計費處理，并為智能用戶生成ECT成功之后的話單，該話單中攜帶ECT標志。
然后，SCP向SSP下發(fā)RC(Release Call，釋放呼叫)消息，釋放相應資源。
對于MPTY、CW、CH等補充業(yè)務，同樣適用于上述技術方案，只是需要修改DP指定準則參數。
當SCP確認智能用戶簽約了MPTY、CW、CH、ECT補充業(yè)務后，在向SSP下發(fā)的RRBE消息中配置相應補充業(yè)務的SSNotifyEvent，而且可以根據需要在一個補充業(yè)務調用通知事件中設置多個DP指定準則參數，即多個補充業(yè)務的類型，如ECT和/或CH和/或CW和/或MPTY；當智能用戶調用MPTY、CW、CH、ECT成功時，SSP都向SCP上報相應補充業(yè)務調用通知事件。因此，SCP中的O-CSI/VT-CSI業(yè)務邏輯能夠很容易獲知智能用戶是否發(fā)生補充業(yè)務，而且能夠得知補充業(yè)務成功前后的通話時長，從而進行計費處理，并產生補充業(yè)務成功前后的計費話單。
由于MPTY、CW、CH補充業(yè)務有可能在一次呼叫過程中多次發(fā)生，因此，在呼叫結束前，對于SCP向SSP下發(fā)的RRBE消息中配置的SSNotifyEvent，當發(fā)生一次補充業(yè)務后不應解配，因此，可以在SCP向SSP下發(fā)的RRBE消息中配置SSNotifyEvent時，采用自動重配置的方式，此時補充業(yè)務調用成功事件類型必須配置為EDP-N。采用自動重配置的方式，當SSP上報了一次補充業(yè)務調用成功事件之后，SCP無需重新配置SSNotifyEvent，就可以實現(xiàn)當再次發(fā)生補充業(yè)務調用成功時，SSP再次上報補充業(yè)務調用成功事件的目的，而且SSP前后上報的補充業(yè)務類型可以不同。
除增加補充業(yè)務調用通知事件之外，另外還可以通過擴展ACR消息的方式來實現(xiàn)向SCP上報相應補充業(yè)務調用成功的消息。
具體實施方式
如圖4所示，包括如下步驟步驟41當智能用戶發(fā)起呼叫請求后，SSP向SCP上報IDP消息。
該IDP消息中承載有Service Interaction Indicators Two參數，如果智能用戶簽約了ECT、MPTY、CW、CH補充業(yè)務，則在該參數中應攜帶ECT/MPTY/CW/CH Treatment Indicator信息。
如果補充業(yè)務將發(fā)生在MO端，SSP在O-CSI智能流程中向SCP上報IDP消息；如果補充業(yè)務將發(fā)生在MVT端，SSP在VT-CSI智能流程中向SCP上報IDP消息。
步驟42SCP收到IDP消息后，檢查Service Interaction Indicators Two參數，如果該參數中攜帶了ECT/MPTY/CW/CH Treatment Indicator信息，則確定該智能用戶簽約了相應的補充業(yè)務；然后向SSP下發(fā)RRBE消息、AC消息以及Continue消息。
步驟43SSP收到SCP下發(fā)的RRBE消息以及AC和Continue消息后開始收集計費信息，并向SCP上報ERB應答消息。
其中，SSP向SCP上報ERB應答消息不是必需的，是可選的。
步驟44在呼叫過程中，如果智能用戶成功發(fā)起ECT/MPTY/CW/CH，則SSP向SCP上報ACR消息，該消息中除了承載有智能用戶的通話時長信息外，還承載有ECT/MPTY/CW/CH補充業(yè)務調用成功標志以及相應的補充業(yè)務類型。
步驟45、SCP根據ACR消息中承載的補充業(yè)務調用成功標志以及相應的補充業(yè)務類型確定計費策略，并將ACR消息中承載的智能用戶的通話時長作為ECT/MPTY/CW/CH成功之前的通話時長，根據補充業(yè)務調用成功前的計費策略進行計費處理，并為智能用戶生成ECT/MPTY/CW/CH成功之前的話單，該話單中沒有ECT/MPTY/CW/CH標志。
然后SCP向SSP繼續(xù)下發(fā)AC消息，通話繼續(xù)。
步驟46當呼叫結束時，SSP向SCP上報ERB消息，該消息中承載的事件類型為O-Disconnect/T-Diconnect，通知SCP呼叫拆線；同時上報ACR消息。
ACR消息中承載有智能用戶的通話時長信息，該通話時長為智能用戶總的通話時長(即自開始計費至呼叫結束止)。
步驟47SCP收到ERB拆線消息以及ACR消息后，將從該ACR消息中獲取的通話時長減去從上次ACR消息中獲取的通話時長作為ECT/MPTY/CW/CH成功之后的通話時長，根據補充業(yè)務調用成功后的計費策略進行計費處理，并為智能用戶生成ECT/MPTY/CW/CH成功之后的話單，該話單中攜帶ECT/MPTY/CW/CH標志。
然后SCP后向SSP下發(fā)RC消息，釋放相應資源。
采用上述兩種技術方案，SCP中的O-CSI/VT-CSI業(yè)務邏輯能夠很容易獲知智能用戶是否發(fā)生補充業(yè)務，而且能夠準確確定補充業(yè)務成功前后的通話時長，因此，對于該智能用戶，不但可以選擇月租計費方式，而且還可以選擇整體計費方式或獨立計費方式，當選擇整體計費方式時，可以準確判斷補充業(yè)務成功前后的通話時間比例，可以確定具體的折扣比例，使得整體計費方式成為一種精確的計費方式；當選擇獨立計費方式時，可以針對補充業(yè)務成功前后采用不同的計費策略，而且計費準確。因此為運營商提供了靈活的計費手段。具體采用整體計費方式還是獨立計費方式，由運營商來確定，但需要MSC和SCP保持一致，因此在SCP扣費的時候，MSC也同步生成話單，用于計費對帳。
本發(fā)明還提供了一種實現(xiàn)智能用戶補充業(yè)務計費的系統(tǒng)，如圖5所示，該系統(tǒng)包括補充業(yè)務調用成功通知模塊、計費信息上報模塊和補充業(yè)務計費處理模塊。其中，補充業(yè)務調用成功消息通知模塊，設置于SSP中，其功能為在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務時，向補充業(yè)務計費處理模塊上報相應補充業(yè)務調用成功消息；計費信息上報模塊，設置于SSP中，其功能為向補充業(yè)務計費處理模塊上報智能用戶的計費信息；補充業(yè)務計費處理模塊，設置于SCP中，其功能為根據補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長，并根據補充業(yè)務調用成功前后的計費策略進行計費處理。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，可輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
權利要求
1.一種智能用戶補充業(yè)務計費的實現(xiàn)方法，其特征在于，包括在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務后，業(yè)務控制點SCP根據業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長，根據補充業(yè)務調用成功前后的計費策略進行計費處理。
2.根據權利要求1所述的方法，其特征在于，所述補充業(yè)務包括顯示呼叫轉移ECT、呼叫等待CW、呼叫保持CH、多方通話業(yè)務MPTY。
3.根據權利要求1所述的方法，其特征在于，該方法具體包括A、當智能用戶發(fā)起呼叫請求后，SCP根據SSP上報的初始檢測點IDP消息確定智能用戶簽約了補充業(yè)務后，向SSP下發(fā)當補充業(yè)務調用成功后向SCP上報的命令；B、當所述補充業(yè)務調用成功后，SSP根據SCP的命令向SCP上報補充業(yè)務調用成功消息，并上報相應的計費信息；當呼叫結束后，SSP再次向SCP上報相應的計費信息；C、SCP根據SSP上報的補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長，并根據補充業(yè)務調用成功前后的計費策略進行計費處理。
4.根據權利要求3所述的方法，其特征在于，所述步驟A具體包括當智能用戶發(fā)起呼叫請求后，SCP根據SSP上報的初始探測點消息中的業(yè)務交互指示語2參數確定智能用戶簽約了補充業(yè)務后，向SSP下發(fā)請求報告基本呼叫狀態(tài)模型事件RRBE消息，并且在該消息中配置補充業(yè)務調用通知事件SSNotifyEvent，且該SSNotifyEvent包括檢測點DP指定準則參數、事件類型參數、呼叫方參數以及監(jiān)視模式參數。
5.根據權利要求4所述的方法，其特征在于，所述步驟B具體包括B1、當所述補充業(yè)務調用成功后，SSP向SCP上報基本呼叫狀態(tài)模型事件報告ERB消息，該消息中承載有SSNotifyEvent，且該SSNotifyEvent包括的DP指定準則參數、事件類型參數以及監(jiān)視模式參數與SCP下發(fā)的SSNotifyEvent的相應參數相同；并且在DP指定準則參數中還攜帶有參與補充業(yè)務的用戶數，以及相應的用戶號碼；B2、SSP向SCP上報ERB消息的同時上報申請計費報告ACR消息，該消息中承載有智能用戶已經通話的時長信息；B3、當呼叫結束后，SSP再次向SCP上報ACR消息，該消息中承載有智能用戶已經通話的時長信息。
6.根據權利要求5所述的方法，其特征在于，所述步驟C具體包括C1、SCP收到所述SSNotifyEvent后根據補充業(yè)務類型、參與補充業(yè)務的用戶數以及用戶號碼信息確定計費策略，并將SSP同時上報的ACR消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長，根據所述補充業(yè)務成功前的計費策略進行計費處理，并生成所述補充業(yè)務成功前的計費話單；C2、當呼叫結束后，SCP根據SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長，根據所述補充業(yè)務成功后的計費策略進行計費處理，并生成所述補充業(yè)務成功后的計費話單。
7.根據權利要求4至6任一項所述的方法，其特征在于當所述補充業(yè)務為CW、CH、MPTY時，SCP通過RRBE配置所述SSNotifyEvent時，采用自動重配置方式。
8.根據權利要求4至6任一項所述的方法，其特征在于在一個SSNotifyEvent中配置多個DP指定準則參數。
9.根據權利要求1所述的方法，其特征在于，該方法具體包括D、當補充業(yè)務調用成功后，SSP向SCP上報ACR消息，該消息中承載有補充業(yè)務調用成功標志和補充業(yè)務類型，以及智能用戶已經通話的時長信息；E、SCP收到所述ACR消息后根據ACR中承載的補充業(yè)務調用成功標志和補充業(yè)務類型確定計費策略，將該消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長，根據補充業(yè)務調用成功前的計費策略進行計費處理，并生成所述補充業(yè)務成功前的計費話單；F、當呼叫結束后，SCP根據SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長，根據所述補充業(yè)務成功后的計費策略行計費處理，并生成所述補充業(yè)務成功后的計費話單。
10.根據權利要求6或9所述的方法，其特征在于，步驟C2或步驟F中所述補充業(yè)務成功后的計費話單中攜帶所述補充業(yè)務的標志。
11.一種實現(xiàn)智能用戶補充業(yè)務計費的系統(tǒng)，其特征在于，系統(tǒng)包括補充業(yè)務調用成功通知模塊，設置于SSP中，用于在呼叫過程中當智能用戶成功調用補充業(yè)務后，向補充業(yè)務計費處理模塊上報相應補充業(yè)務調用成功消息；計費信息上報模塊，設置于SSP中，用于向補充業(yè)務計費處理模塊上報智能用戶的計費信息；補充業(yè)務計費處理模塊，設置于SCP，用于根據補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長，并根據補充業(yè)務調用成功前后的計費策略進行計費處理。
全文摘要
本發(fā)明公開了一種智能用戶補充業(yè)務計費的實現(xiàn)方法及系統(tǒng)，該方法的核心為在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務后，業(yè)務控制點SCP根據業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長，根據補充業(yè)務調用成功前后的計費策略進行計費處理。采用本發(fā)明的方法及系統(tǒng)，SCP能夠準確獲得補充業(yè)務調用成功前后的通話時長，可以采用獨立計費方式對智能用戶發(fā)起的ECT補充業(yè)務進行精確計費，而且不會影響SCP運行性能。
文檔編號H04M15/00GK1874535SQ20061005740
公開日2006年12月6日 申請日期2006年3月13日 優(yōu)先權日2006年3月13日
發(fā)明者石勝兵 申請人:華為技術有限公司