專利名稱：一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計費領(lǐng)域，特別是指一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法。
背景技術(shù)：
隨著分組數(shù)據(jù)業(yè)務(wù)應(yīng)用的逐漸廣泛，如何準(zhǔn)確合理地對分組數(shù)據(jù)業(yè)務(wù)進(jìn)行計費，已成為運營商普遍關(guān)注的問題。
圖1為分組數(shù)據(jù)協(xié)議上下文(PDP Context，Packet Data Protocol Context)激活、傳輸數(shù)據(jù)、去激活流程圖，如圖1所示，在通用分組無線業(yè)務(wù)(GPRS，General Packet Radio Service)中，PDP Context激活、傳輸數(shù)據(jù)、去激活的實現(xiàn)過程包括以下步驟步驟101用戶設(shè)備(UE)向服務(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)識(TEID，Tunnel Identifier)的組成部分，用于標(biāo)識PDP Context；PDP類型包括端對端協(xié)議(PPP，Peer-Peer Protocol)類型、網(wǎng)際協(xié)議(IP，Internet Protocol)類型等；APN可由UE向SGSN提供，SGSN根據(jù)APN尋址到相應(yīng)GGSN，GGSN根據(jù)APN確定UE所要訪問的外部網(wǎng)絡(luò)，UE也可不向SGSN提供APN，此時，由SGSN根據(jù)UE用戶的簽約信息選擇缺省的APN；QoS參數(shù)為UE指定的分組數(shù)據(jù)業(yè)務(wù)所要達(dá)到的質(zhì)量要求；TI用于UE標(biāo)識一個PDP context。
步驟102SGSN收到Activate PDP Context Request后，與UE進(jìn)行安全性檢查和加密，該步驟為可選步驟。
步驟103SGSN根據(jù)APN解析GGSN地址信息，如果SGSN能夠根據(jù)APN解析出GGSN的地址信息，則為PDP Context創(chuàng)建TEID，該TEID可為國際移動用戶標(biāo)識(IMSI，International Mobile Subscriber Identity)與NSAPI的組合，用于在SGSN和GGSN之間唯一標(biāo)識一個PDP Context，然后SGSN向GGSN發(fā)送PDP Context創(chuàng)建請求(Create PDP Context Request)，該Create PDP Context Request中攜帶有PDP類型、PDP地址、APN、QoS參數(shù)、TEID、選擇模式等，其中，PDP地址為UE的IP地址，為可選參數(shù)，Create PDP Context Request可不攜帶PDP地址，此時，在后續(xù)的處理過程中，可由GGSN為UE分配IP地址，也可由最終與UE建立連接的分組數(shù)據(jù)網(wǎng)絡(luò)(PDN，Packet Data Network)為UE分配IP地址；選擇模式是指APN的選擇模式，即APN是由UE選定的還是由SGSN選定的。如果SGSN無法根據(jù)APN解析出GGSN的地址信息，則SGSN拒絕UE發(fā)起的PDPContext激活請求。
步驟104GGSN收到Create PDP Context Request后，根據(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)，該Create PDP Context Response中攜帶有TEID、PDP地址、鏈路承載(Backbone Bearer)協(xié)議、QoS參數(shù)、Charging ID等信息。如果GGSN無法滿足QoS參數(shù)的服務(wù)質(zhì)量要求，則GGSN拒絕SGSN發(fā)起的PDP Context創(chuàng)建請求，然后SGSN拒絕UE發(fā)起的PDP Context激活請求。
步驟105SGSN收到Create PDP Context Response后，在PDP Context中插入NSAPI和GGSN地址信息，用于標(biāo)識該PDP Context，并根據(jù)QoS參數(shù)選擇無線優(yōu)先權(quán)，然后向UE返回PDP Context激活響應(yīng)(Activate PDPContext Accept)，該Activate PDP Context Accept中攜帶有PDP類型、PDP地址、TI、QoS參數(shù)、無線優(yōu)先權(quán)、PDP配置選項等信息。并且，SGSN啟動計費。UE收到Activate PDP Context Accept，建立與GGSN之間的路由，此時，UE與PDN建立了傳輸通道，可以進(jìn)行數(shù)據(jù)傳輸了。
步驟106UE通過SGSN、GGSN與PDN進(jìn)行數(shù)據(jù)傳輸。
步驟107數(shù)據(jù)傳輸完畢，UE向SGSN發(fā)送PDP Context去激活請求(Deactivate PDP Context Request)，該Deactivate PDP Context Request中攜帶有TI。
步驟108SGSN收到Deactivate PDP Context Request后，與UE進(jìn)行安全性檢查和加密，該步驟為可選步驟。
步驟109～步驟111SGSN向GGSN發(fā)送PDP Context刪除請求(DeletePDP Context Request)，該Delete PDP Context Request中攜帶有TEID。GGSN收到Delete PDP Context Request后，結(jié)束對UE的計費，刪除對應(yīng)于TEID的PDP Context，然后向SGSN發(fā)送PDP Context刪除響應(yīng)(Delete PDPContext Response)，該Delete PDP Context Response中攜帶有TEID。SGSN收到Delete PDP Context Response后，結(jié)束對UE的計費，刪除對應(yīng)于TEID的PDP Context，然后向UE發(fā)送PDP Context去激活響應(yīng)(Deactivate PDPContext Response)，該Deactivate PDP Context Response中攜帶有TI。UE收到Deactivate PDP Context Response后，刪除對應(yīng)于TI的PDP Context。
由圖1描述的流程可見，當(dāng)前的GPRS計費系統(tǒng)中，由于計費的起始點設(shè)置在PDP Context激活時，計費的終止點設(shè)置在PDP Context刪除時，因此只能根據(jù)PDP Context傳輸?shù)臄?shù)據(jù)流量進(jìn)行計費，或是根據(jù)PDP Context處于激活狀態(tài)的時間長度進(jìn)行計費。然而，在實際應(yīng)用中，UE與PDN建立起傳輸通道后，該UE可以基于一個激活的PDP Context進(jìn)行多種業(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ù)，則UE在與該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ù)進(jìn)行區(qū)分計費。
針對上述情況，第三代合作伙伴計劃(3GPP，The 3rd GenerationPartnership Project)目前正在討論如何實現(xiàn)基于IP數(shù)據(jù)流的計費(FBC，F(xiàn)lowBased Charging)。對于一個分組數(shù)據(jù)業(yè)務(wù)而言，UE的用戶使用該業(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ù)流對資源的占用情況。基于IP數(shù)據(jù)流的計費可被認(rèn)為是通過一些類似篩子的過濾器將同一PDP Context中承載的不同業(yè)務(wù)的IP數(shù)據(jù)流分別篩選出來，然后針對不同過濾器過濾出的IP數(shù)據(jù)流進(jìn)行分別計費，以達(dá)到對不同的業(yè)務(wù)數(shù)據(jù)流分別計費的目的。這樣，基于IP數(shù)據(jù)流的計費粒度要遠(yuǎn)遠(yuǎn)小于基于一個PDPContext的計費粒度，粒度可看作是篩子孔的大小，基于一個PDP Context的計費粒度是一個PDP Context就是一個篩子孔，而基于IP數(shù)據(jù)流的計費粒度則是一個IP業(yè)務(wù)數(shù)據(jù)流則為一個篩子孔，即針對一個PDP Contcxt中包含多個篩子孔，因此，基于IP數(shù)據(jù)流的計費與比基于一個PDP Context的計費相比，基于IP數(shù)據(jù)流的計費能夠為運營商或業(yè)務(wù)提供者提供更為豐富的計費手段。
3GPP中對FBC的系統(tǒng)結(jié)構(gòu)、功能要求以及消息交互流程等方面均進(jìn)行了描述，支持在線計費的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。CCF202通過Ry接口與基于業(yè)務(wù)數(shù)據(jù)流計費的計費規(guī)則功能實體(CRF，Service Data Flow Based Charging Rule Function)203相連，CRF203通過Rx接口與應(yīng)用功能實體(AF，Application Function)204相連，CRF203通過Gx接口與傳輸面功能實體(TPF，Traffic Plane Function)205相連，CCF202通過Gy接口與TPF205相連。
支持離線計費的FBC系統(tǒng)結(jié)構(gòu)如圖2B所示，CRF203通過Rx接口與AF204相連，CRF203通過Gx接口與TPF205相連，TPF205通過Gz接口分別與計費網(wǎng)關(guān)功能實體(CGF，Charging Gateway Function)207和計費采集功能實體(CCF，Charging Collection Function)208相連。
根據(jù)目前3GPP對于實現(xiàn)FBC功能實體的劃分，TPF205承載IP數(shù)據(jù)流，當(dāng)IP數(shù)據(jù)流的承載建立時，TPF205通過Gx接口向CRF203發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有與用戶和UE相關(guān)的信息、承載特性以及與網(wǎng)絡(luò)相關(guān)的信息等，其中與用戶和UE相關(guān)的信息可為移動臺國際號碼(MSISDN)、國際移動用戶標(biāo)識(IMSI)等，與網(wǎng)絡(luò)相關(guān)的信息可為移動網(wǎng)絡(luò)編碼(MNC)、移動國家碼(MCC)等。另外，由于在IP數(shù)據(jù)流傳輸過程中，會對承載進(jìn)行修改，如對QoS參數(shù)進(jìn)行重新協(xié)商，當(dāng)用戶使用同一業(yè)務(wù)的QoS參數(shù)不同時，計費規(guī)則可能不同，如QoS參數(shù)下降相應(yīng)的費率也下降。此時，TPF205可在承載修改時，重新向CRF203發(fā)送計費規(guī)則請求，請求新的計費規(guī)則；CRF203根據(jù)TPF205提供的上述輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF205返回選定的計費規(guī)則，計費規(guī)則中包括計費機制、計費類型、計費鍵、業(yè)務(wù)數(shù)據(jù)流過濾器、計費規(guī)則優(yōu)先級等信息。其中，計費機制可為采用在線計費還是離線計費；計費類型可為基于時間長度進(jìn)行計費還是基于數(shù)據(jù)流量進(jìn)行計費；計費鍵是與計費費率相關(guān)的參數(shù)，CRF203可不直接向TPF205提供計費費率，而只是向TPF205提供與計費費率相關(guān)的參數(shù)；業(yè)務(wù)數(shù)據(jù)過濾器用于指示TPF205對哪些IP數(shù)據(jù)流進(jìn)行過濾，然后TPF205根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進(jìn)行計費。業(yè)務(wù)數(shù)據(jù)過濾器可包含IP5元組，IP5元組可包括源/目的IP地址、源/目的端口號(Port Number)、協(xié)議標(biāo)識(Protocol ID)等信息，例如，CRF203指示TPF205對源地址為10.0.0.1、目的地址為10.0.0.2、源/目的端口號為20、協(xié)議類型為傳輸控制協(xié)議(TCP)的IP數(shù)據(jù)流進(jìn)行過濾，并根據(jù)計費規(guī)則對過濾出的IP數(shù)據(jù)流進(jìn)行計費。最后，當(dāng)承載刪除時，TPF205也可向CRF203發(fā)送計費規(guī)則請求，要求CRF提供新的計費規(guī)則，此時CRF203可要求TPF205刪除先前建立的計費規(guī)則。
另外，CRF203除了根據(jù)TPF205的輸入信息確定計費規(guī)則之外，CRF203還可根據(jù)AF204或OCS206的輸入信息確定計費規(guī)則，如AF204通知CRF203用戶當(dāng)前使用的業(yè)務(wù)類型，CRF203根據(jù)該業(yè)務(wù)類型選取相應(yīng)的計費規(guī)則。
對應(yīng)于GPRS網(wǎng)絡(luò)，TPF205為GGSN，AF為PDN中的一個業(yè)務(wù)網(wǎng)關(guān)或業(yè)務(wù)服務(wù)器，CRF203為新增的邏輯實體。TPF205為計費規(guī)則的執(zhí)行點，CRF203為計費規(guī)則的控制點。
圖3A為承載建立時下發(fā)計費規(guī)則流程圖，如圖3A所示，承載建立時下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟301AUE向TPF發(fā)送承載建立請求(Establish Bearer ServiceRequest)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Create PDP Context Request。
步驟302ATPF收到承載建立請求后，向CRF發(fā)送計費規(guī)則請求(Request Charging Rules)，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟303A～步驟304ACRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息選取計費規(guī)則，然后向TPF返回提供計費規(guī)則(Provision Charging Rules)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟305A～步驟306ATPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則，然后向UE返回承載建立響應(yīng)(EstablishBearer Service Accept)，接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程。
圖3B為承載修改時下發(fā)計費規(guī)則流程圖，如圖3A所示，承載修改時下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟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ī)則請求中攜帶的輸入信息選取計費規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟305B～步驟306BTPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則，然后向UE返回承載修改響應(yīng)(Modify BearerService Accept)，接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程。
圖3C為承載刪除時下發(fā)計費規(guī)則流程圖，如圖3A所示，承載刪除時下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟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ī)則請求中攜帶的輸入信息選取計費規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟305C～步驟306CTPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則，然后向UE返回承載刪除響應(yīng)(RemoveBearer Service Accept)，接受UE發(fā)起的承載刪除請求，并繼續(xù)后續(xù)的承載刪除流程。
另外，對于CRF也可主動向TPF發(fā)送計費規(guī)則，如當(dāng)UE與AF進(jìn)行業(yè)務(wù)數(shù)據(jù)傳輸?shù)倪^程中，CRF收到AF的計費相關(guān)輸入信息后，根據(jù)AF提供的輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，然后主動向TPF下發(fā)選定的計費規(guī)則。對于AF向CRF提供計費輸入信息的具體實現(xiàn)過程如圖4所示步驟401AF向CRF發(fā)送應(yīng)用/業(yè)務(wù)計費相關(guān)信息(SendApplication/Service Data Flow Charging Information)。
步驟402CRF收到應(yīng)用/業(yè)務(wù)計費相關(guān)信息后，向AF返回響應(yīng)(Ack)，通知AF已收到其發(fā)送的計費相關(guān)輸入信息。
圖5為CRF主動向TPF下發(fā)計費規(guī)則流程圖，如圖5所示，CRF主動向TPF下發(fā)計費規(guī)則的實現(xiàn)過程包括以下步驟步驟501CRF收到某個內(nèi)部或外部的觸發(fā)事件(Internal or ExternalTrigger Event)，以及與該事件相關(guān)的信息，如AF向CRF發(fā)送計費規(guī)則選擇輸入信息的事件。
步驟502CRF根據(jù)獲取的信息選擇相應(yīng)的計費規(guī)則。這些信息可為AF提供的計費相關(guān)輸入信息，例如，用戶使用AF提供的某一業(yè)務(wù)，該業(yè)務(wù)對計費有特殊要求，如計費費率與其他業(yè)務(wù)的計費費率不同，因此，AF向CRF提供與該業(yè)務(wù)相關(guān)的計費信息；也可為TPF提供的計費相關(guān)輸入信息。
步驟503如果需要的話，CRF向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟504TPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則。
對于目前3GPP規(guī)范中定義的TPF與CRF關(guān)于計費規(guī)則的交互方式是在一定的觸發(fā)事件發(fā)生時，如承載需要建立、修改或刪除時，TPF向CRF發(fā)送計費規(guī)則請求，CRF根據(jù)計費規(guī)則請求中攜帶的信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF下發(fā)選定的計費規(guī)則。這樣，請求計費規(guī)則的事件點是由TPF進(jìn)行控制的，在TPF中預(yù)先配置請求計費規(guī)則的事件點，如設(shè)置請求計費規(guī)則的事件點為當(dāng)承載建立、修改以及刪除時，均需要TPF向CRF請求計費規(guī)則。但是，對于一些情況下，當(dāng)承載修改時，如修改QoS參數(shù)時，修改后的QoS參數(shù)與原有的QoS參數(shù)相差不大，還沒有達(dá)到需要修改計費規(guī)則的級別，如果此時TPF仍然向CRF請求計費規(guī)則，則CRF會選擇一個原計費規(guī)則相同的計費規(guī)則下發(fā)給TPF，這樣，必然導(dǎo)致TPF與CRF之間生成大量冗余信息。
由以上描述可見，在3GPP規(guī)范中，CRF雖然是計費規(guī)則的控制點，卻并不能夠?qū)崿F(xiàn)對計費的完全控制。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法，使得對分組數(shù)據(jù)業(yè)務(wù)計費的控制更為合理完善。
為了達(dá)到上述目的，本發(fā)明提供了一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法，該方法包含
A、設(shè)置觸發(fā)事件點；B、所述觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求。
所述步驟A為CRF設(shè)置觸發(fā)事件點，并向TPF發(fā)送所述觸發(fā)事件點。
所述步驟A之前進(jìn)一步包括A0、在TPF中配置靜態(tài)觸發(fā)事件點，所述靜態(tài)觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求。
所述靜態(tài)觸發(fā)事件點發(fā)生之前進(jìn)一步包括TPF監(jiān)測所述靜態(tài)觸發(fā)事件點的發(fā)生。
步驟A0中所述計費規(guī)則請求中攜帶有用于標(biāo)明靜態(tài)觸發(fā)事件點的事件標(biāo)識。
所述步驟A為CRF收到計費規(guī)則請求后，設(shè)置動態(tài)觸發(fā)事件點，并向TPF發(fā)送所述動態(tài)觸發(fā)事件點。
所述步驟A0之后進(jìn)一步包括CRF向TPF提供計費規(guī)則。
所述步驟B之前進(jìn)一步包括TPF存儲所述觸發(fā)事件點，并監(jiān)測所述觸發(fā)事件點的發(fā)生。
步驟B中所述計費規(guī)則請求中攜帶有用于標(biāo)明觸發(fā)事件點的事件標(biāo)識。
所述步驟B之后進(jìn)一步包括CRF向TPF提供計費規(guī)則。
CRF根據(jù)發(fā)生的觸發(fā)事件點確定所述計費規(guī)則。
所述觸發(fā)事件點為CRF根據(jù)自身存儲信息進(jìn)行設(shè)置。
所述觸發(fā)事件點為CRF根據(jù)AF，或OCS，或TPF，或以上所述任意組合提供的計費相關(guān)輸入信息設(shè)置。
本發(fā)明中，由CRF確定需要TPF向其請求計費規(guī)則的觸發(fā)事件點，然后向TPF下發(fā)這些觸發(fā)事件點，當(dāng)觸發(fā)事件點發(fā)生時，TPF向CRF請求計費規(guī)則并提供計費相關(guān)輸入信息，CRF根據(jù)計費相關(guān)輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF下發(fā)選定的計費規(guī)則，這樣，可實現(xiàn)CRF對TPF向其請求計費規(guī)則的時機進(jìn)行控制，避免了由于TPF在不必要的時候向CRF請求計費規(guī)則而導(dǎo)致的冗余信息，使得TPF與CRF之間的信息交互更為有效，對于分組數(shù)據(jù)業(yè)務(wù)計費的控制更為合理完善。
另外，由于CRF能夠獲取AF或OCS提供的計費相關(guān)輸入信息，這些計費相關(guān)輸入信息可能對計費規(guī)則產(chǎn)生影響，根據(jù)本發(fā)明提出的方法，CRF可根據(jù)這些計費相關(guān)輸入信息靈活設(shè)置觸發(fā)事件點，然后向FPF下發(fā)當(dāng)前設(shè)置的觸發(fā)事件點，使得TPF能夠在滿足一定條件時，即觸發(fā)事件點發(fā)生時，向CRF請求新的計費規(guī)則，這樣，使得計費規(guī)則的應(yīng)用更為靈活豐富，這些功能通過現(xiàn)有TPF與CRF的交互是根本無法實現(xiàn)的。


