專利名稱：一種基于分組數(shù)據(jù)流計費的處理方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及分組數(shù)據(jù)計費領域，特別是指一種基于分組數(shù)據(jù)流計費的處理方法及系統(tǒng)。
背景技術：
隨著分組數(shù)據(jù)業(yè)務應用的逐漸廣泛，如何準確合理地對分組數(shù)據(jù)業(yè)務進行計費，已成為運營商普遍關注的問題。
圖1示出了分組數(shù)據(jù)協(xié)議上下文(PDP Context，Packet Data ProtocolContext)激活、數(shù)據(jù)傳輸、去激活流程圖，如圖1所示，在通用分組無線業(yè)務(GPRS，General Packet Radio Service)中，激活PDP Context、與外部分組數(shù)據(jù)網(wǎng)絡(PDN，Packet Data Network)進行數(shù)據(jù)交互、去激活該PDPContext的實現(xiàn)過程包括以下步驟步驟101移動終端(MS)向服務通用分組無線業(yè)務支持節(jié)點(SGSN，Serving GPRS Support Node)發(fā)送PDP Context激活請求(Activate PDPContext Request)，該Activate PDP Context Request中攜帶有網(wǎng)絡層業(yè)務訪問點標識(NSAPI，Network Layer Service Access Point Identifier)、PDP類型、接入點名稱(APN，Access Point Name)、要求的服務質(zhì)量(QoS)參數(shù)、事務標識(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和網(wǎng)關通用分組無線業(yè)務支持節(jié)點(GGSN，Gateway GPRS Support Node)之間作為隧道標識(TID，Tunnel Identifier)的組成部分，用于標識PDPContext；PDP類型包括端對端協(xié)議(PPP，Peer-Peer Protocol)類型、網(wǎng)際協(xié)議(IP，Internet Protocol)類型等；APN可由MS向SGSN提供，SGSN根據(jù)APN尋址到相應GGSN，GGSN根據(jù)APN確定MS所要訪問的外部網(wǎng)絡，MS也可不向SGSN提供APN，此時，由SGSN根據(jù)MS用戶的簽約信息選擇缺省的APN；QoS參數(shù)為MS指定的分組數(shù)據(jù)業(yè)務所要達到的質(zhì)量要求；TI用于MS標識某個PDP context。
步驟102SGSN收到Activate PDP Context Request后，與MS進行安全性檢查和加密，該步驟為可選步驟。
步驟103SGSN根據(jù)APN解析GGSN的地址信息，如果SGSN能夠根據(jù)APN解析出GGSN的地址信息，則為PDP Context創(chuàng)建TEID，該TEID可為國際移動用戶標識(IMSI，International Mobile SubscriberIdentity)與NSAPI的組合，然后SGSN向GGSN發(fā)送PDP Context創(chuàng)建請求(Create PDPContext Request)，該PDP Context創(chuàng)建請求中攜帶有PDP類型、PDP地址、APN、QoS參數(shù)、TEID、選擇模式等，其中，PDP地址可為MS的IP地址，為可選參數(shù)，PDP Context創(chuàng)建請求中可不攜帶PDP地址，此時，在后續(xù)的處理過程中，可由GGSN為MS分配IP地址，也可由最終與MS建立連接的PDN為MS分配IP地址；選擇模式是指APN的選擇模式，即APN是由MS選定的還是由SGSN選定的。如果SGSN無法根據(jù)APN解析出GGSN的地址信息，則SGSN拒絕MS發(fā)起的PDP Context激活請求。
步驟104GGSN收到PDP Context創(chuàng)建請求后，根據(jù)APN確定外部PDN，然后分配計費標識(Charging ID)、啟動計費，并且協(xié)商QoS，如果GGSN能夠滿足QoS參數(shù)的服務質(zhì)量要求，則向SGSN返回PDP Context創(chuàng)建響應(Create PDP Context Response)，該PDP Context創(chuàng)建響應中攜帶有TEID、PDP地址、鏈路承載(Backbone Bearer)協(xié)議、商定的QoS參數(shù)、Charging ID等信息。如果GGSN無法滿足QoS參數(shù)的服務質(zhì)量要求，則GGSN拒絕SGSN發(fā)起的PDP Context創(chuàng)建請求，然后SGSN拒絕MS發(fā)起的PDP Context激活請求。
步驟105SGSN收到PDP Context創(chuàng)建響應后，在PDP Context中插入用于標識PDP Context的NSAPI和GGSN地址信息，并根據(jù)商定的QoS參數(shù)選擇無線優(yōu)先權，然后向MS返回PDP Context激活響應(Activate PDPContext Accept)，該PDP Context激活響應中攜帶有PDP類型、PDP地址、TI、商定的QoS參數(shù)、無線優(yōu)先權、PDP配置選項等信息。并且，SGSN啟動計費。MS收到PDP Context激活響應，就已經(jīng)建立了MS與GGSN直接的路由，可以進行分組數(shù)據(jù)的傳輸了。
步驟106MS通過SGSN、GGSN與PDN進行分組數(shù)據(jù)的交互。
步驟107結束分組數(shù)據(jù)交互后，MS向SGSN發(fā)送PDP Context去激活請求(Deactivate PDP Context Request)，該PDP Context去激活請求中攜帶有TI。
步驟108SGSN收到PDP Context去激活請求后，與MS進行安全性檢查和加密，該步驟為可選步驟。
步驟109～步驟111SGSN向GGSN發(fā)送PDP Context刪除請求(DeletePDP Context Request)，該PDP Context刪除請求中攜帶有TEID。GGSN收到PDP Context刪除請求后，結束對MS的計費，刪除對應于TEID的PDPContext，然后向SGSN發(fā)送PDP Context刪除響應(Delete PDP ContextResponse)，該PDP Context刪除響應中攜帶有TEID。SGSN收到PDP Context刪除響應后，結束對MS的計費，刪除對應于TEID的PDP Context，然后向MS發(fā)送PDP Context去激活響應(Deactivate PDP Context Response)，該PDP Context去激活響應中攜帶有TI。MS收到PDP Context去激活響應后，刪除對應于TI的PDP Context。
由圖1描述的實現(xiàn)過程可見，當前的GPRS計費系統(tǒng)中，由于計費的起始點設置在PDP Context激活時，計費的終止點設置在PDP Context刪除時，因此只能根據(jù)PDP Context傳輸?shù)臄?shù)據(jù)流量進行計費，或是根據(jù)PDP Context處于激活狀態(tài)的時間長度進行計費。然而，在實際應用中，MS與PDN進行數(shù)據(jù)交互后，該MS可以基于一個激活的PDP Context進行多種業(yè)務，也就是說，如果PDN能夠提供多種業(yè)務，如電子郵件(Email)收發(fā)業(yè)務、基于無線應用協(xié)議的(WAP，Wireless Application Protocol)的瀏覽業(yè)務、基于文件傳輸協(xié)議(FTP，F(xiàn)ile Transfer Protocol)的文件傳輸?shù)葮I(yè)務，則MS在與該PDN建立傳輸通道后，可通過一個激活的PDP Context承載該PDN能夠提供的各種業(yè)務。但是，運營商對于各種業(yè)務的計費模式很可能采用不同的計費方式，如對于Email收發(fā)業(yè)務可基于Email接收和發(fā)送事件的觸發(fā)按次計費，對于WAP瀏覽業(yè)務可根據(jù)流量計費，對于文件傳輸業(yè)務也可根據(jù)流量計費，WAP瀏覽業(yè)務的費率與文件傳輸業(yè)務的費率卻不盡相同，這樣，根據(jù)現(xiàn)有的GPRS計費系統(tǒng)，根本無法對同一PDP Context承載的不同業(yè)務進行區(qū)分計費。
針對上述情況，第三代合作伙伴計劃(3GPP，The 3rd GenerationPartnership Project)目前正在討論如何實現(xiàn)基于IP數(shù)據(jù)流的計費(FBC，F(xiàn)lowBased Charging)。對于一個分組數(shù)據(jù)業(yè)務而言，MS的用戶使用該業(yè)務時，傳輸和接收到的所有IP數(shù)據(jù)流(IP Flow)，也可為IP分組包(IP packet)，總稱為業(yè)務數(shù)據(jù)流(Service Data Flow)，即業(yè)務數(shù)據(jù)流是多個IP數(shù)據(jù)流組成的集合，因此基于IP數(shù)據(jù)流的計費能夠真實反映某個業(yè)務數(shù)據(jù)流對資源的占用情況?；贗P數(shù)據(jù)流的計費可被認為是通過一些類似篩子的過濾器將同一PDP Context中承載的不同業(yè)務的IP數(shù)據(jù)流分別篩選出來，然后針對不同過濾器過濾出的IP數(shù)據(jù)流進行分別計費，以達到對不同的業(yè)務數(shù)據(jù)流分別計費的目的。這樣，基于IP數(shù)據(jù)流的計費粒度要遠遠小于基于一個PDPContext的計費粒度，粒度可看作是篩子孔的大小，基于一個PDP Context的計費粒度是一個PDP Context就是一個篩子孔，而基于IP數(shù)據(jù)流的計費粒度則是一個IP業(yè)務數(shù)據(jù)流則為一個篩子孔，即針對一個PDP Context中包含多個篩子孔，因此，基于IP數(shù)據(jù)流的計費與比基于一個PDP Context的計費相比，基于IP數(shù)據(jù)流的計費能夠為運營商或業(yè)務提供者提供更為豐富的計費手段。
3GPP中對FBC的系統(tǒng)結構、功能要求以及消息交互流程等方面均進行了描述，支持在線計費的FBC系統(tǒng)結構如圖2A所示，基于移動網(wǎng)絡增強邏輯的客戶化應用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的業(yè)務控制點(SCP，Service Control Point)201和基于業(yè)務數(shù)據(jù)流計費的信用控制功能實體(CCF，Service Data Flow Based CreditControl Function)202組成了在線計費系統(tǒng)(OCS，Online Charging System)206。CCF 202通過Ry接口與基于業(yè)務數(shù)據(jù)流計費的計費規(guī)則功能實體(CRF，Service Data Flow Based Charging Rule Function)203互通，CRF 203通過Rx接口與應用功能實體(AF，Application Function)204互通，CRF 203通過Gx接口與傳輸面功能實體(TPF，Traffic Plane Function)205互通，CCF 202通過Gy接口與TPF 205互通。
支持離線計費的FBC系統(tǒng)結構如圖2B所示，CRF 203通過Rx接口與AF 204互通，CRF 203通過Gx接口與TPF 205互通，TPF 205通過Gz接口分別與計費網(wǎng)關功能實體(CGF，Charging Gateway Function)207和計費采集功能實體(CDF，Charging Data Function)208互通。
TPF 205承載IP數(shù)據(jù)流，當IP數(shù)據(jù)流的承載建立時，TPF 205通過Gx接口向CRF 203發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有與用戶和MS相關的信息、承載特性以及與網(wǎng)絡相關的信息等，其中與用戶和MS相關的信息可為移動臺國際號碼(MSISDN)、國際移動用戶標識(IMSI)等，與網(wǎng)絡相關的信息可為移動網(wǎng)絡編碼(MNC)、移動國家碼(MCC)等。另外，由于在IP數(shù)據(jù)流傳輸過程中，會對承載進行修改，如對QoS參數(shù)進行重新協(xié)商，當用戶使用同一業(yè)務的QoS參數(shù)不同時，計費規(guī)則可能不同，如QoS參數(shù)下降相應的費率也下降。此時，TPF 205可在承載修改時，重新向CRF 203發(fā)送計費規(guī)則請求，請求新的計費規(guī)則；CRF 203根據(jù)TPF 205提供的上述輸入信息選擇適當?shù)挠嬞M規(guī)則，并向TPF 205返回選定的計費規(guī)則，計費規(guī)則中包括計費機制、計費類型、計費鍵(Charging Key)、業(yè)務數(shù)據(jù)流過濾器、計費規(guī)則優(yōu)先級等信息。其中，計費機制可為采用在線計費還是離線計費；計費類型可為基于時間長度進行計費還是基于數(shù)據(jù)流量進行計費；計費鍵是與費率相關的參數(shù)，CRF 203可不直接向TPF 205提供費率，而只是向TPF 205提供與費率相關的參數(shù)；業(yè)務數(shù)據(jù)過濾器用于指示TPF205對哪些IP數(shù)據(jù)流進行過濾，然后TPF 205根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進行計費。業(yè)務數(shù)據(jù)過濾器可包含IP5元組，IP5元組可包括源/目的IP地址、源/目的端口號(Port Number)、協(xié)議標識(Protocol ID)等信息，例如，CRF 203指示TPF 205對源地址為10.0.0.1、目的地址為10.0.0.2、源/目的端口號為20、協(xié)議類型為傳輸控制協(xié)議(TCP)的IP數(shù)據(jù)流進行過濾，并根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進行計費。
CRF 203可向TPF 205提供觸發(fā)事件(Event Trigger)，用以要求TPF 205在特定事件發(fā)生時，向CRF 205請求新的計費規(guī)則，如CRF 203要求TPF 205在某些承載進行修改的事件發(fā)生時，向CRF 203請求新的計費規(guī)則。觸發(fā)事件可視為與計費規(guī)則相關的事件。目前，3GPP規(guī)范中對CRF通過觸發(fā)事件上報機制控制TPF的計費方式進行了描述，即TPF監(jiān)測到觸發(fā)事件發(fā)生后向CRF上報，CRF通過TPF上報的觸發(fā)事件獲知承載發(fā)生變化，然后確定相應的計費規(guī)則并下發(fā)給TPF。3GPP規(guī)范中定義的觸發(fā)事件可包括公用陸地移動通信網(wǎng)絡(PLMN)變化(PLMN change)事件，QoS參數(shù)變化(QoSchanges)事件，無線接入技術(RAT)類型變化(RAT type change)事件，傳輸流模板(TFT)變化(TFT change)事件。
CRF 203除了根據(jù)TPF 205提供的輸入信息選擇適當?shù)挠嬞M規(guī)則之外，CRF 203還可根據(jù)AF 204或OCS 206的輸入信息選擇適當?shù)挠嬞M規(guī)則，如AF 204通知CRF 203用戶當前使用的業(yè)務類型，CRF 203根據(jù)該業(yè)務類型選擇相應的計費規(guī)則。
OCS 206作為在線計費系統(tǒng)，由SCP 201和CCF 202兩個功能實體組成，其中，CCF 202是執(zhí)行信用控制的功能實體，僅應用于在線計費系統(tǒng)，可通過在現(xiàn)有的OCS 206中增加新的功能來實現(xiàn)。在在線計費過程中，CCF 202對用戶信用進行管理和控制，當用戶使用業(yè)務時，CCF 202對該用戶信用池中的信用進行鑒權，并通過Gy接口向TPF 205下發(fā)用戶能夠使用的信用。
另外，OCS 206可要求TPF 205在重鑒權事件(Re-authorisation triggers)發(fā)生時向其上報，然后OCS 206根據(jù)TPF 205上報的相應重鑒權事件對用戶進行重鑒權，并可能重新計算用戶的信用。例如，OCS 206向TPF 205提供的用戶信用使用完畢，TPF 205需根據(jù)重鑒權事件中的允許信用過期事件，向OCS 206上報其允許的用戶信用使用過期事件的發(fā)生，OCS 206根據(jù)用戶剩余帳戶信息，重新對允許用戶使用的信用進行計算。又例如，分區(qū)域計費時，OCS 206根據(jù)用戶當前所在位置確定費率，并根據(jù)該費率計算用戶的信用；當用戶移動至另一位置時，如PLMN發(fā)生變化，TPF 205需要根據(jù)重鑒權事件中的PLMN變化事件，向OCS 206上報PLMN變化事件的發(fā)生，OCS206根據(jù)用戶更新后的當前所在位置重新確定費率，并重新計算用戶的信用。又例如，當OCS 206根據(jù)用戶使用業(yè)務的當前QoS參數(shù)確定費率，當用戶對QoS參數(shù)進行修改，TPF 205需要根據(jù)重鑒權事件中的承載修改事件，向OCS 206上報承載修改事件的發(fā)生，OCS 206根據(jù)用戶修改后的QoS參數(shù)確定費率，并重新計算用戶的信用。
另外，3GPP規(guī)范中還對OCS通過重鑒權事件上報的機制控制TPF的信用使用情況進行了描述，即TPF監(jiān)測到重鑒權事件發(fā)生后向OCS上報，OCS通過TPF上報的重鑒權事件，獲知用戶的信用使用情況以及承載的變化，對用戶的信用重新進行計算并下發(fā)給TPF。3GPP規(guī)范中定義的重鑒權事件可包括允許信用過期(credit authorization lifetime expiry)事件，用戶空閑狀態(tài)超時(idle timeout)事件，計費規(guī)則變化(charging rule is changed)事件，PLMN變化事件，QoS參數(shù)變化事件，RAT類型變化事件。
對應于GPRS網(wǎng)絡，TPF 205為GGSN，AF為PDN中的一個業(yè)務網(wǎng)關或業(yè)務服務器，CRF 203為新增的邏輯實體。TPF 205為計費規(guī)則的執(zhí)行點，CRF 203為計費規(guī)則的控制點。
對于目前的FBC系統(tǒng)結構，離線計費情況下的計費信息采集點是TPF，TPF收集針對業(yè)務數(shù)據(jù)流的信息，如業(yè)務數(shù)據(jù)流傳輸?shù)臄?shù)據(jù)流量、業(yè)務數(shù)據(jù)流使用的時間長度等，然后生成計費信息，并將該計費信息經(jīng)由CGF/CDF207發(fā)送至計費中心；在線計費情況下的計費信息采集點是TPF和OCS，TPF收集針對業(yè)務數(shù)據(jù)流的信息，并將該計費信息經(jīng)由CGF/CDF發(fā)送至計費中心，OCS收集費用扣除情況信息，然后生成計費信息，并將該計費信息經(jīng)由CGF/CDF發(fā)送至計費中心。
然而，在實際的網(wǎng)絡運營中，對于增值業(yè)務部分，運營商通常向用戶收取通信費用和業(yè)務費用兩種費用，通信費用用于對用戶占用的網(wǎng)絡資源進行計量，又稱為流量費或承載費；業(yè)務費用用于對用戶使用業(yè)務的業(yè)務信息進行計量，又稱為內(nèi)容費或信息費。例如，用戶通過移動終端使用“看電視”業(yè)務，運營商不僅需要向用戶收取使用“看電視”業(yè)務過程中由傳輸業(yè)務的數(shù)據(jù)流量或是使用業(yè)務的時間長度導致的費用，還需要向用戶收取用戶收看的電視節(jié)目內(nèi)容的費用；又如，用戶使用“游戲下載”業(yè)務，運營商不僅需要向用戶收取用戶下載游戲過程中由數(shù)據(jù)流量而生成的費用，還需要向用戶收取用戶購買該游戲使用權的費用。
通常，對于電視節(jié)目、游戲等業(yè)務應用可由專門的業(yè)務提供商(SP，Service Provider)進行開發(fā)，并通過與網(wǎng)絡運營商合作向用戶提供各種業(yè)務應用。雖然SP可直接向用戶收取業(yè)務費用，這樣就需要SP建立面向用戶收取業(yè)務費用的渠道，如計費系統(tǒng)等，但由于一方面采用SP自行建立計費系統(tǒng)的方式會增加SP的成本，提高了SP的門檻，不利于SP自身的發(fā)展；另一方面SP自行建立計費系統(tǒng)的方式還需要解決用戶對SP的信任問題，因此，目前大部分網(wǎng)絡運營商都代替SP收取業(yè)務費用，并同SP進行業(yè)務費用分成的計費模式，例如中國移動的“移動夢網(wǎng)”平臺和中國聯(lián)通的“聯(lián)通無限”就是整合了各SP并提供統(tǒng)一計費的平臺。通過這種網(wǎng)絡運營商代收業(yè)務費用的方式，使得網(wǎng)絡運營商可只專注于網(wǎng)絡的運營，SP可只專注于業(yè)務應用的開發(fā)，用戶只需要面對一個統(tǒng)一的收費系統(tǒng)和一張同時包含通信費用和業(yè)務費用的用戶話單。
然而，基于目前的FBC系統(tǒng)結構，由于TPF與AF之間沒有信令接口，因此，TPF無法獲知業(yè)務的使用成功與否的信息，例如，對于下載類業(yè)務，如果下載過程中出現(xiàn)異常中斷的情況，則此時只應收取通信費用，而不應收取業(yè)務費用；并且，TPF也無法獲知用戶訂購業(yè)務的情況，例如，某用戶在訂購一項業(yè)務時對業(yè)務費用采用的計費方式是包月計費，TPF無法獲知用戶的業(yè)務費用應該是每個月統(tǒng)一進行扣除，而不能在用戶每次使用業(yè)務時扣除。因此，基于目前FBC系統(tǒng)結構無法實現(xiàn)業(yè)務費用的收取，不能滿足在網(wǎng)絡中進行業(yè)務運營的要求。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的一個目的在于提供一種基于分組數(shù)據(jù)流計費的處理方法，本發(fā)明的另一目的在于提供一種基于分組數(shù)據(jù)流計費的系統(tǒng)，滿足在網(wǎng)絡中進行業(yè)務運營的要求。
為了達到上述目的，本發(fā)明提供了一種基于分組數(shù)據(jù)流計費的處理方法，該方法包含CRF向OCS發(fā)送信用請求，OCS向CRF返回信用響應。
所述信用響應中攜帶有信用額度或信用額度是否充足信息。
該方法進一步包括CRF向OCS回退需要回補的信用額度，OCS將收到的所述信用額度回補到用戶的帳戶上。
所述OCS收到需要回補的信用額度，之后進一步包括OCS向CRF返回用于通知CRF已收到需要回補的信用額度的響應。
本發(fā)明還提供了一種基于分組數(shù)據(jù)流計費的處理方法，該方法包含AF通知CRF用戶請求使用業(yè)務，CRF根據(jù)業(yè)務訂購信息判斷是否允許用戶使用業(yè)務，如果是，則通知AF為用戶提供所述業(yè)務；否則，通知AF不為用戶提供所述業(yè)務。
所述業(yè)務訂購信息是在用戶訂購業(yè)務時，由AF向CRF提供的。
所述CRF收到AF提供的業(yè)務訂購信息后，進一步包括CRF向AF返回用于通知AF已收到業(yè)務訂購信息的響應。
所述通知AF為用戶提供所述業(yè)務，之前進一步包括CRF開始計費信息的采集。
所述通知AF為用戶提供所述業(yè)務，之后進一步包括a1、AF通知CRF用戶的業(yè)務使用情況。
所述步驟a1之后進一步包括CRF向AF返回用于通知AF已收到業(yè)務使用情況的響應。
所述步驟a1之后進一步包括b1、CRF停止計費信息的采集。
所述步驟b1之后進一步包括CRF向CDF/CGF發(fā)送計費信息。
在線計費情況下，所述通知AF為用戶提供所述業(yè)務，之前進一步包括CRF向OCS發(fā)送信用請求，OCS向CRF返回信用響應。
所述步驟a1之后進一步包括CRF向OCS回退需要回補的信用額度，OCS將收到的所述信用額度回補到用戶的帳戶上。
本發(fā)明還提供了一種基于分組數(shù)據(jù)流計費的系統(tǒng)，該系統(tǒng)包括CRF與TPF相連，用于使CRF向TPF提供計費規(guī)則，TPF與CDF/CGF相連，用于TPF向CDF/CGF提供對應于承載的計費信息；該系統(tǒng)中，AF與CRF相連，用于傳送業(yè)務相關信息，CRF與CDF/CGF相連，用于CRF向CDF/CGF提供對應于業(yè)務的計費信息。
所述CRF與CDF/CGF通過Rz接口相連。
該系統(tǒng)進一步包括OCS，與TPF相連，用于根據(jù)TPF的請求向TPF提供信用信息；并與CRF相連，用于根據(jù)CRF的請求向CRF提供信用信息。
根據(jù)本發(fā)明提出的方案，在CRF中增加計費信息采集功能，增加CRF與OCS之間的交互流程，使得OCS能夠根據(jù)CRF的信用請求，向CRF提供信用信息，如具體的信用額度、信用額度是否充足等信息，還可使CRF能夠向OCS返回需回補的信用額度，OCS將相應信用額度回補到用戶的帳戶上；并增加CRF與AF之間的交互流程，使得CRF能夠獲知用戶訂購業(yè)務的情況，并且能夠獲知業(yè)務的使用成功與否的信息。另外，增加CRF與CDF/CGF之間的信令接口，使CRF能夠?qū)⒃诰€計費情況下或是離線計費情況下生成的計費信息通過CDF/CGF上報至計費中心，從而實現(xiàn)基于FBC系統(tǒng)結構對業(yè)務費用的收取，滿足在網(wǎng)絡中進行業(yè)務運營的要求。


