專利名稱：一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法
技術領域：
本發(fā)明涉及計費領域，特別是指一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法。
背景技術：
隨著分組數(shù)據(jù)業(yè)務應用的逐漸廣泛，如何準確合理地對分組數(shù)據(jù)業(yè)務進行計費，已成為運營商普遍關注的問題。
當前的通用分組無線業(yè)務(GPRS，General Packet Radio Service)計費系統(tǒng)中，針對用戶的業(yè)務數(shù)據(jù)流只能識別到接入點名稱(APN)和分組數(shù)據(jù)協(xié)議上下文(PDP Context，Packet Data Protocol Context)這一級別，因此只能根據(jù)APN和PDP Context進行計費。然而，在實際應用中，多個并行的業(yè)務數(shù)據(jù)流很可能會通過同一個PDP Context承載，而不同業(yè)務則可能需要采用不同的計費方式進行計費，當前的GPRS計費系統(tǒng)無法滿足這一需求。例如，用戶同時進行流媒體業(yè)務和多媒體消息業(yè)務，這兩個業(yè)務同時承載于同一APN和PDP Context中，但這兩個業(yè)務的計費規(guī)則是完全不同的，如流媒體業(yè)務需要根據(jù)用戶的數(shù)據(jù)流量或該業(yè)務進行的時間長度進行計費，多媒體消息業(yè)務需要根據(jù)事件進行計費，該事件可為發(fā)送或接收一條多媒體消息。為了對不同類型的分組數(shù)據(jù)業(yè)務使用相同的計費方案，需要對當前的GPRS計費系統(tǒng)提出一種新的計費方式，采用一種通用的基于數(shù)據(jù)流的計費機制。
針對上述情況，第三代合作伙伴計劃(3GPP，The 3rd GenerationPartnership Project)目前正在討論如何實現(xiàn)基于網際協(xié)議(IP)數(shù)據(jù)流的計費(FBC，F(xiàn)low Based Charging)。對于一個分組數(shù)據(jù)業(yè)務而言，用戶使用該業(yè)務時所消耗的數(shù)據(jù)量稱為業(yè)務數(shù)據(jù)流(Service Data Flow)，業(yè)務數(shù)據(jù)流是多個IP數(shù)據(jù)流組成的集合。在一個APN和PDP Context中可承載多個不同的分組數(shù)據(jù)業(yè)務。這樣，基于IP數(shù)據(jù)流的計費粒度要遠遠小于基于一個PDP Context的計費粒度，基于IP數(shù)據(jù)流的計費能夠更真實地反映某個業(yè)務數(shù)據(jù)流對資源的占用情況，因此，基于IP數(shù)據(jù)流的計費能夠為運營商或業(yè)務提供者提供更為豐富的計費手段。
3GPP中對FBC的系統(tǒng)結構、功能要求以及消息交互流程等方面均進行了描述，支持在線計費的FBC系統(tǒng)結構如圖1A所示，基于移動網絡增強邏輯的客戶化應用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的業(yè)務控制點(SCP，Service Control Point)101和基于業(yè)務數(shù)據(jù)流計費的信用控制功能實體(CC，Service Data Flow Based CreditControl Function)102組成了在線計費系統(tǒng)(OCS，Online Charging System)106。CC 102通過Ry接口與基于業(yè)務數(shù)據(jù)流計費的計費規(guī)則功能實體(CRF，Service Data Flow Based Charging Rule Function)103相連，CRF 103通過Rx接口與應用功能實體(AF，Application Function)104相連，CRF 103通過Gx接口與傳輸面功能實體(TPF，Traffic Plane Function)105相連，CC 102通過Gy接口與TPF 105相連。
支持離線計費的FBC系統(tǒng)結構如圖1B所示，CRF 103通過Rx接口與AF 104相連，CRF 103通過Gx接口與TPF 105相連，TPF 105通過Gz接口分別與計費網關功能實體(CGF，Charging Gateway Function)107和計費采集功能實體(CCF，Charging Collection Function)108相連。
下面根據(jù)目前3GPP對于實現(xiàn)FBC功能實體的劃分，對各功能實體實現(xiàn)的功能進行描述。
TPF 105是承載業(yè)務數(shù)據(jù)流的功能實體，能夠對屬于不同分組數(shù)據(jù)業(yè)務流程的分組數(shù)據(jù)包進行區(qū)分，用于收集離線計費信息和執(zhí)行在線信用控制，當業(yè)務數(shù)據(jù)流的承載發(fā)生改變時，如承載建立、承載修改、承載刪除等過程中，TPF 105通過Gx接口向CRF 103請求計費規(guī)則，在請求計費規(guī)則的消息中可攜帶有與用戶和終端相關的信息、承載特性以及與網絡相關的信息等，其中與用戶和終端相關的信息可為移動臺綜合業(yè)務服務網國際號碼(MSISDN)、國際移動用戶標識(IMSI)等，與承載特性相關的信息可為服務質量(QoS)參數(shù)、APN，與網絡相關的信息可為移動網絡編碼(MNC)、移動國家碼(MCC)等。TPF 105根據(jù)CRF 103返回的計費規(guī)則，在相應的業(yè)務數(shù)據(jù)流上執(zhí)行分組數(shù)據(jù)過濾和計費信息收集。一個TPF 105可由一個或多個CRF 103提供服務，當有多個CRF 103為同一TPF 105提供服務時，可根據(jù)終端標識選擇相應的CRF 103與其進行交互。TPF 105支持預先定義的計費規(guī)則以及預先定義的業(yè)務數(shù)據(jù)流過濾器。
CRF 103是存儲計費規(guī)則的功能實體，支持動態(tài)和靜態(tài)的計費規(guī)則。動態(tài)計費規(guī)則是指根據(jù)分組數(shù)據(jù)業(yè)務準則實時生成的、應用于業(yè)務數(shù)據(jù)流的計費規(guī)則，靜態(tài)計費規(guī)則是指在用戶使用分組數(shù)據(jù)業(yè)務過程中一成不變的計費規(guī)則，靜態(tài)計費規(guī)則可通過用戶使用分組數(shù)據(jù)業(yè)務的過程被動態(tài)的激活。CRF 103可根據(jù)TPF 105、AF 104或OCS 106提供的信息，選取適當?shù)挠嬞M規(guī)則，在TPF 105向其請求計費規(guī)則或特定事件發(fā)生時，CRF 103將選定的計費規(guī)則提供給TPF 105。一個CRF 103可對應多個TPF 105。
AF 104代表所有與應用相關的功能實體，AF 104可為運營商自身的網絡實體，也可為第三方業(yè)務提供商的網絡實體。AF 104向CRF 103提供相應信息，使得CRF 103能夠根據(jù)該信息選擇或配置相應的計費規(guī)則，AF 104向CRF 103提供的信息包括業(yè)務數(shù)據(jù)流的標識信息和用于選擇計費規(guī)則的信息。業(yè)務數(shù)據(jù)流的標識信息，可通過通配標識多個IP流的聚合；用于選擇計費規(guī)則的信息，包括應用/業(yè)務標識、應用/業(yè)務計費規(guī)則觸發(fā)事件、業(yè)務數(shù)據(jù)流的類型、業(yè)務數(shù)據(jù)流的速率等信息。業(yè)務數(shù)據(jù)流的標識信息可通配；業(yè)務數(shù)據(jù)流的類型可為視頻、音頻等，業(yè)務數(shù)據(jù)流的類型為可選參數(shù)，業(yè)務數(shù)據(jù)流的速率也為可選參數(shù)。一個AF 104可對應于多個CRF 103，當一個CRF 103對應于同一AF 104時，可根據(jù)用戶終端標識選擇相應的CRF 103與其進行交互。
CC 102是執(zhí)行信用控制的功能實體，僅應用于在線計費系統(tǒng)，可通過在現(xiàn)有的OCS 106中增加新的功能來實現(xiàn)。OCS 106中的CC 102可通過Ry接口向CRF 103提供用于選擇計費規(guī)則的相關信息。
CGF 107/CCF 108是應用于離線計費系統(tǒng)的功能實體，可沿用現(xiàn)有的GPRS計費系統(tǒng)中的實現(xiàn)方式。
如果承載網絡為GPRS網絡，則TPF 105位于網關通用分組無線業(yè)務支持節(jié)點(GGSN，Gateway GPRS Support Node)，AF i04為分組數(shù)據(jù)網絡(PDN，Packet Data Network)中的一個業(yè)務網關或業(yè)務服務器，當IP多媒體子系統(tǒng)(IMS，IP Multimedia Subsystem)承載于GPRS網絡之上時，AF 104為代理呼叫會話控制功能實體(P-CSCF，Proxy Call Session ControlFunction)，CRF 103為新增的邏輯實體。
上述計費機制同樣可應用于3GPP2的網絡架構中。
為實現(xiàn)基于FBC機制的計費，在通信網絡中增加CRF 103這個功能實體，CRF 103是存儲計費規(guī)則的功能實體，支持動態(tài)計費規(guī)則和靜態(tài)計費規(guī)則的決策與實施。為支持動態(tài)計費規(guī)則的決策和實施，CRF 103分別與AF104、OCS 106及TPF 105相連，CRF 103通過與AF 104之間的Rx接口，獲取與應用/業(yè)務相關的輸入信息；CRF 103通過與OCS 106之間的Ry接口，獲取在線計費過程中與信用控制相關的輸入信息；在承載建立、修改和刪除時，CRF 103通過與TPF 105之間的Gx接口獲取用戶標識、承載特性、與通信網絡相關的信息等用于選擇計費規(guī)則的輸入信息，CRF 103根據(jù)這些輸入信息選擇適當?shù)挠嬞M規(guī)則，并通過Gx接口提供給TPF 105。
圖2A為承載建立時在線計費流程圖，如圖2A所示，承載建立時在線計費的實現(xiàn)過程包括以下步驟步驟201A用戶設備(UE)向TPF發(fā)送承載建立請求(Establish BearerService Request)，在GPRS網絡中，則是GGSN收到PDP Context創(chuàng)建請求(Create PDP Context Request)。
步驟202ATPF收到承載建立請求后，向CRF發(fā)送計費規(guī)則請求(Request Charging Rules)，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟203A～步驟204ACRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關輸入信息，選擇適當?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則(Provision Charging Rules)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟205A～步驟206ATPF收到提供計費規(guī)則后，對計費規(guī)則進行相應操作，然后向UE返回承載建立響應(Establish Bearer Service Accept)，接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程。
圖2B為承載修改時在線計費流程圖，如圖2B所示，承載修改時在線計費的實現(xiàn)過程包括以下步驟步驟201BUE向TPF發(fā)送承載修改請求(Modify Bearer ServiceRequest)，在GPRS網絡中，則是GGSN收到PDP Context更新請求(UpdatePDP Context Request)。
步驟202BTPF收到承載修改請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟203B～步驟204BCRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關輸入信息，選擇適當?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟205B～步驟206BTPF收到提供計費規(guī)則后，對CRF計費規(guī)則進行相應操作，然后向UE返回承載修改響應(Modify Bearer Service Accept)，接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程。
圖2C為承載刪除時在線計費流程圖，如圖2C所示，承載刪除時在線計費的實現(xiàn)過程包括以下步驟步驟201CUE向TPF發(fā)送承載刪除請求(Remove Bearer ServiceRequest)，在GPRS網絡中，則是GGSN收到PDP Context刪除請求(DeletePDP Context Request)。
步驟202CTPF收到承載刪除請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟203C～步驟204CCRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關輸入信息，選擇適當?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟205C～步驟206CTPF收到提供計費規(guī)則后，對計費規(guī)則進行相應操作，然后向UE返回承載刪除響應(Remove Bearer Service Accept)，接受UE發(fā)起的承載刪除請求，并繼續(xù)后續(xù)的承載刪除流程。
圖3為CRF主動向TPF下發(fā)計費規(guī)則流程圖，如圖3所示，CRF主動向TPF下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟301CRF收到某個內部或外部觸發(fā)事件(Internal or ExternalTrigger Event)的信息，以及與該事件相關的信息，如AF向CRF發(fā)送計費規(guī)則選擇輸入信息的事件。
步驟302CRF根據(jù)獲取的輸入信息選擇適當?shù)挠嬞M規(guī)則。這些輸入信息可為AF提供的與應用/業(yè)務相關的輸入信息，例如，用戶使用AF提供的某一業(yè)務，該業(yè)務對計費有特殊要求，如計費費率與其他業(yè)務的計費費率不同，因此，AF向CRF提供與該業(yè)務相關的計費輸入信息；也可為TPF提供的計費相關輸入信息。
步驟303～步驟304如果計費規(guī)則發(fā)生變化，CRF向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。TPF收到提供計費規(guī)則后，對計費規(guī)則進行相應操作。
以上所述的計費規(guī)則中包括計費機制、計費類型、計費鍵、業(yè)務數(shù)據(jù)流過濾器、計費規(guī)則優(yōu)先級等信息。其中，計費機制可為采用在線計費還是離線計費；計費類型可為基于時間長度進行計費還是基于數(shù)據(jù)流量進行計費；計費鍵，與計費費率相關的參數(shù)；業(yè)務數(shù)據(jù)過濾器用于指示TPF對哪些IP數(shù)據(jù)流進行過濾，然后TPF根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進行計費。業(yè)務數(shù)據(jù)過濾器可包含IP5元組。
由以上描述可見，由于基于業(yè)務數(shù)據(jù)流的計費中，TPF與CRF之間的信息交互過程非常重要，因此，3GPP規(guī)范基于FBC機制的計費實現(xiàn)過程中，著重描述了這部分的實現(xiàn)過程；在線計費的實現(xiàn)過程中，基于FBC機制的計費方案中僅提到CRF可從OCS處獲取在線計費時與信用控制相關的輸入信息，該輸入信息用于CRF選擇和配置適當?shù)挠嬞M規(guī)則，而沒有具體描述CRF將選定的計費規(guī)則提供給TPF之后，TPF如何將不同的計費費率應用到OCS上，使OCS實現(xiàn)信用控制，進而控制在線計費的實施。
另外，AF收到UE發(fā)送的分組數(shù)據(jù)業(yè)務請求后，會向CRF提供與應用/業(yè)務相關的輸入信息，這些輸入信息可能導致計費規(guī)則的更改，從而使在線計費中的信用控制發(fā)生變化，進而也會對在線計費的實施產生影響，這種情況在基于FBC機制的計費方法中也未給出相應描述。
綜上所述，現(xiàn)有基于FBC機制的計費方案并未針對在線計費的實現(xiàn)過程給出完整描述，依據(jù)現(xiàn)有基于FBC機制的計費方案根本無法實現(xiàn)基于業(yè)務數(shù)據(jù)流的在線計費。

