專利名稱：一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分組數(shù)據(jù)計費領(lǐng)域，特別是指一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法。
背景技術(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ù)訪問點標識(NSAPI，Network Layer Service Access Point Identifier)、PDP類型、接入點名稱(APN，Access Point Name)、要求的服務(wù)質(zhì)量(QoS)參數(shù)、事務(wù)標識(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和網(wǎng)關(guān)通用分組無線業(yè)務(wù)支持節(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尋址到相應(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標識某個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 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，然后分配計費標識(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中插入用于標識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)過程可見，當前的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 Project)目前正在討論如何實現(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和計費采集功能實體(CCF，Charging Collection Function)208互通。
TPF 205承載IP數(shù)據(jù)流，當IP數(shù)據(jù)流的承載建立時，TPF 205通過Gx接口向CRF 203發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有與用戶和MS相關(guān)的信息、承載特性以及與網(wǎng)絡(luò)相關(guān)的信息等，其中與用戶和MS相關(guān)的信息可為移動臺國際號碼(MSISDN)、國際移動用戶標識(IMSI)等，與網(wǎng)絡(luò)相關(guān)的信息可為移動網(wǎng)絡(luò)編碼(MNC)、移動國家碼(MCC)等。另外，由于在IP數(shù)據(jù)流傳輸過程中，會對承載進行修改，如對QoS參數(shù)進行重新協(xié)商，當用戶使用同一業(yè)務(wù)的QoS參數(shù)不同時，計費規(guī)則可能不同，如QoS參數(shù)下降相應(yīng)的費率也下降。此時，TPF 205可在承載修改時，重新向CRF 203發(fā)送計費規(guī)則請求，請求新的計費規(guī)則；CRF 203根據(jù)TPF 205提供的上述輸入信息選擇適當?shù)挠嬞M規(guī)則，并向TPF 205返回選定的計費規(guī)則，計費規(guī)則中包括計費機制、計費類型、計費鍵、業(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ù)過濾器用于指示TPF 205對哪些IP數(shù)據(jù)流進行過濾，然后TPF 205根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進行計費。業(yè)務(wù)數(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ī)則。
CRF 203除了根據(jù)TPF 205提供的輸入信息選擇適當?shù)挠嬞M規(guī)則之外，CRF 203還可根據(jù)AF 204或OCS 206的輸入信息選擇適當?shù)挠嬞M規(guī)則，如AF 204通知CRF 203用戶當前使用的業(yè)務(wù)類型，CRF 203根據(jù)該業(yè)務(wù)類型選擇相應(yīng)的計費規(guī)則。
OCS 206由SCP 201和CCF(Service Data Flow Based Credit ControlFunction)202兩個功能實體組成，其中，CCF(Service Data Flow Based CreditControl Function)202是執(zhí)行信用控制的功能實體，僅應(yīng)用于在線計費系統(tǒng)，可通過在現(xiàn)有的OCS 206中增加新的功能來實現(xiàn)。在在線計費過程中，CCF(Service Data Flow Based Credit Control Function)202對用戶信用進行管理和控制，當用戶使用業(yè)務(wù)時，CCF(Service Data Flow Based Credit ControlFunction)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ù)用戶當前所在位置確定計費費率，并根據(jù)該計費費率計算用戶的信用；當用戶移動至另一位置時，如SGSN發(fā)生變化，TPF 205需要根據(jù)重鑒權(quán)事件中的SGSN變化事件，向OCS 206上報SGSN變化事件的發(fā)生，OCS 206根據(jù)用戶更新后的當前所在位置重新確定計費費率，并重新計算用戶的信用。又例如，當OCS 206根據(jù)用戶使用業(yè)務(wù)的當前QoS參數(shù)確定計費費率，當用戶對QoS參數(shù)進行修改，TPF 205需要根據(jù)重鑒權(quán)事件中的承載修改事件，向OCS 206上報承載修改事件的發(fā)生，OCS 206根據(jù)用戶修改后的QoS參數(shù)確定計費費率，并重新計算用戶的信用。規(guī)范中定義的重鑒權(quán)事件可包括允許信用過期(credit authorization lifetime expiry)事件，用戶空閑狀態(tài)超時(idle timeout)事件，計費規(guī)則改變(charging rule ischanged)事件，還可包括一些GPRS事件，如SGSN變化(SGSN change)事件，QoS參數(shù)改變(QoS changes)事件，無線接入技術(shù)(RAT)類型改變(RAT type change)事件。
對應(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定義了承載建立時，在線計費情況下，TPF向CRF請求計費規(guī)則的處理過程如圖3所示步驟301用戶設(shè)備(UE)向TPF發(fā)送承載建立請求(Establish BearerService Request)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Create PDP ContextRequest。
步驟302TPF收到承載建立請求后，向CRF發(fā)送計費規(guī)則請求(RequestCharging Rules)，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟303～步驟304CRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則(Provision Charging Rules)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則和計費規(guī)則操作指示。
步驟305TPF收到提供計費規(guī)則后，根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作。
步驟306TPF向OCS發(fā)送信用請求(Credit Request)，向OCS請求用戶的信用。
步驟307OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)(Credit Response)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用，如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。
步驟308TPF收到信用響應(yīng)后，向UE返回承載建立響應(yīng)(EstablishBearer Service Accept)，如果信用響應(yīng)中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程；如果信用響應(yīng)中未攜帶有用戶的信用，則TPF拒絕UE發(fā)起的承載建立請求。
對于在線計費情況下，承載修改會觸發(fā)TPF請求OCS進行重鑒權(quán)的流程，具體實現(xiàn)過程如圖4所示步驟401UE向TPF發(fā)送承載修改請求(Modify Bearer ServiceRequest)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到PDP Context更新請求(UpdatePDP Context Request)。
步驟402TPF收到承載修改請求后，將承載修改事件與預(yù)先存儲的重鑒權(quán)事件進行匹配，如果能夠匹配，則執(zhí)行步驟403，否則，結(jié)束當前重鑒權(quán)流程。
步驟403TPF向OCS發(fā)送信用控制請求(Credit Control Request)，該信用控制請求中攜帶有用戶的剩余信用和相關(guān)的計費規(guī)則信息，請求OCS重新計算用戶的信用。TPF向OCS提供的相關(guān)計費規(guī)則信息可來自CRF。
步驟404OCS收到信用控制請求后，重新對用戶的信用進行計算，然后向TPF返回信用控制響應(yīng)(Credit Control Answer)，如果OCS計算出用戶的信用，則該信用控制響應(yīng)中攜帶有OCS重新計算的用戶信用，如果OCS未計算出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。
步驟405TPF收到信用控制響應(yīng)后，向UE返回承載修改響應(yīng)(ModifyBearer Service Accept)，如果信用控制響應(yīng)中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程；如果信用控制響應(yīng)中未攜帶有用戶的信用，則拒絕UE發(fā)起的承載修改請求。
目前，規(guī)范中雖然定義了在線計費情況下，TPF在承載修改時，可根據(jù)重鑒權(quán)事件的發(fā)生向OCS發(fā)起重鑒權(quán)流程，請求OCS重新計算用戶的信用并向TPF返回，但是，目前規(guī)范中未提到TPF中重鑒權(quán)事件的來源，導(dǎo)致重鑒權(quán)流程實現(xiàn)上的不確定性。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法，明確重鑒權(quán)流程的實現(xiàn)。
為了達到上述目的，本發(fā)明提供了一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法，該方法包含以下步驟A、TPF獲取重鑒權(quán)事件信息；B、TPF監(jiān)測到重鑒權(quán)事件發(fā)生時，請求OCS對用戶進行重鑒權(quán)。
所述步驟A為TPF中預(yù)先存儲重鑒權(quán)事件。
所述步驟A為TPF接收OCS提供的重鑒權(quán)事件信息。
所述重鑒權(quán)事件信息為重鑒權(quán)事件。
所述步驟A為TPF中預(yù)先存儲重鑒權(quán)事件，并接收OCS提供的重鑒權(quán)事件信息。
所述重鑒權(quán)事件信息為重鑒權(quán)事件標識，或重鑒權(quán)事件，或以上二者的組合，或內(nèi)容為空的重鑒權(quán)事件信息。
所述重鑒權(quán)事件信息在承載建立時，OCS向TPF返回信用響應(yīng)時提供；或承載修改時，OCS向TPF返回信用控制響應(yīng)時提供。
所述步驟B進一步包括TPF向OSC提供當前觸發(fā)重鑒權(quán)流程的重鑒權(quán)事件。
所述步驟B之后進一步包括OCS重新對用戶的信用進行計算，并向TPF返回重新計算后的用戶信用。
根據(jù)本發(fā)明提出的方法，TPF中預(yù)先存儲重鑒權(quán)事件，或由OCS向TPF提供重鑒權(quán)事件，使得TPF能夠準確獲知需要監(jiān)測的重鑒權(quán)事件；TPF對重鑒權(quán)事件的發(fā)生進行監(jiān)測，重鑒權(quán)事件發(fā)生時，TPF請求OCS對用戶進行重鑒權(quán)，OCS重新對用戶信用進行計算，并向TPF返回重新計算后的用戶信用。這樣，通過增加了重鑒權(quán)事件的提供方式，使得基于分組數(shù)據(jù)流計費的重鑒權(quán)流程的實現(xiàn)更為明確和清晰。另外，TPF請求OCS對用戶進行重鑒權(quán)時，可進一步向OCS提供觸發(fā)當前重鑒權(quán)流程的重鑒權(quán)事件，使得TPF與OCS之間關(guān)于重鑒權(quán)的信息交互更為合理和完善。


