專利名稱：一種基于分組數(shù)據(jù)流計費的系統(tǒng)及處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分組數(shù)據(jù)計費領(lǐng)域，特別是指一種基于分組數(shù)據(jù)流計費的系統(tǒng)及處理方法。
背景技術(shù)：
隨著分組數(shù)據(jù)業(yè)務(wù)應(yīng)用的逐漸廣泛，如何準確合理地對分組數(shù)據(jù)業(yè)務(wù)進行計費，已成為運營商普遍關(guān)注的問題。
圖1示出了分組數(shù)據(jù)協(xié)議上下文(PDP Context，Packet Data ProtocolContext)激活、數(shù)據(jù)傳輸、去激活流程圖，如圖1所示，在通用分組無線業(yè)務(wù)(GPRS，General Packet Radio Service)中，激活PDP Context、與外部分組數(shù)據(jù)網(wǎng)絡(luò)(PDN，Packet Data Network)進行數(shù)據(jù)交互、去激活該PDPContext的實現(xiàn)過程包括以下步驟步驟101移動終端(MS)向服務(wù)通用分組無線業(yè)務(wù)支持節(jié)點(SGSN，Serving GPRS Support Node)發(fā)送PDP Context激活請求(Activate PDPContext Request)，該Activate PDP Context Request中攜帶有網(wǎng)絡(luò)層業(yè)務(wù)訪問點標(biāo)識(NSAPI，Network Layer Service Access Point Identifier)、PDP類型、接入點名稱(APN，Access Point Name)、要求的服務(wù)質(zhì)量(QoS)參數(shù)、事務(wù)標(biāo)識(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和網(wǎng)關(guān)通用分組無線業(yè)務(wù)支持節(jié)點(GGSN，Gateway GPRS Support Node)之間作為隧道標(biāo)識(TID，Tunnel Identifier)的組成部分，用于標(biāo)識PDPContext；PDP類型包括端對端協(xié)議(PPP，Peer-Peer Protocol)類型、網(wǎng)際協(xié)議(IP，Internet Protocol)類型等；ApN可由MS向SGSN提供，SGSN根據(jù)APN尋址到相應(yīng)GGSN，GGSN根據(jù)APN確定MS所要訪問的外部網(wǎng)絡(luò)，MS也可不向SGSN提供APN，此時，由SGSN根據(jù)MS用戶的簽約信息選擇缺省的APN；QoS參數(shù)為MS指定的分組數(shù)據(jù)業(yè)務(wù)所要達到的質(zhì)量要求；TI用于MS標(biāo)識某個PDP context。
步驟102SGSN收到Activate PDP Context Request后，與MS進行安全性檢查和加密，該步驟為可選步驟。
步驟103SGSN根據(jù)APN解析GGSN的地址信息，如果SGSN能夠根據(jù)APN解析出GGSN的地址信息，則為PDP Context創(chuàng)建TEID，該TEID可為國際移動用戶標(biāo)識(IMSI，International Mobile Subscriber Identity)與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，然后分配計費標(biāo)識(Charging ID)、啟動計費，并且協(xié)商QoS，如果GGSN能夠滿足QoS參數(shù)的服務(wù)質(zhì)量要求，則向SGSN返回PDP Context創(chuàng)建響應(yīng)(Create PDP Context Response)，該PDP Context創(chuàng)建響應(yīng)中攜帶有TEID、PDP地址、鏈路承載(Backbone Bearer)協(xié)議、商定的QoS參數(shù)、Charging ID等信息。如果GGSN無法滿足QoS參數(shù)的服務(wù)質(zhì)量要求，則GGSN拒絕SGSN發(fā)起的PDP Context創(chuàng)建請求，然后SGSN拒絕MS發(fā)起的PDP Context激活請求。
步驟105SGSN收到PDP Context創(chuàng)建響應(yīng)后，在PDP Context中插入用于標(biāo)識PDP Context的NSAPI和GGSN地址信息，并根據(jù)商定的QoS參數(shù)選擇無線優(yōu)先權(quán)，然后向MS返回PDP Context激活響應(yīng)(Activate PDPContext Accept)，該PDP Context激活響應(yīng)中攜帶有PDP類型、PDP地址、TI、商定的QoS參數(shù)、無線優(yōu)先權(quán)、PDP配置選項等信息。并且，SGSN啟動計費。MS收到PDP Context激活響應(yīng)，就已經(jīng)建立了MS與GGSN直接的路由，可以進行分組數(shù)據(jù)的傳輸了。
步驟106MS通過SGSN、GGSN與PDN進行分組數(shù)據(jù)的交互。
步驟107結(jié)束分組數(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刪除請求后，結(jié)束對MS的計費，刪除對應(yīng)于TEID的PDPContext，然后向SGSN發(fā)送PDP Context刪除響應(yīng)(Delete PDP ContextResponse)，該PDP Context刪除響應(yīng)中攜帶有TEID。SGSN收到PDP Context刪除響應(yīng)后，結(jié)束對MS的計費，刪除對應(yīng)于TEID的PDP Context，然后向MS發(fā)送PDP Context去激活響應(yīng)(Deactivate PDP Context Response)，該PDP Context去激活響應(yīng)中攜帶有TI。MS收到PDP Context去激活響應(yīng)后，刪除對應(yīng)于TI的PDP Context。
由圖1描述的實現(xiàn)過程可見，當(dāng)前的GPRS計費系統(tǒng)中，由于計費的起始點設(shè)置在PDP Context激活時，計費的終止點設(shè)置在PDP Context刪除時，因此只能根據(jù)PDP Context傳輸?shù)臄?shù)據(jù)流量進行計費，或是根據(jù)PDP Context處于激活狀態(tài)的時間長度進行計費。然而，在實際應(yīng)用中，MS與PDN進行數(shù)據(jù)交互后，該MS可以基于一個激活的PDP Context進行多種業(yè)務(wù)，也就是說，如果PDN能夠提供多種業(yè)務(wù)，如電子郵件(Email)收發(fā)業(yè)務(wù)、基于無線應(yīng)用協(xié)議的(WAP，Wireless Application Protocol)的瀏覽業(yè)務(wù)、基于文件傳輸協(xié)議(FTP，F(xiàn)ile Transfer Protocol)的文件傳輸?shù)葮I(yè)務(wù)，則MS在與該PDN建立傳輸通道后，可通過一個激活的PDP Context承載該PDN能夠提供的各種業(yè)務(wù)，但是，運營商對于各種業(yè)務(wù)的計費模式很可能采用不同的計費方式，如對于Email收發(fā)業(yè)務(wù)可基于Email接收和發(fā)送事件的觸發(fā)按次計費，對于WAP瀏覽業(yè)務(wù)可根據(jù)流量計費，對于文件傳輸業(yè)務(wù)也可根據(jù)流量計費，WAP瀏覽業(yè)務(wù)的費率與文件傳輸業(yè)務(wù)的費率卻不盡相同。這樣，根據(jù)現(xiàn)有的GPRS計費系統(tǒng)，根本無法對同一PDP Context承載的不同業(yè)務(wù)進行區(qū)分計費。
針對上述情況，第三代合作伙伴計劃(3GPP，The 3rd GenerationPartnership Proiect)目前正在討論如何實現(xiàn)基于IP數(shù)據(jù)流的計費(FBC，F(xiàn)lowBased Charging)。對于一個分組數(shù)據(jù)業(yè)務(wù)而言，MS的用戶使用該業(yè)務(wù)時，傳輸和接收到的所有IP數(shù)據(jù)流(IP Flow)，也可為IP分組包(IP packet)，總稱為業(yè)務(wù)數(shù)據(jù)流(Service Data Flow)，即業(yè)務(wù)數(shù)據(jù)流是多個IP數(shù)據(jù)流組成的集合，因此基于IP數(shù)據(jù)流的計費能夠真實反映某個業(yè)務(wù)數(shù)據(jù)流對資源的占用情況?；贗P數(shù)據(jù)流的計費可被認為是通過一些類似篩子的過濾器將同一PDP Context中承載的不同業(yè)務(wù)的IP數(shù)據(jù)流分別篩選出來，然后針對不同過濾器過濾出的IP數(shù)據(jù)流進行分別計費，以達到對不同的業(yè)務(wù)數(shù)據(jù)流分別計費的目的。這樣，基于IP數(shù)據(jù)流的計費粒度要遠遠小于基于一個PDPContext的計費粒度，粒度可看作是篩子孔的大小，基于一個PDP Context的計費粒度是一個PDP Context就是一個篩子孔，而基于IP數(shù)據(jù)流的計費粒度則是一個IP業(yè)務(wù)數(shù)據(jù)流則為一個篩子孔，即針對一個PDP Context中包含多個篩子孔，因此，基于IP數(shù)據(jù)流的計費與比基于一個PDP Context的計費相比，基于IP數(shù)據(jù)流的計費能夠為運營商或業(yè)務(wù)提供者提供更為豐富的計費手段。
3GPP中對FBC的系統(tǒng)結(jié)構(gòu)、功能要求以及消息交互流程等方面均進行了描述，支持在線計費的FBC系統(tǒng)結(jié)構(gòu)如圖2A所示，基于移動網(wǎng)絡(luò)增強邏輯的客戶化應(yīng)用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的業(yè)務(wù)控制點(SCP，Service Control Point)201和基于業(yè)務(wù)數(shù)據(jù)流計費的信用控制功能實體(CCF，Service Data Flow Based CreditControl Function)202組成了在線計費系統(tǒng)(OCS，Online Charging System)206。CCF 202通過Ry接口與基于業(yè)務(wù)數(shù)據(jù)流計費的計費規(guī)則功能實體(CRF，Service Data Flow Based Charging Rule Function)203互通，CRF 203通過Rx接口與應(yīng)用功能實體(AF，Application Function)204互通，CRF 203通過Gx接口與傳輸面功能實體(TPF，Traffic Plane Function)205互通，CCF 202通過Gy接口與TPF 205互通。
支持離線計費的FBC系統(tǒng)結(jié)構(gòu)如圖2B所示，CRF 203通過Rx接口與AF 204互通，CRF 203通過Gx接口與TPF 205互通，TPF 205通過Gz接口分別與計費網(wǎng)關(guān)功能實體(CGF，Charging Gateway Function)207和計費采集功能實體(CDF，Charging data Function)208互通。
TPF 205承載IP數(shù)據(jù)流，當(dāng)IP數(shù)據(jù)流的承載建立時，TPF 205通過Gx接口向CRF 203發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有與用戶和MS相關(guān)的信息、承載特性以及與網(wǎng)絡(luò)相關(guān)的信息等，其中與用戶和MS相關(guān)的信息可為移動臺國際號碼(MSISDN)、國際移動用戶標(biāo)識(IMSI)等，與網(wǎng)絡(luò)相關(guān)的信息可為移動網(wǎng)絡(luò)編碼(MNC)、移動國家碼(MCC)等。另外，由于在IP數(shù)據(jù)流傳輸過程中，會對承載進行修改，如對QoS參數(shù)進行重新協(xié)商，當(dāng)用戶使用同一業(yè)務(wù)的QoS參數(shù)不同時，計費規(guī)則可能不同，如QoS參數(shù)下降相應(yīng)的費率也下降。此時，TPF 205可在承載修改時，重新向CRF 203發(fā)送計費規(guī)則請求，請求新的計費規(guī)則；CRF 203根據(jù)TPF 205提供的上述輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF 205返回選定的計費規(guī)則，計費規(guī)則中包括計費機制、計費類型、計費鍵(Charging Key)、業(yè)務(wù)數(shù)據(jù)流過濾器、計費規(guī)則優(yōu)先級等信息。其中，計費機制可為采用在線計費還是離線計費；計費類型可為基于時間長度進行計費還是基于數(shù)據(jù)流量進行計費；計費鍵是與費率相關(guān)的參數(shù)，CRF 203可不直接向TPF 205提供費率，而只是向TPF 205提供與費率相關(guān)的參數(shù)；業(yè)務(wù)數(shù)據(jù)過濾器用于指示TPF205對哪些IP數(shù)據(jù)流進行過濾，然后TPF 205根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進行計費。業(yè)務(wù)數(shù)據(jù)過濾器可包含IP5元組，IP5元組可包括源/目的IP地址、源/目的端口號(Port Number)、協(xié)議標(biāo)識(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ī)則相關(guān)的事件。目前，3GPP規(guī)范中對CRF通過觸發(fā)事件上報機制，控制TPF的計費方式進行了描述，即TPF 205監(jiān)測到觸發(fā)事件發(fā)生后向CRF 203上報，CRF 203通過TPF 205上報的觸發(fā)事件獲知承載發(fā)生變化，然后確定相應(yīng)的計費規(guī)則并下發(fā)給TPF 205。3GPP規(guī)范中定義的觸發(fā)事件可包括公用陸地移動通信網(wǎng)絡(luò)(PLMN)變化(PLMN change)事件，QoS參數(shù)變化(QoS changes)事件，無線接入技術(shù)(RAT)類型變化(RAT type change)事件，傳輸流模板(TFT)變化(TFT change)事件。
CRF 203除了根據(jù)TPF 205提供的輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則之外，CRF 203還可根據(jù)AF 204或OCS 206的輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，如AF 204通知CRF 203用戶當(dāng)前使用的業(yè)務(wù)類型，CRF 203根據(jù)該業(yè)務(wù)類型選擇相應(yīng)的計費規(guī)則。
OCS 206作為在線計費系統(tǒng)，由SCP 201和CCF 202兩個功能實體組成，其中，CCF 202是執(zhí)行信用控制的功能實體，僅應(yīng)用于在線計費系統(tǒng)，可通過在現(xiàn)有的OCS 206中增加新的功能來實現(xiàn)。在在線計費過程中，CCF 202對用戶信用進行管理和控制，當(dāng)用戶使用業(yè)務(wù)時，CCF 202對該用戶信用池中的信用進行鑒權(quán)，并通過Gy接口向TPF 205下發(fā)用戶能夠使用的信用。
另外，OCS 206可要求TPF 205在重鑒權(quán)事件(Re-authorisation triggers)發(fā)生時向其上報，然后OCS 206根據(jù)TPF 205上報的相應(yīng)重鑒權(quán)事件對用戶進行重鑒權(quán)，并可能重新計算用戶的信用。例如，OCS 206向TPF 205提供的用戶信用使用完畢，TPF 205需根據(jù)重鑒權(quán)事件中的允許信用過期事件，向OCS 206上報其允許的用戶信用使用過期事件的發(fā)生，OCS 206根據(jù)用戶剩余帳戶信息，重新對允許用戶使用的信用進行計算。又例如，分區(qū)域計費時，OCS 206根據(jù)用戶當(dāng)前所在位置確定費率，并根據(jù)該費率計算用戶的信用；當(dāng)用戶移動至另一位置時，如PLMN發(fā)生變化，TPF 205需要根據(jù)重鑒權(quán)事件中的PLMN變化事件，向OCS 206上報PLMN變化事件的發(fā)生，OCS206根據(jù)用戶更新后的當(dāng)前所在位置重新確定費率，并重新計算用戶的信用。又例如，當(dāng)OCS 206根據(jù)用戶使用業(yè)務(wù)的當(dāng)前QoS參數(shù)確定費率，當(dāng)用戶對QoS參數(shù)進行修改，TPF 205需要根據(jù)重鑒權(quán)事件中的承載修改事件，向OCS 206上報承載修改事件的發(fā)生，OCS 206根據(jù)用戶修改后的QoS參數(shù)確定費率，并重新計算用戶的信用。
另外，3GPP規(guī)范中還對OCS 206通過重鑒權(quán)事件上報的機制，控制TPF205的信用使用情況進行了描述，即TPF 205監(jiān)測到重鑒權(quán)事件發(fā)生后向OCS 206上報，OCS 206通過TPF 205上報的重鑒權(quán)事件，獲知用戶的信用使用情況以及承載的變化，對用戶的信用重新進行計算并下發(fā)給TPF 205。3GPP規(guī)范中定義的重鑒權(quán)事件可包括允許信用過期(credit authorizationlifetime expiry)事件，用戶空閑狀態(tài)超時(idle timeout)事件，計費規(guī)則變化(charging rule is changed)事件，PLMN變化事件，QoS參數(shù)變化事件，RAT類型變化事件。
對應(yīng)于GPRS網(wǎng)絡(luò)，TPF 205為GGSN，AF為PDN中的一個業(yè)務(wù)網(wǎng)關(guān)或業(yè)務(wù)服務(wù)器，CRF 203為新增的邏輯實體。TPF 205為計費規(guī)則的執(zhí)行點，CRF 203為計費規(guī)則的控制點。
目前，3GPP定義了承載建立時，在線計費情況下，請求計費規(guī)則和用戶信用的處理過程如圖3A所示步驟301A用戶設(shè)備(UE)向TPF發(fā)送承載建立請求(Establish BearerService Request)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Create PDP ContextRequest。
步驟302ATPF收到承載建立請求后，向CRF發(fā)送計費規(guī)則請求(Request Charging Rules)，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟303A～步驟304ACRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則(Provision Charging Rules)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和觸發(fā)事件信息。
步驟305ATPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即建立計費規(guī)則。
步驟306A～步驟307ATPF根據(jù)計費規(guī)則中的在線計費指示，向OCS發(fā)送信用請求(Credit Request)，請求用戶的信用。OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)(Credit Response)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用，如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。
步驟308ATPF收到信用響應(yīng)后，向UE返回承載建立響應(yīng)(EstablishBearer Service Accept)，如果信用響應(yīng)中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程；如果信用響應(yīng)中未攜帶有用戶的信用，則拒絕UE發(fā)起的承載建立請求。
對于承載修改，在線計費情況下，請求計費規(guī)則和用戶信用的處理過程如圖3B所示
步驟301BUE向TPF發(fā)送承載修改請求(Modify Bearer ServiceRequest)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到PDP Context更新請求(UpdatePDP Context Request)。
步驟302BTPF收到承載修改請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟303B～步驟304BCRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和觸發(fā)事件信息。
步驟305BTPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即建立、修改、刪除計費規(guī)則。
步驟306B～步驟307BTPF根據(jù)計費規(guī)則中的在線計費指示，向OCS發(fā)送信用請求，請求用戶的信用。OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用，如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。
步驟308BTPF收到信用響應(yīng)后，向UE返回承載修改響應(yīng)(ModifyBearer Service Accept)，如果信用響應(yīng)中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程；如果信用響應(yīng)中未攜帶有用戶的信用，則拒絕UE發(fā)起的承載修改請求。
對于承載刪除，在線計費情況下，請求計費規(guī)則和用戶信用的處理過程如圖3C所示步驟301CUE向TPF發(fā)送承載刪除請求(Remove Bearer ServiceRequest)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Delete PDP Context Request。
步驟302CTPF收到承載刪除請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟303C～步驟304CCRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和計費規(guī)則操作指示。
步驟305CTPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即刪除計費規(guī)則。
步驟306C～步驟307CTPF向OCS發(fā)送信用報告(Final Remaining CreditReport)，通知OCS為用戶建立的承載已經(jīng)終止，該信用報告中攜帶有用戶信用的使用情況，如用戶使用分組數(shù)據(jù)業(yè)務(wù)的時間長度、使用分組數(shù)據(jù)的流量大小，或是用戶的剩余信用。OCS收到信用報告后，向TPF返回信用報告響應(yīng)(Response)。
步驟308CTPF收到信用報告響應(yīng)后，向UE返回承載刪除響應(yīng)(RemoveBearer Service Accept)，接受UE發(fā)起的承載刪除請求，并繼續(xù)后續(xù)的承載刪除流程。
目前，3GPP定義了離線計費情況下，承載修改會觸發(fā)TPF向CRF請求計費規(guī)則的處理過程，具體實現(xiàn)過程如圖4A所示步驟401AUE向TPF發(fā)送承載修改請求，在GPRS網(wǎng)絡(luò)中，則是GGSN收到PDP Context更新請求。
步驟402ATPF收到承載修改請求后，將承載修改事件與存儲的觸發(fā)事件相匹配，如果能夠匹配，則執(zhí)行步驟403A；否則，繼續(xù)監(jiān)測觸發(fā)事件的發(fā)生。
步驟403ATPF向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟404A～步驟405ACRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和觸發(fā)事件信息。
步驟406ATPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即建立、修改、刪除計費規(guī)則。
步驟407ATPF向UE返回承載修改響應(yīng)，并繼續(xù)后續(xù)的承載修改流程。
在線計費情況下，承載修改會觸發(fā)TPF請求OCS對用戶進行重鑒權(quán)的流程，具體實現(xiàn)過程如圖4B所示步驟401B～步驟406B與步驟401A～步驟406A相同。
步驟407BTPF將承載修改事件與存儲的重鑒權(quán)事件進行匹配，如果能夠匹配，則執(zhí)行步驟408B，否則，繼續(xù)監(jiān)測重鑒權(quán)事件的發(fā)生。
步驟408B如果重鑒權(quán)事件發(fā)生了，或是計費規(guī)則發(fā)生了改變，TPF向OCS發(fā)送信用及重鑒權(quán)請求(Credit Request and Re-authorisationRequest)，該信用及重鑒權(quán)請求中攜帶有用戶的剩余信用和相關(guān)的計費規(guī)則信息，還可攜帶相應(yīng)的重鑒權(quán)事件，請求OCS重新計算用戶的信用。TPF向OCS提供的相關(guān)計費規(guī)則信息可來自CRF。
步驟409BOCS收到信用控制請求后，重新對用戶的信用進行計算，然后向TPF返回信用及重鑒權(quán)響應(yīng)(Credit Response and Re-authorizationResponse)，如果OCS計算出用戶的信用，則該信用及重鑒權(quán)響應(yīng)中攜帶有OCS重新計算的用戶信用，如果OCS未計算出用戶的信用，則該信用控制響應(yīng)中可攜帶有差錯原因值。
步驟410BTPF收到信用控制響應(yīng)后，向UE返回承載修改響應(yīng)，如果信用控制響應(yīng)中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程；如果信用控制響應(yīng)中未攜帶有用戶的信用，則拒絕UE發(fā)起的承載修改請求。
另外，CRF也可主動向TPF發(fā)送計費規(guī)則，如當(dāng)UE與AF進行業(yè)務(wù)數(shù)據(jù)傳輸?shù)倪^程中，CRF收到AF的計費規(guī)則輸入信息后，根據(jù)AF提供的計費規(guī)則輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，然后主動向TPF下發(fā)選定的計費規(guī)則。對于AF向CRF提供計費規(guī)則輸入信息的具體實現(xiàn)過程如圖5所示步驟501AF向CRF發(fā)送應(yīng)用/業(yè)務(wù)計費相關(guān)信息(SendApplication/Service Data Flow Charging Information)。
步驟502CRF收到應(yīng)用/業(yè)務(wù)計費相關(guān)信息后，向AF返回響應(yīng)(Ack)，通知AF已收到其發(fā)送的計費規(guī)則輸入信息。
圖6示出了CRF主動向TPF下發(fā)計費規(guī)則流程圖，如圖6所示，CRF主動向TPF下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟601CRF收到某個內(nèi)部或外部的觸發(fā)事件(Internal or ExternalTrigger Event)，以及與該事件相關(guān)的信息，如AF向CRF發(fā)送計費規(guī)則輸入信息的事件。
步驟602CRF根據(jù)獲取的信息選擇相應(yīng)的計費規(guī)則。這些信息可為AF提供的計費規(guī)則輸入信息，例如，用戶使用AF提供的某一業(yè)務(wù)，該業(yè)務(wù)對計費有特殊要求，如費率與其他業(yè)務(wù)的費率不同，因此，AF向CRF提供與該業(yè)務(wù)相關(guān)的計費信息；也可為TPF提供的計費規(guī)則輸入信息。
步驟603如果需要的話，CRF向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和觸發(fā)事件信息。
步驟604TPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即建立、修改、刪除計費規(guī)則。
步驟605～步驟606TPF向OCS發(fā)送信用請求，請求用戶的信用。OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用，如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。
目前，規(guī)范中對CRF通過觸發(fā)事件上報機制控制TPF的計費方式進行了定義，即TPF監(jiān)測到觸發(fā)事件發(fā)生后向CRF上報，CRF通過TPF上報的觸發(fā)事件獲知承載發(fā)生變化，然后確定相應(yīng)的計費規(guī)則并下發(fā)給TPF。規(guī)范中定義的觸發(fā)事件可包括PLMN變化(PLMN change)事件，QoS參數(shù)變化(QoS changes)事件，無線接入技術(shù)(RAT)類型變化(RAT type change)事件，傳輸流模板(TFT)變化(TFT change)事件。
另外，規(guī)范中還對OCS通過重鑒權(quán)事件上報的機制控制TPF的信用使用情況進行了描述，即TPF監(jiān)測到重鑒權(quán)事件發(fā)生后向OCS上報，OCS通過TPF上報的重鑒權(quán)事件，獲知用戶的信用使用情況以及承載的變化，對用戶的信用重新進行計算并下發(fā)給TPF。規(guī)范中定義的重鑒權(quán)事件可包括允許信用過期(credit authorization lifetime expiry)事件，用戶空閑狀態(tài)超時(idle timeout)事件，計費規(guī)則變化(charging rule is changed)事件，PLMN變化事件，QoS參數(shù)變化事件，RAT類型變化事件。
通過以上描述可見，觸發(fā)事件和重鑒權(quán)事件中都包括SGSN變化事件、QoS參數(shù)變化事件、RAT類型變化事件等，這樣，對于某個發(fā)生的GPRS事件，TPF會將該GPRS事件同時匹配到觸發(fā)事件和重鑒權(quán)事件，因此，需要分別向CRF和OCS上報該GPRS事件的發(fā)生，造成對FBC系統(tǒng)資源的浪費。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的一個目的在于提供一種基于分組數(shù)據(jù)流計費的系統(tǒng)，本發(fā)明的另一目的在于提供一種基于分組數(shù)據(jù)流計費的處理方法，完善基于分組數(shù)據(jù)流計費的系統(tǒng)結(jié)構(gòu)和實現(xiàn)流程。
為了達到上述目的，本發(fā)明提供了一種基于分組數(shù)據(jù)流計費的系統(tǒng)，該系統(tǒng)包括承載數(shù)據(jù)業(yè)務(wù)流的TPF與用于選擇計費規(guī)則及進行信用控制的CRF-CCF相連，用于傳送計費及信用控制信息；所述計費及信用控制信息為TPF向CRF-CCF發(fā)送的計費規(guī)則和/或用戶信用請求、以及CRF-CCF向TPF提供的計費規(guī)則和/或用戶信用；所述CRF-CCF進一步用于向TPF提供計費觸發(fā)事件，所述TPF用于在計費觸發(fā)事件發(fā)生時向CRF-CCF上報。所述CRF-CCF進一步與用于提供業(yè)務(wù)使用信息的AF相連，用于傳送確定計費規(guī)則的輸入信息。
本發(fā)明還提供了一種基于分組數(shù)據(jù)流計費的處理方法，該方法包含TPF向CRF-CCF發(fā)送計費規(guī)則及信用請求，CRF-CCF收到計費規(guī)則及信用請求后，向TPF返回計費規(guī)則和/或用戶信用；或CRF-CCF向TPF提供計費觸發(fā)事件，TPF監(jiān)測到計費觸發(fā)事件發(fā)生時，向CRF-CCF上報；或AF向CRF-CCF提供用于選擇計費規(guī)則的輸入信息；或CRF-CCF要求TPF返回用戶信用的使用情況，TPF向CRF-CCF返回用戶信用使用情況信息。
計費規(guī)則及信用請求中攜帶有用于選擇計費規(guī)則的輸入信息，或計費觸發(fā)事件，或用戶已經(jīng)使用的信用，或用戶的剩余信用，或以上任意的組合。
向TPF返回計費規(guī)則和/或用戶信用進一步包括提供計費觸發(fā)事件。
較佳地，承載建立時，CRF-CCF收到計費規(guī)則及信用請求之后，進一步包括CRF-CCF判斷UE用戶是否為簽約的網(wǎng)絡(luò)用戶，如果是，則直接向TPF返回計費規(guī)則和/或用戶信用；否則，向TPF提供UE歸屬的CRF-CCF的地址信息，TPF根據(jù)收到的CRF-CCF地址信息，向該CRF-CCF發(fā)送計費規(guī)則及信用請求，UE歸屬的CRF-CCF收到計費規(guī)則及信用請求后，向TPF返回計費規(guī)則和/或用戶信用。
所述計費觸發(fā)事件為計費規(guī)則觸發(fā)事件，或為重鑒權(quán)事件，或為以上二者的組合。
所述向CRF-CCF上報為向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求。
所述計費觸發(fā)事件包括計費規(guī)則觸發(fā)事件和重鑒權(quán)事件，向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求之前，進一步包括TPF判斷發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則向CRF-CCF發(fā)送攜帶有重鑒權(quán)事件的計費規(guī)則及信用請求，該計費規(guī)則及信用請求中進一步攜帶有用戶信用使用情況信息。
所述計費觸發(fā)事件包括計費規(guī)則觸發(fā)事件和重鑒權(quán)事件，所述計費規(guī)則及信用請求中進一步攜帶有用戶信用使用情況信息，所述向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求之后，進一步包括CRF-CCF收到計費規(guī)則及信用請求后，判斷TPF上報的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則CRF-CCF選定計費規(guī)則并重新計算用戶信用，然后將計費規(guī)則和用戶信用提供給TPF；否則，CRF-CCF選定計費規(guī)則并提供給TPF。
較佳地，該方法進一步包括CRF-CCF向AF返回表明收到所述輸入信息的響應(yīng)。
根據(jù)本發(fā)明提出的方案，在OCS中實現(xiàn)CRF功能，這樣，觸發(fā)事件可同重鑒權(quán)事件合并實現(xiàn)，統(tǒng)一了TPF的事件上報機制，并且本發(fā)明還描述了基于實現(xiàn)CRF功能的OCS結(jié)構(gòu)下的各種流程，使得TPF與OCS之間以及TPF與CRF之間的處理流程更為清晰。