圖1示出了PDP Context激活、數(shù)據(jù)傳輸、去激活流程圖；圖2A示出了支持在線計費的FBC系統(tǒng)結構示意圖；圖2B示出了支持離線計費的FBC系統(tǒng)結構示意圖；圖3A示出了本發(fā)明中CRF向OCS請求信用信息實現(xiàn)過程示意圖；圖3B示出了本發(fā)明中CRF向OCS回補信用額度實現(xiàn)過程示意圖；圖4A示出了本發(fā)明中CRF通過AF獲知用戶業(yè)務訂購實現(xiàn)過程示意圖；圖4B示出了本發(fā)明中CRF通過AF獲知業(yè)務使用情況實現(xiàn)過程示意圖；圖5A示出了本發(fā)明中支持在線計費的FBC系統(tǒng)結構示意圖；圖5B示出了本發(fā)明中支持離線計費的FBC系統(tǒng)結構示意圖；圖6示出了本發(fā)明中實施例一實現(xiàn)過程示意圖；圖7示出了本發(fā)明中實施例二實現(xiàn)過程示意圖。
具體實施例方式
為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，在CRF中增加計費信息采集功能，增加CRF與OCS之間的交互流程，使得OCS能夠根據(jù)CRF的信用請求，向CRF提供信用信息，如具體的信用額度、信用額度是否充足等信息，還可使CRF能夠向OCS返回需回補的信用額度，OCS將相應信用額度回補到用戶的帳戶上；并增加CRF與AF之間的交互流程，使得CRF能夠獲知用戶訂購業(yè)務的情況，并且能夠獲知業(yè)務的使用成功與否的信息。另外，增加CRF與CDF/CGF之間的信令接口，使CRF能夠?qū)⒃诰€計費情況下或是離線計費情況下生成的計費信息通過CDF/CGF上報至計費中心，從而實現(xiàn)基于FBC系統(tǒng)結構對業(yè)務費用的收取，滿足在網(wǎng)絡中進行業(yè)務運營的要求。
圖3A示出了本發(fā)明中CRF向OCS請求信用信息實現(xiàn)過程示意圖，如圖3A所示，CRF向OCS請求信用信息的實現(xiàn)過程包括以下步驟步驟301A～步驟302ACRF向OCS發(fā)送信用請求(Credit Request)，該信用請求中攜帶有用戶標識、業(yè)務信息、費率信息等供OCS確定信用信息的輸入信息。OCS收到信用請求后，向OCS返回信用響應(CreditResponse)，該信用響應中攜帶有信用信息，如OCS計算出的用戶信用額度、信用額度是否充足等信息。
在信用額度未消耗或未消耗完畢的情況下，CRF能夠向OCS返回需要回補的信用額度，OCS將相應信用額度回補到用戶的帳戶上。
圖3B示出了本發(fā)明中CRF向OCS回補信用額度實現(xiàn)過程示意圖，如圖3B所示，CRF向OCS回補信用額度的實現(xiàn)過程包括以下步驟步驟301B～步驟302BCRF向OCS發(fā)送信用回補消息(Credit Return)，該信用回補消息中攜帶有用戶標識、業(yè)務信息、需要回補的信用額度等信息。OCS收到信用回補消息后，將需要回補的信用額度回補到用戶的帳戶上，然后可進一步向CRF返回響應(Ack)，通知CRF已將相應信用額度回補。
以上所述需要回補的信用額度可以是消耗OCS分配的信用額度后的剩余信用額度，也可以是CRF請求的全部的信用額度。這里，CRF向OCS回補信用額度流程的應用場景可以是業(yè)務使用不成功時，信用額度未消耗，CRF將請求的全部信用額度回退給OCS，或是信用額度未消耗完畢，CRF只將未消耗的剩余信用額度回退給OCS，然后OCS將接收到的需回補的信用額度回補到用戶的帳戶上。另外，CRF向OCS回補信用額度流程的應用場景也可以是業(yè)務使用成功時，如果請求到的信用額度尚未消耗完畢，CRF需要將未使用的信用額度回退給OCS，然后，OCS將接收到的需回補的信用額度回補到用戶的帳戶上。
圖4A示出了本發(fā)明中CRF通過AF獲知用戶業(yè)務訂購實現(xiàn)過程示意圖，如圖4A所示，CRF通過AF獲知用戶業(yè)務訂購的實現(xiàn)過程包括以下步驟步驟401A～步驟402A用戶訂購業(yè)務時，AF向CRF發(fā)送業(yè)務訂購消息(Subscribed Info)，該業(yè)務訂購消息中攜帶有業(yè)務訂購信息，如用戶標識、業(yè)務信息、計費模式等信息，計費模式可為包月計費、按條數(shù)計費、按次數(shù)計費、按頁面計費等等。CRF收到業(yè)務訂購消息后，存儲訂購信息，并可進一步向CRF返回響應，通知AF已收到其發(fā)送的業(yè)務定購信息。
圖4B示出了本發(fā)明中CRF通過AF獲知業(yè)務使用情況實現(xiàn)過程示意圖，如圖4B所示，CRF通過AF獲知業(yè)務使用情況的實現(xiàn)過程包括以下步驟步驟401BAF向CRF發(fā)送業(yè)務開始消息(Service Start)，該業(yè)務開始消息中攜帶有用戶標識、業(yè)務信息等，通知CRF用戶開始使用相應業(yè)務。
步驟402BCRF根據(jù)先前獲取的業(yè)務訂購信息，判斷用戶是否能夠使用相應業(yè)務，如果用戶能夠使用相應業(yè)務，則離線計費情況下，向AF發(fā)送業(yè)務繼續(xù)消息(Service Continue)，然后記錄相關信息，如開始計費信息的采集，后續(xù)可執(zhí)行步驟403B；在線計費情況下，CRF與OCS進行交互以獲取相應信用額度，如果OCS提供了信用額度或返回了信用充足信息，則CRF向AF發(fā)送業(yè)務繼續(xù)消息，然后記錄相關信息，如開始計費信息的采集，后續(xù)可執(zhí)行步驟403B，如果OCS未提供信用額度或返回了信用不足信息，則CRF向AF發(fā)送業(yè)務終止消息(Service Terminate)，該業(yè)務終止消息中可攜帶有終止原因。如果用戶不能夠使用相應業(yè)務，則CRF向AF發(fā)送業(yè)務終止消息，該業(yè)務終止消息中可攜帶有終止原因。
步驟403BAF根據(jù)用戶使用業(yè)務的情況，如果用戶成功使用業(yè)務，則向CRF發(fā)送業(yè)務成功消息(Service Success)，通知CRF用戶成功使用業(yè)務，如果用戶使用業(yè)務失敗，則向CRF發(fā)送業(yè)務失敗消息(Service Failure)，通知CRF用戶使用業(yè)務失敗。
步驟404BCRF收到業(yè)務成功/失敗消息后，結束計費信息的采集，并可進一步向AF返回響應，通知AF已獲知用戶的業(yè)務使用情況。在線計費情況下，對于CRF收到業(yè)務成功消息后，如果分配的信用額度尚未消耗完畢，CRF可向OCS返回未使用的信用額度，對于CRF收到業(yè)務失敗消息后，CRF可向OCS回退需要回補的信用額度，由OCS將接收到的需回補的信用額度回補到用戶的帳戶上；對于CRF收到業(yè)務失敗消息后，信用額度未消耗，CRF將請求的全部信用額度回退給OCS，或是信用額度未消耗完畢，CRF只將未消耗的剩余信用額度回退給OCS，然后OCS將接收到的需回補的信用額度回補到用戶的帳戶上。
圖5A示出了本發(fā)明中支持在線計費的FBC系統(tǒng)結構示意圖，如圖5A所示，在線計費情況下，將CRF 203與CDF/CGF 207通過Rz接口相連，用于CRF 203將計費信息發(fā)送至CDF/CGF 207，然后由CDF/CGF 207將CRF203提供的計費信息上報至計費中心，從而實現(xiàn)在線情況下基于FBC系統(tǒng)結構對業(yè)務費用的收取。
圖5B示出了本發(fā)明中支持離線計費的FBC系統(tǒng)結構示意圖，如圖5B所示，離線計費情況下，將CRF 203與CDF/CGF 207通過Rz接口相連，用于CRF 203將計費信息發(fā)送至CDF/CGF 207，然后由CDF/CGF 207將CRF203提供的計費信息上報至計費中心，從而實現(xiàn)在線情況下基于FBC系統(tǒng)結構對業(yè)務費用的收取。
以上所述CRF與CDF/CGF的連接方式不限于通過Rz接口相連，還可采用其他連接方式，如通過其他功能實體間接相連等等。
無論在線計費情況下還是離線計費情況下，有關業(yè)務計費的計費信息采集點是CRF，CRF收集針對業(yè)務使用情況的信息，然后生產(chǎn)計費信息，并將該計費信息經(jīng)由CGF/CDF 207發(fā)送至計費中心，從而基于FBC系統(tǒng)結構對業(yè)務費用的收取。
圖6示出了本發(fā)明中實施例一實現(xiàn)過程示意圖，如圖6所示，本實施例中CRF作為離線計費信息采集點的具體實現(xiàn)過程包括以下步驟步驟601～步驟603AF收到用戶訂購業(yè)務消息(Subscribe to a Service)，獲知用戶訂購了某業(yè)務，然后向CRF發(fā)送業(yè)務訂購消息，該業(yè)務訂購消息中攜帶有業(yè)務訂購信息，如用戶標識、業(yè)務信息、計費模式等信息，計費模式可為包月計費、按條數(shù)計費、按次數(shù)計費、按頁面計費等等。CRF收到業(yè)務訂購消息后，存儲訂購信息，并可進一步向CRF返回響應，通知AF已收到其發(fā)送的業(yè)務定購信息。
步驟604～步驟605AF收到用戶發(fā)送的業(yè)務請求(Service Request)后，向CRF發(fā)送業(yè)務開始消息，該業(yè)務開始消息中攜帶有用戶標識、業(yè)務信息等，通知CRF用戶開始使用相應業(yè)務。
步驟606～步驟607CRF根據(jù)先前獲取的業(yè)務訂購信息，判斷用戶是否能夠使用相應業(yè)務，如果是，向AF發(fā)送業(yè)務繼續(xù)消息，然后記錄相關信息，如開始計費信息的采集，AF收到CRF發(fā)送的業(yè)務繼續(xù)消息后，向用戶返回業(yè)務接受消息，通知用戶其業(yè)務請求已被接受，后續(xù)可執(zhí)行步驟608；否則，CRF向AF發(fā)送業(yè)務終止消息，該業(yè)務終止消息中可攜帶有終止原因，AF收到CRF發(fā)送的業(yè)務終止消息后，向用戶發(fā)送業(yè)務拒絕消息，該業(yè)務拒絕消息中可攜帶有拒絕原因。
步驟608～步驟609AF根據(jù)用戶使用業(yè)務的情況，如果用戶成功使用業(yè)務，則向CRF發(fā)送業(yè)務成功消息，通知CRF用戶成功使用業(yè)務，如果用戶使用業(yè)務失敗，則向CRF發(fā)送業(yè)務失敗消息，通知CRF用戶使用業(yè)務失敗。CRF收到業(yè)務成功/失敗消息后，結束計費信息的采集，并可進一步向AF返回響應，通知AF已獲知用戶的業(yè)務使用情況。
最后，CRF生成與業(yè)務使用情況相關的計費信息，并通過CDF/CGF將該計費信息上報至計費中心，由計費中心為用戶生成與業(yè)務使用情況相關的業(yè)務費用清單。
圖7示出了本發(fā)明中實施例二實現(xiàn)過程示意圖，如圖7所示，本實施例中CRF作為在線計費信息采集點的具體實現(xiàn)過程包括以下步驟步驟701～步驟705與步驟601～步驟605相同。
步驟706～步驟707CRF根據(jù)先前獲取的業(yè)務訂購信息，判斷用戶是否能夠使用相應業(yè)務，如果是，則OCS發(fā)送信用請求，該信用請求中攜帶有用戶標識、業(yè)務信息、費率信息等供OCS確定信用信息的輸入信息，OCS收到信用請求后，向OCS返回信用響應，該信用響應中攜帶有信用信息，如OCS計算的信用額度、信用額度是否充足等信息；否則，直接執(zhí)行步驟708中的向AF發(fā)送業(yè)務終止消息，該業(yè)務終止消息中可攜帶有終止原因。
步驟708～步驟709如果OCS提供了信用額度或返回了信用充足信息，則CRF向AF發(fā)送業(yè)務繼續(xù)消息，然后記錄相關信息，如開始計費信息的采集，AF收到CRF發(fā)送的業(yè)務繼續(xù)消息后，向用戶返回業(yè)務接受消息，通知用戶其業(yè)務請求已被接受，后續(xù)可執(zhí)行步驟710；如果OCS未提供信用額度或返回了信用不足信息，以及用戶不能夠使用相應業(yè)務，則CRF向AF發(fā)送業(yè)務終止消息，該業(yè)務終止消息中可攜帶有終止原因，AF收到CRF發(fā)送的業(yè)務終止消息后，向用戶發(fā)送業(yè)務拒絕消息，該業(yè)務拒絕消息中可攜帶有拒絕原因。
步驟710～步驟711與步驟608～步驟609相同。
在線計費情況下，業(yè)務成功時，若信用額度尚未使用完畢或業(yè)務失敗時，CRF還需向OCS返回需要回補的信用額度，即CRF向OCS發(fā)送信用回補消息，該信用回補消息中用戶標識、業(yè)務信息、需要回補的信用額度等信息。OCS收到信用回補消息后，將需要回補的信用額度回補，然后可進一步向CRF返回響應(Ack)，通知CRF已將相應信用額度回補。
最后，CRF生成與業(yè)務使用情況相關的計費信息，并通過CDF/CGF將該計費信息上報至計費中心，由計費中心為用戶生成與業(yè)務使用情況相關的業(yè)務費用清單。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含CRF向OCS發(fā)送信用請求，OCS向CRF返回信用響應。
2.根據(jù)權利要求1所述的方法，其特征在于，所述信用響應中攜帶有信用額度或信用額度是否充足信息。
3.根據(jù)權利要求1所述的方法，其特征在于，該方法進一步包括CRF向OCS回退需要回補的信用額度，OCS將收到的所述信用額度回補到用戶的帳戶上。
4.根據(jù)權利要求3所述的方法，其特征在于，所述OCS收到需要回補的信用額度，之后進一步包括OCS向CRF返回用于通知CRF已收到需要回補的信用額度的響應。
5.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含AF通知CRF用戶請求使用業(yè)務，CRF根據(jù)業(yè)務訂購信息判斷是否允許用戶使用業(yè)務，如果是，則通知AF為用戶提供所述業(yè)務；否則，通知AF不為用戶提供所述業(yè)務。
6.根據(jù)權利要求5所述的方法，其特征在于，所述業(yè)務訂購信息是在用戶訂購業(yè)務時，由AF向CRF提供的。
7.根據(jù)權利要求6所述的方法，其特征在于，所述CRF收到AF提供的業(yè)務訂購信息后，進一步包括CRF向AF返回用于通知AF已收到業(yè)務訂購信息的響應。
8.根據(jù)權利要求5所述的方法，其特征在于，所述通知AF為用戶提供所述業(yè)務，之前進一步包括CRF開始計費信息的采集。
9.根據(jù)權利要求5所述的方法，其特征在于，所述通知AF為用戶提供所述業(yè)務，之后進一步包括a1、AF通知CRF用戶的業(yè)務使用情況。
10.根據(jù)權利要求9所述的方法，其特征在于，所述步驟a1之后進一步包括CRF向AF返回用于通知AF已收到業(yè)務使用情況的響應。
11.根據(jù)權利要求9所述的方法，其特征在于，所述步驟a1之后進一步包括b1、CRF停止計費信息的采集。
12.根據(jù)權利要求11所述的方法，其特征在于，所述步驟b1之后進一步包括CRF向CDF/CGF發(fā)送計費信息。
13.根據(jù)權利要求5至12任一所述的方法，其特征在于，在線計費情況下，所述通知AF為用戶提供所述業(yè)務，之前進一步包括CRF向OCS發(fā)送信用請求，OCS向CRF返回信用響應。
14.根據(jù)權利要求13所述的方法，其特征在于，所述步驟a1之后進一步包括CRF向OCS回退需要回補的信用額度，OCS將收到的所述信用額度回補到用戶的帳戶上。
15.一種基于分組數(shù)據(jù)流計費的系統(tǒng)，該系統(tǒng)包括CRF與TPF相連，用于使CRF向TPF提供計費規(guī)則，TPF與CDF/CGF相連，用于TPF向CDF/CGF提供對應于承載的計費信息；其特征在于，該系統(tǒng)中，AF與CRF相連，用于傳送業(yè)務相關信息，CRF與CDF/CGF相連，用于CRF向CDF/CGF提供對應于業(yè)務的計費信息。
16.根據(jù)權利要求15所述的系統(tǒng)，其特征在于，所述CRF與CDF/CGF通過Rz接口相連。
17.根據(jù)權利要求15或16所述的方法，其特征在于，該系統(tǒng)進一步包括OCS，與TPF相連，用于根據(jù)TPF的請求向TPF提供信用信息；并與CRF相連，用于根據(jù)CRF的請求向CRF提供信用信息。
全文摘要
本發(fā)明公開了一種基于分組數(shù)據(jù)流計費的處理方法，在CRF中增加計費信息采集功能，增加CRF與OCS之間的交互流程，使得OCS能夠根據(jù)CRF的信用請求，向CRF提供信用信息，如具體的信用額度、信用額度是否充足等信息，還可使CRF能夠向OCS返回需回補的信用額度，OCS將相應信用額度回補到用戶的帳戶上；并增加CRF與AF之間的交互流程，使得CRF能夠獲知用戶訂購業(yè)務的情況，并且能夠獲知業(yè)務的使用成功與否的信息。另外，本發(fā)明還公開了一種基于分組數(shù)據(jù)流計費的系統(tǒng)，增加CRF與CDF/CGF之間的信令接口，使CRF能夠?qū)⒃诰€計費情況下或是離線計費情況下生成的計費信息通過CDF/CGF上報至計費中心，從而實現(xiàn)基于FBC系統(tǒng)結構對業(yè)務費用的收取，滿足在網(wǎng)絡中進行業(yè)務運營的要求。
文檔編號H04L12/14GK1773922SQ200410090929
公開日2006年5月17日 申請日期2004年11月10日 優(yōu)先權日2004年11月10日
發(fā)明者段小琴 申請人:華為技術有限公司