專利名稱：一種基于分組數(shù)據(jù)流計費的對話號分配方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分組數(shù)據(jù)計費領(lǐng)域，特別是指一種基于分組數(shù)據(jù)流計費的對話號分配方法。
背景技術(shù)：
隨著分組數(shù)據(jù)業(yè)務(wù)應(yīng)用的逐漸廣泛，如何準(zhǔn)確合理地對分組數(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 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ù)流，當(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ī)則中包括計費機制、計費類型、計費鍵、業(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é)議標(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ī)則。
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由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對用戶信用進行管理和控制，當(dāng)用戶使用業(yè)務(wù)時，CCF(Service Data Flow Based Credit ControlFunction)202對該用戶信用池中的信用進行鑒權(quán)，并通過Gy接口向TPF 205下發(fā)用戶能夠使用的信用。
對應(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ī)則的控制點。
目前，規(guī)范中定義了在CRF和TPF之間通過對話的方式進行通信，并且不同對話通過對話號進行標(biāo)識，即當(dāng)承載建立時，TPF向CRF請求計費規(guī)則，通過對話號標(biāo)識TPF和CRF之間建立的對話。在后續(xù)承載修改、承載刪除的過程中，TPF需要向CRF重新請求計費規(guī)則時，TPF通過對話號標(biāo)識當(dāng)前計費規(guī)則請求是基于先前建立的對話之間的對應(yīng)關(guān)系；同樣地，CRF需要主動向TPF提供計費規(guī)則時，如CRF收到AF或OCS提供的用于確定計費規(guī)則的輸入信息，CRF也需要通過對話號標(biāo)識當(dāng)前提供的計費規(guī)則與先前建立的對話之間的對應(yīng)關(guān)系。
在兩個實體間建立對話的意義在于在兩個實體間建立狀態(tài)機，這樣，兩個實體在進行后續(xù)交互時可直接使用狀態(tài)機中的數(shù)據(jù)，而無需在每次交互時都提供相關(guān)信息。例如，承載建立時，TPF需向CRF提供用戶信息、承載屬性、網(wǎng)絡(luò)信息等相關(guān)信息，TPF與CRF之間建立對話后，TPF和CRF均會存儲這些相關(guān)信息，在TPF與CRF之間后續(xù)的交互過程中，如承載修改、承載刪除等過程，發(fā)送方無需再向接收方提供這些相關(guān)信息，而是僅僅提供對話號標(biāo)識出相應(yīng)的對話即可。
雖然規(guī)范中定義了在CRF和TPF之間通過對話的方式進行通信，但規(guī)范中并未指出用于標(biāo)識對話的對話號是如何分配的，導(dǎo)致了現(xiàn)有流程在實現(xiàn)上的不確定性。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的在于提供一種基于分組數(shù)據(jù)流計費的對話號分配方法，使得基于分組數(shù)據(jù)流計費的各流程的實現(xiàn)更為完整。
為了達到上述目的，本發(fā)明提供了一種基于分組數(shù)據(jù)流計費的對話號分配方法，該方法包含以下步驟A1、消息發(fā)送方分配對話號。
所述步驟A1之后進一步包括
B1、消息發(fā)送方向消息接收方提供分配的對話號。
所述消息發(fā)送方為TPF。
所述消息接收方為CRF，所述步驟B1為TPF向CRF提供分配的對話號，所述對話號攜帶在計費規(guī)則請求中。
所述步驟B1之后進一步包括CRF向TPF提供計費規(guī)則時，進一步向TPF提供所述對話號。
所述消息接收方為OCS，所述步驟B1為TPF向OCS提供分配的對話號，所述對話號攜帶在信用請求中。
所述步驟B1之后進一步包括CRF向TPF返回用戶的信用時，進一步向TPF提供所述對話號。
所述步驟B1之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
本發(fā)明還提供了一種基于分組數(shù)據(jù)流計費的對話號分配方法，該方法包含A2、消息接收方分配對話號。
所述步驟A2之后進一步包括B2、消息接收方向消息發(fā)送方提供分配的對話號。
所述消息接收方為CRF。
所述消息接收方為CRF，所述步驟B2為CRF向TPF提供分配的對話號，所述對話號攜帶在提供計費規(guī)則的消息中。
所述消息接收方為OCS。
所述消息發(fā)送方為TPF，所述步驟B2為OCS向TPF提供分配的對話號，所述對話號攜帶在提供用戶信用的消息中。
所述步驟B2之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
本發(fā)明又提供了一種基于分組數(shù)據(jù)流計費的對話號分配方法，該方法包含以下步驟A3、消息發(fā)送方分配第一部分對話號；B3、消息接收方分配第二部分對話號，所述第一部分對話號和第二部分對話號構(gòu)成完整對話號。
所述步驟A3進一步包括消息發(fā)送方向消息接收方提供分配的第一部分對話號；所述步驟B3為消息接收方分配第二部分對話號，將分配的第二部分對話號與接收的第一部分對話號構(gòu)成完整對話號。
所述步驟B3之后進一步包括C3、消息接收方向消息發(fā)送方提供完整對話號。
所述消息發(fā)送方為TPF，所述消息接收方為CRF，所述步驟A3為TPF向CRF提供分配的第一部分對話號，所述第一部分對話號攜帶在計費規(guī)則請求中。
所述步驟C3為CRF向TPF提供完整對話號，所述完整對話號攜帶在提供計費規(guī)則的消息中。
所述消息發(fā)送方為TPF，所述消息接收方為OCS，所述步驟A3為TPF向OCS提供分配的第一部分對話號，所述第一部分對話號攜帶在信用請求中。
所述步驟C3為OCS向TPF提供完整對話號，所述完整對話號攜帶在提供用戶信用的消息中。
所述步驟C3之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
根據(jù)本發(fā)明，在基于分組數(shù)據(jù)流的計費中，明確了對話號的分配實體，通過對話號能夠唯一標(biāo)識消息發(fā)送方和消息接收方之間的對話，使得基于分組數(shù)據(jù)流計費的各流程的實現(xiàn)更為完整。并且，本發(fā)明中提供了多種對話號的分配方法，為實際應(yīng)用提供了靈活的選擇。