發(fā)明內容
有鑒于此，本發(fā)明的目的在于提供一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，對基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)過程進行了完善，使得基于業(yè)務數(shù)據(jù)流的在線計費處理流程能夠順利完成。
為了達到上述目的，本發(fā)明提供了一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，該方法包含以下步驟A1、CRF向OCS提供信用控制輸入信息；B1、OCS根據(jù)所述信用控制輸入信息，確定信用；C1、OCS向TPF提供所述信用。
所述步驟C1為OCS主動向TPF提供所述信用。
所述步驟C1包括以下步驟C11、TPF向OCS發(fā)送信用請求；C12、OCS收到信用請求后，向TPF提供所述信用。
所述信用請求中攜帶有用戶帳戶標識信息。
該方法進一步包括OCS向CRF返回確認接收信用控制輸入信息的響應。
所述步驟A1之前進一步包括CRF收到觸發(fā)事件信息。
所述步驟A1進一步包括CRF向TPF提供計費規(guī)則。
所述CRF向TPF提供計費規(guī)則之前進一步包括CRF收到觸發(fā)事件信息。
所述觸發(fā)事件信息包括但不限于TPF向CRF發(fā)送計費規(guī)則請求，或AF向CRF提供應用/業(yè)務輸入信息，或CRF內部配置的觸發(fā)事件信息。
所述步驟C之后進一步包括TPF向OCS返回確認接收信用的響應。
所述信用控制輸入信息包括但不限于業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、數(shù)據(jù)速率、計費規(guī)則標識、TPF地址信息。
該方法進一步包括以下步驟a1、在OCS中配置觸發(fā)點信息；b1、所述觸發(fā)點被觸發(fā)時，OCS向TPF提供信用。
該方法進一步包括以下步驟a2、在OCS中配置觸發(fā)點信息；b2、所述觸發(fā)點被觸發(fā)時，OCS向CRF提供信用控制輸入信息。
本發(fā)明中還提供了一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，其特征在于，該方法包含以下步驟
A2、CRF通過TPF向OCS提供信用控制輸入信息；B2、OCS根據(jù)所述信用控制輸入信息，確定信用；C2、OCS向TPF提供所述信用。
所述步驟A2之前進一步包括A20、CRF向TPF提供計費規(guī)則。
所述步驟A20進一步包括CRF向TPF提供在線計費信息；所述步驟B2進一步包括TPF根據(jù)在線計費信息確定所述信用控制輸入信息。
所述在線計費信息包括但不限于業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、數(shù)據(jù)速率、扣費單位。
所述步驟A20之前進一步包括CRF收到觸發(fā)事件信息。
所述觸發(fā)事件信息包括但不限于TPF向CRF發(fā)送計費規(guī)則請求，或AF向CRF提供應用/業(yè)務輸入信息，或CRF內部配置的觸發(fā)事件信息。
所述步驟A20之后進一步包括TPF向CRF返回確認接收計費規(guī)則的響應。
所述信用控制輸入信息攜帶在TPF向OCS發(fā)送的信用請求中。
所述步驟C2之后進一步包括TPF向OCS返回確認接收信用的響應。
該方法進一步包括以下步驟a3、在OCS中配置觸發(fā)點信息；b3、所述觸發(fā)點被觸發(fā)時，OCS向CRF提供信用控制輸入信息。
根據(jù)本發(fā)明提出的方法，在線計費實現(xiàn)過程中，CRF可直接向OCS提供與信用控制相關的輸入信息，然后由OCS主動向TPF下發(fā)信用，或者由TPF向OCS請求新的信用，從而這些與信用控制相關的輸入信息可不需要攜帶在TPF發(fā)送給OCS的消息中，減輕了實體間的消息負荷；CRF也可通過計費規(guī)則中攜帶的信息向TPF提供與在線計費相關的輸入信息，并且這些輸入信息很可能就是計費規(guī)則中包含的一部分內容，然后TPF應用這些輸入信息向OCS發(fā)起信用請求，上述實現(xiàn)過程對現(xiàn)有基于FBC機制的在線計費結構改動最小。
本發(fā)明中提供了多種實現(xiàn)方式，獨立應用其中任何一種實現(xiàn)方式，都能夠解決在線計費中信用的請求和下發(fā)問題，使得基于業(yè)務數(shù)據(jù)流的在線計費處理流程能夠順利完成，從而完善了現(xiàn)有FBC計費機制中實時計費的實現(xiàn)方案，并具有靈活的選擇性。


