專利名稱：一種組用戶用量監(jiān)控方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信技術(shù)領(lǐng)域，尤其涉及一種組用戶用量監(jiān)控方法及系統(tǒng)。
背景技術(shù)：
第三代合作伙伴計劃(3rdGeneration Partnership Pro ject,簡稱為 3GPP)定義了針對移動網(wǎng)絡(luò)的策略和計費控制(Policy and Charging Control，簡稱為PCC)架構(gòu)。如圖I所示，PCC架構(gòu)中各實體功能描述如下PCRF(Policy and Charging Rules Function,策略和計費規(guī)則功能)為業(yè)務(wù)包含的業(yè)務(wù)數(shù)據(jù)流在傳輸過程中使用網(wǎng)絡(luò)資源制定資源控制策略，包括QoS(Quality ofService，服務(wù)質(zhì)量)控制策略和計費控制策略。
PCEF(Policy and Charging Enforcement Function,策略和計費執(zhí)行功能)用于執(zhí)行PCRF下發(fā)的或者PCEF上預(yù)配置的PCC規(guī)則，對網(wǎng)絡(luò)上傳輸?shù)腎P報文進行檢測，識別該IP報文隸屬的業(yè)務(wù)數(shù)據(jù)流，并對業(yè)務(wù)數(shù)據(jù)流提供QoS和計費控制。BBERF (Bearer Binding and Event Report Function,承載綁定和事件上報功能)主要用于對網(wǎng)絡(luò)上傳輸?shù)腎P報文進行檢測，并將IP報文按照規(guī)則映射到對應(yīng)的承載通道上。BBERF還執(zhí)行承載相關(guān)事件的上報，例如當(dāng)承載丟失，或者發(fā)生接入網(wǎng)絡(luò)切換的時候，都需要將相應(yīng)的事件上報給PCRF，請求PCRF進行相應(yīng)的決策。SPR(Subscription Profile Repository,用戶簽約數(shù)據(jù)庫)用于保存用戶簽約的業(yè)務(wù)信息，為PCRF制訂PCC規(guī)則提供必要的用戶簽約信息。OCS(Online Charging System,在線計費系統(tǒng))和 OFCS(Offline ChargingSystem，離線計費系統(tǒng))分別用于離線和在線計費。在用戶開展業(yè)務(wù)過程中，PCC按照如下方式為業(yè)務(wù)(由若干業(yè)務(wù)數(shù)據(jù)流組成)在傳輸過程中動態(tài)提供QoS保證業(yè)務(wù)包含的每個業(yè)務(wù)數(shù)據(jù)流都對應(yīng)一個具體的PCC規(guī)則，PCC規(guī)則中定義了該業(yè)務(wù)數(shù)據(jù)流傳輸時需要使用的QoS資源。在業(yè)務(wù)數(shù)據(jù)流在承載網(wǎng)絡(luò)中傳輸之前，PCRF需要依據(jù)相關(guān)信息為業(yè)務(wù)數(shù)據(jù)流決策并制定PCC規(guī)則。PCRF決策并制定PCC規(guī)則所依據(jù)的相關(guān)信息包括如下信息從AF接收的業(yè)務(wù)協(xié)商信息，該業(yè)務(wù)協(xié)商信息就是用戶開展業(yè)務(wù)時和通信對端協(xié)商的開展所述業(yè)務(wù)的信息，例如開展所述業(yè)務(wù)對QoS的要求，通信雙方使用的IP地址、端口號、所使用的協(xié)議等信息；從SPR接收的用戶簽約信息，例如用戶簽約信息中包含用戶和運營商簽約的QoS信息，用戶開展業(yè)務(wù)時，業(yè)務(wù)對QoS的要求不能超過用戶簽約信息所規(guī)定的用戶可以使用的QoS信息；PCRF自身存儲的運營商自定義策略，例如運營商對漫游用戶和非漫游用戶開展業(yè)務(wù)需要區(qū)分控制，這種運營商自行定義的區(qū)分控制策略可以配置在PCRF上；從PCEF或者BBERF上接收的接入相關(guān)信息，例如用戶附著到網(wǎng)絡(luò)時，PCRF需要通過PCEF或者BBERF獲取用戶接入網(wǎng)絡(luò)的信息，以供PCRF為用戶開展業(yè)務(wù)進行策略決策；從OCS獲取用戶的信用信息，例如一旦用戶的信用用完或者不夠時，PCRF就無法授權(quán)所述用戶開展業(yè)務(wù)。PCRF根據(jù)上述信息為業(yè)務(wù)數(shù)據(jù)流決策制定PCC規(guī)則，并將PCC規(guī)則下發(fā)給PCEF (如果網(wǎng)絡(luò)中存在BBERF，則PCRF還需要制定QoS規(guī)則，并下發(fā)給BBERF)。PCEF需要根據(jù)PCC規(guī)則的QoS要求建立相應(yīng)的承載，并將PCC規(guī)則綁定到對應(yīng)的承載上(如果網(wǎng)絡(luò)中存在BBERF，則由BBERF根據(jù)QoS規(guī)則建立承載)。如果網(wǎng)絡(luò)中已經(jīng)有和PCC規(guī)則或者QoS規(guī)則指示的QoS相匹配的承載，則將所述PCC規(guī)則或者QoS規(guī)則綁定到已有的承載上。此后，當(dāng)用戶開展業(yè)務(wù)，業(yè)務(wù)數(shù)據(jù)流在承載網(wǎng)絡(luò)上傳輸?shù)臅r候，終端和網(wǎng)絡(luò)設(shè)備可以根據(jù)五元組(由源IP地址、源端口號、目的IP地址、目的端口號、協(xié)議組成)將組成該業(yè)務(wù)數(shù)據(jù)流的IP報文匹配到相應(yīng)的PCC規(guī)則/QoS規(guī)則，根據(jù)PCC規(guī)則/QoS規(guī)則和承載的綁
定關(guān)系，就可以將所述業(yè)務(wù)數(shù)據(jù)流匹配到相應(yīng)的承載上，從而為業(yè)務(wù)數(shù)據(jù)流在承載網(wǎng)絡(luò)上的傳輸提供QoS保證。當(dāng)用戶開展的業(yè)務(wù)結(jié)束的時候，相應(yīng)的PCC規(guī)則需要從承載網(wǎng)絡(luò)上刪除，即釋放分配給所述業(yè)務(wù)使用的QoS資源。通過上述PCC機制，一方面可以按照業(yè)務(wù)對QoS的需求分配相應(yīng)的QoS資源，另一方面實現(xiàn)了需要QoS資源時就可以分配，不需要QoS資源時可以及時釋放，因此，通過PCC機制可以達到提升用戶業(yè)務(wù)體驗，提高網(wǎng)絡(luò)資源使用效率的目的。為了提高網(wǎng)絡(luò)營運的靈活性，比如，對于某種業(yè)務(wù)，運營商希望前IOM是供用戶免費使用的，當(dāng)用戶的用量超出IOM之后，就需要收取費用；再比如，運營商希望用戶的用量在IOM之內(nèi)使用一種帶寬保證，當(dāng)用量超出IOM之后需要對用戶的帶寬進行限制。對于上述場景，就要求用戶開展業(yè)務(wù)時，PCRF向PCEF下發(fā)針對業(yè)務(wù)的控制策略的同時，還需要下發(fā)用量監(jiān)控指示，要求PCEF對所述業(yè)務(wù)實施用量監(jiān)控，當(dāng)所述業(yè)務(wù)的流量達到監(jiān)控所要求的閾值時，PCEF就要對用量監(jiān)控實施上報，以便PCRF重新對所述業(yè)務(wù)進行策略決策，產(chǎn)生新的控制策略。現(xiàn)有技術(shù)的用量監(jiān)控的實現(xiàn)過程如圖2所示，該過程主要包括如下步驟步驟AI-A3，為PCRF向PCEF下發(fā)用量監(jiān)控的過程。業(yè)務(wù)由一個或者多個業(yè)務(wù)數(shù)據(jù)流構(gòu)成，對業(yè)務(wù)實施策略控制在現(xiàn)實時實際上是針對業(yè)務(wù)數(shù)據(jù)流的策略控制，通過PCRF為業(yè)務(wù)數(shù)據(jù)流制定控制策略(PCC規(guī)則)并下發(fā)給PCEF執(zhí)行，實現(xiàn)針對業(yè)務(wù)的策略控制。如果需要對該業(yè)務(wù)實施用量監(jiān)控，則在PCRF向PCEF下發(fā)的PCC 規(guī)則(charging rule definition)中包含監(jiān)控鍵(monitoring key),同時PCRF為該monitoring key分配一個用量監(jiān)控信息(usage monitoring information)并下發(fā)給 PCEF。Usage monitoring information 中包含所述 monitoring key、分配的監(jiān)控閾值(threshold)以及其他信息。例如流程中需要實施用量監(jiān)控的業(yè)務(wù)包含了業(yè)務(wù)數(shù)據(jù)流-I和業(yè)務(wù)數(shù)據(jù)流_2，則PCRF向PCEF下發(fā)用量監(jiān)控指示的過程如步驟A1-A3描述步驟Al,PCEF 向 PCRF 發(fā)送 CCR(Credit Control Request,信用控制請求)請求。步驟A2，PCRF向 PCEF下發(fā) CCA(Credit Control Answer，信用控制應(yīng)答)響應(yīng)，包含 PCC 規(guī)則-I (用 charging rule definition-1 表不)、PCC 規(guī)則-2 (用 charging ruledefinition-2 表不)以及 usage monitoring information。
其中，PCC規(guī)貝丨J -I中包含了 PCC規(guī)則名(用charging rule name-1表示),和monitoring key ；PCC 規(guī)則-2 中包含了 PCC規(guī)則名(用 charging rule name-2 表不)，和monitoringkey ；Usage monitoring information 中包含了上述 monitoring key,以及 PCRF 為其分配的監(jiān)控閾值(threshold)。此外，PCRF也可在發(fā)送給PCEF的RAR消息中包含上述用量監(jiān)控信息。步驟A3，對應(yīng)PCRF向PCEF下發(fā)RAR (Re-Auth-Request,重鑒權(quán)請求)消息，則PCEF向PCRF返回RAA(Re-Auth_Answer,重鑒權(quán)應(yīng)答)消息。步驟B，當(dāng)PCEF收到PCRF下發(fā)的PCC規(guī)則后，安裝規(guī)則，并按照用量監(jiān)控信息，對PCC規(guī)則對應(yīng)的業(yè)務(wù)數(shù)據(jù)流(即業(yè)務(wù)數(shù)據(jù)流I和業(yè)務(wù)數(shù)據(jù)流2)實施用量監(jiān)控。
步驟C1-C2為PCEF上報用量監(jiān)控的過程。步驟Cl,當(dāng)PCEF對該Monitoring Key監(jiān)控的累計用量達到步驟A2下發(fā)的閾值時，PCEF進行用量監(jiān)控上報。PCEF向PCRF發(fā)送CCR消息，攜帶Usage MonitoringInformation,其中包含上述 Monitoring Key 以及累計用量(Used Service Unit)。步驟C2，PCRF向PCEF返回CCA響應(yīng)。步驟D,根據(jù)上報的用量，PCRF對利用該monitoring key進行用量監(jiān)控的業(yè)務(wù)數(shù)據(jù)流(即業(yè)務(wù)數(shù)據(jù)流-I和業(yè)務(wù)數(shù)據(jù)流-2)重新制定相應(yīng)的控制策略。步驟E1-E2為PCRF重新制定策略下發(fā)的過程。步驟El，PCRF向PCEF下發(fā)RAR消息，為業(yè)務(wù)數(shù)據(jù)流I和2重新下發(fā)控制策略。步驟E2，PCEF向PCRF返回響應(yīng)。上述流程描述的是對單個業(yè)務(wù)的用量監(jiān)控。另外，在實際運營中，還包括針對用戶采取用量監(jiān)控的需求。由于用戶可以開展多種業(yè)務(wù)，對用戶的用量監(jiān)控實際上是針對多個業(yè)務(wù)進行用量監(jiān)控。在利用上述用量監(jiān)控上報機制在實現(xiàn)對用戶開展的多個業(yè)務(wù)實施用量監(jiān)控時，需要由同一網(wǎng)絡(luò)設(shè)備管理用戶的簽約用量。由于用戶附著時就選擇了一個為其服務(wù)的PCRF，即用戶開展的各種業(yè)務(wù)都由該PCRF提供策略控制，因此，由該PCRF管理用戶的簽約用量，同時為用戶開展的多個業(yè)務(wù)分配相同的monitoring key,就可以實現(xiàn)針對用戶開展的多個業(yè)務(wù)實施用量監(jiān)控。在實際運營中還存在一種需求，就是需要針對一組用戶實施用量監(jiān)控。例如，運營商開通家庭套餐，簽約一定的免費用量，使得每個家庭成員都可以使用該簽約免費用量，一旦免費用量超出之后，針對該家庭成員的用量都要計費。再如集團用戶套餐，對于集團內(nèi)用戶在體驗?zāi)骋活悩I(yè)務(wù)時在簽約用量內(nèi)可以獲得較高的業(yè)務(wù)體驗，當(dāng)超出簽約用量時，就無法保證所述業(yè)務(wù)的體驗效果。對于上述家庭用戶或集團用戶(統(tǒng)稱為組用戶)，雖然組用戶內(nèi)的每個成員可以共享簽約用量，但是不能保證組內(nèi)用戶附著到網(wǎng)絡(luò)的時候都能選擇到同一個PCRF，因此，使用現(xiàn)有用量監(jiān)控機制將無法實現(xiàn)對組用戶實施用量監(jiān)控。另外，組內(nèi)用戶還有可能使用不同的SPR保存簽約信息，例如實際運營中運營商選擇將PCRF和SPR合設(shè)，這樣SPR也不適合統(tǒng)一管理組用戶的簽約用量，并對組用戶實施用量監(jiān)控。因此，針對現(xiàn)有用量監(jiān)控上報機制，尚無法實現(xiàn)對共享簽約用量的組用戶實施用量監(jiān)控。