圖1示出了PDP Context激活、數(shù)據(jù)傳輸、去激活流程圖；圖2A示出了在線計費的FBC系統(tǒng)結(jié)構(gòu)示意圖；圖2B示出了離線計費的FBC系統(tǒng)結(jié)構(gòu)示意圖；圖3A示出了在線計費承載建立時請求計費規(guī)則和用戶信用的處理流程圖；圖3B示出了在線計費承載修改時請求計費規(guī)則和用戶信用的處理流程圖；圖3C示出了在線計費承載刪除時請求計費規(guī)則和用戶信用的處理流程圖；圖4A示出了現(xiàn)有技術(shù)中離線計費時承載修改處理流程圖；圖4B示出了現(xiàn)有技術(shù)中在線計費時承載修改處理流程圖；圖5示出了AF向CRF提供計費規(guī)則輸入信息流程圖；圖6示出了CRF主動向TPF下發(fā)計費規(guī)則流程圖；圖7示出了本發(fā)明中FBC系統(tǒng)結(jié)構(gòu)示意圖；
圖8A示出了本發(fā)明中承載建立時請求計費規(guī)則和用戶信用的處理流程圖；圖8B示出了本發(fā)明中承載修改時請求計費規(guī)則和用戶信用的處理流程圖；圖8C示出了本發(fā)明中承載刪除時請求計費規(guī)則和用戶信用的處理流程圖；圖9示出了本發(fā)明中AF向CRF-CCF提供計費規(guī)則輸入信息的處理流程圖；圖10示出了本發(fā)明中AF向CRF-CCF提供輸入信息觸發(fā)計費規(guī)則和/或信用請求的處理流程圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，對FBC系統(tǒng)結(jié)構(gòu)進行了改進，在OCS系統(tǒng)中增加CRF功能，這樣，觸發(fā)事件和重鑒權(quán)事件可合并實現(xiàn)，統(tǒng)一了TPF基于事件上報的機制，使得TPF與OCS及TPF與CRF之間的處理流程更為清晰。本發(fā)明提出的方案既適用于在線計費情況也適用于離線計費情況。
圖7示出了本發(fā)明中FBC系統(tǒng)結(jié)構(gòu)示意圖，如圖7所示，在本發(fā)明的FBC系統(tǒng)結(jié)構(gòu)中，將CRF和CCF兩個邏輯功能實體的功能集成在OCS 70中實現(xiàn)，這樣，現(xiàn)有中連接CRF與CCF之間的Ry接口變?yōu)閮?nèi)部接口，以下將CRF和CCF集成后的邏輯功能實體稱為CRF-CCF 701，SCP 201和CRF-CCF 701組成了本發(fā)明中的OCS 70，SCP 201與CRF-CCF 701之間的交互遵循CAMEL規(guī)范，SCP 201與CRF-CCF 701之間可傳送在線計費控制信息。CRF-CCF 701可通過對現(xiàn)有的CCF進行增強，以使其能夠?qū)崿F(xiàn)CRF的功能。CRF-CCF 701通過Rx接口與AF 204互通，AF 204可通過Rx接口向CRF提供用于選擇計費規(guī)則的輸入信息。CRF-CCF 701通過Gy+Gx接口與TPF 205互通，該Gy+Gx接口上需要實現(xiàn)計費規(guī)則的請求和提供，用戶信用的請求和提供，以及計費規(guī)則觸發(fā)事件和重鑒權(quán)事件的提供和觸發(fā)等功能。
由于在線計費時，計費規(guī)則觸發(fā)事件和重鑒權(quán)事件都是由CRF-CCF 701請求TPF 205對指定事件進行監(jiān)控的，因此，可將計費規(guī)則觸發(fā)事件和重鑒權(quán)事件合并下發(fā)，即CRF-CCF 701向TPF 205提供計費規(guī)則觸發(fā)事件和重鑒權(quán)事件的合集，以下將該計費規(guī)則觸發(fā)事件和重鑒權(quán)事件的合集稱為計費觸發(fā)事件(Charging Trigger)。
TPF 205監(jiān)測到計費觸發(fā)事件發(fā)生后，通知CRF-CCF 701當(dāng)前發(fā)生的計費觸發(fā)事件，并向CRF-CCF 701提供用戶已經(jīng)使用的信用；CRF-CCF 701根據(jù)當(dāng)前發(fā)生的計費觸發(fā)事件，選擇計費規(guī)則，并且重新對用戶的信用進行計算，然后向TPF 205返回選定的計費規(guī)則和重新計算的用戶信用。
CRF-CCF 701可進一步向TPF 205指明計費觸發(fā)事件中包括的重鑒權(quán)事件，這樣，TPF 205監(jiān)測到計費觸發(fā)事件發(fā)生后，判斷發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件。如果TPF 205確定發(fā)生的計費觸發(fā)事件為重鑒權(quán)事件，則TPF 205通知CRF-CCF 701當(dāng)前發(fā)生的計費觸發(fā)事件，并向CRF-CCF701提供用戶已經(jīng)使用的信用，請求CRF-CCF 701對用戶進行重鑒權(quán)；CRF-CCF 701根據(jù)當(dāng)前發(fā)生的計費觸發(fā)事件，選擇計費規(guī)則，并且重新對用戶的信用進行計算，然后向TPF 205返回選定的計費規(guī)則和重新計算的用戶信用。如果TPF 205確定發(fā)生的計費觸發(fā)事件不是重鑒權(quán)事件，則TPF 205僅通知CRF-CCF 701當(dāng)前發(fā)生的計費觸發(fā)事件；CRF-CCF 701根據(jù)當(dāng)前發(fā)生的計費觸發(fā)事件，選擇計費規(guī)則，然后向TPF 205返回選定的計費規(guī)則。
另外，CRF-CCF 701可不向TPF 205指明計費觸發(fā)事件中包括的重鑒權(quán)事件，這樣，TPF 205監(jiān)測到計費觸發(fā)事件發(fā)生后，通知CRF-CCF 701當(dāng)前發(fā)生的計費觸發(fā)事件，并向CRF-CCF 701提供用戶已經(jīng)使用的信用，CRF-CCF 701判斷當(dāng)前發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則CRF-CCF 701根據(jù)當(dāng)前發(fā)生的計費觸發(fā)事件，選擇計費規(guī)則，并且重新對用戶的信用進行計算，然后向TPF 205返回選定的計費規(guī)則和重新計算的用戶信用；否則，CRF-CCF 701僅根據(jù)當(dāng)前發(fā)生的計費觸發(fā)事件，選擇計費規(guī)則，然后向TPF 205返回選定的計費規(guī)則。
具體實現(xiàn)過程中，可在同一消息中實現(xiàn)計費規(guī)則請求和信用請求，例如，TPF 205向CRF-CCF 701發(fā)送計費規(guī)則及信用請求(Charging Rule and CreditRequest)，該計費規(guī)則及信用請求中可攜帶供CRF-CCF 701選擇計費規(guī)則的輸入信息，以及供CRF-CCF 701確定用戶信用的輸入信息，如，用戶和終端的相關(guān)信息，如MSISDN、IMSI等，承載特性，如QoS信息，網(wǎng)絡(luò)相關(guān)信息，如MNC、MCC等。
對于CRF-CCF 701向TPF 205提供的計費規(guī)則、提供的信用、以及提供的計費觸發(fā)事件也可在同一消息中實現(xiàn)，如CRF-CCF 701向TPF 205發(fā)送計費規(guī)則及信用響應(yīng)(Charging Rule and Credit Response)，該計費規(guī)則及信用響應(yīng)中攜帶有CRF-CCF 701選定的計費規(guī)則、用戶信用，該計費規(guī)則及信用響應(yīng)中還可攜帶計費觸發(fā)事件。
圖8A示出了本發(fā)明中承載建立時請求計費規(guī)則和用戶信用的處理流程圖，如圖8A所示，承載建立時請求計費規(guī)則和用戶信用的處理過程包括以下步驟步驟801A與步驟301A相同。
步驟802A～步驟803ATPF收到承載建立請求后，向CRF-CCF發(fā)送計費規(guī)則及信用請求，該計費規(guī)則及信用請求中攜帶有供CRF-CCF確定計費規(guī)則的輸入信息和確定用戶信用的輸入信息，TPF可根據(jù)UE標(biāo)識尋址到相應(yīng)CRF-CCF，也可根據(jù)自身配置的數(shù)據(jù)尋址到相應(yīng)CRF-CCF，還可根據(jù)承載建立時UE提供的接入訪問點尋址到相應(yīng)CRF-CCF。CRF-CCF收到計費規(guī)則請求后，判斷該UE用戶是否為簽約的網(wǎng)絡(luò)用戶，如果是，即該CRF-CCF為UE的歸屬CRF-CCF，則執(zhí)行步驟806A；否則，CRF-CCF可根據(jù)UE標(biāo)識獲取UE歸屬CRF-CCF的地址信息，然后執(zhí)行804A。
步驟804A～步驟805ACRF-CCF向TPF返回計費規(guī)則及信用響應(yīng)，該計費規(guī)則及信用響應(yīng)中攜帶有UE歸屬的CRF-CCF的地址信息。TPF收到計費規(guī)則及信用響應(yīng)后，根據(jù)收到的CRF-CCF地址信息向該CRF-CCF發(fā)送計費規(guī)則及信用請求，該計費規(guī)則及信用請求中攜帶有供CRF-CCF確定計費規(guī)則和用戶信用的輸入信息。
步驟806A～步驟807ACRF-CCF收到計費規(guī)則及信用請求后，根據(jù)該計費規(guī)則及信用請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，另外，CRF-CCF可進一步判斷當(dāng)前計費方式是否應(yīng)為在線計費，如判斷UE用戶是否為預(yù)付費用戶，或是判斷UE用戶是否使用預(yù)付費業(yè)務(wù)。如果CRF-CCF判斷出當(dāng)前計費方式應(yīng)為在線計費，則CRF-CCF根據(jù)選定的計費規(guī)則計算用戶信用，并向TPF返回計費規(guī)則及信用響應(yīng)，該計費規(guī)則及信用響應(yīng)中攜帶有計費規(guī)則操作指示、選定的計費規(guī)則和計算的用戶信用，如果CRF-CCF未計算出用戶的信用，則該計費規(guī)則及信用響應(yīng)中可攜帶有差錯原因值。計費規(guī)則及信用響應(yīng)中可進一步攜帶有計費觸發(fā)事件，并可進一步指明TPF計費觸發(fā)事件中所包括的重鑒權(quán)事件。如果CRF-CCF判斷出當(dāng)前計費方式不應(yīng)為在線計費，則CRF-CCF向TPF提供的計費規(guī)則及信用響應(yīng)中不攜帶有計算的用戶信用和重鑒權(quán)事件信息。
步驟808ATPF收到計費規(guī)則及信用響應(yīng)后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即建立計費規(guī)則；并對計費規(guī)則及信用請求中攜帶的計費觸發(fā)事件進行存儲。
步驟809ATPF向UE返回承載建立響應(yīng)，如果為在線計費，并且計費規(guī)則及信用請求中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程；如果計費規(guī)則及信用請求中沒有攜帶有用戶的信用，則TPF拒絕UE發(fā)起的承載建立請求。如果為離線計費，則TPF直接接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程。
由于在承載建立過程，TPF已經(jīng)獲取到UE歸屬的CRF-CCF的地址信息，因此，在后續(xù)進行計費規(guī)則及信用請求的過程中均與UE歸屬的CRF-CCF進行交互，這樣，后續(xù)描述中涉及的CRF-CCF均為UE歸屬的CRF-CCF。
圖8B示出了本發(fā)明中承載修改時請求計費規(guī)則和用戶信用的處理流程圖，如圖8B所示，承載修改時請求計費規(guī)則和用戶信用的處理過程包括以下步驟步驟801B與步驟301B相同。
步驟802B承載修改可能會觸發(fā)計費觸發(fā)事件，因此，TPF收到承載修改請求后，將承載修改事件與存儲的計費觸發(fā)事件進行匹配，如果能夠匹配，則執(zhí)行步驟803B；否則，結(jié)束當(dāng)前流程。
步驟803BTPF向CRF-CCF發(fā)送計費規(guī)則及信用請求，該計費規(guī)則及信用請求中攜帶有供CRF-CCF確定計費規(guī)則和用戶信用的輸入信息，該計費規(guī)則及信用請求中可進一步攜帶有當(dāng)前發(fā)生的計費觸發(fā)事件，并可進一步向TPF指明計費觸發(fā)事件中包括的重鑒權(quán)事件。
步驟804B～步驟806B與步驟806A～步驟808A相同。
步驟807BTPF向UE返回承載修改響應(yīng)，對于在線計費，如果計費規(guī)則及信用請求中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程，如果計費規(guī)則及信用請求中攜帶有差錯原因值，則TPF拒絕UE發(fā)起的承載修改請求；對于離線計費，TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程。
如果CRF-CCF向TPF指明了計費觸發(fā)事件中包括的重鑒權(quán)事件，則TPF監(jiān)測到計費觸發(fā)事件發(fā)生后，判斷發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則TPF向CRF-CCF發(fā)送的計費規(guī)則及信用請求中攜帶有CRF-CCF確定用戶信用的輸入信息，如用戶的剩余信用，否則，TPF向CRF-CCF發(fā)送的計費規(guī)則及信用請求中不攜帶CRF-CCF確定用戶信用的輸入信息；CRF-CCF根據(jù)計費規(guī)則及信用請求中是否攜帶有確定用戶信用的輸入信息，確定是否計算用戶信用。
如果CRF-CCF未向TPF指明計費觸發(fā)事件中包括的重鑒權(quán)事件，并且由CRF-CCF收到TPF上報的當(dāng)前發(fā)生的計費觸發(fā)事件后，由CRF-CCF判斷當(dāng)前發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件時，此時TPF監(jiān)測到計費觸發(fā)事件發(fā)生后，向CRF-CCF發(fā)送的計費規(guī)則及信用請求中攜帶有CRF-CCF確定用戶信用的輸入信息，如用戶的剩余信用。由CRF-CCF根據(jù)計費觸發(fā)事件的判斷結(jié)果確定是否計算用戶信用，如果當(dāng)前發(fā)生的計費觸發(fā)事件為重鑒權(quán)事件，則CRF-CCF計算用戶信用并提供給TPF；如果當(dāng)前發(fā)生的計費觸發(fā)事件不是重鑒權(quán)事件，則CRF-CCF不重新計算用戶信用，向TPF返回的計費規(guī)則及信用響應(yīng)中直接攜帶原來的信用。
圖8C示出了本發(fā)明中承載刪除時請求計費規(guī)則和用戶信用的處理流程圖，如圖8C所示，承載刪除時請求計費規(guī)則和用戶信用的處理過程包括以下步驟步驟801C與步驟301C相同。
步驟802C～步驟804CTPF收到承載刪除請求后，向CRF-CCF發(fā)送計費規(guī)則及信用請求，該計費規(guī)則及信用請求中攜帶有供CRF-CCF確定計費規(guī)則和用戶的剩余信用。CRF-CCF收到計費規(guī)則及信用請求后，根據(jù)該計費規(guī)則及信用請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，并對用戶的剩余信用進行處理，然后向TPF返回計費規(guī)則及信用響應(yīng)，該計費規(guī)則及信用響應(yīng)中攜帶有選定的計費規(guī)則。
步驟805C～步驟806CTPF收到計費規(guī)則及信用響應(yīng)后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，即刪除計費規(guī)則，然后向UE返回承載刪除響應(yīng)，接受UE發(fā)起的承載刪除請求，并繼續(xù)后續(xù)的承載刪除流程。
另外，CRF-CCF也可主動向TPF發(fā)送計費規(guī)則，如當(dāng)UE與AF進行業(yè)務(wù)數(shù)據(jù)傳輸?shù)倪^程中，CRF-CCF收到AF的計費規(guī)則輸入信息后，根據(jù)AF提供的計費規(guī)則輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，然后主動向TPF下發(fā)選定的計費規(guī)則。對于AF向CRF-CCF提供計費規(guī)則輸入信息的具體實現(xiàn)過程如圖9所示步驟901～步驟902AF向CRF-CCF發(fā)送應(yīng)用/業(yè)務(wù)計費相關(guān)信息。CRF-CCF收到應(yīng)用/業(yè)務(wù)計費相關(guān)信息后，向AF返回響應(yīng)，通知AF已收到其發(fā)送的計費規(guī)則輸入信息。
AF可根據(jù)UE標(biāo)識尋址到相應(yīng)CRF-CCF，也可根據(jù)自身配置的數(shù)據(jù)尋址到相應(yīng)CRF-CCF，還可根據(jù)獲取的CRF-CCF地址信息尋址到相應(yīng)CRF-CCF。
另外，AF向CRF-CCF提供輸入信息后，CRF-CCF會根據(jù)AF的輸入信息判斷是否需要觸發(fā)重鑒權(quán)流程，如果是，如CRF-CCF根據(jù)AF提供的輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則后，發(fā)現(xiàn)計費規(guī)則中的計費鍵指示的費率發(fā)生了變化，需要應(yīng)用新的費率對用戶信用進行計算，此時，需要對用戶進行重鑒權(quán)，則CRF-CCF向TPF發(fā)送重鑒權(quán)指示，要求TPF提供確定用戶信用的輸入信息，如用戶的剩余信用，否則，即不需要觸發(fā)重鑒權(quán)流程，直接向TPF提供根據(jù)來自AF的輸入信息選定的計費規(guī)則，具體實現(xiàn)過程如圖10所示步驟A1～步驟A2AF向CRF-CCF發(fā)送AF輸入信息(AF Input)，CRF-CCF收到AF輸入信息后，向AF返回AF輸入信息響應(yīng)(AF Input Ack)，通知已收到其發(fā)送的輸入信息。
步驟A3CRF-CCF根據(jù)收到的AF輸入信息，判斷是否需要進行重鑒權(quán)流程，如果是，則執(zhí)行步驟A4a；否則，執(zhí)行步驟A4b。
步驟A4aCRF-CCF可要求TPF向其返回用戶的信用使用情況，以對用戶信用進行有效控制，即CRF-CCF向TPF發(fā)送返回信用請求(ReturnCredit Request)，要求TPF向其提供用于確定用戶信用的輸入信息，如返回用戶的信用使用情況，即剩余信用。
步驟A5aTPF收到返回信用請求后，向CRF-CCF發(fā)送計費規(guī)則及信用請求，該計費規(guī)則及信用請求中攜帶有供CRF-CCF確定計費規(guī)則和用戶信用的輸入信息，如用戶的剩余信用。
步驟A6a～步驟A8a與步驟806A～步驟808A相同。
步驟A4b～步驟A6bCRF根據(jù)AF輸入信息，也可根據(jù)來自TPF的輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和計費規(guī)則操作指示。TPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
1.一種基于分組數(shù)據(jù)流計費的系統(tǒng)，其特征在于，該系統(tǒng)包括承載數(shù)據(jù)業(yè)務(wù)流的TPF與用于選擇計費規(guī)則及進行信用控制的CRF-CCF相連，用于傳送計費及信用控制信息。
2.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述計費及信用控制信息為TPF向CRF-CCF發(fā)送的計費規(guī)則和/或用戶信用請求、以及CRF-CCF向TPF提供的計費規(guī)則和/或用戶信用。
3.根據(jù)權(quán)利要求1或2所述的系統(tǒng)，其特征在于，所述CRF-CCF進一步用于向TPF提供計費觸發(fā)事件，所述TPF用于在計費觸發(fā)事件發(fā)生時向CRF-CCF上報。
4.根據(jù)權(quán)利要求3所述的系統(tǒng)，其特征在于，所述計費觸發(fā)事件為計費規(guī)則觸發(fā)事件，或為重鑒權(quán)事件，或為以上二者的組合。
5.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述相連為通過Gy+Gx接口相連。
6.根據(jù)權(quán)利要求1所述的系統(tǒng)，其特征在于，所述CRF-CCF進一步與用于提供業(yè)務(wù)使用信息的AF相連，用于傳送確定計費規(guī)則的輸入信息。
7.根據(jù)權(quán)利要求6所述的系統(tǒng)，其特征在于，所述相連為通過Rx接口相連。
8.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含TPF向CRF-CCF發(fā)送計費規(guī)則及信用請求，CRF-CCF收到計費規(guī)則及信用請求后，向TPF返回計費規(guī)則和/或用戶信用。
9.根據(jù)權(quán)利要求8所述的方法，其特征在于，所述計費規(guī)則及信用請求中攜帶有用于選擇計費規(guī)則的輸入信息，或計費觸發(fā)事件，或用戶已經(jīng)使用的信用，或用戶的剩余信用，或以上任意的組合。
10.根據(jù)權(quán)利要求8所述的方法，其特征在于，所述向TPF返回計費規(guī)則和/或用戶信用進一步包括提供計費觸發(fā)事件。
11.根據(jù)權(quán)利要求8所述的方法，其特征在于，承載建立時，CRF-CCF收到計費規(guī)則及信用請求之后，進一步包括CRF-CCF判斷UIE用戶是否為簽約的網(wǎng)絡(luò)用戶，如果是，則直接向TPF返回計費規(guī)則和/或用戶信用；否則，向TPF提供UE歸屬的CRF-CCF的地址信息，TPF根據(jù)收到的CRF-CCF地址信息，向該CRF-CCF發(fā)送計費規(guī)則及信用請求，UE歸屬的CRF-CCF收到計費規(guī)則及信用請求后，向TPF返回計費規(guī)則和/或用戶信用。
12.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含CRF-CCF向TPF提供計費觸發(fā)事件，TPF監(jiān)測到計費觸發(fā)事件發(fā)生時，向CRF-CCF上報。
13.根據(jù)權(quán)利要求12所述的方法，其特征在于，所述計費觸發(fā)事件為計費規(guī)則觸發(fā)事件，或為重鑒權(quán)事件，或為以上二者的組合。
14.根據(jù)權(quán)利要求12或13所述的方法，其特征在于，所述向CRF-CCF上報為向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求。
15.根據(jù)權(quán)利要求14所述的方法，其特征在于，所述計費觸發(fā)事件包括計費規(guī)則觸發(fā)事件和重鑒權(quán)事件，向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求之前，進一步包括TPF判斷發(fā)生的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則向CRF-CCF發(fā)送攜帶有重鑒權(quán)事件的計費規(guī)則及信用請求，該計費規(guī)則及信用請求中進一步攜帶有用戶信用使用情況信息。
16.根據(jù)權(quán)利要求14所述的方法，其特征在于，所述計費觸發(fā)事件包括計費規(guī)則觸發(fā)事件和重鑒權(quán)事件，所述計費規(guī)則及信用請求中進一步攜帶有用戶信用使用情況信息，所述向CRF-CCF發(fā)送攜帶有計費觸發(fā)事件的計費規(guī)則及信用請求之后，進一步包括CRF-CCF收到計費規(guī)則及信用請求后，判斷TPF上報的計費觸發(fā)事件是否為重鑒權(quán)事件，如果是，則CRF-CCF選定計費規(guī)則并重新計算用戶信用，然后將計費規(guī)則和用戶信用提供給TPF；否則，CRF-CCF選定計費規(guī)則并提供給TPF。
17.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含AF向CRF-CCF提供用于選擇計費規(guī)則的輸入信息。
18.根據(jù)權(quán)利要求17所述的方法，其特征在于，該方法進一步包括CRF-CCF向AF返回表明收到所述輸入信息的響應(yīng)。
19.一種基于分組數(shù)據(jù)流計費的處理方法，其特征在于，該方法包含CRF-CCF要求TPF返回用戶信用的使用情況，TPF向CRF-CCF返回用戶信用使用情況信息。
全文摘要
本發(fā)明公開了一種基于分組數(shù)據(jù)流計費的系統(tǒng)及處理方法，在OCS中實現(xiàn)CRF功能，這樣，觸發(fā)事件可同重鑒權(quán)事件合并實現(xiàn)，統(tǒng)一了TPF的事件上報機制，并且本發(fā)明還描述了基于實現(xiàn)CRF功能的OCS結(jié)構(gòu)下的各種流程，包括TPF與CRF－CCF之間交互計費規(guī)則及用戶信用的流程，CRF－CCF與TPF之間基于計費觸發(fā)事件的交互流程，CRF－CCF與AF之間交互相關(guān)信息的流程，以及CRF－CCF與TPF交互用戶信用使用情況的流程，使得TPF與OCS之間以及TPF與CRF之間的處理流程更為清晰。
文檔編號H04L12/14GK1787442SQ20041009854
公開日2006年6月14日 申請日期2004年12月9日 優(yōu)先權(quán)日2004年12月9日
發(fā)明者段小琴 申請人:華為技術(shù)有限公司