圖1為PDP Context激活、傳輸數(shù)據(jù)、去激活流程圖；圖2A為在線計費的FBC系統(tǒng)結(jié)構(gòu)示意圖；圖2B為離線計費的FBC系統(tǒng)結(jié)構(gòu)示意圖；圖3A為承載建立時下發(fā)計費規(guī)則流程圖；圖3B為承載修改時下發(fā)計費規(guī)則流程圖；圖3C為承載刪除時下發(fā)計費規(guī)則流程圖；圖4為AF向CRF提供計費輸入信息流程圖；圖5為CRF主動向TPF下發(fā)計費規(guī)則流程圖；圖6為本發(fā)明中CRF控制TPF發(fā)送計費規(guī)則請求流程圖；圖7為本發(fā)明中實施例一示意圖；圖8為本發(fā)明中實施例二示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖對本發(fā)明作進(jìn)一步的詳細(xì)描述。
本發(fā)明中，由CRF確定需要TPF向其請求計費規(guī)則的觸發(fā)事件點，然后向TPF下發(fā)這些觸發(fā)事件點，當(dāng)觸發(fā)事件點發(fā)生時，TPF向CRF請求計費規(guī)則并提供計費相關(guān)輸入信息，CRF根據(jù)計費相關(guān)輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF下發(fā)選定的計費規(guī)則。這樣，CRF可根據(jù)計費規(guī)則、計費模式靈活設(shè)置觸發(fā)事件點，實現(xiàn)CRF對計費的完全控制，使得TPF能夠有效地向CRF請求計費規(guī)則，避免了TPF與CRF之間冗余信息的生成。
圖6為本發(fā)明中CRF控制TPF發(fā)送計費規(guī)則請求流程圖，如圖6所示，CRF控制TPF發(fā)送計費規(guī)則請求的實現(xiàn)過程包括以下步驟步驟601在TPF中配置向CRF請求計費規(guī)則的靜態(tài)觸發(fā)事件點，如承載建立，當(dāng)靜態(tài)觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有計費相關(guān)輸入信息，如與用戶和UE相關(guān)的信息、承載特性以及與網(wǎng)絡(luò)相關(guān)的信息等；該計費規(guī)則請求中還可攜帶有事件標(biāo)識，用于指示當(dāng)前計費規(guī)則請求為靜態(tài)觸發(fā)事件點觸發(fā)的。
另外，可在TPF中配置多個靜態(tài)觸發(fā)事件點，如承載建立、承載刪除等，當(dāng)其中一個靜態(tài)觸發(fā)事件點發(fā)生時，TPF向CRF請求計費規(guī)則。
步驟602CRF收到計費規(guī)則請求后，設(shè)置要求TPF請求計費規(guī)則的動態(tài)觸發(fā)事件點，然后向TPF發(fā)送動態(tài)觸發(fā)事件點上報請求，該動態(tài)觸發(fā)事件點上報請求中攜帶有設(shè)置的動態(tài)觸發(fā)事件點列表，動態(tài)觸發(fā)事件點A、動態(tài)觸發(fā)事件點B、動態(tài)觸發(fā)事件點C等等，可為承載修改、劃分的QoS參數(shù)修改的不同級別段、承載刪除等動態(tài)觸發(fā)事件點。
步驟603CRF根據(jù)計費規(guī)則請求中攜帶的計費相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則，如計費規(guī)則1。
步驟602和步驟603中CRF向TPF發(fā)送的各信息可通過一條消息承載。
步驟604TPF收到動態(tài)事件點列表和CRF當(dāng)前選定的計費規(guī)則后，存儲動態(tài)觸發(fā)事件點列表，根據(jù)該計費規(guī)則進(jìn)行計費信息統(tǒng)計，并監(jiān)測動態(tài)觸發(fā)事件點的發(fā)生。
步驟605TPF監(jiān)測到動態(tài)觸發(fā)事件點A發(fā)生，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有動態(tài)觸發(fā)事件點A發(fā)生指示。
步驟606CRF收到計費規(guī)則請求后，根據(jù)動態(tài)觸發(fā)事件點A發(fā)生指示確定該計費規(guī)則請求是由動態(tài)觸發(fā)事件點A觸發(fā)的，并根據(jù)動態(tài)觸發(fā)事件點A選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的新的計費規(guī)則，如計費規(guī)則2。
步驟607TPF收到提供計費規(guī)則后，根據(jù)該計費規(guī)則進(jìn)行計費信息統(tǒng)計。
如果有多個動態(tài)觸發(fā)事件點，則TPF繼續(xù)監(jiān)測其余的動態(tài)觸發(fā)事件點的發(fā)生。
步驟608TPF監(jiān)測到動態(tài)觸發(fā)事件點B發(fā)生，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有動態(tài)觸發(fā)事件點B發(fā)生指示。
步驟609CRF收到計費規(guī)則請求后，根據(jù)動態(tài)觸發(fā)事件點B發(fā)生指示確定該計費規(guī)則請求是由動態(tài)觸發(fā)事件點B觸發(fā)的，并根據(jù)動態(tài)觸發(fā)事件點B選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的新的計費規(guī)則，如計費規(guī)則3。
步驟610TPF收到提供計費規(guī)則后，根據(jù)該計費規(guī)則進(jìn)行計費信息統(tǒng)計。
后續(xù)流程與上述流程相似，不再贅述。
另外，在同一個會話中，對于GPRS網(wǎng)絡(luò)，同一個會話即為同一個PDPContext，CRF可多次設(shè)置動態(tài)觸發(fā)事件點并發(fā)送給TPF。例如，CRF收到AF或是OCS的計費相關(guān)輸入信息時，可根據(jù)計費相關(guān)輸入信息確定是否需要設(shè)置新的動態(tài)觸發(fā)事件點，如果是，則設(shè)置新的動態(tài)觸發(fā)事件點并發(fā)送給TPF，TPF收到新的動態(tài)觸發(fā)事件點后，存儲新的動態(tài)觸發(fā)事件點并監(jiān)測動態(tài)觸發(fā)事件點的發(fā)生。
另外，由于在TPF中可配置向CRF請求計費規(guī)則的靜態(tài)觸發(fā)事件點，對于一些比較固化的事件，如承載建立，承載QoS修改，流量或者時間長度到達(dá)某一個固定的值，承載刪除等等，可直接通過在TPF中預(yù)先配置靜態(tài)事件點來向CRF上報承載的變化信息。而不需要CRF向TPF下發(fā)動態(tài)事件點。對于一些運營商或業(yè)務(wù)提供商對承載變化的事件很固定，如總是要求業(yè)務(wù)流量達(dá)到10M時TPF向CRF上報，或是總是要求業(yè)務(wù)激活時長達(dá)到100分鐘后TPF向CRF上報，而沒有其它需要動態(tài)配置的事件點，這樣，只在TPF中預(yù)先配置相應(yīng)的靜態(tài)事件點就可以實現(xiàn)，CRF不下發(fā)任何動態(tài)事件點，可以減輕TPF和CRF之間的信令負(fù)荷。
圖7為本發(fā)明中實施例一示意圖，本實施例中將TPF向CRF請求計費規(guī)則的靜態(tài)觸發(fā)事件點設(shè)置為承載建立，CRF將需要TPF向其請求計費規(guī)則的動態(tài)觸發(fā)事件點設(shè)置為承載修改和承載刪除，CRF控制TPF發(fā)送計費規(guī)則請求的實現(xiàn)過程包括以下步驟步驟701UE向TPF發(fā)送承載建立請求，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Create PDP Context Request。
步驟702TPF收到承載建立請求后，確定靜態(tài)觸發(fā)事件點已發(fā)生，然后向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有計費相關(guān)輸入信息，如與用戶和UE相關(guān)的信息、承載特性以及與網(wǎng)絡(luò)相關(guān)的信息等；該計費規(guī)則請求中還可攜帶有事件標(biāo)識，用于指示當(dāng)前計費規(guī)則請求為靜態(tài)觸發(fā)事件點觸發(fā)的。
步驟703～步驟704CRF收到計費規(guī)則請求后，根據(jù)事件標(biāo)識確定該計費規(guī)則請求是由靜態(tài)觸發(fā)事件點觸發(fā)的，然后設(shè)置動態(tài)觸發(fā)事件點列表包括承載修改和承載刪除，并向TPF發(fā)送動態(tài)觸發(fā)事件點上報請求(RequestDynamic Event Report)，該動態(tài)觸發(fā)事件點上報請求中攜帶有動態(tài)觸發(fā)事件點列表。另外，CRF還可在承載修改的動態(tài)觸發(fā)事件點中設(shè)置多個不同的值，如不同的QoS參數(shù)級別，每個值均可作為一個獨立的動態(tài)觸發(fā)事件點。
步驟705～步驟706CRF根據(jù)計費規(guī)則請求中攜帶的計費相關(guān)輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則(Charging RuleResponse)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟707～步驟708TPF收到CRF設(shè)置的動態(tài)觸發(fā)事件點列表和CRF選定的計費規(guī)則后，存儲動態(tài)觸發(fā)事件點列表，根據(jù)計費規(guī)則進(jìn)行計費信息統(tǒng)計，并監(jiān)測動態(tài)觸發(fā)事件點的發(fā)生。TPF向UE返回承載建立響應(yīng)，接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程。
步驟709一段時間后，UE向TPF發(fā)送承載修改請求，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Update PDP Context Request。
步驟710TPF收到承載修改請求后，確定動態(tài)觸發(fā)事件點列表中的動態(tài)觸發(fā)事件點承載修改已發(fā)生，然后向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有動態(tài)觸發(fā)事件點發(fā)生指示。
步驟711～步驟712CRF收到計費規(guī)則請求后，根據(jù)動態(tài)觸發(fā)事件點發(fā)生指示確定該計費規(guī)則請求是由動態(tài)觸發(fā)事件點承載修改觸發(fā)的，并根據(jù)承載修改選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟713～步驟714TPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則，然后向UE返回承載修改響應(yīng)，接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程。
步驟715一段時間后，UE向TPF發(fā)送承載刪除請求，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Delete PDP Context Request。
步驟716TPF收到承載刪除請求后，確定動態(tài)觸發(fā)事件點列表中的動態(tài)觸發(fā)事件點承載刪除已發(fā)生，然后向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有動態(tài)觸發(fā)事件點發(fā)生指示。
步驟717～步驟718CRF收到計費規(guī)則請求后，根據(jù)動態(tài)觸發(fā)事件點發(fā)生指示確定該計費規(guī)則請求是由動態(tài)觸發(fā)事件點承載刪除觸發(fā)的，并根據(jù)承載刪除選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟719～步驟720TPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則，然后向UE返回承載刪除響應(yīng)，接受UE發(fā)起的承載刪除請求，并繼續(xù)后續(xù)的承載刪除流程。
現(xiàn)有技術(shù)中，AF可向CRF發(fā)送應(yīng)用/業(yè)務(wù)計費相關(guān)信息，作為CRF選擇計費規(guī)則的計費相關(guān)輸入信息；那么，根據(jù)本發(fā)明提出的方法，AF可向CRF發(fā)送應(yīng)用/業(yè)務(wù)計費相關(guān)信息，作為CRF動態(tài)設(shè)置動態(tài)觸發(fā)事件點的輸入信息。
圖8為本發(fā)明中實施例二示意圖，如圖8所示，本實施例中，CRF向TPF下發(fā)動態(tài)觸發(fā)事件點的實現(xiàn)過程包括以下步驟步驟801CRF收到某個內(nèi)部或外部的觸發(fā)事件，如AF為用戶提供積分活動，如果用戶訪問該AF的某個業(yè)務(wù)的數(shù)據(jù)流量達(dá)到一定數(shù)值，則這個用戶訪問該業(yè)務(wù)的后續(xù)計費費率將降低，此時，AF要求CRF在某個業(yè)務(wù)過濾器的數(shù)據(jù)流量達(dá)到一定值時，采用優(yōu)惠的計費費率對后續(xù)的數(shù)據(jù)流量進(jìn)行計費信息統(tǒng)計，或如果用戶訪問該AF的某個業(yè)務(wù)的使用時間長度達(dá)到一定數(shù)值，則這個用戶訪問該業(yè)務(wù)的后續(xù)計費費率將降低，此時，AF要求CRF在某個業(yè)務(wù)過濾器的使用時間長度達(dá)到一定值時，采用優(yōu)惠的計費費率對后續(xù)的數(shù)據(jù)流量進(jìn)行計費信息統(tǒng)計。
步驟802CRF配置動態(tài)觸發(fā)事件點，例如，設(shè)置動態(tài)觸發(fā)事件點為某個業(yè)務(wù)過濾器的數(shù)據(jù)流量達(dá)到一定值，或設(shè)置動態(tài)觸發(fā)事件點為某個業(yè)務(wù)過濾器的業(yè)務(wù)使用時間長度達(dá)到一定值。另外，CRF可根據(jù)當(dāng)前獲知的信息，如TPF提供的用戶/終端信息，承載特性，網(wǎng)絡(luò)相關(guān)信息等選擇適當(dāng)?shù)挠嬞M規(guī)則。
步驟803CRF向TPF發(fā)送動態(tài)觸發(fā)事件點上報請求，該動態(tài)觸發(fā)事件點上報請求中攜帶有當(dāng)前設(shè)置的動態(tài)觸發(fā)事件點列表，要求TPF在動態(tài)觸發(fā)事件點發(fā)生時，向其請求計費規(guī)則。
步驟804CRF向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有當(dāng)前選定的計費規(guī)則，該步驟為可選步驟。
步驟805TPF收到CRF當(dāng)前設(shè)置的動態(tài)觸發(fā)事件點列表，存儲該動態(tài)觸發(fā)事件點列表。如果TPF還收到提供計費規(guī)則，則根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則。
步驟806一段時間后，TPF監(jiān)測到動態(tài)觸發(fā)事件點發(fā)生，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有動態(tài)觸發(fā)事件點發(fā)生指示。
步驟807～步驟808CRF收到計費規(guī)則請求后，根據(jù)動態(tài)觸發(fā)事件點發(fā)生指示可確定該計費規(guī)則請求是由哪一個動態(tài)觸發(fā)事件點觸發(fā)的，例如，某個業(yè)務(wù)過濾器的數(shù)據(jù)流量已經(jīng)達(dá)到一定值，或某個業(yè)務(wù)過濾器的業(yè)務(wù)使用時間長度已經(jīng)達(dá)到一定值，并根據(jù)該動態(tài)觸發(fā)事件點選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則。
步驟809TPF收到提供計費規(guī)則后，根據(jù)CRF選定的計費規(guī)則，建立新的計費規(guī)則，或是刪除原有的計費規(guī)則，或是刪除原有計費規(guī)則的同時建立新的計費規(guī)則。
另外，CRF也可根據(jù)OCS發(fā)送的與用戶信用相關(guān)的計費相關(guān)輸入信息，對動態(tài)觸發(fā)事件點進(jìn)行動態(tài)設(shè)置，相應(yīng)的流程與上述流程基本相同，在此不再贅述。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
1.一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法，其特征在于，該方法包含以下步驟A、設(shè)置觸發(fā)事件點；B、所述觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A為CRF設(shè)置觸發(fā)事件點，并向TPF發(fā)送所述觸發(fā)事件點。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述步驟A之前進(jìn)一步包括A0、在TPF中配置靜態(tài)觸發(fā)事件點，所述靜態(tài)觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述靜態(tài)觸發(fā)事件點發(fā)生之前進(jìn)一步包括TPF監(jiān)測所述靜態(tài)觸發(fā)事件點的發(fā)生。
5.根據(jù)權(quán)利要求3所述的方法，其特征在于，步驟A0中所述計費規(guī)則請求中攜帶有用于標(biāo)明靜態(tài)觸發(fā)事件點的事件標(biāo)識。
6.根據(jù)權(quán)利要求3、4或5所述的方法，其特征在于，所述步驟A為CRF收到計費規(guī)則請求后，設(shè)置動態(tài)觸發(fā)事件點，并向TPF發(fā)送所述動態(tài)觸發(fā)事件點。
7.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述步驟A0之后進(jìn)一步包括CRF向TPF提供計費規(guī)則。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟B之前進(jìn)一步包括TPF存儲所述觸發(fā)事件點，并監(jiān)測所述觸發(fā)事件點的發(fā)生。
9.根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中所述計費規(guī)則請求中攜帶有用于標(biāo)明觸發(fā)事件點的事件標(biāo)識。
10.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟B之后進(jìn)一步包括CRF向TPF提供計費規(guī)則。
11.根據(jù)權(quán)利要求10所述的方法，其特征在于，CRF根據(jù)發(fā)生的觸發(fā)事件點確定所述計費規(guī)則。
12.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述觸發(fā)事件點為CRF根據(jù)自身存儲信息進(jìn)行設(shè)置。
13.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述觸發(fā)事件點為CRF根據(jù)AF，或OCS，或TPF，或以上所述任意組合提供的計費相關(guān)輸入信息設(shè)置。
全文摘要
本發(fā)明公開了一種分組數(shù)據(jù)業(yè)務(wù)的計費控制方法，該方法包含設(shè)置觸發(fā)事件點；觸發(fā)事件點發(fā)生時，TPF向CRF發(fā)送計費規(guī)則請求。本發(fā)明中，由CRF確定需要TPF向其請求計費規(guī)則的觸發(fā)事件點，然后向TPF下發(fā)這些觸發(fā)事件點，當(dāng)觸發(fā)事件點發(fā)生時，TPF向CRF請求計費規(guī)則并提供計費相關(guān)輸入信息，CRF根據(jù)計費相關(guān)輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則，并向TPF下發(fā)選定的計費規(guī)則，這樣，可實現(xiàn)CRF對TPF向其請求計費規(guī)則的時機進(jìn)行控制，避免了由于TPF在不必要的時候向CRF請求計費規(guī)則而導(dǎo)致的冗余信息，使得TPF與CRF之間的信息交互更為有效，對于分組數(shù)據(jù)業(yè)務(wù)計費的控制更為合理完善。
文檔編號H04L12/14GK1645805SQ20041003372
公開日2005年7月27日 申請日期2004年4月9日 優(yōu)先權(quán)日2004年4月1日
發(fā)明者段小琴 申請人:華為技術(shù)有限公司