發(fā)明內(nèi)容
本發(fā)明解決的技術(shù)問題是提供一種組用戶用量監(jiān)控方法及系統(tǒng)，實現(xiàn)對組用戶的用量監(jiān)控。為解決上述技術(shù)問題，本發(fā)明提供了一種組用戶用量監(jiān)控方法，第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求；所述第二策略控制實體收到所述用量監(jiān)控請求時，根據(jù)用戶組簽約用量進行用量監(jiān)控決策，并向所述第一策略控制實體下發(fā)用量監(jiān)控信息；
所述第一策略控制實體根據(jù)收到的所述用量監(jiān)控信息，對用戶進行用量監(jiān)控。進一步地,所述第一策略控制實體通過Diameter路由代理(DRA)發(fā)現(xiàn)所述第二策略控制實體，并向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求；其中所述DRA通過用戶的用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。進一步地，所述第一策略控制實體在獲取到針對所述用戶進行用量監(jiān)控的指示時，向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求。進一步地，所述第二策略控制實體向所述第一策略控制實體下發(fā)的所述用量監(jiān)控信息，包括監(jiān)控鍵和監(jiān)控閾值。進一步地，所述第一策略控制實體根據(jù)收到的所述用量監(jiān)控信息，對用戶進行用量監(jiān)控，具體包括所述第一策略控制實體向策略執(zhí)行實體下發(fā)控制策略和所述用量監(jiān)控信息，所述控制策略中包含所述監(jiān)控鍵，所述用量監(jiān)控信息中包含所述監(jiān)控鍵和監(jiān)控閾值；所述策略執(zhí)行實體執(zhí)行用量監(jiān)控；所述策略執(zhí)行實體向所述第一策略控制實體上報累計監(jiān)控用量；所述第一策略控制實體根據(jù)收到的所述累計監(jiān)控用量決策控制策略、和/或，根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求。進一步地，所述第一策略控制實體根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求，具體包括如果所述累計監(jiān)控用量達到所述監(jiān)控閾值，則所述第一策略控制實體決策向所述第二策略控制實體發(fā)送用量監(jiān)控請求；如果所述累計監(jiān)控用量沒有達到所述監(jiān)控閾值，則所述第一策略控制實體決策不向所述第二策略控制實體發(fā)送用量監(jiān)控請求。本發(fā)明還提供了一種組用戶用量監(jiān)控系統(tǒng)，所述系統(tǒng)包括第一策略控制實體，第二策略控制實體，其中所述第一策略控制實體用于，向所述第二策略控制實體發(fā)送用量監(jiān)控請求；并根據(jù)收到的用量監(jiān)控信息，對用戶進行用量監(jiān)控；所述第二策略控制實體用于，收到所述用量監(jiān)控請求時，根據(jù)所述用戶的用戶組簽約用量進行用量監(jiān)控決策，并向所述第一策略控制實體下發(fā)用量監(jiān)控信息。進一步地，所述第一策略控制實體用于，所述第一策略控制實體通過DRA發(fā)現(xiàn)所述第二策略控制實體，并向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求；其中所述DRA通過用戶的用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。進一步地，所述第一策略控制實體用于，在獲取到針對所述用戶進行用量監(jiān)控的指示時，向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求。進一步地，所述第二策略控制實體向所述第一策略控制實體下發(fā)的所述用量監(jiān)控信息，包括監(jiān)控鍵和監(jiān)控閾值。進一步地,所述系統(tǒng)還包括策略執(zhí)行實體，所述第一策略控制實體用于，收到所述用量監(jiān)控信息后，向所述策略執(zhí)行實體下發(fā)控制策略和所述用量監(jiān)控信息，其中所述控制策略中包含所述監(jiān)控鍵，所述用量監(jiān)控信息中包含所述監(jiān)控鍵和監(jiān)控閾值；以及，根據(jù)收到的所述策略執(zhí)行實體上報的累計監(jiān)控用量決策控制策略、和/或，根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求；所述策略執(zhí)行實體用于，根據(jù)收到的控制策略和所述用量監(jiān)控信息，執(zhí)行用量監(jiān)控；以及，向所述第一策略控制實體上報累計監(jiān)控用量?！?br> 進一步地，所述第一策略控制實體根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求，是指如果所述累計監(jiān)控用量達到所述監(jiān)控閾值，則所述第一策略控制實體決策向所述第二策略控制實體發(fā)送用量監(jiān)控請求；如果所述累計監(jiān)控用量沒有達到所述監(jiān)控閾值，則所述第一策略控制實體決策不向所述第二策略控制實體發(fā)送用量監(jiān)控請求。本發(fā)明提供了一種針對組用戶的用量監(jiān)控機制，通過引入專用的策略控制實體，用戶組內(nèi)的每個成員用戶附著的策略控制實體，向該專用的策略控制實體請求用量監(jiān)控，實現(xiàn)對共享簽約用量的組用戶的用量監(jiān)控，從而解決了現(xiàn)有用量監(jiān)控機制的不足。


