專利名稱:智能用戶補充業(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簽約數(shù)據(jù)的智能用戶,其呼叫產生的話單由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)方式月租計費方式,整體計費方式和獨立計費方式。
月租計費方式結算簡單,不能根據(jù)通話長短對用戶扣費,運營商無法確定計費策略。該方式對MSC沒有額外要求,因此可以不關心。
對于整體計費方式,不關心ECT成功的時間戳,在ECT成功之后,依舊按照A-B呼叫和A-C呼叫進行計費,即對用戶A產生兩張計費話單,話單中指示曾經發(fā)生過ECT補充業(yè)務,計費中心依據(jù)該標志進行折扣處理,但由于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)參數(shù),在該參數(shù)中存在ECT Treatment Indicator(ECT指示語)信息,SCP根據(jù)該信息可以知道當前用戶簽約了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簽約數(shù)據(jù)),當用戶發(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è)務調用通知的時候,需要根據(jù)用戶的MSISDN(Mobile Station ISDN(Integated Services Digital Network,綜合業(yè)務數(shù)字網)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根據(jù)業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長,根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
所述補充業(yè)務包括顯示呼叫轉移ECT、呼叫等待CW、呼叫保持CH、多方通話業(yè)務MPTY。
該方法具體包括A、當智能用戶發(fā)起呼叫請求后,SCP根據(jù)SSP上報的初始檢測點IDP消息確定智能用戶簽約了補充業(yè)務后,向SSP下發(fā)當補充業(yè)務調用成功后向SCP上報的命令;B、當所述補充業(yè)務調用成功后,SSP根據(jù)SCP的命令向SCP上報補充業(yè)務調用成功消息,并上報相應的計費信息;當呼叫結束后,SSP再次向SCP上報相應的計費信息;C、SCP根據(jù)SSP上報的補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長,并根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
所述步驟A具體包括當智能用戶發(fā)起呼叫請求后,SCP根據(jù)SSP上報的初始探測點消息中的業(yè)務交互指示語2參數(shù)確定智能用戶簽約了補充業(yè)務后,向SSP下發(fā)請求報告基本呼叫狀態(tài)模型事件RRBE消息,并且在該消息中配置補充業(yè)務調用通知事件SSNotifyEvent,且該SSNotifyEvent包括檢測點DP指定準則參數(shù)、事件類型參數(shù)、呼叫方參數(shù)以及監(jiān)視模式參數(shù)。
所述步驟B具體包括B1、當所述補充業(yè)務調用成功后,SSP向SCP上報基本呼叫狀態(tài)模型事件報告ERB消息,該消息中承載有SSNotifyEvent,且該SSNotifyEvent包括的DP指定準則參數(shù)、事件類型參數(shù)以及監(jiān)視模式參數(shù)與SCP下發(fā)的SSNotifyEvent的相應參數(shù)相同;并且在DP指定準則參數(shù)中還攜帶有參與補充業(yè)務的用戶數(shù),以及相應的用戶號碼;
B2、SSP向SCP上報ERB消息的同時上報申請計費報告ACR消息,該消息中承載有智能用戶已經通話的時長信息;B3、當呼叫結束后,SSP再次向SCP上報ACR消息,該消息中承載有智能用戶已經通話的時長信息。
所述步驟C具體包括C1、SCP收到所述SSNotifyEvent后根據(jù)補充業(yè)務類型、參與補充業(yè)務的用戶數(shù)以及用戶號碼信息確定計費策略,并將SSP同時上報的ACR消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長,根據(jù)所述補充業(yè)務成功前的計費策略進行計費處理,并生成所述補充業(yè)務成功前的計費話單;C2、當呼叫結束后,SCP根據(jù)SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長,根據(jù)所述補充業(yè)務成功后的計費策略進行計費處理,并生成所述補充業(yè)務成功后的計費話單。
當所述補充業(yè)務為CW、CH、MPTY時,SCP通過RRBE配置所述SSNotifyEvent時,采用自動重配置方式。
在一個SSNotifyEvent中配置多個DP指定準則參數(shù)。
該方法具體包括D、當補充業(yè)務調用成功后,SSP向SCP上報ACR消息,該消息中承載有補充業(yè)務調用成功標志和補充業(yè)務類型,以及智能用戶已經通話的時長信息;E、SCP收到所述ACR消息后根據(jù)ACR中承載的補充業(yè)務調用成功標志和補充業(yè)務類型確定計費策略,將該消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長,根據(jù)補充業(yè)務調用成功前的計費策略進行計費處理,并生成所述補充業(yè)務成功前的計費話單;F、當呼叫結束后,SCP根據(jù)SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長,根據(jù)所述補充業(yè)務成功后的計費策略行計費處理,并生成所述補充業(yè)務成功后的計費話單。
步驟C2或步驟F中所述補充業(yè)務成功后的計費話單中攜帶所述補充業(yè)務的標志。
本發(fā)明還提供一種實現(xiàn)智能用戶補充業(yè)務計費的系統(tǒng),該系統(tǒng)包括補充業(yè)務調用成功通知模塊,設置于SSP中,用于在呼叫過程中當智能用戶成功調用補充業(yè)務后,向補充業(yè)務計費處理模塊上報相應補充業(yè)務調用成功消息;計費信息上報模塊,設置于SSP中,用于向補充業(yè)務計費處理模塊上報智能用戶的計費信息;補充業(yè)務計費處理模塊,設置于SCP,用于根據(jù)補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長,并根據(jù)補充業(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根據(jù)SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后通話時長,并根據(jù)相應補充業(yè)務調用成功前后的計費策略進行計費處理。
在實際應用中,可以針對ECT、MPTY、CW、CH等補充業(yè)務增加SSNotifyEvent(Supplementary Service Notify Event,補充業(yè)務調用通知事件)來實現(xiàn)向SCP上報相應補充業(yè)務調用成功的消息。補充業(yè)務調用成功事件是在移動始發(fā)CAMEL簽約信息O-CSI、移動終結CAMEL簽約數(shù)據(jù)VT-CSI所觸發(fā)的MO(移動始發(fā))、MVT(移動VMSC終結)流程中上報的。
SSNotifyEvent的具體參數(shù)如下
其中,當補充業(yè)務發(fā)生在MO端時,事件類型為O-SSNotifyEvent,當補充業(yè)務發(fā)生在MVT端時,事件類型為T-SSNotifyEvent;當呼叫方為主叫方時,呼叫方參數(shù)為Leg1,當呼叫方為被叫方時,呼叫方參數(shù)為Leg2;EDP(英文,中文)-N(NotifyAndContinue)表示通知類型事件,EDP-R(Request)表示請求類型事件。
為了對本發(fā)明有進一步的了解,下面以ECT補充業(yè)務為例并結合附圖對本發(fā)明進行詳細的說明。
本發(fā)明的具體實施方式
如圖3所示,包括如下步驟步驟31當智能用戶發(fā)起呼叫請求后,SSP向SCP上報IDP消息。
該IDP消息中承載有Service Interaction Indicators Two參數(shù),如果智能用戶簽約了ECT補充業(yè)務,在該參數(shù)中應攜帶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參數(shù),如果該參數(shù)中攜帶了ECT Treatment Indicator信息,則確定該智能用戶屬于ECT簽約用戶,在向SSP下發(fā)的RRBE(Request Report BCSM(Basic CallState Model,基本呼叫狀態(tài)模型)Event,請求報告BCSM事件)中配置SSNotifyEvent。
該事件的DP指定準則參數(shù)為ECT,監(jiān)視模式參數(shù)可以根據(jù)需要確定,一般的情況下配置為EDP-N;如果ECT業(yè)務將發(fā)生在MO端,事件類型參數(shù)為O-SSNotifyEvent,呼叫方參數(shù)為Leg1;如果ECT業(yè)務將發(fā)生在MVT端,事件類型參數(shù)為T-SSNotifyEvent,呼叫方參數(shù)為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指定準則參數(shù),這些參數(shù)與SCP下發(fā)的RRBE消息中承載的SSNotifyEvent的相應參數(shù)相同,其中DP指定準則參數(shù)除了包括ECT業(yè)務類型外,還包括參與此次補充業(yè)務的用戶數(shù),以及相應的用戶號碼。
ACR消息中承載有智能用戶的通話時長信息,該通話時長為從應答開始計費到SSP上報該ACR消息期間智能用戶總的通話時長。
步驟35SCP收到所述SSNotifyEvent后根據(jù)補充業(yè)務類型、參與補充業(yè)務的用戶數(shù)以及用戶號碼信息確定計費策略,并將ACR消息中智能用戶的通話時長作為ECT調用成功之前的通話時長,根據(jù)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成功之后的通話時長,根據(jù)ECT調用成功后的計費策略進行計費處理,并為智能用戶生成ECT成功之后的話單,該話單中攜帶ECT標志。
然后,SCP向SSP下發(fā)RC(Release Call,釋放呼叫)消息,釋放相應資源。
對于MPTY、CW、CH等補充業(yè)務,同樣適用于上述技術方案,只是需要修改DP指定準則參數(shù)。
當SCP確認智能用戶簽約了MPTY、CW、CH、ECT補充業(yè)務后,在向SSP下發(fā)的RRBE消息中配置相應補充業(yè)務的SSNotifyEvent,而且可以根據(jù)需要在一個補充業(yè)務調用通知事件中設置多個DP指定準則參數(shù),即多個補充業(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參數(shù),如果智能用戶簽約了ECT、MPTY、CW、CH補充業(yè)務,則在該參數(shù)中應攜帶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參數(shù),如果該參數(shù)中攜帶了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根據(jù)ACR消息中承載的補充業(yè)務調用成功標志以及相應的補充業(yè)務類型確定計費策略,并將ACR消息中承載的智能用戶的通話時長作為ECT/MPTY/CW/CH成功之前的通話時長,根據(jù)補充業(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成功之后的通話時長,根據(jù)補充業(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中,其功能為根據(jù)補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長,并根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
以上所述,僅為本發(fā)明較佳的具體實施方式
,但本發(fā)明的保護范圍并不局限于此,任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內,可輕易想到的變化或替換,都應涵蓋在本發(fā)明的保護范圍之內。因此,本發(fā)明的保護范圍應該以權利要求的保護范圍為準。
權利要求
1.一種智能用戶補充業(yè)務計費的實現(xiàn)方法,其特征在于,包括在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務后,業(yè)務控制點SCP根據(jù)業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長,根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
2.根據(jù)權利要求1所述的方法,其特征在于,所述補充業(yè)務包括顯示呼叫轉移ECT、呼叫等待CW、呼叫保持CH、多方通話業(yè)務MPTY。
3.根據(jù)權利要求1所述的方法,其特征在于,該方法具體包括A、當智能用戶發(fā)起呼叫請求后,SCP根據(jù)SSP上報的初始檢測點IDP消息確定智能用戶簽約了補充業(yè)務后,向SSP下發(fā)當補充業(yè)務調用成功后向SCP上報的命令;B、當所述補充業(yè)務調用成功后,SSP根據(jù)SCP的命令向SCP上報補充業(yè)務調用成功消息,并上報相應的計費信息;當呼叫結束后,SSP再次向SCP上報相應的計費信息;C、SCP根據(jù)SSP上報的補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長,并根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
4.根據(jù)權利要求3所述的方法,其特征在于,所述步驟A具體包括當智能用戶發(fā)起呼叫請求后,SCP根據(jù)SSP上報的初始探測點消息中的業(yè)務交互指示語2參數(shù)確定智能用戶簽約了補充業(yè)務后,向SSP下發(fā)請求報告基本呼叫狀態(tài)模型事件RRBE消息,并且在該消息中配置補充業(yè)務調用通知事件SSNotifyEvent,且該SSNotifyEvent包括檢測點DP指定準則參數(shù)、事件類型參數(shù)、呼叫方參數(shù)以及監(jiān)視模式參數(shù)。
5.根據(jù)權利要求4所述的方法,其特征在于,所述步驟B具體包括B1、當所述補充業(yè)務調用成功后,SSP向SCP上報基本呼叫狀態(tài)模型事件報告ERB消息,該消息中承載有SSNotifyEvent,且該SSNotifyEvent包括的DP指定準則參數(shù)、事件類型參數(shù)以及監(jiān)視模式參數(shù)與SCP下發(fā)的SSNotifyEvent的相應參數(shù)相同;并且在DP指定準則參數(shù)中還攜帶有參與補充業(yè)務的用戶數(shù),以及相應的用戶號碼;B2、SSP向SCP上報ERB消息的同時上報申請計費報告ACR消息,該消息中承載有智能用戶已經通話的時長信息;B3、當呼叫結束后,SSP再次向SCP上報ACR消息,該消息中承載有智能用戶已經通話的時長信息。
6.根據(jù)權利要求5所述的方法,其特征在于,所述步驟C具體包括C1、SCP收到所述SSNotifyEvent后根據(jù)補充業(yè)務類型、參與補充業(yè)務的用戶數(shù)以及用戶號碼信息確定計費策略,并將SSP同時上報的ACR消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長,根據(jù)所述補充業(yè)務成功前的計費策略進行計費處理,并生成所述補充業(yè)務成功前的計費話單;C2、當呼叫結束后,SCP根據(jù)SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長,根據(jù)所述補充業(yè)務成功后的計費策略進行計費處理,并生成所述補充業(yè)務成功后的計費話單。
7.根據(jù)權利要求4至6任一項所述的方法,其特征在于當所述補充業(yè)務為CW、CH、MPTY時,SCP通過RRBE配置所述SSNotifyEvent時,采用自動重配置方式。
8.根據(jù)權利要求4至6任一項所述的方法,其特征在于在一個SSNotifyEvent中配置多個DP指定準則參數(shù)。
9.根據(jù)權利要求1所述的方法,其特征在于,該方法具體包括D、當補充業(yè)務調用成功后,SSP向SCP上報ACR消息,該消息中承載有補充業(yè)務調用成功標志和補充業(yè)務類型,以及智能用戶已經通話的時長信息;E、SCP收到所述ACR消息后根據(jù)ACR中承載的補充業(yè)務調用成功標志和補充業(yè)務類型確定計費策略,將該消息中承載的通話時長作為所述補充業(yè)務成功前的通話時長,根據(jù)補充業(yè)務調用成功前的計費策略進行計費處理,并生成所述補充業(yè)務成功前的計費話單;F、當呼叫結束后,SCP根據(jù)SSP再次上報的ACR消息中承載的通話時長以及確定的所述補充業(yè)務成功前的通話時長確定所述補充業(yè)務成功后的通話時長,根據(jù)所述補充業(yè)務成功后的計費策略行計費處理,并生成所述補充業(yè)務成功后的計費話單。
10.根據(jù)權利要求6或9所述的方法,其特征在于,步驟C2或步驟F中所述補充業(yè)務成功后的計費話單中攜帶所述補充業(yè)務的標志。
11.一種實現(xiàn)智能用戶補充業(yè)務計費的系統(tǒng),其特征在于,系統(tǒng)包括補充業(yè)務調用成功通知模塊,設置于SSP中,用于在呼叫過程中當智能用戶成功調用補充業(yè)務后,向補充業(yè)務計費處理模塊上報相應補充業(yè)務調用成功消息;計費信息上報模塊,設置于SSP中,用于向補充業(yè)務計費處理模塊上報智能用戶的計費信息;補充業(yè)務計費處理模塊,設置于SCP,用于根據(jù)補充業(yè)務調用成功消息以及智能用戶的計費信息確定所述補充業(yè)務調用成功前后的通話時長,并根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。
全文摘要
本發(fā)明公開了一種智能用戶補充業(yè)務計費的實現(xiàn)方法及系統(tǒng),該方法的核心為在呼叫過程中當智能用戶成功發(fā)起補充業(yè)務后,業(yè)務控制點SCP根據(jù)業(yè)務交換點SSP上報的相應補充業(yè)務調用成功消息以及計費信息確定所述補充業(yè)務調用成功前后的通話時長,根據(jù)補充業(yè)務調用成功前后的計費策略進行計費處理。采用本發(fā)明的方法及系統(tǒng),SCP能夠準確獲得補充業(yè)務調用成功前后的通話時長,可以采用獨立計費方式對智能用戶發(fā)起的ECT補充業(yè)務進行精確計費,而且不會影響SCP運行性能。
文檔編號H04M15/00GK1874535SQ20061005740
公開日2006年12月6日 申請日期2006年3月13日 優(yōu)先權日2006年3月13日
發(fā)明者石勝兵 申請人:華為技術有限公司