圖1示出了PDP Context激活、數(shù)據(jù)傳輸、去激活流程圖；圖2A示出了支持在線計費的FBC系統(tǒng)結(jié)構(gòu)圖；圖2B示出了支持離線計費的FBC系統(tǒng)結(jié)構(gòu)圖；圖3示出了現(xiàn)有技術(shù)中在線計費承載建立時流程圖；圖4示出了現(xiàn)有技術(shù)中承載修改時TPF請求OCS進行重鑒權(quán)流程圖；圖5示出了本發(fā)明中在線計費承載建立時流程圖；圖6示出了本發(fā)明中承載修改時TPF請求OCS進行重鑒權(quán)一實施例流程圖；
圖7示出了本發(fā)明中承載修改時TPF請求OCS進行重鑒權(quán)另一實施例流程圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，TPF中預(yù)先存儲重鑒權(quán)事件，或由OCS向TPF提供重鑒權(quán)事件，由TPF對重鑒權(quán)事件的發(fā)生進行監(jiān)測，重鑒權(quán)事件發(fā)生時，TPF請求OCS對用戶進行重鑒權(quán)，OCS重新對用戶信用進行計算，并向TPF返回重新計算后的用戶信用。
圖5示出了本發(fā)明中在線計費承載建立時流程圖，如圖5所示，在線計費承載建立時的具體實現(xiàn)過程包括以下步驟步驟501～步驟506與步驟301～步驟306基本相同。
步驟507OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)(Credit Response)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用，并進一步攜帶有重鑒權(quán)事件信息，要求TPF對相應(yīng)重鑒權(quán)事件的發(fā)生進行監(jiān)測。如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值。本發(fā)明中所述的重鑒權(quán)事件信息可為重鑒權(quán)事件，也可為重鑒權(quán)事件標識，還可為重鑒權(quán)事件和重鑒權(quán)事件標識的組合，甚至還可為空。
如果TPF中未存儲重鑒權(quán)事件，則OCS向TPF提供的重鑒權(quán)事件信息為重鑒權(quán)事件，要求TPF對OCS提供的重鑒權(quán)事件的發(fā)生進行監(jiān)測。如果TPF中預(yù)先存儲有重鑒權(quán)事件，則重鑒權(quán)事件信息可為重鑒權(quán)事件標識，要求TPF對對應(yīng)于相應(yīng)標識的重鑒權(quán)事件的發(fā)生進行監(jiān)測；重鑒權(quán)事件信息也可為重鑒權(quán)事件和重鑒權(quán)事件標識的組合，要求TPF對OCS提供的重鑒權(quán)事件和對應(yīng)于相應(yīng)標識的重鑒權(quán)事件的發(fā)生進行監(jiān)測；重鑒權(quán)事件信息還可為空，TPF根據(jù)預(yù)先設(shè)定，獲知OCS要求其對所有預(yù)先存儲的重鑒權(quán)事件的發(fā)生進行監(jiān)測，或不對任何重鑒權(quán)事件的發(fā)生進行監(jiān)測。
在TPF中預(yù)先存儲有重鑒權(quán)事件時，重鑒權(quán)事件信息也可僅為重鑒權(quán)事件，TPF根據(jù)預(yù)先設(shè)定，獲知OCS要求其對OCS提供的重鑒權(quán)事件和所有預(yù)先存儲的重鑒權(quán)事件的發(fā)生進行監(jiān)測，或僅對OCS提供的重鑒權(quán)事件的發(fā)生進行監(jiān)測。
步驟508TPF收到信用響應(yīng)后，如果該信用響應(yīng)中攜帶有重鑒權(quán)事件信息，則根據(jù)重鑒權(quán)事件信息，開始對相應(yīng)重鑒權(quán)事件的發(fā)生進行監(jiān)測，如果監(jiān)測到相應(yīng)重鑒權(quán)事件發(fā)生，則請求OCS對用戶進行重鑒權(quán)。
步驟509與步驟308基本相同。
步驟508與步驟509之間沒有明顯的先后順序。
本發(fā)明中，OCS可以通過在信用響應(yīng)中攜帶重鑒權(quán)事件信息，也可將重鑒權(quán)事件信息通過攜帶在獨立的消息中發(fā)送給TPF。
圖6示出了本發(fā)明中承載修改時TPF請求OCS進行重鑒權(quán)一實施例流程圖，如圖6所示，本實施例中承載修改時TPF請求OCS進行重鑒權(quán)的實現(xiàn)過程包括以下步驟步驟601～步驟602與步驟401～步驟402基本相同。
步驟603TPF向OCS發(fā)送信用控制請求(Credit Control Request)，該信用控制請求中攜帶有用戶的剩余信用和相關(guān)的計費規(guī)則信息，請求OCS重新計算用戶的信用。TPF向OCS提供的相關(guān)計費規(guī)則信息可來自于CRF。信用控制請求中可進一步攜帶有當前發(fā)生的重鑒權(quán)事件，用以通知OCS當前觸發(fā)重鑒權(quán)流程的具體的重鑒權(quán)事件。
步驟604～步驟605與步驟404～步驟405基本相同。
圖7示出了本發(fā)明中承載修改時TPF請求OCS進行重鑒權(quán)另一實施例流程圖，如圖7所示，本實施例中承載修改時TPF請求OCS進行重鑒權(quán)的實現(xiàn)過程包括以下步驟步驟701～步驟702與步驟401～步驟402基本相同。
步驟703與步驟603基本相同。
步驟704OCS收到信用控制請求后，重新對用戶的信用進行計算，然后向TPF返回信用控制響應(yīng)，如果OCS計算出用戶的信用，則該信用控制響應(yīng)中攜帶有OCS重新計算后的用戶信用，如果OCS未計算出用戶的信用，如用戶信用不足時，則該信用響應(yīng)中可攜帶有差錯原因值。信用控制響應(yīng)中可進一步攜帶有重鑒權(quán)事件信息，要求TPF更新監(jiān)測的重鑒權(quán)事件。
如果TPF中未存儲重鑒權(quán)事件，則OCS向TPF提供的重鑒權(quán)事件信息為重鑒權(quán)事件，要求TPF對OCS提供的重鑒權(quán)事件的發(fā)生進行監(jiān)測。如果TPF中預(yù)先存儲有重鑒權(quán)事件，則重鑒權(quán)事件信息可為重鑒權(quán)事件標識，要求TPF對對應(yīng)于相應(yīng)標識的重鑒權(quán)事件的發(fā)生進行監(jiān)測；重鑒權(quán)事件信息也可為重鑒權(quán)事件和重鑒權(quán)事件標識的組合，要求TPF對OCS提供的重鑒權(quán)事件和對應(yīng)于相應(yīng)標識的重鑒權(quán)事件的發(fā)生進行監(jiān)測；重鑒權(quán)事件信息還可為空，TPF根據(jù)預(yù)先設(shè)定，獲知OCS要求其對所有預(yù)先存儲的重鑒權(quán)事件的發(fā)生進行監(jiān)測，或不對任何重鑒權(quán)事件的發(fā)生進行監(jiān)測。
在TPF中預(yù)先存儲有重鑒權(quán)事件時，重鑒權(quán)事件信息也可僅為重鑒權(quán)事件，TPF根據(jù)預(yù)先設(shè)定，獲知OCS要求其對OCS提供的重鑒權(quán)事件和所有預(yù)先存儲的重鑒權(quán)事件的發(fā)生進行監(jiān)測，或僅對OCS提供的重鑒權(quán)事件的發(fā)生進行監(jiān)測。
步驟705TPF收到信用控制響應(yīng)后，如果該信用控制響應(yīng)中攜帶有重鑒權(quán)事件信息，則根據(jù)重鑒權(quán)事件信息，開始對相應(yīng)重鑒權(quán)事件的發(fā)生進行監(jiān)測，如果監(jiān)測到相應(yīng)重鑒權(quán)事件發(fā)生，則請求OCS對用戶進行重鑒權(quán)。
步驟706與步驟405基本相同。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
1.一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法，其特征在于，該方法包含以下步驟A、TPF獲取重鑒權(quán)事件信息；B、TPF監(jiān)測到重鑒權(quán)事件發(fā)生時，請求OCS對用戶進行重鑒權(quán)。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A為TPF中預(yù)先存儲重鑒權(quán)事件。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A為TPF接收OCS提供的重鑒權(quán)事件信息。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述重鑒權(quán)事件信息為重鑒權(quán)事件。
5.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A為TPF中預(yù)先存儲重鑒權(quán)事件，并接收OCS提供的重鑒權(quán)事件信息。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述重鑒權(quán)事件信息為重鑒權(quán)事件標識，或重鑒權(quán)事件，或以上二者的組合，或內(nèi)容為空的重鑒權(quán)事件信包。
7.根據(jù)權(quán)利要求3或5所述的方法，其特征在于，所述重鑒權(quán)事件信息在承載建立時，OCS向TPF返回信用響應(yīng)時提供；或承載修改時，OCS向TPF返回信用控制響應(yīng)時提供。
8.根據(jù)權(quán)利要求1、2、3或5所述的方法，其特征在于，所述步驟B進一步包括TPF向OSC提供當前觸發(fā)重鑒權(quán)流程的重鑒權(quán)事件。
9.根據(jù)權(quán)利要求1、2、3或5所述的方法，其特征在于，所述步驟B之后進一步包括OCS重新對用戶的信用進行計算，并向TPF返回重新計算后的用戶信用。
全文摘要
本發(fā)明公開了一種基于分組數(shù)據(jù)流計費重鑒權(quán)的處理方法，該方法包含TPF獲取重鑒權(quán)事件信息；TPF監(jiān)測到重鑒權(quán)事件發(fā)生時，請求OCS對用戶進行重鑒權(quán)。根據(jù)本發(fā)明提出的方法，TPF中預(yù)先存儲重鑒權(quán)事件，或由OCS向TPF提供重鑒權(quán)事件，使得TPF能夠準確獲知需要監(jiān)測的重鑒權(quán)事件；TPF對重鑒權(quán)事件的發(fā)生進行監(jiān)測，重鑒權(quán)事件發(fā)生時，TPF請求OCS對用戶進行重鑒權(quán)，OCS重新對用戶信用進行計算，并向TPF返回重新計算后的用戶信用。這樣，通過增加了重鑒權(quán)事件的提供方式，使得基于分組數(shù)據(jù)流計費的重鑒權(quán)流程的實現(xiàn)更為明確和清晰。
文檔編號H04L9/32GK1649306SQ20041006268
公開日2005年8月3日 申請日期2004年8月6日 優(yōu)先權(quán)日2004年8月6日
發(fā)明者段小琴 申請人:華為技術(shù)有限公司