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

發(fā)明內容
有鑒于此，本發(fā)明的目的在于提供一種基于分組數(shù)據流計費觸發(fā)事件和重鑒權事件的處理方法，完善基于分組數(shù)據流計費的重鑒權流程。
為了達到上述目的，本發(fā)明提供了一種基于分組數(shù)據流計費觸發(fā)事件和重鑒權事件的處理方法，該方法包含以下步驟A、TPF判斷當前發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果是，則執(zhí)行步驟B，否則，直接執(zhí)行步驟C；B、TPF觸發(fā)計費規(guī)則請求流程；C、TPF判斷是否需要觸發(fā)重鑒權流程，如果是，則觸發(fā)重鑒權流程，否則，結束當前流程。
所述步驟B包括TPF向CRF請求計費規(guī)則，CRF向TPF返回選定的計費規(guī)則。
所述步驟B進一步包括TPF向CRF提供當前發(fā)生的承載事件。
如果TPF判斷出當前發(fā)生的承載事件與觸發(fā)事件相匹配，則步驟C中所述判斷是否需要觸發(fā)重鑒權流程為判斷CRF提供的計費規(guī)則是否變化，如果是，則觸發(fā)重鑒權流程；否則，結束當前流程。
步驟C中所述觸發(fā)重鑒權流程之前，進一步包括判斷計費規(guī)則的變化是否需要觸發(fā)重鑒權流程，如果是，觸發(fā)重鑒權流程；否則，結束當前流程。
步驟C中所述觸發(fā)重鑒權流程之前，進一步包括TPF判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則觸發(fā)重鑒權流程，并進一步向OCS提供當前發(fā)生的承載事件；否則，僅觸發(fā)重鑒權流程。
所述觸發(fā)重鑒權流程進一步包括TPF向OCS提供變化的計費規(guī)則。
如果TPF判斷出當前發(fā)生的承載事件未與觸發(fā)事件相匹配，則步驟C中所述判斷是否需要觸發(fā)重鑒權流程為判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則觸發(fā)重鑒權流程；否則，結束當前流程。
所述觸發(fā)重鑒權流程進一步包括TPF向OCS提供當前發(fā)生的承載事件。
所述觸發(fā)重鑒權流程包括TPF向OCS請求用戶信用，OCS向TPF返回重新計算的用戶信用。
所述觸發(fā)事件由CRF提供給TPF。
所述重鑒權事件由OCS提供給TPF，或由OCS通過CRF提供給TPF。
根據本發(fā)明提出的方法，當承載事件發(fā)生時，TPF首先判斷發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果匹配，則向CRF上報發(fā)生的觸發(fā)事件；然后再判斷發(fā)生的承載事件是否與重鑒權事件相匹配，如果匹配，則向OCS上報發(fā)生的重鑒權事件，繼續(xù)后續(xù)重鑒權流程。這樣，TPF與OCS之間僅需要進行一次重鑒權的交互，優(yōu)化了觸發(fā)事件和重鑒權事件重疊時的重鑒權流程，完善了基于分組數(shù)據流計費的重鑒權流程。