此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當(dāng)限定。在附圖中圖I為現(xiàn)有技術(shù)的3GPP PCC R8架構(gòu)的示意圖；圖2為根據(jù)現(xiàn)有技術(shù)的用量監(jiān)控實現(xiàn)流程圖；圖3為根據(jù)本發(fā)明實施例一的組用戶用量監(jiān)控的流程圖；圖4為根據(jù)本發(fā)明實施例二的流程圖；圖5為根據(jù)本發(fā)明實施例三的流程圖；圖6為根據(jù)本發(fā)明實施例四的流程圖；圖7為根據(jù)本發(fā)明實施例五的流程圖。
具體實施例方式為解決現(xiàn)有技術(shù)中存在的問題，本實施方式中，通過引入一個專用策略控制實體(以下稱作第二策略控制實體)，實現(xiàn)針對組用戶的用量監(jiān)控。所述的專用策略控制實體可以單獨設(shè)置，也可以集成在其他策略控制實體中。所述的專用策略控制實體從其他網(wǎng)元獲取組用戶簽約信息，或者在所述專用策略控制實體上配置組用戶簽約信息。所述的組用戶簽約信息包含了用戶組標(biāo)識、組內(nèi)用戶的標(biāo)識、用戶組簽約用量等信息。本實施方式提供的一種針對組用戶實施用量監(jiān)控的方法，具體采用如下技術(shù)方案步驟一，第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求；具體地，所述第一策略控制實體通過DRA(Diameter Routing Agent, Diameter路由代理)發(fā)現(xiàn)所述第二策略控制實體，所述DRA根據(jù)用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。其中，所述第一策略控制實體可采用現(xiàn)有的PCRF，第二策略控制實體則可通過擴展了現(xiàn)有功能的PCRF實現(xiàn)。 步驟二，所述第二策略控制實體根據(jù)用戶組簽約用量進行用量監(jiān)控決策，并下發(fā)用量監(jiān)控信息給所述第一策略控制實體；具體地，所述用量監(jiān)控信息，包括第二策略控制實體為所述用戶分配的監(jiān)控鍵(monitoring key)和監(jiān)控閾值(threshold)。步驟三，所述第一策略控制實體根據(jù)收到的用量監(jiān)控信息，對用戶進行用量監(jiān)控；所述的對用戶進行用量監(jiān)控，進一步包括所述第一策略控制實體向策略執(zhí)行實體(如PCEF)下發(fā)控制策略(包含所述監(jiān)控鍵)和用量監(jiān)控信息(包含所述監(jiān)控鍵和監(jiān)控閾值)；所述策略執(zhí)行實體執(zhí)行用量監(jiān)控；所述策略執(zhí)行實體向所述第一策略控制實體上報累計監(jiān)控用量；所述第一策略控制實體根據(jù)上報的累計監(jiān)控用量進行策略決策；具體地，所述第一策略控制實體根據(jù)累計監(jiān)控用量決策控制策略(即PCC規(guī)則)，并根據(jù)累計監(jiān)控用量上報結(jié)果決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求。為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚明白，下文中將結(jié)合附圖對本發(fā)明的實施例進行詳細說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。實施例一圖3示出了本發(fā)明實施例的組用戶用量監(jiān)控方法的流程示意圖，如圖3所示，本實施例流程主要包括如下實施步驟步驟301，第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求；具體地，當(dāng)所述第一策略控制實體獲取到為用戶進行用量監(jiān)控的指示時，則向所述第二策略控制實體發(fā)送用量監(jiān)控請求。所述第一策略控制實體通過DRA發(fā)現(xiàn)所述第二策略控制實體，所述DRA根據(jù)用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。步驟302，所述第二策略控制實體根據(jù)用戶組簽約用量進行用量監(jiān)控決策，為所述用戶分配監(jiān)控鍵(monitoring key)和監(jiān)控閾值(threshold)。步驟303，第二策略控制實體將所述監(jiān)控鍵和監(jiān)控閾值下發(fā)給所述第一策略控制實體。步驟304，第一策略控制實體向第一策略執(zhí)行實體下發(fā)用量監(jiān)控信息，包含所述監(jiān)控鍵和監(jiān)控閾值。步驟305，第一策略執(zhí)行實體執(zhí)行用量監(jiān)控。步驟306 (可選)，第一策略執(zhí)行實體收到第一策略控制實體下發(fā)的用量監(jiān)控上報指示。步驟307，第一策略執(zhí)行實體向第一策略控制實體上報累計監(jiān)控用量。步驟308，第一策略控制實體根據(jù)上報的累計監(jiān)控用量進行策略決策(即PCC規(guī)則)，并根據(jù)累計監(jiān)控用量上報結(jié)果決策是否向第二策略控制實體發(fā)送用量監(jiān)控請求，如果是，則執(zhí)行步驟309。步驟309，第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求。實施例二 本實施例假設(shè)用戶組包含了 UE-I和UE-2。根據(jù)現(xiàn)有UE附著的流程，當(dāng)UE-I附著到網(wǎng)絡(luò)時，選擇PCEF-I和PCRF-I (即第一策略控制實體)為其接入服務(wù)；當(dāng)UE-2附著到網(wǎng)絡(luò)時，選擇PCEF-2和PCRF-2為其接入服務(wù)。SPR-I用于保存UE-I的簽約信息，其中包含了UE-I需要執(zhí)行組用戶用量監(jiān)控的指示。SPR-2用于保存UE-2的簽約信息，其中包含了 UE-2需要執(zhí)行組用戶用量監(jiān)控的指示。PCRF-3是專門為組用戶提供用量監(jiān)控的策略控制實體(即第二策略控制實體)。當(dāng)組用戶附著到網(wǎng)絡(luò)，網(wǎng)絡(luò)設(shè)備根據(jù)用量監(jiān)控指示向PCRF-3請求用量監(jiān)控，以及PCRF-3下發(fā)用量監(jiān)控的過程如圖4所示。該流程描述如下步驟401. PCRF-3獲取用戶組簽約信息，包括用戶組標(biāo)識、組內(nèi)所有用戶的標(biāo)識、用戶組簽約用量。所述用戶組簽約信息可以預(yù)保存在PCRF-3上，也可以由PCRF-3從保存所述信息的其他網(wǎng)元獲取。步驟402. UE-I附著到網(wǎng)絡(luò)，選擇PCEF-1。PCEF-I根據(jù)選擇PCRF-1為UE-1接入服務(wù)，向PCRF-I發(fā)送IP-CAN會話建立請求，攜帶用戶標(biāo)識。步驟403. PCRF-I根據(jù)用戶標(biāo)識判斷還沒有UE-I的簽約信息，從SPR-I中獲取UE-I的簽約信息，其中包含要求為UE-I進行用量監(jiān)控的指示。步驟404. PCRF-I根據(jù)從SPR-I獲取的UE-I的簽約信息中包含為UE-I進行用量監(jiān)控的指示，PCRF-I通過DRA根據(jù)用戶組標(biāo)識發(fā)現(xiàn)所述PCRF-3，PCRF-I向PCRF-3發(fā)送對UE-I進行用量監(jiān)控的請求，包含UE-I標(biāo)識、用戶組標(biāo)識等信息。其中，所述用戶組標(biāo)識可以從PCEF-I發(fā)送的IP-CAN會話建立請求消息中獲取，或者從SPR-I的UE-I簽約信息中獲取。步驟405. PCRF-3接收所述請求后，根據(jù)用戶組簽約用量信息進行用量監(jiān)控決策，為UE-I分配用量監(jiān)控鍵(monitoring key),并針對所述monitoring key分配監(jiān)控閾值(threshold)。步驟406. PCRF-3向PCRF-1下發(fā)用量監(jiān)控，包含分配給UE-1的monitoring key和threshold。至此，PCRF-I與PCRF-3之間建立策略控制會話。步驟407. PCRF-I針對IP-CAN會話建立請求進行策略決策，產(chǎn)生控制策略。步驟408. PCRF-I向PCEF-I返回IP-CAN會話建立成功的響應(yīng)，包含控制策略，以及用量監(jiān)控信息(monitoring key, threshold),要求對UE-I實施用量監(jiān)控。步驟409. PCEF-I執(zhí)行策略，并根據(jù)PCRF-1的要求，對UE-1執(zhí)行用量監(jiān)控。步驟410.用戶組下的UE-2附著到網(wǎng)絡(luò)的過程，參考UE-I的附著過程。當(dāng)選擇PCRF-2為UE-2接入服務(wù)時，PCRF-2根據(jù)從SPR-2接收的要求為UE-2執(zhí)行用量監(jiān)控的指示之后，根據(jù)用戶組標(biāo)識發(fā)現(xiàn)PCRF-3并建立策略控制會話，請求為UE-2進行用量監(jiān)控。PCRF-3根據(jù)用戶組簽約用量信息進行用量監(jiān)控決策，為UE-2產(chǎn)生用量監(jiān)控信息并下發(fā)給PCRF-2。PCRF-2進一步下發(fā)給PCEF-2，啟動針對UE-2的用量監(jiān)控。實施例三上述實施例二給出了用戶組內(nèi)的UE-I和UE-2附著到網(wǎng)絡(luò)的過程。本實施例中給出了 UE附著到網(wǎng)絡(luò)之后，開展業(yè)務(wù)。PCEF對UE進行用量監(jiān)控，并進行用量監(jiān)控上報，以及PCRF根據(jù)用量監(jiān)控上報結(jié)果實施策略調(diào)整的過程。為簡便起見，本實施例僅給出了對UE-I實施用量監(jiān)控的過程。對UE-2實施用量監(jiān)控的過程，則可參考針對UE-I實施用量監(jiān)控的過程。本實施例的用量監(jiān)控上報以及根據(jù)用量監(jiān)控結(jié)果進行策略調(diào)整的過程如圖5所示，其流程描述如下
步驟501. UE-I開展業(yè)務(wù)，PCEF-I對UE-I實施用量監(jiān)控。步驟502. PCEF-I從PCRF-1中收到要求上報用量監(jiān)控的指示。步驟503. PCEF-I向PCRF-1返回確認消息。步驟504. PCEF-I將監(jiān)控的累計用量(該累計監(jiān)控用量可能沒有到達監(jiān)控閾值threshold)上報給 PCRF-1。步驟505. PCRF-I根據(jù)上報的累計監(jiān)控用量進行策略決策，為UE-I進行策略調(diào)整，例如限制UE-I的帶寬等。步驟506. PCRF-I將新的控制策略下發(fā)給PCEF-1。步驟507.根據(jù)PCRF-I下發(fā)的策略，PCEF-I執(zhí)行新的控制策略。實施例四本實施例和前述實施例三描述的場景相同，同為用量監(jiān)控上報和根據(jù)用量監(jiān)控上報結(jié)果進行策略調(diào)整的過程。區(qū)別在于實施例三中描述的是累計監(jiān)控用量沒有達到閾值時，PCEF-I應(yīng)PCRF-I的要求上報用量監(jiān)控的過程；而本實施例中描述的是當(dāng)累計監(jiān)控用量到達閾值時，PCEF-I向PCRF-I主動上報用量監(jiān)控的過程。其實現(xiàn)如圖6所示，流程描述如下步驟601. UE-I開展業(yè)務(wù)，PCEF-I對UE-1實施用量監(jiān)控。步驟602.當(dāng)UE-I使用的用量達到實施例二中步驟408下發(fā)的監(jiān)控閾值時，PCEF-I向PCRF-I上報用量監(jiān)控，攜帶monitoring key和累計監(jiān)控用量。步驟603. PCRF-I收到用量監(jiān)控上報后，判斷分配給UE-I使用的用量已經(jīng)被UE-I用完，PCRF-I決策向PCRF-3發(fā)送用量監(jiān)控請求,請求消息中攜帶monitoring key。步驟604. PCRF-3收到請求消息，根據(jù)用戶組簽約用量信息進行用量監(jiān)控決策。如果此時所述用戶組的簽約用量沒有分配完，則為該monitoring key分配新的監(jiān)控閾值threshold-2 ;如果所述用戶組簽約用量已經(jīng)完全分配給了組內(nèi)用戶，則PCRF-3無法再為所述monitoring key分配新的監(jiān)控閾值。步驟605a.如果PCRF-3為UE-1分配了新的監(jiān)控閾值，則PCRF-3將monitoringkey和對應(yīng)的新的監(jiān)控閾值threshold-2下發(fā)給PCRF-1。步驟605b.如果PCRF-3沒有為UE-I分配新的監(jiān)控閾值，則PCRF-3向PCRF-I下發(fā)停止用量監(jiān)控的指示(該指示可以通過一個明確的信息表示，也可以通過在下發(fā)的消息中不攜帶任何用量監(jiān)控相關(guān)的信息表示停止用量監(jiān)控)。步驟606.根據(jù)602步PCEF-I上報的用量監(jiān)控的結(jié)果，PCRF-I執(zhí)行策略決策，產(chǎn)生新的控制控制策略。步驟607. PCRF-I將從PCRF-3接收的用量監(jiān)控信息(monitoring key和threshold-2)連同控制策略下發(fā)給PCEF-1。步驟608. PCEF-I執(zhí)行控制策略，并對UE-1繼續(xù)執(zhí)行用量監(jiān)控。實施例五前述實施例二、三和四描述的是在用戶組內(nèi)的UE附著到網(wǎng)絡(luò)，建立IP-CAN會話的過程中PCRF-3下發(fā)用量監(jiān)控的過程。而本實施例中描述的是在IP-CAN會話修改過程中下發(fā)用量監(jiān)控的過程，即UE附著到網(wǎng)絡(luò)之后，在開展業(yè)務(wù)的過程中，才啟動針對組內(nèi)用戶開展業(yè)務(wù)的用量監(jiān)控。當(dāng)然，本實施例也可在前述實施例的基礎(chǔ)上進行實施，即，在UE附著到 網(wǎng)絡(luò)的過程，以及，在開展業(yè)務(wù)的過程中，均進行針對組內(nèi)用戶開展業(yè)務(wù)的用量監(jiān)控。其過程如圖7所示，具體流程描述如下步驟701. UE-I開展業(yè)務(wù)，和AF之間完成業(yè)務(wù)協(xié)商過程。步驟702. PCRF-I收到IP-CAN會話修改的觸發(fā)。其觸發(fā)可以來自于AF，例如收到AF的業(yè)務(wù)授權(quán)請求，該請求將觸發(fā)PCRF-I發(fā)起IP-CAN會話的修改；或者收到來自PCEF-I的IP-CAN會話修改請求，請求建立/修改IP-CAN承載。步驟703.根據(jù)從SPR-I接收的UE-I的簽約信息中包含為UE-I進行用量監(jiān)控的指示，PCRF-I向PCRF-3發(fā)起用量監(jiān)控請求。如果此時PCRF-I和PCRF-3還沒有建立策略控制會話，則PCRF-I通過DRA根據(jù)用戶組標(biāo)識發(fā)現(xiàn)PCRF-3，并建立策略控制會話。PCRF-I向PCRF-3發(fā)起用量監(jiān)控請求，請求消息中包含用戶組標(biāo)識、UE-I標(biāo)識。步驟704.當(dāng)PCRF-3收到請求消息之后，根據(jù)用戶組簽約用量信息進行用量監(jiān)控決策，為UE-I分配監(jiān)控鍵(monitoring key),并分配相應(yīng)的監(jiān)控閾值(threshold)。步驟705. PCRF-3向PCRF-1下發(fā)用量監(jiān)控，包含上述信息。步驟706. PCRF-I為UE-I開展的所述業(yè)務(wù)進行策略決策，產(chǎn)生PCC規(guī)則，并在PCC規(guī)則中包含所述monitoring key,表示針對UE-I開展的所述業(yè)務(wù)啟動用量監(jiān)控。 步驟707. PCRF-I向PCEF-1下發(fā)控制策略和用量監(jiān)控信息。步驟708. PCEF-I執(zhí)行策略，并啟動針對UE-I開展的所述業(yè)務(wù)的用量監(jiān)控。步驟709.當(dāng)PCEF-I監(jiān)控的累計用量達到所述監(jiān)控閾值的時候，PCEF-1向PCRF-1上報用量監(jiān)控，攜帶monitoring key和累計監(jiān)控用量。步驟710.當(dāng)PCRF-I接收到所述用量監(jiān)控上報結(jié)果之后，判斷分配給UE-1開展所述業(yè)務(wù)的監(jiān)控閾值已經(jīng)到達，PCRF-I決定向PCRF-3請求針對UE-1開展的所述業(yè)務(wù)繼續(xù)進行用量監(jiān)控，請求消息中攜帶所述monitoring key。步驟711. PCRF-3接收到所述請求之后，根據(jù)用戶組的簽約用量信息進行用量監(jiān)控決策，為所述monitoring key分配新的監(jiān)控閾值threshold-2。步驟712. PCRF-3 向 PCRF-1 下發(fā)用量監(jiān)控,包含 monitoring key 和 threshold-2。步驟713. PCRF-I對UE_1開展的所述業(yè)務(wù)，根據(jù)PCEF-I上報的用量監(jiān)控結(jié)果進行策略決策，例如降低UE-I開展所述業(yè)務(wù)的授權(quán)帶寬，決策產(chǎn)生新的PCC規(guī)則，所述PCC規(guī)則中仍然包含所述monitoring key。
步驟714. PCRF-I向PCEF-I下發(fā)新的策略，包含所述PCC規(guī)則和用量監(jiān)控信息(monitoring key 和 threshold-2)步驟715. PCEF-I執(zhí)行PCRF-I下發(fā)的策略，并繼續(xù)針對UE-I開展的所述業(yè)務(wù)啟動用量監(jiān)控。此外，本發(fā)明實施例中還提供了一種組用戶用量監(jiān)控系統(tǒng)，該系統(tǒng)主要包括第一策略控制實體，第二策略控制實體，其中第一策略控制實體用于，向第二策略控制實體發(fā)送用量監(jiān)控請求；并根據(jù)收到的用量監(jiān)控信息，對用戶進行用量監(jiān)控；第二策略控制實體用于，收到用量監(jiān)控請求時，根據(jù)用戶的用戶組簽約用量進行用量監(jiān)控決策，并向第一策略控制實體下發(fā)用量監(jiān)控信息。進一步地，第一策略控制實體用于，第一策略控制實體通過DRA發(fā)現(xiàn)第二策略控 制實體，并向第二策略控制實體發(fā)送用量監(jiān)控請求；其中DRA通過用戶的用戶組標(biāo)識發(fā)現(xiàn)第二策略控制實體。進一步地，第一策略控制實體用于，在獲取到針對用戶進行用量監(jiān)控的指示時，向第二策略控制實體發(fā)送用量監(jiān)控請求。進一步地，第二策略控制實體向第一策略控制實體下發(fā)的用量監(jiān)控信息，包括監(jiān)控鍵和監(jiān)控閾值。進一步地，系統(tǒng)還包括策略執(zhí)行實體，第一策略控制實體用于，收到用量監(jiān)控信息后，向策略執(zhí)行實體下發(fā)控制策略和用量監(jiān)控信息，其中控制策略中包含監(jiān)控鍵，用量監(jiān)控信息中包含監(jiān)控鍵和監(jiān)控閾值；以及，根據(jù)收到的策略執(zhí)行實體上報的累計監(jiān)控用量決策控制策略、和/或，根據(jù)累計監(jiān)控用量決策是否向第二策略控制實體發(fā)送用量監(jiān)控請求；策略執(zhí)行實體用于，根據(jù)收到的控制策略和用量監(jiān)控信息，執(zhí)行用量監(jiān)控；以及，向第一策略控制實體上報累計監(jiān)控用量。進一步地，第一策略控制實體根據(jù)累計監(jiān)控用量決策是否向第二策略控制實體發(fā)送用量監(jiān)控請求，是指如果累計監(jiān)控用量達到監(jiān)控閾值，則第一策略控制實體決策向第二策略控制實體發(fā)送用量監(jiān)控請求；如果累計監(jiān)控用量沒有達到監(jiān)控閾值，則第一策略控制實體決策不向第二策略控制實體發(fā)送用量監(jiān)控請求。以上僅為本發(fā)明的優(yōu)選實施案例而已，并不用于限制本發(fā)明，本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況下，熟悉本領(lǐng)域的技術(shù)人員可根據(jù)本發(fā)明做出各種相應(yīng)的改變和變形，但這些相應(yīng)的改變和變形都應(yīng)屬于本發(fā)明所附的權(quán)利要求的保護范圍。顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié) 合。
權(quán)利要求
1.一種組用戶用量監(jiān)控方法，其特征在于， 第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求； 所述第二策略控制實體收到所述用量監(jiān)控請求時，根據(jù)用戶組簽約用量進行用量監(jiān)控決策，并向所述第一策略控制實體下發(fā)用量監(jiān)控信息； 所述第一策略控制實體根據(jù)收到的所述用量監(jiān)控信息，對用戶進行用量監(jiān)控。
2.如權(quán)利要求I所述的方法，其特征在于， 所述第一策略控制實體通過Diameter路由代理(DRA)發(fā)現(xiàn)所述第二策略控制實體，并向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求； 其中所述DRA通過用戶的用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。
3.如權(quán)利要求I所述的方法，其特征在于， 所述第一策略控制實體在獲取到針對所述用戶進行用量監(jiān)控的指示時，向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求。
4.如權(quán)利要求1、2或3所述的方法，其特征在于， 所述第二策略控制實體向所述第一策略控制實體下發(fā)的所述用量監(jiān)控信息，包括監(jiān)控鍵和監(jiān)控閾值。
5.如權(quán)利要求4所述的方法，其特征在于，所述第一策略控制實體根據(jù)收到的所述用量監(jiān)控信息，對用戶進行用量監(jiān)控，具體包括 所述第一策略控制實體向策略執(zhí)行實體下發(fā)控制策略和所述用量監(jiān)控信息，所述控制策略中包含所述監(jiān)控鍵，所述用量監(jiān)控信息中包含所述監(jiān)控鍵和監(jiān)控閾值； 所述策略執(zhí)行實體執(zhí)行用量監(jiān)控； 所述策略執(zhí)行實體向所述第一策略控制實體上報累計監(jiān)控用量； 所述第一策略控制實體根據(jù)收到的所述累計監(jiān)控用量決策控制策略、和/或，根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求。
6.如權(quán)利要求5所述的方法，其特征在于，所述第一策略控制實體根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求，具體包括 如果所述累計監(jiān)控用量達到所述監(jiān)控閾值，則所述第一策略控制實體決策向所述第二策略控制實體發(fā)送用量監(jiān)控請求； 如果所述累計監(jiān)控用量沒有達到所述監(jiān)控閾值，則所述第一策略控制實體決策不向所述第二策略控制實體發(fā)送用量監(jiān)控請求。
7.一種組用戶用量監(jiān)控系統(tǒng)，其特征在于，所述系統(tǒng)包括第一策略控制實體，第二策略控制實體，其中 所述第一策略控制實體用于，向所述第二策略控制實體發(fā)送用量監(jiān)控請求；并根據(jù)收到的用量監(jiān)控信息，對用戶進行用量監(jiān)控； 所述第二策略控制實體用于，收到所述用量監(jiān)控請求時，根據(jù)所述用戶的用戶組簽約用量進行用量監(jiān)控決策，并向所述第一策略控制實體下發(fā)用量監(jiān)控信息。
8.如權(quán)利要求7所述的系統(tǒng)，其特征在于， 所述第一策略控制實體用于，所述第一策略控制實體通過DRA發(fā)現(xiàn)所述第二策略控制實體，并向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求； 其中所述DRA通過用戶的用戶組標(biāo)識發(fā)現(xiàn)所述第二策略控制實體。
9.如權(quán)利要求7或8所述的系統(tǒng)，其特征在于， 所述第一策略控制實體用于，在獲取到針對所述用戶進行用量監(jiān)控的指示時，向所述第二策略控制實體發(fā)送所述用量監(jiān)控請求。
10.如權(quán)利要求7或8所述的系統(tǒng)，其特征在于， 所述第二策略控制實體向所述第一策略控制實體下發(fā)的所述用量監(jiān)控信息，包括監(jiān)控鍵和監(jiān)控閾值。
11.如權(quán)利要求10所述的系統(tǒng)，其特征在于，所述系統(tǒng)還包括策略執(zhí)行實體， 所述第一策略控制實體用于，收到所述用量監(jiān)控信息后，向所述策略執(zhí)行實體下發(fā)控制策略和所述用量監(jiān)控信息，其中所述控制策略中包含所述監(jiān)控鍵，所述用量監(jiān)控信息中包含所述監(jiān)控鍵和監(jiān)控閾值；以及，根據(jù)收到的所述策略執(zhí)行實體上報的累計監(jiān)控用量決策控制策略、和/或，根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求； 所述策略執(zhí)行實體用于，根據(jù)收到的控制策略和所述用量監(jiān)控信息，執(zhí)行用量監(jiān)控；以及，向所述第一策略控制實體上報累計監(jiān)控用量。
12.如權(quán)利要求11所述的系統(tǒng)，其特征在于， 所述第一策略控制實體根據(jù)所述累計監(jiān)控用量決策是否向所述第二策略控制實體發(fā)送用量監(jiān)控請求，是指 如果所述累計監(jiān)控用量達到所述監(jiān)控閾值，則所述第一策略控制實體決策向所述第二策略控制實體發(fā)送用量監(jiān)控請求； 如果所述累計監(jiān)控用量沒有達到所述監(jiān)控閾值，則所述第一策略控制實體決策不向所述第二策略控制實體發(fā)送用量監(jiān)控請求。
全文摘要
本發(fā)明公開了一種組用戶用量監(jiān)控方法及系統(tǒng)，第一策略控制實體向第二策略控制實體發(fā)送用量監(jiān)控請求；第二策略控制實體收到用量監(jiān)控請求時，根據(jù)用戶組簽約用量進行用量監(jiān)控決策，并向第一策略控制實體下發(fā)用量監(jiān)控信息；第一策略控制實體根據(jù)收到的用量監(jiān)控信息，對用戶進行用量監(jiān)控。本發(fā)明通過引入專用的策略控制實體，用戶組內(nèi)的每個成員用戶附著的策略控制實體向該專用的策略控制實體請求用量監(jiān)控，實現(xiàn)對共享簽約用量的組用戶的用量監(jiān)控，從而解決了現(xiàn)有用量監(jiān)控機制的不足。
文檔編號H04L12/24GK102904740SQ20111021355
公開日2013年1月30日 申請日期2011年7月28日 優(yōu)先權(quán)日2011年7月28日
發(fā)明者毛玉欣 申請人:中興通訊股份有限公司