專利名稱：一種對計費鍵進行處理的方法
技術領域：
本發(fā)明涉及分組數據計費領域，特別是指一種傳輸面功能實體對計費規(guī)則進行處理的方法。
背景技術：
隨著分組數據業(yè)務應用的逐漸廣泛，如何準確合理地對分組數據業(yè)務進行計費，已成為運營商普遍關注的問題。
圖1示出了分組數據協議上下文(PDP Context，Packet Data ProtocolContext)激活、數據傳輸、去激活流程圖，如圖1所示，在通用分組無線業(yè)務(GPRS，General Packet Radio Service)中，激活PDP Context、與外部分組數據網絡(PDN，Packet Data Network)進行數據交互、去激活該PDPContext的實現過程包括以下步驟步驟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)參數、事務標識(TI，Transaction Identifier)等信息，其中，NSAPI在SGSN和網關通用分組無線業(yè)務支持節(jié)點(GGSN，Gateway GPRS Support Node)之間作為隧道標識(TID，Tunnel Identifier)的組成部分，用于標識PDPContext；PDP類型包括端對端協議(PPP，Peer-Peer Protocol)類型、網際協議(IP，Internet Protocol)類型等；APN可由MS向SGSN提供，SGSN根據APN尋址到相應GGSN，GGSN根據APN確定MS所要訪問的外部網絡，MS也可不向SGSN提供APN，此時，由SGSN根據MS用戶的簽約信息選擇缺省的APN；QoS參數為MS指定的分組數據業(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參數、TEID、選擇模式等，其中，PDP地址可為MS的IP地址，為可選參數，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)、啟動計費，并且協商QoS，如果GGSN能夠滿足QoS參數的服務質量要求，則向SGSN返回PDP Context創(chuàng)建響應(Create PDP Context Response)，該PDP Context創(chuàng)建響應中攜帶有TEID、PDP地址、鏈路承載(Backbone Bearer)協議、商定的QoS參數、Charging ID等信息。如果GGSN無法滿足QoS參數的服務質量要求，則GGSN拒絕SGSN發(fā)起的PDP Context創(chuàng)建請求，然后SGSN拒絕MS發(fā)起的PDP Context激活請求。
步驟105SGSN收到PDP Context創(chuàng)建響應后，在PDP Context中插入用于標識PDP Context的NSAPI和GGSN地址信息，并根據商定的QoS參數選擇無線優(yōu)先權，然后向MS返回PDP Context激活響應(Activate PDPContext Accept)，該PDP Context激活響應中攜帶有PDP類型、PDP地址、TI、商定的QoS參數、無線優(yōu)先權、PDP配置選項等信息。并且，SGSN啟動計費。MS收到PDP Context激活響應，就已經建立了MS與GGSN直接的路由，可以進行分組數據的傳輸了。
步驟106MS通過SGSN、GGSN與PDN進行分組數據的交互。
步驟107結束分組數據交互后，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描述的實現過程可見，當前的GPRS計費系統(tǒng)中，由于計費的起始點設置在PDP Context激活時，計費的終止點設置在PDP Context刪除時，因此只能根據PDP Context傳輸的數據流量進行計費，或是根據PDP Context處于激活狀態(tài)的時間長度進行計費。然而，在實際應用中，MS與PDN進行數據交互后，該MS可以基于一個激活的PDP Context進行多種業(yè)務，也就是說，如果PDN能夠提供多種業(yè)務，如電子郵件(Email)收發(fā)業(yè)務、基于無線應用協議的(WAP，Wireless Application Protocol)的瀏覽業(yè)務、基于文件傳輸協議(FTP，File Transfer Protocol)的文件傳輸等業(yè)務，則MS在與該PDN建立傳輸通道后，可通過一個激活的PDP Context承載該PDN能夠提供的各種業(yè)務。但是，運營商對于各種業(yè)務的計費模式很可能采用不同的計費方式，如對于Email收發(fā)業(yè)務可基于Email接收和發(fā)送事件的觸發(fā)按次計費，對于WAP瀏覽業(yè)務可根據流量計費，對于文件傳輸業(yè)務也可根據流量計費，WAP瀏覽業(yè)務的費率與文件傳輸業(yè)務的費率卻不盡相同，這樣，根據現有的GPRS計費系統(tǒng)，根本無法對同一PDP Context承載的不同業(yè)務進行區(qū)分計費。
針對上述情況，第三代合作伙伴計劃(3GPP，The 3rd GenerationPartnership Project)目前正在討論如何實現基于IP數據流的計費(FBC，FlowBased Charging)。對于一個分組數據業(yè)務而言，MS的用戶使用該業(yè)務時，傳輸和接收到的所有IP數據流(IP Flow)，也可為IP分組包(IP packet)，總稱為業(yè)務數據流(Service Data Flow)，即業(yè)務數據流是多個IP數據流組成的集合，因此基于IP數據流的計費能夠真實反映某個業(yè)務數據流對資源的占用情況。基于IP數據流的計費可被認為是通過一些類似篩子的過濾器將同一PDP Context中承載的不同業(yè)務的IP數據流分別篩選出來，然后針對不同過濾器過濾出的IP數據流進行分別計費，以達到對不同的業(yè)務數據流分別計費的目的。這樣，基于IP數據流的計費粒度要遠遠小于基于一個PDPContext的計費粒度，粒度可看作是篩子孔的大小，基于一個PDP Context的計費粒度是一個PDP Context就是一個篩子孔，而基于IP數據流的計費粒度則是一個IP業(yè)務數據流則為一個篩子孔，即針對一個PDP Context中包含多個篩子孔，因此，基于IP數據流的計費與比基于一個PDP Context的計費相比，基于IP數據流的計費能夠為運營商或業(yè)務提供者提供更為豐富的計費手段。
3GPP中對FBC的系統(tǒng)結構、功能要求以及消息交互流程等方面均進行了描述，支持在線計費的FBC系統(tǒng)結構如圖2A所示，基于移動網絡增強邏輯的客戶化應用(CAMEL，Customised Application for Mobile NetworkEnhanced Logic)的業(yè)務控制點(SCP，Service Control Point)201和基于業(yè)務數據流計費的信用控制功能實體(CCF，Service Data Flow Based CreditControl Function)202組成了在線計費系統(tǒng)(OCS，Online Charging System)206。CCF 202通過Ry接口與基于業(yè)務數據流計費的計費規(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數據流，當IP數據流的承載建立時，TPF 205通過Gx接口向CRF 203發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有與用戶和MS相關的信息、承載特性以及與網絡相關的信息等，其中與用戶和MS相關的信息可為移動臺國際號碼(MSISDN)、國際移動用戶標識(IMSI)等，與網絡相關的信息可為移動網絡編碼(MNC)、移動國家碼(MCC)等。另外，由于在IP數據流傳輸過程中，會對承載進行修改，如對QoS參數進行重新協商，當用戶使用同一業(yè)務的QoS參數不同時，計費規(guī)則可能不同，如QoS參數下降相應的費率也下降。此時，TPF 205可在承載修改時，重新向CRF 203發(fā)送計費規(guī)則請求，請求新的計費規(guī)則；CRF 203根據TPF 205提供的上述輸入信息選擇適當的計費規(guī)則，并向TPF 205返回選定的計費規(guī)則，計費規(guī)則中包括計費機制、計費類型、計費鍵(Charging Key)、業(yè)務數據流過濾器、計費規(guī)則優(yōu)先級等信息。其中，計費機制可為采用在線計費還是離線計費；計費類型可為基于時間長度進行計費還是基于數據流量進行計費；計費鍵是與費率相關的參數，CRF 203可不直接向TPF 205提供費率，而只是向TPF 205提供與費率相關的參數；業(yè)務數據過濾器用于指示TPF205對哪些IP數據流進行過濾，然后TPF 205根據計費規(guī)則對過濾出的IP數據流進行計費。業(yè)務數據過濾器可包含IP5元組，IP5元組可包括源/目的IP地址、源/目的端口號(Port Number)、協議標識(Protocol ID)等信息，例如，CRF 203指示TPF 205對源地址為10.0.0.1、目的地址為10.0.0.2、源/目的端口號為20、協議類型為傳輸控制協議(TCP)的IP數據流進行過濾，并根據計費規(guī)則對過濾出的IP數據流進行計費。
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ā)事件可包括公用陸地移動通信網絡(PLMN)變化(PLMN change)事件，QoS參數變化(QoSchanges)事件，無線接入技術(RAT)類型變化(RAT type change)事件，傳輸流模板(TFT)變化(TFT change)事件。
CRF 203除了根據TPF 205提供的輸入信息選擇適當的計費規(guī)則之外，CRF 203還可根據AF 204或OCS 206的輸入信息選擇適當的計費規(guī)則，如AF 204通知CRF 203用戶當前使用的業(yè)務類型，CRF 203根據該業(yè)務類型選擇相應的計費規(guī)則。
OCS 206作為在線計費系統(tǒng)，由SCP 201和CCF(Service Data FlowBased Credit Control Function)202兩個功能實體組成，其中，CCF(ServiceData Flow Based Credit Control Function)202是執(zhí)行信用控制的功能實體，僅應用于在線計費系統(tǒng)，可通過在現有的OCS 206中增加新的功能來實現。在在線計費過程中，CCF(Service Data Flow Based Credit Control Function)202對用戶信用進行管理和控制，當用戶使用業(yè)務時，CCF(Service Data FlowBased Credit Control Function)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根據用戶當前所在位置確定費率，并根據該費率計算用戶的信用；當用戶移動至另一位置時，如PLMN發(fā)生變化，TPF 205需要根據重鑒權事件中的PLMN變化事件，向OCS 206上報PLMN變化事件的發(fā)生，OCS206根據用戶更新后的當前所在位置重新確定費率，并重新計算用戶的信用。又例如，當OCS 206根據用戶使用業(yè)務的當前QoS參數確定費率，當用戶對QoS參數進行修改，TPF 205需要根據重鑒權事件中的承載修改事件，向OCS 206上報承載修改事件的發(fā)生，OCS 206根據用戶修改后的QoS參數確定費率，并重新計算用戶的信用。
另外，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參數變化事件，RAT類型變化事件，傳輸流模板變化事件等。
對應于GPRS網絡，TPF 205為GGSN，AF為PDN中的一個業(yè)務網關或業(yè)務服務器，CRF 203為新增的邏輯實體。TPF 205為計費規(guī)則的執(zhí)行點，CRF 203為計費規(guī)則的控制點。
對于基于業(yè)務數據流的計費，在線計費過程中，3GPP規(guī)范中描述的請求信用額度的方式是基于每個計費規(guī)則(Charging Rule)進行的，具體實現過程為TPF收到CRF提供的計費規(guī)則后，根據計費規(guī)則中的在線計費機制，確定需要為該計費規(guī)則向OCS請求信用額度時，TPF直接向OCS請求針對該計費規(guī)則的信用額度。
但是，CRF向TPF提供的計費規(guī)則的計費粒度是針對不同的業(yè)務數據流，這樣，在線計費時，TPF需要針對每個業(yè)務數據流進行在線計費交互，即針對每個業(yè)務數據流TPF都需要向OCS請求信用額度，OCS根據TPF的信用請求，需要對每個業(yè)務數據流都分配相應的信用額度，并下發(fā)給TPF，由于同一用戶同時可以使用多個業(yè)務，從而產生多個業(yè)務數據流，因此，這種基于不同的業(yè)務數據流進行在線計費交互的處理機制必然會使得TPF與OCS的交互過于頻繁，導致TPF與OCS的處理性能下降，從而使整個在線計費處理過程的實用性大大降低。