圖1示出了PDP Context激活、數(shù)據傳輸、去激活流程圖；圖2A示出了支持在線計費的FBC系統(tǒng)結構圖；圖2B示出了支持離線計費的FBC系統(tǒng)結構圖；圖3示出了現(xiàn)有技術中觸發(fā)事件觸發(fā)TPF向CRF請求計費規(guī)則流程圖；圖4示出了現(xiàn)有技術中重鑒權事件觸發(fā)TPF請求OCS進行重鑒權流程圖；圖5示出了本發(fā)明中觸發(fā)事件和重鑒權事件的處理流程圖；圖6示出了本發(fā)明中觸發(fā)事件和重鑒權事件的處理過程消息交互示意圖。
具體實施例方式
為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，當承載事件發(fā)生時，TPF首先判斷發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果匹配，則向CRF上報發(fā)生的觸發(fā)事件；然后再判斷發(fā)生的承載事件是否與重鑒權事件相匹配，如果匹配，則向OCS上報發(fā)生的重鑒權事件，繼續(xù)后續(xù)重鑒權流程。這樣，TPF與OCS之間僅需要進行一次重鑒權的交互，優(yōu)化了觸發(fā)事件和重鑒權事件重疊時的重鑒權流程。
圖5示出了本發(fā)明中觸發(fā)事件和重鑒權事件的處理流程圖，如圖5所示，觸發(fā)事件和重鑒權事件的處理過程包括以下步驟步驟501～步驟502TPF監(jiān)測到承載事件的發(fā)生，判斷發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果是，則執(zhí)行步驟503；否則，執(zhí)行步驟507。
步驟503TPF觸發(fā)計費規(guī)則請求流程，即TPF向CRF提供選擇計費規(guī)則的輸入信息，并進一步向CRF提供當前發(fā)生的承載事件，用以通知CRF當前觸發(fā)計費規(guī)則請求流程的觸發(fā)事件，請求CRF提供計費規(guī)則；CRF接收到計費規(guī)則請求后，根據提供輸入信息以及承載事件選擇計費規(guī)則，向TPF提供選定的計費規(guī)則和計費規(guī)則操作指示。TPF收到提供計費規(guī)則后，根據計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應操作。
步驟504TPF判斷CRF提供的計費規(guī)則是否變化，如果是，則執(zhí)行步驟505；否則，執(zhí)行步驟507。
步驟505TPF判斷計費規(guī)則的變化是否需要觸發(fā)重鑒權流程，如果是，則執(zhí)行步驟506；否則，執(zhí)行步驟507。
步驟506TPF判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則執(zhí)行步驟508；否則，執(zhí)行步驟509。
步驟507TPF判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則執(zhí)行步驟508；否則，結束當前流程。
步驟508TPF觸發(fā)重鑒權流程，即TPF向OCS提供用戶的剩余信用和相關的計費規(guī)則信息，請求OCS重新計算用戶的信用，并進一步向OCS提供當前發(fā)生的承載事件，用以通知OCS當前觸發(fā)重鑒權流程的重鑒權事件；OCS向TPF提供重新計算的用戶信用，然后結束當前流程。
步驟509TPF觸發(fā)重鑒權流程，即TPF向OCS提供用戶的剩余信用和相關的計費規(guī)則信息，請求OCS重新計算用戶的信用；OCS向TPF提供重新計算的用戶信用。
步驟506也可在步驟501～步驟505之間的任意時刻進行，只要TPF判斷出當前發(fā)生的承載事件與重鑒權事件相匹配，則在后續(xù)步驟508觸發(fā)重鑒權流程時，進一步向OCS提供當前發(fā)生的承載事件，用以通知OCS當前發(fā)生的重鑒權事件。
圖6示出了本發(fā)明中觸發(fā)事件和重鑒權事件的處理過程消息交互示意圖，如圖6所示，觸發(fā)事件和重鑒權事件處理過程中的消息交互過程包括以下步驟步驟601與步驟301相同。
步驟602TPF收到承載修改請求后，將當前發(fā)生的承載修改事件與預先存儲的觸發(fā)事件相匹配，如果能夠匹配，則執(zhí)行步驟603；否則，直接執(zhí)行步驟608。
承載建立時，具體實現(xiàn)過程如下在線計費情況下，承載建立時，TPF向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有計費規(guī)則輸入信息，如UE的信息、承載屬性、網絡信息等，CRF根據收到的收入信息選擇適當?shù)挠嬞M規(guī)則，另外，CRF根據TPF提供的輸入信息，可進一步確定需要TPF進行監(jiān)測的觸發(fā)事件，然后將計費規(guī)則和觸發(fā)事件下發(fā)給TPF。
另外，承載修改時，CRF也可向TPF提供要求其進行監(jiān)測的觸發(fā)事件，即當觸發(fā)事件發(fā)生時，TPF向CRF上報發(fā)生的觸發(fā)事件；CRF收到TPF上報的觸發(fā)事件后，可繼續(xù)向TPF下發(fā)新的觸發(fā)事件。當CRF接收到外部實體，如AF、OCS提供的輸入信息后，也可向TPF提供要求其進行監(jiān)控的觸發(fā)事件，即CRF可主動地向TPF下發(fā)觸發(fā)事件。
TPF收到CRF提供的計費規(guī)則和觸發(fā)事件后，對觸發(fā)事件的發(fā)生進行監(jiān)測，并根據計費規(guī)則中的過濾器(Filter)過濾出相應的IP數(shù)據流，然后應用相應計費規(guī)則對過濾出的IP數(shù)據流進行計費。
OCS可直接向TPF提供要求其進行監(jiān)測的重鑒權事件。如在鑒權流程中，TPF向OCS發(fā)送信用請求，OCS接收到信用請求后，對用戶的信用進行計算并向TPF返回，返回的信用響應中除攜帶有用戶信用，可進一步攜帶有重鑒權事件，要求TPF對提供的重鑒權事件進行監(jiān)測，當重鑒權事件發(fā)生時觸發(fā)重鑒權流程，向OCS上報當前發(fā)生的重鑒權事件。OCS也可通過CRF向TPF下發(fā)重鑒權事件。
另外，當重鑒權事件發(fā)生時，TPF向OCS上報當前發(fā)生的重鑒權事件；OCS收到TPF上報的重鑒權事件后，可繼續(xù)向TPF下發(fā)新的重鑒權事件。
步驟603TPF向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息，該計費規(guī)則請求中可進一步攜帶有當前發(fā)生的承載相關事件，用以通知CRF觸發(fā)當前計費規(guī)則請求流程的觸發(fā)事件。
步驟604～步驟606與步驟304～步驟306相同。
步驟607TPF判斷CRF提供的計費規(guī)則是否變化，如果計費規(guī)則變化，則繼續(xù)判斷計費規(guī)則的變化是否需要觸發(fā)重鑒權流程，如果是，則可繼續(xù)執(zhí)行步驟608；如果計費規(guī)則未變化或計費規(guī)則的變化無需觸發(fā)重鑒權流程，則執(zhí)行步驟608。
步驟608TPF將當前發(fā)生的承載修改事件與預先存儲的重鑒權事件相匹配，如果能夠匹配，則執(zhí)行步驟609；否則，TPF繼續(xù)判斷在步驟607中是否決定需要觸發(fā)重鑒權流程，如果需要，則執(zhí)行步驟609，如果不需要，則直接執(zhí)行步驟611。
步驟609TPF向OCS發(fā)送信用請求(Credit Request)，該信用請求中攜帶有用戶的剩余信用和相關的計費規(guī)則信息，請求OCS重新計算用戶的信用。如果在步驟607中決定需要觸發(fā)重鑒權流程時，TPF向OCS發(fā)送的信用請求中可進一步攜帶有修改的計費規(guī)則信息。另外，如果在步驟608中決定需要觸發(fā)重鑒權流程時，TPF向OCS發(fā)送的信用請求消息中可進一步提供承載修改事件中修改的承載信息。
步驟610OCS收到信用請求后，重新對用戶的信用進行計算，然后向TPF返回信用響應(Credit Answer)，如果OCS計算出用戶的信用，則該信用響應中攜帶有OCS重新計算的用戶信用，如果OCS未計算出用戶的信用，則該信用響應中可攜帶有差錯原因值。
步驟611TPF向UE返回承載修改響應，根據以上處理結果確定是否接受UE發(fā)起的承載修改請求，如果接受，則繼續(xù)后續(xù)的承載修改流程；否則，拒絕UE發(fā)起的承載修改請求，例如，如果信用響應中攜帶有用戶的信用，則TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程；如果信用響應中未攜帶有用戶的信用，則拒絕UE發(fā)起的承載修改請求。
上述流程中，步驟607當TPF判斷出計費規(guī)則發(fā)生變化，并且計費規(guī)則發(fā)生變化事件需要觸發(fā)重鑒權流程時，則可直接執(zhí)行步驟609，不再執(zhí)行步驟608。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種基于分組數(shù)據流計費觸發(fā)事件和重鑒權事件的處理方法，其特征在于，該方法包含以下步驟A、TPF判斷當前發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果是，則執(zhí)行步驟B，否則，直接執(zhí)行步驟C；B、TPF觸發(fā)計費規(guī)則請求流程；C、TPF判斷是否需要觸發(fā)重鑒權流程，如果是，則觸發(fā)重鑒權流程，否則，結束當前流程。
2.根據權利要求1所述的方法，其特征在于，所述步驟B包括TPF向CRF請求計費規(guī)則，CRF向TPF返回選定的計費規(guī)則。
3.根據權利要求2所述的方法，其特征在于，所述步驟B進一步包括TPF向CRF提供當前發(fā)生的承載事件。
4.根據權利要求2所述的方法，其特征在于，如果TPF判斷出當前發(fā)生的承載事件與觸發(fā)事件相匹配，則步驟C中所述判斷是否需要觸發(fā)重鑒權流程為判斷CRF提供的計費規(guī)則是否變化，如果是，則觸發(fā)重鑒權流程；否則，結束當前流程。
5.根據權利要求4所述的方法，其特征在于，步驟C中所述觸發(fā)重鑒權流程之前，進一步包括判斷計費規(guī)則的變化是否需要觸發(fā)重鑒權流程，如果是，觸發(fā)重鑒權流程；否則，結束當前流程。
6.根據權利要求4所述的方法，其特征在于，步驟C中所述觸發(fā)重鑒權流程之前，進一步包括TPF判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則觸發(fā)重鑒權流程，并進一步向OCS提供當前發(fā)生的承載事件；否則，僅觸發(fā)重鑒權流程。
7.根據權利要求4所述的方法，其特征在于，所述觸發(fā)重鑒權流程進一步包括TPF向OCS提供變化的計費規(guī)則。
8.根據權利要求1所述的方法，其特征在于，如果TPF判斷出當前發(fā)生的承載事件未與觸發(fā)事件相匹配，則步驟C中所述判斷是否需要觸發(fā)重鑒權流程為判斷當前發(fā)生的承載事件是否與重鑒權事件相匹配，如果是，則觸發(fā)重鑒權流程；否則，結束當前流程。
9.根據權利要求8所述的方法，其特征在于，所述觸發(fā)重鑒權流程進一步包括TPF向OCS提供當前發(fā)生的承載事件。
10.根據權利要求1所述的方法，其特征在于，所述觸發(fā)重鑒權流程包括TPF向OCS請求用戶信用，OCS向TPF返回重新計算的用戶信用。
11.根據權利要求1所述的方法，其特征在于，所述觸發(fā)事件由CRF提供給TPF。
12.根據權利要求1所述的方法，其特征在于，所述重鑒權事件由OCS提供給TPF，或由OCS通過CRF提供給TPF。
全文摘要
本發(fā)明公開了一種基于分組數(shù)據流計費觸發(fā)事件和重鑒權事件的處理方法，該方法包含TPF判斷當前發(fā)生的承載事件是否與觸發(fā)事件相匹配，如果承載事件與觸發(fā)事件相匹配，則TPF觸發(fā)計費規(guī)則請求流程，然后TPF判斷是否需要觸發(fā)重鑒權流程，如果是，則觸發(fā)重鑒權流程，否則，結束當前流程；如果承載事件與觸發(fā)事件不匹配，則直接判斷是否需要觸發(fā)重鑒權流程，如果是，則觸發(fā)重鑒權流程，否則，結束當前流程。這樣，TPF與OCS之間僅需要進行一次重鑒權的交互，優(yōu)化了觸發(fā)事件和重鑒權事件重疊時的重鑒權流程，完善了基于分組數(shù)據流計費的重鑒權流程。
文檔編號H04L12/14GK1645806SQ200410059148
公開日2005年7月27日 申請日期2004年8月11日 優(yōu)先權日2004年8月11日
發(fā)明者段小琴 申請人:華為技術有限公司