圖1A為在線計費的FBC系統(tǒng)結構示意圖；圖1B為離線計費的FBC系統(tǒng)結構示意圖；圖2A為承載建立時在線計費流程圖；圖2B為承載修改時在線計費流程圖；圖2C為承載刪除時在線計費流程圖；圖3為CRF主動向TPF下發(fā)計費規(guī)則流程圖；圖4為本發(fā)明中實施例一示意圖；圖5為本發(fā)明中實施例二示意圖。
具體實施例方式
為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，OCS根據(jù)獲取的與信用控制相關的輸入信息，確定信用，然后向TPF提供針對計費規(guī)則的信用。
圖4為本發(fā)明中實施例一示意圖，如圖4所示，本實施例中，基于業(yè)務數(shù)據(jù)流的在線計費實現(xiàn)過程包括以下步驟步驟401～步驟403UE向TPF發(fā)送承載建立請求。TPF收到承載建立請求后，向CRF請求計費規(guī)則，并向CRF提供確定計費規(guī)則的輸入信息。CRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關輸入信息，確定當前分組數(shù)據(jù)業(yè)務的計費方式為在線計費，并選擇適當?shù)挠嬞M規(guī)則，然后向TPF返回選定的計費規(guī)則和在線計費指示，在線計費指示用于通知TPF該分組數(shù)據(jù)業(yè)務的當前計費方式為在線計費。
步驟404TPF收到計費規(guī)則后，對計費規(guī)則進行相應操作，并根據(jù)在線計費指示，TPF確定需要向OCS請求信用后，向OCS發(fā)送信用請求，該信用請求中攜帶有與信用控制相關的輸入信息，如計費規(guī)則中的計費鍵。
步驟405～步驟406OCS收到信用請求后，根據(jù)TPF提供的輸入信息確定信用，然后向TPF返回信用響應，如果OCS確定出針對計費規(guī)則的信用，則該信用響應中攜帶有信用，TPF收到攜帶有信用的信用響應后，可向UE返回承載建立響應，通知用戶接受其發(fā)起的承載建立請求，繼續(xù)后續(xù)的承載建立流程，后續(xù)處理過程中，可繼續(xù)執(zhí)行步驟406；如果OCS無法提供信用，則該信用響應中可攜帶有差錯原因值，TPF收到攜帶有差錯原因值的信用響應后，可向UE返回承載建立響應，拒絕用戶發(fā)起的承載建立請求。
步驟407CRF收到某個內部或外部觸發(fā)事件的信息，例如，AF根據(jù)分組數(shù)據(jù)業(yè)務的應用情況，向CRF發(fā)送與應用/業(yè)務相關的輸入信息，或TPF向CRF發(fā)送的承載修改請求，或CRF自身配置的觸發(fā)點被觸發(fā)等。
步驟408CRF根據(jù)收到的信息確定需要對信用控制進行修改后，向OCS提供與信用控制相關的輸入信息，如業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、業(yè)務數(shù)據(jù)速率、相關的計費規(guī)則標識、相關的TPF地址信息等等。如果CRF確定計費規(guī)則發(fā)生更改，則選擇適當?shù)男碌挠嬞M規(guī)則，然后向TPF提供新的計費規(guī)則和在線計費指示，TPF對收到的計費規(guī)則進行相應操作；如果CRF確定計費規(guī)則未發(fā)生更改，則可向TPF發(fā)送內容為空的計費規(guī)則。
在后續(xù)的在線計費處理過程中，既可執(zhí)行步驟409A～步驟410A，也可執(zhí)行步驟409B～步驟410B，步驟409A～步驟410A與步驟409B～步驟410B為并行的兩種后續(xù)處理方式。
步驟409A～步驟410AOCS根據(jù)CRF提供的輸入信息，重新確定針對計費規(guī)則的信用，如果OCS確定出針對計費規(guī)則的信用，則向TPF提供當前的信用，允許用戶使用分組數(shù)據(jù)業(yè)務，TPF收到OCS提供的信用后，向OCS返回響應，通知OCS其發(fā)送的信用已被接收；如果OCS無法提供信用，如信用不足以支持當前分組數(shù)據(jù)業(yè)務的實施，則向TPF提供差錯原因值，TPF收到OCS提供的差錯原因值后，也可向OCS返回響應，對收到的信息進行確認。
步驟409B～步驟410BTPF根據(jù)在線計費指示，向OCS發(fā)送信用請求，由于大量業(yè)務信息已在步驟404中由CRF提供給OCS了，因此，該信用請求中攜帶的與信用控制相關的輸入信息可簡化一些，僅攜帶能夠標識用戶帳戶的信息即可，不再需要攜帶與業(yè)務相關的信息。OCS收到信用請求后，根據(jù)CRF提供的輸入信息，重新確定針對計費規(guī)則的信用，如果OCS確定出針對計費規(guī)則的信用，則向TPF提供當前的信用，允許用戶使用分組數(shù)據(jù)業(yè)務；如果OCS無法提供信用，如信用不足以支持當前分組數(shù)據(jù)業(yè)務的實施，則向TPF提供差錯原因值，不允許用戶使用分組數(shù)據(jù)業(yè)務。TPF收到OCS提供的相關信息后，可向OCS返回響應，用于對收到的信息進行確認。
在步驟408之后，OCS可向CRF返回響應，該響應與步驟409A～步驟410A或步驟409B～步驟410B之間不存在明確的時間順序，OCS可在收到CRF向其提供的輸入信息后，就向CRF返回響應，用于通知CRF已接收其發(fā)送的信息；也可在收到TPF向其返回的用于確認接收信息的響應后，向CRF返回響應，此時，如果CRF還沒有向TPF提供計費規(guī)則，則CRF可在OCS成功將信用提供給TPF之后，向TPF提供新的計費規(guī)則，當用戶的信用不足以支持當前分組數(shù)據(jù)業(yè)務的實施時，CRF可不向TPF提供計費規(guī)則，也可向TPF提供內容為空的計費規(guī)則。
圖5為本發(fā)明中實施例二示意圖，如圖5所示，本實施例中，基于業(yè)務數(shù)據(jù)流的在線計費實現(xiàn)過程包括以下步驟
步驟501～步驟507與步驟401～步驟407相同。
步驟508CRF根據(jù)收到的信息確定需要對信用控制進行修改后，如果CRF確定計費規(guī)則發(fā)生更改，則選擇適當?shù)男碌挠嬞M規(guī)則，然后向TPF提供新的計費規(guī)則、在線計費相關信息，TPF對收到的計費規(guī)則進行相應操作；如果CRF確定計費規(guī)則未發(fā)生更改，則可向TPF發(fā)送在線計費相關信息。在線計費相關信息可包括業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、數(shù)據(jù)速率、扣費單位等在線計費相關信息用于TPF向OCS請求信用時使用。
步驟509TPF收到CRF提供的信息后，如果收到計費規(guī)則，則對計費規(guī)則進行相應操作，無論TPF收到計費規(guī)則與否，都根據(jù)在線計費指示，TPF確定需要向OCS請求信用后，向OCS發(fā)送信用請求，該信用請求中攜帶有與信用控制相關的輸入信息，包括扣費單位、與費率相關的計費鍵、與當前分組數(shù)據(jù)業(yè)務相關的業(yè)務鍵、用戶標識等信息。
步驟510OCS收到信用請求后，根據(jù)CRF提供的輸入信息，重新確定針對計費規(guī)則的信用，如果OCS確定出針對計費規(guī)則的信用，則向TPF提供當前的信用，允許用戶使用分組數(shù)據(jù)業(yè)務；如果OCS無法提供信用，如用戶的信用不足以支持當前分組數(shù)據(jù)業(yè)務的實施，則向TPF提供差錯原因值，不允許用戶使用分組數(shù)據(jù)業(yè)務。TPF收到OCS提供的相關信息后，可向OCS返回響應，用于對收到的信息進行確認。
TPF可向CRF返回響應，用于對收到的信息進行確認，該步驟可在TPF收到CRF提供的信息后，立即就向CRF返回響應；也可在收到OCS返回的信用后，才向CRF返回響應；還可在收到CRF提供的信息后與收到OCS返回的信用之前這段時間內的任一時刻，向CRF返回響應。
在上述兩個實施例的處理過程中，如果OCS中的信用發(fā)生變化，可能會對計費規(guī)則直接產生影響，如計費規(guī)則也需要做相應修改，此時，OCS根據(jù)自身存儲的配置信息，如觸發(fā)點信息，則OCS在觸發(fā)點被觸發(fā)時，主動向CRF上報與信用控制相關的輸入信息，CRF可根據(jù)該輸入信息，選擇適當?shù)男碌挠嬞M規(guī)則，然后提供給TPF，后續(xù)過程中可由TPF向OCS請求信用；進一步地，OCS在向CRF上報與信用控制相關的輸入信息時，還會向TPF提供信用。OCS中配置的觸發(fā)點信息可由CRF通過Ry接口配置OCS上。所述觸發(fā)點信息可為其他功能實體向OCS提供了與信用控制相關的輸入信息，如AF向OCS提供了與信用控制相關的輸入信息。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，其特征在于，該方法包含以下步驟A1、CRF向OCS提供信用控制輸入信息；B1、OCS根據(jù)所述信用控制輸入信息，確定信用；C1、OCS向TPF提供所述信用。
2.根據(jù)權利要求1所述的方法，其特征在于，所述步驟C1為OCS主動向TPF提供所述信用。
3.根據(jù)權利要求1所述的方法，其特征在于，所述步驟C1包括以下步驟C11、TPF向OCS發(fā)送信用請求；C12、OCS收到信用請求后，向TPF提供所述信用。
4.根據(jù)權利要求3所述的方法，其特征在于，所述信用請求中攜帶有用戶帳戶標識信息。
5.根據(jù)權利要求1的方法，其特征在于，該方法進一步包括OCS向CRF返回確認接收信用控制輸入信息的響應。
6.根據(jù)權利要求1所述的方法，其特征在于，所述步驟A1之前進一步包括CRF收到觸發(fā)事件信息。
7.根據(jù)權利要求1所述的方法，其特征在于，所述步驟A1進一步包括CRF向TPF提供計費規(guī)則。
8.根據(jù)權利要求7所述的方法，其特征在于，所述CRF向TPF提供計費規(guī)則之前進一步包括CRF收到觸發(fā)事件信息。
9.根據(jù)權利要求6或8所述的方法，其特征在于，所述觸發(fā)事件信息包括但不限于TPF向CRF發(fā)送計費規(guī)則請求，或AF向CRF提供應用/業(yè)務輸入信息，或CRF內部配置的觸發(fā)事件信息。
10.根據(jù)權利要求1所述的方法，其特征在于，所述步驟C之后進一步包括TPF向OCS返回確認接收信用的響應。
11.根據(jù)權利要求1所述的方法，其特征在于，所述信用控制輸入信息包括但不限于業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、數(shù)據(jù)速率、計費規(guī)則標識、TPF地址信息。
12.根據(jù)權利要求1所述的方法，其特征在于，該方法進一步包括以下步驟a1、在OCS中配置觸發(fā)點信息；b1、所述觸發(fā)點被觸發(fā)時，OCS向TPF提供信用。
13.根據(jù)權利要求1所述的方法，其特征在于，該方法進一步包括以下步驟a2、在OCS中配置觸發(fā)點信息；b2、所述觸發(fā)點被觸發(fā)時，OCS向CRF提供信用控制輸入信息。
14.一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，其特征在于，該方法包含以下步驟A2、CRF通過TPF向OCS提供信用控制輸入信息；B2、OCS根據(jù)所述信用控制輸入信息，確定信用；C2、OCS向TPF提供所述信用。
15.根據(jù)權利要求14所述的方法，其特征在于，所述步驟A2之前進一步包括A20、CRF向TPF提供計費規(guī)則。
16.根據(jù)權利要求15所述的方法，其特征在于，所述步驟A20進一步包括CRF向TPF提供在線計費信息；所述步驟B2進一步包括TPF根據(jù)在線計費信息確定所述信用控制輸入信息。
17.根據(jù)權利要求16所述的方法，其特征在于，所述在線計費信息包括但不限于業(yè)務鍵、計費鍵、業(yè)務事件標識、用戶標識、媒體類型、數(shù)據(jù)速率、扣費單位。
18.根據(jù)權利要求15所述的方法，其特征在于，所述步驟A20之前進一步包括CRF收到觸發(fā)事件信息。
19.根據(jù)權利要求18所述的方法，其特征在于，所述觸發(fā)事件信息包括但不限于TPF向CRF發(fā)送計費規(guī)則請求，或AF向CRF提供應用/業(yè)務輸入信息，或CRF內部配置的觸發(fā)事件信息。
20.根據(jù)權利要求15所述的方法，其特征在于，所述步驟A20之后進一步包括TPF向CRF返回確認接收計費規(guī)則的響應。
21.根據(jù)權利要求14所述的方法，其特征在于，所述信用控制輸入信息攜帶在TPF向OCS發(fā)送的信用請求中。
22.根據(jù)權利要求14所述的方法，其特征在于，所述步驟C2之后進一步包括TPF向OCS返回確認接收信用的響應。
23.根據(jù)權利要求16所述的方法，其特征在于，該方法進一步包括以下步驟a3、在OCS中配置觸發(fā)點信息；b3、所述觸發(fā)點被觸發(fā)時，OCS向CRF提供信用控制輸入信息。
全文摘要
本發(fā)明公開了一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，該方法包含CRF向OCS提供信用控制輸入信息；OCS根據(jù)所述信用控制輸入信息，確定信用；OCS向TPF提供所述信用。本發(fā)明還公開了一種完善基于業(yè)務數(shù)據(jù)流在線計費的實現(xiàn)方法，該方法包含CRF通過TPF向OCS提供信用控制輸入信息；OCS根據(jù)所述信用控制輸入信息，確定信用；OCS向TPF提供所述信用。根據(jù)本發(fā)明提出的方法，OCS根據(jù)獲取的與信用控制相關的輸入信息，確定信用，然后向TPF提供針對計費規(guī)則的信用，對現(xiàn)有基于FBC機制的在線計費結構改動較小；并且，本發(fā)明中提供了多種實現(xiàn)方式，完善了現(xiàn)有FBC計費機制中實時計費的實現(xiàn)方案，并具有靈活的選擇性。
文檔編號H04L12/14GK1697389SQ200410044430
公開日2005年11月16日 申請日期2004年5月12日 優(yōu)先權日2004年5月12日
發(fā)明者武亞娟, 段小琴 申請人:華為技術有限公司