圖1示出了PDP Context激活、數(shù)據(jù)傳輸、去激活流程圖；圖2A示出了支持在線計費的FBC系統(tǒng)結(jié)構(gòu)圖；圖2B示出了支持離線計費的FBC系統(tǒng)結(jié)構(gòu)圖；圖3示出了消息發(fā)送方分配對話號的過程示意圖；圖4示出了消息接收方分配對話號的過程示意圖；圖5示出了消息發(fā)送方和消息接收方共同分配對話號的過程示意圖；圖6示出了對話號的一種應(yīng)用實例示意圖；圖7示出了對話號的另一種應(yīng)用實例示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面結(jié)合附圖對本發(fā)明作進一步的詳細描述。
本發(fā)明中，在基于分組數(shù)據(jù)流計費的實現(xiàn)過程中，建立對話時，可由消息發(fā)送方分配對話號，然后提供給消息接收方；也可由消息接收方分配對話號，然后提供給消息發(fā)送方，兩方之間后續(xù)的交互過程中，消息發(fā)送方和消息接收方使用分配的對話號標(biāo)識二者之間一次對話中交互的信息。以上所述的消息發(fā)送方是指最初發(fā)送消息的一方。以上所述的消息發(fā)送方為TPF，消息接收方為CRF；或消息接收方為TPF，消息接收方為OCS，等等。
為保證分配的對話號的唯一性，分配的對話號可為分配對話號的網(wǎng)絡(luò)實體的地址信息與隨機數(shù)的組合，分配方的地址信息可為IP地址或七號信令網(wǎng)中網(wǎng)絡(luò)實體的地址信息。
圖3示出了消息發(fā)送方分配對話號的過程示意圖，如圖3所示，消息發(fā)送方分配對話號的實現(xiàn)過程包括以下步驟步驟301用戶設(shè)備(UE)向TPF發(fā)送承載建立請求(Establish BearerService Request)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到Create PDP ContextRequest。
步驟302TPF收到承載建立請求后，為當(dāng)前對話分配對話號，然后向CRF發(fā)送計費規(guī)則請求(Request Charging Rules)，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息和分配的對話號。
步驟303CRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，如果為在線計費方式，也可根據(jù)OCS提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則。
步驟304CRF選擇了適當(dāng)?shù)挠嬞M規(guī)則后，向TPF返回提供計費規(guī)則(Provision Charging Rules)，作為計費規(guī)則請求的響應(yīng)，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則、計費規(guī)則操作指示和TPF在步驟302中分配的對話號，通過該對話號標(biāo)識當(dāng)前計費規(guī)則響應(yīng)與先前計費規(guī)則請求之間的對應(yīng)關(guān)系。
步驟305TPF收到提供計費規(guī)則后，根據(jù)對話號索引到相應(yīng)的對話，并根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，如果為在線計費方式，則繼續(xù)執(zhí)行步驟306～步驟308，如果為離線計費方式，則直接執(zhí)行步驟308。
步驟306TPF根據(jù)計費規(guī)則中的在線計費指示，為當(dāng)前對話分配對話號，然后向OCS發(fā)送信用請求(Credit Request)，向OCS請求用戶的信用信息。
步驟307OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)(Credit Response)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用和TPF在步驟306中分配的對話號；如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值和TPF在步驟306中分配的對話號，通過該對話號標(biāo)識當(dāng)前信用響應(yīng)與先前信用請求之間的對應(yīng)關(guān)系。
步驟308TPF向UE返回承載建立響應(yīng)(Establish Bearer ServiceAccept)，如果TPF能夠根據(jù)已有信息建立承載，如OCS返回了用戶的信用，則該承載建立響應(yīng)為承載建立成功響應(yīng)，TPF接受UE發(fā)起的承載建立請求，并繼續(xù)后續(xù)的承載建立流程；如果TPF無法根據(jù)已有信息建立承載，如OCS未返回用戶的信用，則該承載建立響應(yīng)為承載建立失敗響應(yīng)，TPF拒絕UE發(fā)起的承載建立請求。
圖4示出了消息接收方分配對話號的過程示意圖，如圖4所示，消息接收方分配對話號的實現(xiàn)過程包括以下步驟步驟401與步驟301相同。
步驟402TPF收到承載修改請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息。
步驟403與步驟303相同。
步驟404CRF選擇了適當(dāng)?shù)挠嬞M規(guī)則后，為當(dāng)前對話分配對話號，向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則、計費規(guī)則操作指示和分配的對話號。
步驟405與步驟305相同。
步驟406TPF根據(jù)計費規(guī)則中的在線計費指示，向OCS發(fā)送信用請求，向OCS請求用戶的信用。
步驟407OCS收到信用請求后，確定用戶的信用，并為當(dāng)前對話分配對話號，然后向TPF返回信用響應(yīng)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用和分配的對話號；如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值和分配的對話號。
步驟408與步驟308相同。
由于網(wǎng)絡(luò)組網(wǎng)的原因，消息發(fā)送方和接收方可能不屬于同一網(wǎng)絡(luò)中，因此，發(fā)送方和接收方之間的對話號需要保證全球唯一，這樣不同實體分配的對話號才不會重復(fù)，通信實體才能通過對話號正確索引到相應(yīng)的對話。通常，消息發(fā)送方和接收方可通過在標(biāo)識自身網(wǎng)絡(luò)實體的地址信息上增加隨機分配的序列號的方式進行對話號的分配，此時分配的對話號是全球唯一的。但是，由于用于標(biāo)識網(wǎng)絡(luò)實體地址的信息內(nèi)容都比較多，如果以分配對話號的網(wǎng)絡(luò)實體的地址信息作為對話號的一部分，則將使得對話號所含內(nèi)容過多，而在每條傳送的消息中都會攜帶對話號，可能會過多占用消息傳送實體的資源，因此，可由消息發(fā)送方和消息接收方共同分配對話號，例如，消息發(fā)送方將分配的自身實體中能夠唯一標(biāo)識一次對話的標(biāo)識信息作為部分對話號，填寫在完整對話號的固定位置上，如當(dāng)完整對話號為消息中的一個參數(shù)時，消息發(fā)送方固定地將分配的部分對話號填寫在完整對話號參數(shù)的前3位；又如，當(dāng)完整對話號為消息中的兩個參數(shù)時，消息發(fā)送方將分配的部分對話號填寫在消息中的消息發(fā)送方對話號參數(shù)上，然后向消息接收方提供其分配的部分對話號，消息接收方將分配的自身實體中能夠唯一標(biāo)識一次對話的標(biāo)識信息作為部分對話號，填寫在完整對話號的固定位置上，如當(dāng)完整對話號為消息中的一個參數(shù)時，消息接收方固定地將分配的部分對話號填寫在完整對話號參數(shù)的后3位；又如，當(dāng)完整對話號為消息中的兩個參數(shù)時，消息接收方將分配的部分對話號填寫在消息中的消息接收方對話號參數(shù)上。通過消息發(fā)送方和消息接收方共同分配的部分對話號構(gòu)成完整的對話號，用以在消息發(fā)送方和消息接收方之間傳遞，標(biāo)識一次對話中消息發(fā)送方和消息接收方二者之間一次對話中交互的信息。
圖5示出了消息發(fā)送方和消息接收方共同分配對話號的過程示意圖，如圖5所示，消息發(fā)送方和消息接收方共同分配對話號的實現(xiàn)過程包括以下步驟步驟501與步驟301相同。
步驟502TPF收到承載建立請求后，為當(dāng)前對話分配部分對話號，然后向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息和分配的部分對話號。
步驟503與步驟303相同。
步驟504CRF選擇了適當(dāng)?shù)挠嬞M規(guī)則后，為當(dāng)前對話分配部分對話號，與TPF在步驟502中分配的部分對話號構(gòu)成完整對話號，向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則、計費規(guī)則操作指示和TPF與CRF共同分配的完整對話號。
步驟505與步驟305相同。
步驟506TPF為當(dāng)前對話分配部分對話號，然后向OCS發(fā)送信用請求，向OCS請求用戶的信用信息。
步驟507OCS收到信用請求后，確定用戶的信用，并為當(dāng)前對話分配部分對話號，與TPF在步驟306中分配的部分對話號構(gòu)成完整對話號，然后向TPF返回信用響應(yīng)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用和TPF與OCS共同分配的完整對話號；如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值和TPF與OCS共同分配的完整對話號。
步驟508與步驟308相同。
為描述方便，在以上每幅附圖中將TPF與OCS之間分配對話號的方式，描述為與TPF與CRF之間分配對話號的方式相同，實際應(yīng)用中，TPF與OCS之間分配對話號的方式與TPF與CRF之間分配對話號的方式無任何關(guān)系，可相同也可不同，均可任意選取具體的對話號分配方式。
圖6示出了對話號的一種應(yīng)用實例示意圖，如圖6所示，本實例中，承載修改時，可應(yīng)用先前分配的對話號標(biāo)識一次對話中消息發(fā)送方與消息接收方之間交互的信息，具體描述如下步驟601UE向TPF發(fā)送承載修改請求(Modify Bearer ServiceRequest)，在GPRS網(wǎng)絡(luò)中，則是GGSN收到PDP Context更新請求(UpdatePDP Context Request)。
步驟602TPF收到承載修改請求后，向CRF發(fā)送計費規(guī)則請求，該計費規(guī)則請求中攜帶有供CRF確定計費規(guī)則的輸入信息和先前分配的對話號，用以標(biāo)識當(dāng)前消息與先前建立的對話之間的對應(yīng)關(guān)系。
步驟603～步驟604CRF收到計費規(guī)則請求后，根據(jù)該計費規(guī)則請求中攜帶的輸入信息，還可根據(jù)AF提供的相關(guān)輸入信息，選擇適當(dāng)?shù)挠嬞M規(guī)則，然后向TPF返回提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則、計費規(guī)則操作指示和相應(yīng)對話號。
步驟605TPF收到提供計費規(guī)則后，根據(jù)對話號索引到相應(yīng)的對話，并根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，如果為在線計費方式，則繼續(xù)執(zhí)行步驟606～步驟608，如果為離線計費方式，則直接執(zhí)行步驟608。
步驟606～步驟607TPF根據(jù)計費規(guī)則中的在線計費指示，向OCS發(fā)送信用控制請求(Credit Control Request)，向OCS請求用戶的信用，該信用控制請求中攜帶有先前分配的對話號，用以標(biāo)識當(dāng)前消息與先前建立的對話之間的對應(yīng)關(guān)系。OCS收到信用控制請求后，確定用戶的信用，然后向TPF返回信用控制響應(yīng)(Credit Control Response)，如果OCS確定出用戶的信用，則該信用控制響應(yīng)中攜帶有用戶的信用和相應(yīng)對話號，如果OCS未確定出用戶的信用，則該信用控制響應(yīng)中可攜帶有差錯原因值和相應(yīng)對話號。
步驟608TPF向UE返回承載修改響應(yīng)(Modify Bearer Service Accept)，如果TPF能夠根據(jù)已有信息對承載進行修改，如OCS返回了用戶的信用，則該承載修改響應(yīng)為承載修改成功響應(yīng)，TPF接受UE發(fā)起的承載修改請求，并繼續(xù)后續(xù)的承載修改流程；如果TPF無法根據(jù)已有信息對承載進行修改，如OCS未返回用戶的信用，則該承載修改響應(yīng)為承載修改失敗響應(yīng)，TPF拒絕UE發(fā)起的承載修改請求。
圖7示出了對話號的另一種實例應(yīng)用示意圖，如圖7所示，本實例中，CRF主動向TPF下發(fā)計費規(guī)則時，可應(yīng)用先前分配的對話號標(biāo)識一次對話中消息發(fā)送方與消息接收方之間交互的信息，具體描述如下
步驟701CRF收到某個內(nèi)部或外部的觸發(fā)事件(Internal or ExternalTrigger Event)，以及與該事件相關(guān)的信息，如AF向CRF發(fā)送計費規(guī)則選擇輸入信息的事件。
步驟702CRF根據(jù)獲取的輸入信息選擇適當(dāng)?shù)挠嬞M規(guī)則。這些輸入信息可為AF提供的計費相關(guān)輸入信息，例如，用戶使用AF提供的某一業(yè)務(wù)，該業(yè)務(wù)對計費有特殊要求，如計費費率與其他業(yè)務(wù)的計費費率不同，因此，AF向CRF提供與該業(yè)務(wù)相關(guān)的計費輸入信息；也可為TPF提供的計費相關(guān)輸入信息。
步驟703如果計費規(guī)則發(fā)生變化，CRF向TPF發(fā)送提供計費規(guī)則，該提供計費規(guī)則中可攜帶有選定的計費規(guī)則、計費規(guī)則操作指示和先前分配的對話號，用以標(biāo)識當(dāng)前消息與先前建立的對話之間的對應(yīng)關(guān)系。
步驟704TPF收到提供計費規(guī)則后，根據(jù)對話號索引到相應(yīng)的對話，并根據(jù)計費規(guī)則操作指示對CRF選定的計費規(guī)則進行相應(yīng)操作，如果為在線計費方式，則繼續(xù)執(zhí)行步驟705～步驟706。
步驟705～步驟706TPF根據(jù)計費規(guī)則中的在線計費指示，向OCS發(fā)透信用請求，向OCS請求用戶的信用信息，該信用請求中攜帶有先前分配的對話號，用以標(biāo)識當(dāng)前消息與先前建立的對話之間的對應(yīng)關(guān)系。OCS收到信用請求后，確定用戶的信用，然后向TPF返回信用響應(yīng)，如果OCS確定出用戶的信用，則該信用響應(yīng)中攜帶有用戶的信用和相應(yīng)對話號，如果OCS未確定出用戶的信用，則該信用響應(yīng)中可攜帶有差錯原因值和相應(yīng)對話號。
總之，以上所述僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的保護范圍。
權(quán)利要求
1.一種基于分組數(shù)據(jù)流計費的對話號分配方法，其特征在于，該方法包含A1、消息發(fā)送方分配對話號。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述步驟A1之后進一步包括B1、消息發(fā)送方向消息接收方提供分配的對話號。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于，所述消息發(fā)送方為TPF。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述消息接收方為CRF，所述步驟B1為TPF向CRF提供分配的對話號，所述對話號攜帶在計費規(guī)則請求中。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，所述步驟B1之后進一步包括CRF向TPF提供計費規(guī)則時，進一步向TPF提供所述對話號。
6.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述消息接收方為OCS，所述步驟B1為TPF向OCS提供分配的對話號，所述對話號攜帶在信用請求中。
7.根據(jù)權(quán)利要求6所述的方法，其特征在于，所述步驟B1之后進一步包括CRF向TPF返回用戶的信用時，進一步向TPF提供所述對話號。
8.根據(jù)權(quán)利要求2所述的方法，其特征在于，所述步驟B1之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
9.一種基于分組數(shù)據(jù)流計費的對話號分配方法，其特征在于，該方法包含A2、消息接收方分配對話號。
10.根據(jù)權(quán)利要求9所述的方法，其特征在于，所述步驟A2之后進一步包括B2、消息接收方向消息發(fā)送方提供分配的對話號。
11.根據(jù)權(quán)利要求9或10所述的方法，其特征在于，所述消息接收方為CRF。
12.根據(jù)權(quán)利要求11所述的方法，其特征在于，所述消息接收方為CRF，所述步驟B2為CRF向TPF提供分配的對話號，所述對話號攜帶在提供計費規(guī)則的消息中。
13.根據(jù)權(quán)利要求9或10所述的方法，其特征在于，所述消息接收方為OCS。
14.根據(jù)權(quán)利要求13所述的方法，其特征在于，所述消息發(fā)送方為TPF，所述步驟B2為OCS向TPF提供分配的對話號，所述對話號攜帶在提供用戶信用的消息中。
15.根據(jù)權(quán)利要求10所述的方法，其特征在于，所述步驟B2之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
16.一種基于分組數(shù)據(jù)流計費的對話號分配方法，其特征在于，該方法包含以下步驟A3、消息發(fā)送方分配第一部分對話號；B3、消息接收方分配第二部分對話號，所述第一部分對話號和第二部分對話號構(gòu)成完整對話號。
17.根據(jù)權(quán)利要求16所述的方法，其特征在于，所述步驟A3進一步包括消息發(fā)送方向消息接收方提供分配的第一部分對話號；所述步驟B3為消息接收方分配第二部分對話號，將分配的第二部分對話號與接收的第一部分對話號構(gòu)成完整對話號。
18.根據(jù)權(quán)利要求17所述的方法，其特征在于，所述步驟B3之后進一步包括C3、消息接收方向消息發(fā)送方提供完整對話號。
19.根據(jù)權(quán)利要求18所述的方法，其特征在于，所述消息發(fā)送方為TPF，所述消息接收方為CRF，所述步驟A3為TPF向CRF提供分配的第一部分對話號，所述第一部分對話號攜帶在計費規(guī)則請求中。
20.根據(jù)權(quán)利要求19所述的方法，其特征在于，所述步驟C3為CRF向TPF提供完整對話號，所述完整對話號攜帶在提供計費規(guī)則的消息中。
21.根據(jù)權(quán)利要求18所述的方法，其特征在于，所述消息發(fā)送方為TPF，所述消息接收方為OCS，所述步驟A3為TPF向OCS提供分配的第一部分對話號，所述第一部分對話號攜帶在信用請求中。
22.根據(jù)權(quán)利要求21所述的方法，其特征在于，所述步驟C3為OCS向TPF提供完整對話號，所述完整對話號攜帶在提供用戶信用的消息中。
23.根據(jù)權(quán)利要求18所述的方法，其特征在于，所述步驟C3之后進一步包括消息發(fā)送方和消息接收方通過所述對話號，標(biāo)識一次對話中消息發(fā)送方和消息接收方之間交互的信息。
全文摘要
本發(fā)明公開了一種基于分組數(shù)據(jù)流計費的對話號分配方法，該方法包含消息發(fā)送方分配對話號；或消息接收方分配對話號；或消息發(fā)送方分配第一部分對話號，消息接收方分配第二部分對話號，所述第一部分對話號和第二部分對話號構(gòu)成完整對話號。所述消息發(fā)送方為TPF，消息接收方為CRF；或消息接收方為TPF，消息接收方為OCS等等。兩方之間后續(xù)的交互過程中，消息發(fā)送方和消息接收方使用分配的對話號標(biāo)識二者之間一次對話中交互的信息。根據(jù)本發(fā)明提出的方法，明確了對話號的分配實體，通過對話號能夠唯一標(biāo)識消息發(fā)送方和消息接收方之間的對話，使得基于分組數(shù)據(jù)流計費的各流程的實現(xiàn)更為完整。
文檔編號H04L12/14GK1735021SQ20041005842
公開日2006年2月15日 申請日期2004年8月11日 優(yōu)先權(quán)日2004年8月11日
發(fā)明者段小琴 申請人:華為技術(shù)有限公司