發(fā)明內容
有鑒于此，本發(fā)明的目的在于提供一種對計費鍵進行處理的方法，提高TPF和OCS的處理性能。
為了達到上述目的，本發(fā)明提供了一種對計費鍵進行處理的方法，在線計費情況下，TPF建立計費規(guī)則時，該方法包含A、TPF根據計費規(guī)則中的計費鍵，判斷是否已向OCS請求了針對該計費鍵的信用額度，如果不是，則TPF向OCS發(fā)送信用請求。
所述TPF判斷出已向OCS請求了針對該計費鍵的信用額度，之后進一步包括TPF不向OCS發(fā)送信用請求，直接使用請求到的針對該計費鍵的信用額度。
所述TPF直接使用請求到的針對該計費鍵的信用額度，進一步包括TPF記錄與已請求信用額度的所述計費鍵相對應的計費規(guī)則信息。
步驟A中所述TPF向OCS發(fā)送信用請求，之后進一步包括A1、OCS向TPF返回信用額度。
所述步驟A1之后進一步包括TPF記錄已向OCS請求信用額度的計費鍵信息。
所述步驟A1之后進一步包括TPF記錄與已請求信用額度的所述計費鍵相對應的計費規(guī)則信息。
本發(fā)明還公開了一種對計費鍵進行處理的方法，其特征在于，OCS向TPF提供針對計費鍵的重鑒權事件，TPF監(jiān)測到重鑒權事件發(fā)生時，該方法進一步包括B、TPF向OCS返回所述與重鑒權事件相對應的計費鍵消耗信用額度后的剩余信用額度。
所述步驟B之前進一步包括TPF記錄與所述計費鍵相對應的重鑒權事件信息。
所述步驟B之后進一步包括OCS進行重鑒權，然后向TPF提供重新計算的針對該計費鍵的信用額度。
本發(fā)明又公開了一種對計費鍵進行處理的方法，其特征在于，在線計費情況下，TPF刪除計費規(guī)則時，該方法包含C、TPF根據計費規(guī)則中的計費鍵，判斷是否存在除需要刪除的計費規(guī)則以外的計費規(guī)則使用針對該計費鍵請求到的信用額度，如果不是，則TPF向OCS返回針對該計費鍵的剩余信用額度。
所述步驟C之后進一步包括TPF刪除需要刪除的計費規(guī)則。
根據本發(fā)明提出的方法，TPF請求信用額度的方式是基于每個計費鍵進行的。由于不同的業(yè)務數據流可以具有相同的計費費率，即，對于不同的計費規(guī)則可以具有相同的計費鍵，因此基于每個計費鍵的信用額度請求的粒度大于基于每計費規(guī)則的信用額度請求。這樣，通過實現TPF基于每個計費鍵請求信用額度的處理過程，可以有效減少TPF與OCS之間的交互，提升TPF與OCS的處理性能，增強整個在線計費處理過程的實用性。


圖1示出了PDP Context激活、數據傳輸、去激活流程圖；圖2A示出了支持在線計費的FBC系統(tǒng)結構圖；圖2B示出了支持離線計費的FBC系統(tǒng)結構圖；圖3示出了本發(fā)明中基于計費鍵請求信用額度處理過程示意圖；圖4示出了本發(fā)明中基于計費鍵的重鑒權處理過程示意圖。
具體實施例方式
為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面結合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，TPF請求信用額度的方式是基于每個計費鍵進行的，即TPF以計費鍵作為計費規(guī)則的索引，對具有相同的計費鍵的計費規(guī)則進行記錄，使得在建立計費規(guī)則、刪除計費規(guī)則以及上報重鑒權事件時，能夠根據相同的計費鍵對計費規(guī)則進行批量處理，實現了TPF基于每個計費鍵請求信用額度的處理過程。
TPF收到CRF提供的計費規(guī)則后，如果需要建立新的計費規(guī)則，則TPF首先判斷需要建立的計費規(guī)則中的計費機制是否為在線計費，如果為在線計費，則進一步根據該計費規(guī)則中的計費鍵，判斷是否已針對該計費鍵向OCS請求了信用額度，如果未針對該計費鍵向OCS請求信用額度，則TPF向OCS發(fā)送信用請求，該信用請求中攜帶有該計費鍵，OCS根據該計費鍵計算出用戶的信用額度后，向TPF返回信用響應，該信用響應中攜帶有為該計費鍵分配的信用額度。此時，TPF記錄已請求信用額度的計費鍵以及與相應計費規(guī)則的對應關系，并可進一步記錄OCS針對該計費鍵分配的信用額度。例如，TPF建立在線計費交互信息列表，列表中“已請求信用額度的計費鍵項”記錄該計費鍵，如Charging Key A，對應的“信用額度項”記錄OCS針對Charging Key A分配的信用額度，如100M，對應的“計費規(guī)則項”記錄計費規(guī)則標識，如Charging Rule 1。如果已針對該計費鍵向OCS請求了信用額度，例如TPF根據在線計費交互信息列表中的“已請求信用額度的計費鍵項”中存在該計費鍵，如Charging Key A，則判斷出先前已根據該計費鍵向OCS請求了信用額度，則TPF不再向OCS請求信用額度，直接使用先前針對該計費鍵向OCS請求到的信用額度，即在線計費交互信息列表中與“已請求信用額度的計費鍵項”為Charging Key A相對應的“信用額度項”中信用額度100M。然后，TPF記錄已請求信用額度的計費鍵以及與該計費規(guī)則的對應關系，即在建立的在線計費交互信息列表中，與“已請求信用額度的計費鍵項”為Charging Key A相對應的“計費規(guī)則項”中記錄該計費規(guī)則的標識，如Charging Rule 2。這樣，根據在線計費交互信息列表，針對計費規(guī)則Charging Rule 1和計費規(guī)則Charging Rule 2過濾出的業(yè)務數據流都將消耗Charging Key A所對應的信用額度100M，如在某一個時刻，當TPF監(jiān)測到Charging Rule 1過濾出的業(yè)務數據流量大小與Charging Rule 2過濾出的業(yè)務數據流量大小之和達到信用額度100M時，TPF將發(fā)起重鑒權流程，向OCS發(fā)送信用請求，請求OCS為Charging Key A分配相應的信用額度。
TPF收到CRF提供的計費規(guī)則后，如果需要刪除計費規(guī)則時，則TPF首先判斷需要刪除的計費規(guī)則中的計費機制是否為在線計費，如果為在線計費，則進一步根據該計費規(guī)則中的計費鍵，判斷是否存在除需刪除的計費規(guī)則以外的其他計費規(guī)則使用針對該計費鍵請求到的信用額度，如當需刪除的計費規(guī)則Charging Rule 1中的計費鍵為Charging Key A時，TPF判斷在線計費交互信息列表中與“已請求信用額度的計費鍵項”計費鍵Charging KeyA相對應的“計費規(guī)則項”記錄的計費規(guī)則標識是否除了Charging Rule 1之外，還有其他的計費規(guī)則標識，如果沒有其他計費規(guī)則標識，則TPF刪除CRF指定的計費規(guī)則，不再對該計費規(guī)則指定的業(yè)務數據流進行過濾，更新在線計費交互信息列表中的相應信息，如刪除“已請求信用額度的計費鍵項”中的計費鍵Charging Key A以及其所對應的“信用額度項”中信用額度和“計費規(guī)則項”中的計費規(guī)則標識，并且TPF向OCS返回與該計費鍵相對應的剩余信用額度，結束TPF和OCS之間針對該計費鍵的交互操作；如果TPF判斷出還有其他計費規(guī)則使用針對該計費鍵請求到的信用額度，即在線計費交互信息列表中與“已請求信用額度的計費鍵項”計費鍵Charging Key A相對應的“計費規(guī)則項”記錄的計費規(guī)則標識除了ChargingRule 1之外還有其他計費規(guī)則標識，則TPF刪除CRF指定的計費規(guī)則，如Charging Rule 1，不再對該計費規(guī)則指定的業(yè)務數據流進行過濾，更新在線計費交互信息列表中的相應信息，如刪除與“已請求信用額度的計費鍵項”中計費鍵為Charging Key A相對應的“計費規(guī)則項”中的計費規(guī)則標識Charging Rule 1，并不向OCS返回該計費鍵所對應的剩余信用額度。
另外，根據以上基于每個計費鍵請求信用額度的處理方式，重鑒權流程的處理也可以是基于每個計費鍵的。當TPF向OCS發(fā)送信用請求，OCS向TPF返回信用響應時，OCS除了向TPF提供信用額度之外，還可進一步提供重鑒權事件。此時TPF可記錄已請求信用額度的計費鍵以及與相應重鑒權事件的對應關系，例如，針對在線計費交互信息列表中“已請求信用額度的計費鍵項”記錄的計費鍵，如Charging Key A，與其相對應的“重鑒權事件項”中記錄OCS下發(fā)的重鑒權事件，該重鑒權事件可以是一個或多個，如PLMN變化事件、TFT變化事件等。OCS可針對不同的計費鍵下發(fā)相同的重鑒權事件，如OCS針對Charging Key A和Charging Key B均下發(fā)PLMN變化的重鑒權事件。當TPF監(jiān)測到重鑒權事件發(fā)生時，TPF查找與發(fā)生的重鑒權事件相對應的計費鍵，然后向OCS返回該計費鍵消耗信用額度后的剩余信用額度。如發(fā)生了PLMN變化事件，TPF根據在線計費交互信息列表中記錄的信息查找到與該PLMN變化事件相對應的Charging Key A和Charging Key B，則TPF停止對Charging Key A和Charging Key B分別對應的計費規(guī)則指定的業(yè)務數據流的過濾，計算出針對Charging Key A和Charging Key B消耗信用額度后的剩余信用額度并向OCS返回，請求OCS針對該重鑒權事件重新分配針對于Charging Key A和Charging Key B的信用額度。OCS執(zhí)行完重鑒權后，向TPF提供重新計算的針對于計費鍵的信用額度，然后TPF使用新的信用額度監(jiān)控計費鍵相對應的計費規(guī)則指定的業(yè)務數據流的信用使用情況。例如，OCS分別向TPF提供針對Charging KeyA和Charging Key B計算出的信用額度，TPF獲得針對Charging Key A的新的信用額度后，TPF針對與Charging Key A相對應的計費規(guī)則指定的業(yè)務數據流進行過濾，監(jiān)控業(yè)務數據流是否達到信用額度，達到信用額度后，觸發(fā)允許的信用過期重鑒權事件，TPF再度執(zhí)行重鑒權流程，請求OCS針對Charging Key A重新計算新的信用額度。同樣，對于TPF獲得針對ChargingKey B的新的信用額度后，TPF執(zhí)行與針對Charging Key A相類似的操作，這里不再贅述。
圖3示出了本發(fā)明中基于計費鍵請求信用額度處理過程示意圖，如圖3所示，基于計費鍵請求信用額度的處理過程包括以下步驟步驟301～步驟302CRF可根據收到的來自外部實體的信息，例如，CRF收到來自TPF的承載建立、修改或刪除等消息，或CRF收到AF或OCS提供的與計費規(guī)則相關的輸入信息，選擇需要向TPF提供的計費規(guī)則，CRF可要求TPF建立新的計費規(guī)則，也可要求TPF刪除原來的計費規(guī)則，還可要求TPF對原來的計費規(guī)則進行修改。CRF向TPF提供選定的計費規(guī)則，并指示TPF對計費規(guī)則進行相應操作。
步驟303～步驟304TPF收到計費規(guī)則后，根據計費規(guī)則操作指示對計費規(guī)則進行相應操作，如建立、修改或刪除計費規(guī)則。在線計費情況下，如果TPF是建立新的計費規(guī)則或修改原來的計費規(guī)則，則根據該計費規(guī)則中的計費鍵，判斷是否已根據相應計費鍵向OCS請求了信用額度，如果是，則TPF不再向OCS請求信用額度，直接使用先前針對該計費鍵向OCS請求到的信用額度，即該業(yè)務數據流將消耗TPF先前針對該計費鍵向OCS請求到的信用額度，然后TPF記錄與已請求信用額度的計費鍵相對應的計費規(guī)則信息，如計費規(guī)則標識；否則，執(zhí)行步驟305。在線計費情況下，如果TPF是刪除原來的計費規(guī)則，則根據該計費規(guī)則中的計費鍵，判斷是否存在其他計費規(guī)則使用針對該計費鍵請求到的信用額度，如判斷與該計費鍵相對應的計費規(guī)則是否除需刪除的計費規(guī)則之外還有其他的計費規(guī)則，如果是，則直接刪除該計費規(guī)則，不再對該計費規(guī)則指定的業(yè)務數據流進行過濾；否則，TPF停止對該計費規(guī)則指定的業(yè)務數據流進行過濾，刪除該計費規(guī)則，并向OCS返回針對該計費鍵的剩余信用額度，結束TPF和OCS之間針對該計費鍵的交互操作。
步驟305～步驟306TPF向OCS發(fā)送信用請求(Credit Request)，該信用請求中攜帶有該計費規(guī)則的計費鍵，請求OCS針對該計費鍵提供信用額度。OCS收到信用請求后，根據計費鍵計算用戶的信用額度，然后向TPF返回信用響應(Credit Response)，該信用響應中攜帶分配的信用額度。TPF收到信用響應后，使用收到的信用額度監(jiān)控與計費鍵相對應的計費規(guī)則指定的業(yè)務數據流的信用使用情況。
圖4示出了本發(fā)明中基于計費鍵的重鑒權處理過程示意圖，如圖4所示，基于計費鍵進行重鑒權的處理過程包括以下步驟步驟401TPF監(jiān)測重鑒權事件是否發(fā)生，如果是，則執(zhí)行步驟402；否則，返回執(zhí)行步驟401。
步驟402～步驟403TPF查找與發(fā)生的重鑒權事件相對應的計費鍵，然后向OCS發(fā)送信用及重鑒權請求(Credit Request and re-authorisationRequest)，該信用及重鑒權請求中攜帶有該計費鍵消耗信用額度后的剩余信用額度。OCS收到信用及重鑒權請求后，執(zhí)行重鑒權，重新計算針對該計費鍵的信用額度，然后向TPF返回信用及重鑒權響應(Credit Response andre-authorisation Response)，該信用及重鑒權響應中攜帶有新的信用額度。TPF收到信用及重鑒權響應后，使用新的信用額度監(jiān)控與計費鍵相對應的計費規(guī)則指定的業(yè)務數據流的信用使用情況。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種對計費鍵進行處理的方法，其特征在于，在線計費情況下，TPF建立計費規(guī)則時，該方法包含A、TPF根據計費規(guī)則中的計費鍵，判斷是否已向OCS請求了針對該計費鍵的信用額度，如果不是，則TPF向OCS發(fā)送信用請求。
2.根據權利要求1所述的方法，其特征在于，所述TPF判斷出已向OCS請求了針對該計費鍵的信用額度，之后進一步包括TPF不向OCS發(fā)送信用請求，直接使用請求到的針對該計費鍵的信用額度。
3.根據權利要求2所述的方法，其特征在于，所述TPF直接使用請求到的針對該計費鍵的信用額度，進一步包括TPF記錄與已請求信用額度的所述計費鍵相對應的計費規(guī)則信息。
4.根據權利要求1所述的方法，其特征在于，步驟A中所述TPF向OCS發(fā)送信用請求，之后進一步包括A1、OCS向TPF返回信用額度。
5.根據權利要求4所述的方法，其特征在于，所述步驟A1之后進一步包括TPF記錄已向OCS請求信用額度的計費鍵信息。
6.根據權利要求4或5所述的方法，其特征在于，所述步驟A1之后進一步包括TPF記錄與已請求信用額度的所述計費鍵相對應的計費規(guī)則信息。
7.一種對計費鍵進行處理的方法，其特征在于，OCS向TPF提供針對計費鍵的重鑒權事件，TPF監(jiān)測到重鑒權事件發(fā)生時，該方法進一步包括B、TPF向OCS返回所述與重鑒權事件相對應的計費鍵消耗信用額度后的剩余信用額度。
8.根據權利要求7所述的方法，其特征在于，所述步驟B之前進一步包括TPF記錄與所述計費鍵相對應的重鑒權事件信息。
9.根據權利要求7所述的方法，其特征在于，所述步驟B之后進一步包括OCS進行重鑒權，然后向TPF提供重新計算的針對該計費鍵的信用額度。
10.一種對計費鍵進行處理的方法，其特征在于，在線計費情況下，TPF刪除計費規(guī)則時，該方法包含C、TPF根據計費規(guī)則中的計費鍵，判斷是否存在除需要刪除的計費規(guī)則以外的計費規(guī)則使用針對該計費鍵請求到的信用額度，如果不是，則TPF向OCS返回針對該計費鍵的剩余信用額度。
11.根據權利要求10所述的方法，其特征在于，所述步驟C之后進一步包括TPF刪除需要刪除的計費規(guī)則。
全文摘要
本發(fā)明公開了一種對計費鍵進行處理的方法，該方法包含在線計費情況下，TPF建立計費規(guī)則時，根據計費規(guī)則中的計費鍵，判斷是否已向OCS請求了針對該計費鍵的信用額度，如果不是，則TPF向OCS發(fā)送信用請求；TPF刪除計費規(guī)則時，根據計費規(guī)則中的計費鍵，判斷是否存在除需要刪除的計費規(guī)則以外的計費規(guī)則使用針對該計費鍵請求到的信用額度，如果不是，則TPF向OCS返回針對該計費鍵的剩余信用額度；另外，OCS向TPF提供針對計費鍵的重鑒權事件，TPF監(jiān)測到重鑒權事件發(fā)生時，向OCS返回所述與重鑒權事件相對應的計費鍵消耗信用額度后的剩余信用額度。根據本發(fā)明提出的方案，可以有效減少TPF與OCS之間的交互，提升TPF與OCS的處理性能，增強整個在線計費處理過程的實用性。
文檔編號H04L9/32GK1773921SQ200410090928
公開日2006年5月17日 申請日期2004年11月10日 優(yōu)先權日2004年11月10日
發(fā)明者段小琴 申請人:華為技術有限公司