策略和計費規(guī)則功能的選擇方法、裝置及系統(tǒng)的制作方法
【專利摘要】本發(fā)明公開了一種策略和計費規(guī)則功能（PCRF）的選擇方法、裝置及系統(tǒng)，該方法包括以下步驟：Diameter路由代理（DRA）接收為用戶組中第一用戶服務的PCRF發(fā)送的該用戶組的用戶組信息；DRA根據該用戶組信息和上述PCRF的地址信息，為該用戶組內的其他用戶選擇上述PCRF。通過本發(fā)明，解決了相關技術中用量監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題，保證了為用戶組內的用戶選擇一個統(tǒng)一的PCRF來管理用戶組的用量，提高了系統(tǒng)的可操作性。
【專利說明】策略和計費規(guī)則功能的選擇方法、裝置及系統(tǒng)
【技術領域】
[0001]本發(fā)明涉及通信領域，具體而言，涉及一種策略和計費規(guī)則功能(Policy andCharging Rules Function,簡稱為PCRF)的選擇方法、裝置及系統(tǒng)。
【背景技術】
[0002]第三代合作伙伴計劃(3rdGeneration Partnership Project,簡稱為 3GPP)定義了針對移動網絡的策略和計費控制(Policy and Charging Control，簡稱為PCC)架構，圖1是根據相關技術的3GPP PCC架構示意圖，如圖1所示，各功能如下描述:
[0003]PCRF，用于業(yè)務包含的業(yè)務數(shù)據流在傳輸過程中使用網絡資源制定資源控制策略，包括服務質量(Quality of Service，簡稱為QoS)控制策略和計費控制策略。
[0004]策略和計費執(zhí)行功能(Policyand Charging Enforcement Function,簡稱為PCEF)，用于執(zhí)行PCRF下發(fā)的或者PCEF上預配置的PCC規(guī)則，對網絡上傳輸?shù)腎P報文進行檢測，識別該IP報文隸屬的業(yè)務數(shù)據流，并對業(yè)務數(shù)據流提供QoS和計費控制。
[0005]承載綁定和事件上報功能(BearerBinding and Event Report Function,簡稱為BBERF)，主要用于對網絡上傳輸?shù)木W絡協(xié)議(Internet Protocol，簡稱為IP)報文進行檢測，并將IP報文按照規(guī)則映射到對應的承載通道上。BBERF還執(zhí)行承載相關事件的上報，例如，當承載丟失，或者發(fā)生接入網絡切換的時候，都需要將相應的事件上報給PCRF，請求PCRF進行相應的決策。
[0006]用戶簽約數(shù)據庫(Subscription Profile Repository,簡稱為SPR),用于保存用戶簽約的業(yè)務信息，為PCRF制訂PCC規(guī)則提供必要的用戶簽約信息。
[0007]在線計費系統(tǒng)(Online Charging System,簡稱為0CS)和離線計費系統(tǒng)(Off lineCharging System,簡稱為0FCS),分別用于離線和在線計費。
[0008]在用戶開展業(yè)務過程中，PCC按照如下原理為業(yè)務(由若干業(yè)務數(shù)據流組成)在傳輸過程中動態(tài)提供QoS保證:
[0009]首先，業(yè)務包含的每個業(yè)務數(shù)據流都對應一個具體的PCC規(guī)則，PCC規(guī)則中定義了該業(yè)務數(shù)據流傳輸時需要使用的QoS資源。在業(yè)務數(shù)據流在承載網絡中傳輸之前，PCRF需要根據各種信息為業(yè)務數(shù)據流決策并制定PCC規(guī)則。PCRF決策并制定PCC規(guī)則所依據的信息包括:
[0010](I)從AF接收的業(yè)務協(xié)商信息。該業(yè)務協(xié)商信息就是用戶開展業(yè)務時和通信對端協(xié)商的開展所述業(yè)務的信息，例如，開展所述業(yè)務對QoS的要求、通信雙方使用的IP地址、端口號、所使用的協(xié)議等信息。
[0011](2)從SPR接收的用戶簽約信息。例如，用戶簽約信息中包含用戶和運營商簽約的QoS信息；用戶開展業(yè)務時，業(yè)務對QoS的要求不能超過用戶簽約信息所規(guī)定的用戶可以使用的QoS fp息ο
[0012](3)PCRF自身存儲的運營商自定義策略。例如運營商對漫游用戶和非漫游用戶開展業(yè)務需要區(qū)分控制，這種運營商自行定義的區(qū)分控制策略可以配置在PCRF上。[0013](4)從PCEF或者BBERF上接收的接入相關信息。例如，用戶附著到網絡時，PCRF需要通過PCEF或者BBERF獲取用戶接入網絡的信息，以供PCRF為用戶開展業(yè)務進行策略決策。
[0014](5)從OCS獲取用戶的信用信息。例如，一旦用戶的信用用完或者不夠時，PCRF就無法授權所述用戶開展業(yè)務。
[0015]其次，PCRF根據上述信息對業(yè)務數(shù)據流決策制定PCC規(guī)則，并將PCC規(guī)則下發(fā)給PCEF (如果網絡中存在BBERF，則PCRF還需要制定QoS規(guī)則，并下發(fā)給BBERF)。PCEF需要根據PCC規(guī)則的QoS要求建立相應的承載，并將PCC規(guī)則綁定到對應的承載上(如果網絡中存在BBERF，則由BBERF根據QoS規(guī)則建立承載)。如果網絡中已經有和PCC規(guī)則或者QoS規(guī)則指示的QoS相匹配的承載，則將所述PCC規(guī)則或者QoS規(guī)則綁定到已有的承載上。
[0016]此后，當用戶開展業(yè)務，業(yè)務數(shù)據流在承載網絡上傳輸?shù)臅r候，終端和網絡設備可以根據五元組(由源IP地址、源端口號、目的IP地址、目的端口號、協(xié)議組成)將組成該業(yè)務數(shù)據流的IP報文匹配到相應的PCC規(guī)則/QoS規(guī)則，根據PCC規(guī)則/QoS規(guī)則和承載的綁定關系，就可以將所述業(yè)務數(shù)據流匹配到相應的承載上，從而為業(yè)務數(shù)據流在承載網絡上的傳輸提供QoS保證。當用戶開展的業(yè)務結束的時候，相應的PCC規(guī)則需要從承載網絡上刪除，即釋放分配給所述業(yè)務使用的QoS資源。通過上述PCC機制一方面可以按照業(yè)務對QoS的需求分配相應的QoS資源，另一方面實現(xiàn)了需要QoS資源時就可以分配，不需要QoS資源時，就可以及時釋放，因此通過PCC機制可以達到提升用戶業(yè)務體驗，提高網絡資源使用效率的目的。
[0017]為了提高網絡營運的靈活性，例如，對于某種業(yè)務，運營商希望前IOM是供用戶免費使用的，當用戶的用量超出IOM之后，就需要收取費用；再比如，運營商希望給用戶在IOM的流量之內提供一種帶寬，當流量超出IOM之后需要對該用戶的帶寬進行限制。對于上述場景，要求在用戶開展業(yè)務時，PCRF向PCEF下發(fā)針對業(yè)務的控制策略的同時，還需要下發(fā)用量監(jiān)控，要求PCEF對所述業(yè)務的流量進行監(jiān)控。當所述業(yè)務的流量達到監(jiān)控所要求的閾值時，PCEF需要向PCRF上報用量監(jiān)控結果，以便PCRF根據用量監(jiān)控結果重新對所述業(yè)務進行策略決策，產生新的控制策略。
[0018]圖2是根據相關技術的用量監(jiān)控實現(xiàn)流程的示意圖，如圖2所示，用量監(jiān)控的實現(xiàn)過程的流程如下:
[0019]步驟A1-A3，為PCRF向PCEF下發(fā)用量監(jiān)控的過程。其中，業(yè)務由一個或者多個業(yè)務數(shù)據流構成，PCRF需要為每個業(yè)務數(shù)據流制定控制策略(PCC規(guī)則)并下發(fā)給PCEF，PCEF按照PCC規(guī)則對業(yè)務數(shù)據流實施QoS和計費控制。如果需要對該業(yè)務實施用量監(jiān)控，則PCRF在下發(fā)PCC規(guī)則時，同時下發(fā)用量監(jiān)控，所述用量監(jiān)控由一個監(jiān)控關鍵字(monitoringkey)和閾值(threshold)組成，其中，需要對哪些業(yè)務數(shù)據流實施用量監(jiān)控，就在描述業(yè)務數(shù)據流的PCC規(guī)則中包含所述monitoring key。PCRF將上述信息下發(fā)給PCEF，PCEF收到所述信息后對所述業(yè)務數(shù)據流實施用量監(jiān)控。
[0020]例如，流程中需要實施用量監(jiān)控的業(yè)務包含了業(yè)務數(shù)據流-1和業(yè)務數(shù)據流_2，則PCRF向PCEF下發(fā)用量監(jiān)控的過程如步驟A1-A2描述:
[0021]步驟Al.PCRF為所述業(yè)務進行策略決策，產生控制策略(PCC規(guī)則)，同時需要為所述業(yè)務實施用量監(jiān)控，則PCRF分配監(jiān)控關鍵字monitoring key,并包含在PCC規(guī)則-1和PCC規(guī)則-2中，同時為所述monitoring key根據用戶的簽約用量分配閾值threshold,并將所述monitoring key和threshold包含在用量監(jiān)控信息(Usage MonitoringInformation)中。
[0022]步驟A2.PCRF向PCEF下發(fā)控制策略，包含PCC規(guī)則_1、PCC規(guī)則_2和用量監(jiān)控信
肩、O
[0023]步驟B，當PCEF收到PCRF下發(fā)的控制策略后，安裝PCC規(guī)則，并按照用量監(jiān)控信息，對PCC規(guī)則對應的業(yè)務數(shù)據流(即業(yè)務數(shù)據流I和業(yè)務數(shù)據流2)實施用量監(jiān)控。
[0024]步驟C,用量監(jiān)控上報。當PCEF對該Monitoring Key監(jiān)控的累計用量達到對應的所述閾值時，或者PCRF要求上報用量監(jiān)控時，PCEF上報用量監(jiān)控。上報的用量監(jiān)控信息(Usage Monitoring Information)中包含所述 Monitoring Key 以及累計使用用量。
[0025]步驟D，根據用量監(jiān)控上報結果，PCRF對所述業(yè)務數(shù)據流重新制定控制策略。例如，累計流量已經超出規(guī)定的流量，PCRF需要對所述業(yè)務的使用帶寬進行降低。同時，如果還需要對所述業(yè)務繼續(xù)執(zhí)行用量監(jiān)控，則PCRF需要為所述monitoring key根據用戶簽約用量重新分配閾值。當所述用戶的累計用量已經到達所述簽約用量時，就無法對所述用戶繼續(xù)實施用量監(jiān)控。
[0026]步驟E，PCRF向PCEF下發(fā)針對該業(yè)務的新的控制策略。如果需要繼續(xù)對所述業(yè)務實施用量控制，則下發(fā)的所述信息中還需要包含用量監(jiān)控信息。
[0027]上述流程描述的是對單個業(yè)務實施用量監(jiān)控。如果需要對用戶開展的多個或者所有業(yè)務實施用量監(jiān)控，則需要在對應業(yè)務數(shù)據流的PCC規(guī)則中包含監(jiān)控關鍵字monitoringkey即可。
[0028]可見，現(xiàn)有技術描述的簽約用量針對單個用戶，即僅能實現(xiàn)對單個用戶實施用量監(jiān)控。然而，在實際運營過程中，還會出現(xiàn)多個用戶共享簽約用量的需求，例如，一個家庭簽約一個用量套餐500M，該家庭簽約用量被家庭所有成員所共享。對于如上述家庭用戶組的用量監(jiān)控需求，利用現(xiàn)有用量監(jiān)控機制無法實現(xiàn)。
[0029]針對相關技術中用戶監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題，目前尚未提出有效的解決方案。

【發(fā)明內容】

[0030]本發(fā)明的主要目的在于提供一種PCRF的選擇方案，以至少解決上述相關技術中用戶監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題。
[0031]根據本發(fā)明的一個方面，提供了一種PCRF的選擇方法，包括以下步驟:DRA接收為用戶組中第一用戶服務的PCRF發(fā)送的該用戶組的用戶組信息；DRA根據該用戶組信息和上述PCRF的地址信息，為該用戶組內的其他用戶選擇上述PCRF。
[0032]優(yōu)選地，DRA接收PCRF發(fā)送的上述用戶組信息之前，該方法還包括:PCRF將上述用戶組信息直接發(fā)送給DRA，或者PCRF將上述用戶組信息發(fā)送給PCEF，由該PCEF將上述用戶組信息發(fā)送給DRA，其中，上述用戶組信息包括用戶組標識和用戶組中所有成員的用戶標識。
[0033]優(yōu)選地，PCRF將上述用戶組信息發(fā)送給DRA之前，該方法還包括:PCRF根據第一用戶的用戶標識從SPR獲取該用戶組的用戶組信息。[0034]優(yōu)選地，DRA為該用戶組內的其他用戶選擇上述PCRF之前，該方法還包括:DRA接收PCRF發(fā)送的自身的地址信息。
[0035]優(yōu)選地，DRA接收PCRF發(fā)送的該用戶組的用戶組信息之后，該方法還包括:DRA建立該用戶組信息和上述PCRF的地址信息的對應關系。
[0036]優(yōu)選地，上述第一用戶為DRA首次建立上述對應關系時，PCRF所服務的用戶。
[0037]優(yōu)選地，DRA為該用戶組內的其他用戶選擇PCRF包括:DRA判斷為上述第一用戶選擇的PCRF與為上述第一用戶所屬用戶組內其他用戶選擇的PCRF是否相同；如果不相同，則DRA通知PCEF重新為該用戶組內的其他用戶進行PCRF選擇，其中，重新選擇的PCRF是為上述第一用戶服務的PCRF，該通知中包括為上述第一用戶服務的PCRF的地址信息。
[0038]優(yōu)選地，DRA通知PCEF重新為該用戶組內的其他用戶進行PCRF選擇之后，該方法還包括=PCEF終止與原PCRF的IP-CAN會話，并建立與服務上述第一用戶的PCRF之間的IP-CAN 會話。
[0039]優(yōu)選地，DRA為該用戶組內的其他用戶選擇PCRF之后，該方法還包括:PCRF根據該用戶組的簽約用量信息為該用戶組內的用戶開展業(yè)務進行用量監(jiān)控決策，并向PCEF下發(fā)用戶監(jiān)控。
[0040]根據本發(fā)明的另一方面，提供了一種PCRF的選擇裝置，位于DRA，該裝置包括:接收模塊，用于接收為用戶組中第一用戶服務的PCRF發(fā)送的該用戶組的用戶組信息；以及選擇模塊，用于根據接收模塊接收到的該用戶組信息和上述PCRF的地址信息，為該用戶組內的其他用戶選擇上述PCRF。
[0041]優(yōu)選地，該裝置還包括:建立模塊，用于建立上述用戶組信息和上述PCRF的地址信息的對應關系。
[0042]優(yōu)選地，該裝置還包括:判斷模塊，用于判斷為上述第一用戶選擇的PCRF與為該用戶組內其他用戶選擇的PCRF是否相同；以及處理模塊，用于在判斷模塊判斷為上述第一用戶選擇的PCRF與為上述第一用戶所屬用戶組內其他用戶選擇的PCRF不相同的情況下，通知PCEF重新為該用戶組內的其他用戶進行PCRF選擇，其中，重新選擇的PCRF是為上述第一用戶服務的PCRF，該通知中包括為上述第一用戶服務的PCRF的地址信息。
[0043]根據本發(fā)明的再一方面，還提供了一種PCRF的選擇系統(tǒng)，包括PCRF、SPR和上述PCRF的選擇裝置位于的DRA，其中，PCRF包括:獲取轉發(fā)模塊，用于從SPR獲取第一用戶所屬的用戶組的用戶組信息，并將該用戶組信息發(fā)送給DRA ;SPR包括:查詢下發(fā)模塊，用于根據PCRF的指令查詢并下發(fā)該用戶組信息。
[0044]通過本發(fā)明，采用DRA為歸屬于同一用戶組的用戶選擇相同的PCRF的方式，解決了相關技術中用量監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題，保證了為用戶組內的用戶選擇一個統(tǒng)一的PCRF來管理用戶組的用量，提高了系統(tǒng)的可操作性。
【專利附圖】

【附圖說明】
[0045]此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中:
[0046]圖1是根據相關技術的3GPP PCC架構示意圖；
[0047]圖2是根據相關技術的用量監(jiān)控實現(xiàn)流程的示意圖；[0048]圖3是根據本發(fā)明實施例的PCRF的選擇方法的流程圖；
[0049]圖4是根據本發(fā)明實施例的PCRF的選擇裝置的結構示意圖；
[0050]圖5是根據本發(fā)明優(yōu)選實施例的PCRF的選擇裝置的結構示意圖；
[0051]圖6是根據本發(fā)明實施例的PCRF的選擇系統(tǒng)的結構示意圖；
[0052]圖7是本發(fā)明實施例二的選擇PCRF的流程示意圖；
[0053]圖8是本發(fā)明實施例二的用戶簽約信息的示意圖；
[0054]圖9是本發(fā)明實施例二的用戶組簽約信息的示意圖；
[0055]圖10是本發(fā)明實施例三的選擇PCRF的流程示意圖；
[0056]圖11是本發(fā)明實施例四的選擇PCRF的流程示意圖；
[0057]圖12是本發(fā)明實施例五的PCRF對用戶組進行用量監(jiān)控的流程示意圖。
【具體實施方式】
[0058]下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。
[0059]根據本發(fā)明實施例，提供了一種PCRF的選擇方法。圖3是根據本發(fā)明實施例的PCRF的選擇方法的流程圖，如圖3所示，該方法包括以下步驟:
[0060]步驟S302，DRA接收為用戶組中第一用戶服務的PCRF發(fā)送的該用戶組的用戶組信息；
[0061]步驟S304，DRA根據該用戶組信息和上述PCRF的地址信息，為該用戶組內的其他用戶選擇服務第一用戶的PCRF。
[0062]通過上述步驟，采用DRA為歸屬于同一用戶組的用戶選擇相同的PCRF的方式，解決了相關技術中用量監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題，保證了為用戶組內的用戶選擇一個統(tǒng)一的PCRF來管理用戶組的用量，提高了系統(tǒng)的可操作性。
[0063]例如，在DRA接收到用戶的IP連接訪問網絡(IP-Connectivity Access Network,簡稱為IP-CAN)會話建立請求時，DRA需要選擇一個PCRF進行服務。在實施過程中，方式一、DRA可以獲取該用戶所在的用戶組信息，確定該用戶所在的用戶組中已有成員選擇了PCRF,則DRA選擇該PCRF發(fā)送該用戶的IP-CAN會話建立請求；方式二、用戶組中首次選擇PCRF的用戶在選擇PCRF之后，在DRA中建立了該用戶組和該PCRF的對應關系，則DRA根據該對應關系為該用戶組內其他用戶選擇與該用戶組對應的PCRF。S卩，DRA為歸屬于同一用戶組的用戶選擇相同的PCRF。該方法可以保證DRA在收到同一用戶組的用戶的IP-CAN會話建立請求時，為同一用戶組的用戶選擇同一 PCRF，使PCRF對用戶組的用量監(jiān)控成為可倉泛。
[0064]在實施過程中，DRA可以通過為用戶組中第一用戶服務的PCRF從SPR中獲取第一用戶所屬的用戶組標識。具體地，還可以有兩種方法:(I)該PCRF從SPR中獲取第一用戶所屬的用戶組標識后，將用戶組標識指示的用戶組信息直接發(fā)送給DRA ; (2)該PCRF從SPR中獲取第一用戶所屬的用戶組標識后，將用戶組標識指示的用戶組信息發(fā)送給與第一用戶對應的PCEF，由該PCEF將該用戶組信息轉送給DRA。其中，上述用戶組信息可以包括用戶組標識和該用戶組中所有成員的用戶標識。
[0065]優(yōu)選地，PCRF將用戶組信息發(fā)送給DRA之前，PCRF根據第一用戶的用戶標識從SPR獲取用戶組的用戶組信息。例如，DRA向與第一用戶對應的PCEF返回為第一用戶選擇的PCRF的地址信息；PCEF接收PCRF的地址信息后，通過PCRF的地址信息指示的PCRF從SPR中獲取第一用戶所屬的用戶組信息，并將用戶組信息發(fā)送給DRA。
[0066]優(yōu)選地，步驟S302之后，DRA建立用戶組信息和PCRF地址信息的對應關系。實施過程中，上述第一用戶為DRA首次建立該對應關系時，PCRF所服務的用戶。例如，用戶組標識和PCRF地址的對應關系，其中，用戶組中所有成員均對應同一 PCRF。
[0067]優(yōu)選地，在步驟S304之前，DRA接收到PCRF發(fā)送的用戶組信息之外，還接收到PCRF發(fā)送的自身的地址信息。
[0068]此外，在步驟S304中，DRA還可以判斷為第一用戶選擇的PRCF與為歸屬于同一用戶組的第二用戶選擇的PRCF是否相同；如果不相同，則DRA通知PCEF重新為第二用戶選擇與第一用戶相同的PCRF，在該通知中包括為第一用戶服務的PCRF的地址信息。例如，DRA為第一用戶服務的PCRF為PCRFUU DRA為與第一用戶歸屬相同用戶組的第二用戶也選擇PCRFl進行服務。如果在判斷之前，PCEF為第二用戶選擇PCRF2，則在判斷不同之后，PCEF終止與原PCRF (PCRF2)的IP-CAN會話，并建立與PCRFl之間的IP-CAN會話。這樣可以進一步地保證DRA為歸屬于同一用戶組的用戶選擇相同的PCRF進行服務。
[0069]優(yōu)選地，在步驟S304之后，PCRF根據用戶組的簽約用量信息為用戶組內的用戶開展業(yè)務進行用量監(jiān)控決策，并向PCEF下發(fā)用戶監(jiān)控。通過本優(yōu)選實施例，PCRF可以管理用戶組的簽約用量，從而實現(xiàn)了對用戶組的用量監(jiān)控需求。
[0070]對應于上述方法，本發(fā)明實施例還提供了一種PCRF的選擇裝置。圖4是根據本發(fā)明實施例的PCRF的選擇裝置的結構示意圖，如圖4所示，該裝置位于DRA，包括:接收模塊42，用于接收為用戶組中第一用戶服務的PCRF發(fā)送的該用戶組的用戶組信息；以及選擇模塊44，耦合至接收模塊42，用于根據接收模塊42接收到的該用戶組信息和上述PCRF的地址信息，為該用戶組內的其他用戶選擇上述PCRF進行服務。
[0071]通過上述裝置，選擇模塊44為歸屬于同一用戶組的用戶選擇相同的PCRF，解決了相關技術中用量監(jiān)控機制無法實現(xiàn)家庭用戶組的用量監(jiān)控需求的問題，保證了為用戶組內的用戶選擇一個統(tǒng)一的PCRF來管理用戶組的用量，提高了系統(tǒng)的可操作性。
[0072]圖5是根據本發(fā)明優(yōu)選實施例的PCRF的選擇裝置的結構示意圖，如圖5所示，該裝置還包括:建立模塊52，用于建立第一用戶所屬用戶組信息和上述PCRF的地址信息的對應關系。也即，在用戶組中第一用戶確定其選擇的PCRF后，DRA建立為第一用戶所屬用戶組與第一用戶所選PCRF的對應關系，以便該用戶組中其他用戶選擇與第一用戶相同的PCRF進行服務。
[0073]優(yōu)選地，該裝置還包括:判斷模塊54，耦合至建立模塊52，用于判斷為第一用戶選擇的PCRF與為用戶組內其他用戶選擇的PCRF是否相同；以及處理模塊56，耦合至判斷模塊54和選擇模塊44，用于在判斷模塊54判斷為第一用戶選擇的PCRF與為用戶組內其他用戶選擇的PCRF不相同的情況下，通知PCEF重新為用戶組內的其他用戶進行PCRF選擇，其中，重新選擇的PCRF是為第一用戶服務的PCRF，該通知中包括為第一用戶服務的PCRF的地址信息。
[0074]根據本發(fā)明實施例，還提供了一種PCRF的選擇系統(tǒng)。圖6是根據本發(fā)明實施例的PCRF的選擇系統(tǒng)的結構示意圖，如圖6所示，該系統(tǒng)包括PCRF62、SPR64和上述PCRF的選擇裝置所處的DRA66，其中，PCRF62包括:獲取轉發(fā)模塊622，耦合至接收模塊42和選擇模塊44，用于從SPR64獲取第一用戶所屬的用戶組的用戶組信息，并將該用戶組信息發(fā)送給DRA66 ；SPR64包括:查詢下發(fā)模塊642，耦合至獲取轉發(fā)模塊622，用于根據PCRF62的指令查詢并下發(fā)該用戶組信息。
[0075]下面結合優(yōu)選實施例和附圖對上述實施例的實現(xiàn)過程進行詳細說明。
[0076]實施例一
[0077]由于用量監(jiān)控決策在PCRF上實現(xiàn)，要實現(xiàn)對用戶組的用量監(jiān)控，需要由PCRF管理用戶組的簽約用量。然而，DRA根據用戶標識等選擇為用戶接入服務的PCRF時，不同的用戶接入網絡，可能會選擇不同的PCRF為其服務，這樣無法利用現(xiàn)有用量監(jiān)控機制實現(xiàn)對上述用戶組的用量監(jiān)控需求。所以，為了對共享簽約用量的用戶組的用量監(jiān)控需求，本實施例給出了一種PCRF選擇方法，以實現(xiàn)用戶組用量監(jiān)控的問題。
[0078]在實施過程中，本實施例的PCEF選擇方法可以包括如下步驟:
[0079]步驟I,為用戶組中第一用戶接入服務的PCRF向Diameter路由代理(DiameterRouting Agent，簡稱為DRA)發(fā)送該用戶所屬的用戶組信息。其中，這里的第一用戶為DRA首次建立用戶組信息和PCRF信息對應關系時，PCRF所服務的用戶。
[0080]其中，用戶組信息至少包括:用戶組標識，以及用戶組所包含的所有用戶的用戶標識。用戶組信息可以由PCRF直接發(fā)送給DRA，或者PCRF通過PCEF發(fā)送給DRA。
[0081]優(yōu)選地，在步驟I之前，DRA建立所述第一用戶的用戶標識和PCRF地址的對應關系。以及在步驟I之前，PCRF還從SPR獲取所述第一用戶對應的用戶組簽約信息，該用戶組簽約信息包括用戶組信息之外，至少還包括用戶組簽約用量。PCRF向DRA發(fā)送用戶組信息之外，可選的還包括所述PCRF向DRA發(fā)送所述PCRF的地址信息。
[0082]優(yōu)選地，在步驟I之后，DRA上建立用戶組信息和PCRF地址信息的對應關系。
[0083]步驟2，根據所述用戶組信息和PCRF地址的對應關系，DRA為用戶組內的其他用戶的接入選擇PCRF。
[0084]在步驟2之后，PCRF根據用戶組簽約用量為用戶組內的用戶開展業(yè)務進行用量監(jiān)控決策。
[0085]實施例二
[0086]本實施例中的用戶組由用戶-1和用戶-2構成，且共享用戶組簽約用量。在本實施例中，給出了當用戶-1和用戶-2接入到網絡或者發(fā)起建立PDN連接時，如何為用戶-1和用戶-2，通過proxy DRA (代理DRA)選擇到相同的PCRF的過程。
[0087]圖7是本發(fā)明實施例二的選擇PCRF的流程示意圖，如圖7所示，該流程包括如下步驟:
[0088]步驟S701，用戶組內的用戶-1附著到網絡或者發(fā)起PDN連接建立請求，假設根據請求消息中包含的信息(例如，APN)選擇到PCEF-1，用戶-1向PCEF-1發(fā)起所述請求。
[0089]步驟S702，PCEF-1接收到所述請求之后，向DRA發(fā)送IP-CAN會話建立請求，該請求消息中包含用戶_1的標識(subscriber-lid)。
[0090]步驟S703，DRA根據subscriber-lid選擇為該用戶接入服務的PCRF。DRA建立subscriber-1 id和PCRF信息(例如，PCRF的地址)的對應關系。
[0091 ] 步驟S704，DRA將所述IP-CAN會話建立請求消息轉發(fā)給PCRF。[0092]步驟S705，PCRF根據請求消息中的subscriber-1 id從SPR中獲取用戶-1的簽約信息，同時SPR根據subscriber-1 id判斷用戶-1存在于用戶組中，SPR將對應的用戶組簽約信息一并返回給PCRF。
[0093]圖8是本發(fā)明實施例二的用戶簽約信息的示意圖，如圖8所示，用戶簽約信息至少包括用戶標識(subscriber id)以及用戶組標識(group id)。圖9是本發(fā)明實施例二的用戶組簽約信息的示意圖，如圖9所示，用戶組簽約信息至少包括用戶組標識(group id)、用戶組成員標識(subscriber id)以及簽約用量等。
[0094]PCRF為用戶-1建立IP-CAN會話，并返回IP-CAN會話建立成功的響應，該響應消息中將包括用戶組信息(用戶組標識group id和用戶組成員標識，例如，用戶-1標識subscirber-1 id和用戶-2標識subscriber-2 id),所述信息將反饋給DRA,以便DRA保證為所述用戶組的后續(xù)用戶選擇到相同的PCRF，可通過如下兩種過程(case-Ι和case-2)實現(xiàn):
[0095](I)情況一(Case-1)過程:
[0096]步驟S706a，PCRF為用戶-1建立IP-CAN會話，并返回IP-CAN會話建立成功的響應消息，該響應消息中包括用戶組信息，其中，用戶組信息至少包括用戶組標識(group id)和用戶組成員標識(包括用戶-1標識subscriber-1 id和用戶-2標識subscriber-2 id)。
[0097]步驟S707a，上述IP-CAN會話建立響應消息經過DRA，DRA獲取用戶組信息(groupid, subscriber-lid, subscriber-2id),由于步驟 S703 已經建立 subscriber-1 和 PCRF 信息的對應關系，因此，這里DRA結合這兩部分的信息建立用戶組信息(group id, subscriber-lid, subscriber-2id)和 PCRF 信息的對應關系。
[0098]需要說明的是，上述步驟S706a和步驟S707a也可以為:在步驟S706a中，PCRF在返回的IP-CAN會話建立響應消息中，直接包括步驟S706中的用戶組信息和PCRF信息(例如，PCRF地址);在步驟S707a中，DRA直接建立并保存用戶組信息和PCRF信息的對應關系。
[0099]步驟S708a，DRA將上述IP-CAN會話建立響應消息返回給PCEF-1。用戶-1完成網絡附著或者PDN連接的過程。
[0100](2)情況二(Case-2)過程
[0101]步驟S706b，PCRF向PCEF-1返回IP-CAN會話建立響應消息，該響應消息中包括用戶組信息(group id, subscriber-lid, subscriber_2id)?？蛇x的，響應消息中可以包括PCRF信息。
[0102]步驟S707b，PCEF-1接收所述IP-CAN會話建立響應消息后，將上述用戶組信息發(fā)送給DRA。如果步驟S706b有PCRF信息，則PCEF-1將PCRF信息也發(fā)送給DRA。
[0103]步驟S708b，根據步驟S703中subsriber_lid和PCRF信息的對應關系，以及步驟S707b接收的用戶組信息,DRA建立用戶組信息(group id, subscriber-1 id, subscriber-2id)和PCRF信息的對應關系。如果步驟S707b還發(fā)送了 PCRF信息，則DRA直接建立用戶組信息和PCRF信息的對應關系。
[0104]步驟S709 - S715，為所述用戶組內的用戶_2附著到網絡或者發(fā)起PDN連接建立的過程:
[0105]步驟S709，用戶-2接入網絡，選擇PCEF-2發(fā)起附著請求或者PDN連接建立請求，該請求消息中包括用戶_2標識(subscriber-2 id)。[0106]步驟S710，PCEF-2向DRA發(fā)送IP-CAN會話-2建立請求，該請求消息中包括subscriber-2icL
[0107]步驟S711，DRA根據subscriber-2 id和步驟S707a或者步驟S708b建立的用戶組信息和PCRF信息的對應關系，為用戶-2選擇所述PCRF。
[0108]步驟S712，DRA向PCRF發(fā)起IP-CAN會話-2建立請求。
[0109]步驟S713，PCRF根據subscriber-2 id從SPR獲取用戶_2的簽約信息。PCRF或者SPR根據subscriber-2 id以及步驟S705步傳送過的用戶組信息,判斷subscriber-2id對應的用戶-2屬于所述用戶組，但用戶組信息已經發(fā)送給了 PCRF，因此，在該步驟中可以不用再發(fā)送所述用戶組信息。
[0110]步驟S714，PCRF為用戶_2建立IP-CAN會話_2，并向PCEF-2返回IP-CAN會話-2
建立響應。
[0111]需要說明的是，如果步驟S713中SPR還將所述用戶組信息發(fā)送給PCRF JlJPCRFi可以將步驟S706a或步驟S706b中的所述用戶組信息發(fā)送給DRA，或者通過PCEF-2發(fā)送給DRA (如步驟S715所示)，其發(fā)送過程參考用戶-1接入網絡時對應的發(fā)送過程(case-Ι或case-2描述的過程)。如果步驟S713沒有將所述用戶組信息發(fā)送給PCRF，則向DRA再次更新用戶組信息的過程可省略。
[0112]實施例三
[0113]實施例三描述的場景和實施例二基本相同，區(qū)別在于通過redirect DRA(重定向DRA)為用戶-1和用戶-2選擇到相同的PCRF。圖10是本發(fā)明實施例三的選擇PCRF的流程示意圖，如圖10所示，該流程包括如下步驟:
[0114]步驟S1001，用戶組內的用戶-1附著到網絡或者發(fā)起PDN連接建立請求。假設根據請求消息中包括的信息(例如，APN)選擇到PCEF-1，用戶-1向PCEF-1發(fā)起所述請求。
[0115]步驟S1002，PCEF-1接收到所述請求之后，向DRA發(fā)送IP-CAN會話建立請求，該請求消息中包括用戶_1的標識(subscriber-1 id)。
[0116]步驟S1003，DRA根據subscriber-1 id選擇為所述用戶接入服務的PCRF。DRA建立subscriber-1 id和PCRF信息(例如，PCRF的地址)的對應關系。
[0117]步驟S1004，DRA向PCEF-1返回所述PCRF地址信息。
[0118]步驟S1005，PCEF-1根據DRA返回的PCRF地址信息，向PCRF發(fā)送IP-CAN會話建立請求，該請求消息中包括subscriber-1 id。
[0119]步驟S1006，PCRF根據請求消息中的subscriber-1 id從SPR中獲取用戶-1的簽約信息，同時SPR根據subscriber-1 id判斷用戶-1存在于用戶組中，SPR將對應的用戶組簽約信息一并返回給所述PCRF。其中，用戶簽約信息如圖8所示，至少包括用戶標識(subscriber id)以及用戶組標識(group id);用戶組簽約信息至少包括用戶組標識(group id)、用戶組成員標識(subscriber id)以及簽約用量等。
[0120]步驟S1007，PCRF為用戶-1建立IP-CAN會話，并返回IP-CAN會話建立成功的響應消息，該響應消息中包括用戶組信息，至少包括用戶組標識(group id)和用戶組成員標識(包括用戶-1標識subscriber-1 id和用戶-2標識subscriber-2 id)?？蛇x的,用戶組信息還包括PCRF地址信息。
[0121]步驟S1008，PCEF-1接收所述IP-CAN會話建立響應消息后，將所述用戶組信息發(fā)送給DRA，如果步驟S1007中有PCRF信息，則PCEF-1將該PCRF信息也發(fā)送給DRA。
[0122]步驟S1009，根據步驟S503中subsriber-1 id和PCRF信息的對應關系，以及步驟S1008接收的用戶組信息，DRA建立用戶組信息(group id, subscriber-lid, subscriber-2id)和PCRF信息的對應關系，如果步驟S1008還發(fā)送了 PCRF信息，則DRA直接建立用戶組信息和PCRF信息的對應關系。
[0123]步驟S1010 - S1016為用戶組內的用戶_2附著到網絡或者發(fā)起PDN連接建立的過程:
[0124]步驟SlO 10，用戶-2接入網絡，選擇PCEF-2發(fā)起附著請求或者PDN連接建立請求，該請求消息中包括用戶_2標識(subscriber_2id)。
[0125]步驟S1011，PCEF-2向DRA發(fā)送IP-CAN會話-2建立請求，該請求消息中包括subscriber-2icL
[0126]步驟S1012，DRA根據subscriber_2id和步驟S1009建立的用戶組信息和PCRF信息的對應關系，為用戶-2選擇所述PCRF。
[0127]步驟S1013，DRA將為用戶_2選擇的PCRF地址信息返回給PCEF-2。
[0128]步驟S1014，PCEF-2根據PCRF地址信息向PCRF發(fā)送IP-CAN會話-2建立請求，該請求消息中包含subscriber-2 id。
[0129]步驟S1015，PCRF根據subscriber-2 id從SPR獲取用戶_2的簽約信息。PCRF或者SPR根據subscriber-2 id以及步驟S1006傳送過的用戶組信息,判斷subscriber-2id對應的用戶-2屬于所述用戶組，但用戶組信息已經發(fā)送給了所述PCRF，因此在該步驟中可以不用再發(fā)送所述用戶組信息。
[0130]步驟S1016，PCRF為用戶-2建立IP-CAN會話-2，并向PCEF-2返回IP-CAN會話-2
建立響應。
[0131]需要說明的是，如果步驟S1015中SPR還將所述用戶組信息發(fā)送給所述PCRFJIJPCRF也可以將步驟S1007中用戶組信息通過PCEF-2發(fā)送給DRA (如步驟S1017所示)，其發(fā)送過程參考用戶-1接入網絡時對應的發(fā)送過程(步驟S1007和步驟S1008描述的過程)。如果步驟S1015沒有將所述用戶組信息發(fā)送給PCRF，則向DRA再次更新用戶組信息的過程可省略。
[0132]實施例四
[0133]實施例四描述的場景和實施例二基本相同，區(qū)別在用戶-1接入網絡的流程中，如果DRA還沒有建立用戶組信息和PCRF信息的對應關系，此時用戶組內的用戶-2已經發(fā)起接入網絡的流程，此時，如何保證為用戶-1和用戶-2選擇到同一個PCRF的過程。
[0134]圖11是本發(fā)明實施例四的選擇PCRF的流程示意圖，如圖11所示，該流程包括如下步驟:
[0135]步驟S1101-S1105的過程與實施例二中的步驟S701-S705相同這里不再重復描述。
[0136]步驟S1106-S1111為所述用戶組內的用戶_2接入網絡的流程，其流程發(fā)生過程中，DRA還沒有建立用戶組和PCRF-1地址的對應關系，即Case-1或者Case-2描述的過程還沒有完成。
[0137]步驟S1106，用戶-2向PCEF-2發(fā)起網絡附著或者PDN連接請求。[0138]步驟S1107，PCEF-2向DRA發(fā)起IP-CAN會話_2建立請求，該請求消息中包括subscriber-2icL
[0139]步驟SI 108，由于此時DRA上沒有subscriber-2 id對應的用戶組信息和PCRF地址的對應關系，此時，DRA根據subscriber-2 id為用戶_2選擇到PCRF-2，建立subscriber-2 id和PCRF-2地址的對應關系。
[0140]步驟S1109，DRA將所述IP-CAN會話_2建立請求消息發(fā)送給PCRF-2。
[0141]步驟S1110，根據步驟S1109中PCRF-2獲取的subscriber-2 id，向SPR獲取用戶-2的簽約信息，以及用戶組簽約信息。
[0142]步驟Sllll，PCRF-2向PCEF-2返回IP-CAN會話_2建立成功的響應。
[0143]Case-1和Case-2描述的過程和步驟S1104對應，為PCRF-1返回IP-CAN會話-1建立響應，并向DRA上更新用戶組信息(group id, subscriber-lid, subscriber_2id)的過程，其過程參考實施例二中對應的過程。
[0144]步驟S1115，根據步驟S1113a或步驟S1114b收到的用戶組信息建立的和PCRF的對應關系，即(group id, subscriber-lid, subscriber_2id)和 PCRF-1 地址的對應關系，以及步驟S1108建立的subscriber-2 id和PCRF-2地址的對應關系，DRA判斷為group-1d下的用戶-2選擇的是PCRF-2，并沒有選擇到group id對應的PCRF-1中，DRA重新為subscriber-2對應的用戶_2選擇PCRF-1。
[0145]步驟S1116，DRA向PCEF-2返回PCRF-1的地址，要求PCEF-2終止此前為用戶_2接入網絡建立的IP-CAN會話-2，重新建立IP-CAN會話。
[0146]步驟S1117，收到所述消息之后，PCEF-2發(fā)起到PCRF-2的IP-CAN會話_2的終止。
[0147]步驟S1118，PCEF-2根據PCRF-1的地址重新發(fā)起到PCRF-1的IP-CAN會話-2’的建立過程。
[0148]實施例五
[0149]本實施例是對用戶組進行用量監(jiān)控的過程，以前面的實施例描述的流程為基礎。前面的實施例描述的流程實現(xiàn)了對于用戶組內的所有用戶接入網絡的時候，都選擇相同的PCRF為其接入服務，本實施例由PCRF管理用戶組的簽約用量，為所述用戶組進行用量監(jiān)控。
[0150]圖12是本發(fā)明實施例五的PCRF對用戶組進行用量監(jiān)控的流程示意圖，如圖12所示，該流程包括如下步驟:
[0151]步驟S1201，用戶-1開展業(yè)務
[0152]步驟S1202，AF將業(yè)務協(xié)商信息下發(fā)給PCRF。
[0153]步驟S1203，根據該業(yè)務協(xié)商信息以及其他信息(例如，運營商策略等)，PCRF為所述業(yè)務進行策略決策，包括產生QoS和計費控制策略。同時根據前面實施例描述的PCRF從SPR中獲取的用戶組簽約信息(包括簽約用量)PCRF為所述用戶開展的所述業(yè)務進行用量監(jiān)控決策，包括為所述業(yè)務流分配monitoring key，并根據用戶組可用簽約用量為所述monitoring key 分配閾值(threshold-1)。
[0154]步驟S1204，PCRF將控制策略和用量監(jiān)控下發(fā)給PCEF-1。
[0155]步驟S1205，根據PCRF下發(fā)的信息，PCEF-1啟動用量監(jiān)控。
[0156]步驟S1206，當累計用量達到PCRF分配的threshold-1時，PCEF-1上報累計用量，PCRF可以根據上報結果重新分配新的閾值繼續(xù)實施監(jiān)控，或者終止用量監(jiān)控。
[0157]步驟S1207，用戶組內的用戶-2開展業(yè)務。
[0158]步驟S1208，AF將業(yè)務協(xié)商信息下發(fā)給PCRF。
[0159]步驟S1209，PCRF進行策略決策，同時進行用量監(jiān)控決策，即為所述業(yè)務分配monitoring key-2,同時根據用戶組的可用簽約用量為所述monitoring key分配閾值(threshold-2)。
[0160]步驟S1210，PCRF將控制策略和用量監(jiān)控下發(fā)給PCEF-2
[0161]步驟S1211，PCEF-2按照下發(fā)的信息對用戶_2開展的所述業(yè)務啟動用量監(jiān)控。
[0162]步驟S1212，當累計用量達到threshold-2時，PCEF-2執(zhí)行用量監(jiān)控上報，PCRF據此進行用量在分配，或者終止用量監(jiān)控。有關用量監(jiān)控決策、下發(fā)和上報的過程完全可以參照現(xiàn)有的用量監(jiān)控實現(xiàn)機制，不再詳細贅述。
[0163]綜上所述，本發(fā)明實施例提供了一種PCRF的選擇方案，采用DRA為歸屬于同一用戶組的用戶的IP-CAN會話建立請求選擇相同的PCRF的方式，保證了為用戶組內的用戶選擇到同一個PCRF，實現(xiàn)了對用戶組用量監(jiān)控的需求。
[0164]顯然，本領域的技術人員應該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結合。
[0165]以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。
【權利要求】
1.一種策略和計費規(guī)則功能PCRF的選擇方法，其特征在于，包括以下步驟: Diameter路由代理DRA接收為用戶組中第一用戶服務的PCRF發(fā)送的所述用戶組的用戶組信息； 所述DRA根據所述用戶組信息和所述PCRF的地址信息，為所述用戶組內的其他用戶選擇所述PCRF。
2.根據權利要求1所述的方法，其特征在于，所述DRA接收所述PCRF發(fā)送的所述用戶組信息之前，還包括: 所述PCRF將所述用戶組信息直接發(fā)送給所述DRA，或者所述PCRF將所述用戶組信息發(fā)送給策略和計費執(zhí)行功能PCEF，由該PCEF將所述用戶組信息發(fā)送給所述DRA，其中，所述用戶組信息包括所述用戶組標識和所述用戶組中所有成員的用戶標識。
3.根據權利要求2所述的方法，其特征在于，所述PCRF將所述用戶組信息發(fā)送給所述DRA之前,還包括: 所述PCRF根據所述第一用戶的用戶標識從用戶簽約數(shù)據庫SPR獲取所述用戶組的用戶組信息。
4.根據權利要求1所述的方法，其特征在于，所述DRA為所述用戶組內的其他用戶選擇所述PCRF之前,還包括: 所述DRA接收所述PCRF發(fā)送的所述PCRF的地址信息。
5.根據權利要求1所述的方法，`其特征在于，所述DRA接收所述PCRF發(fā)送的所述用戶組的用戶組信息之后，還包括: 所述DRA建立所述用戶組信息和所述PCRF的地址信息的對應關系。
6.根據權利要求5所述的方法，其特征在于，所述第一用戶為所述DRA首次建立所述對應關系時，所述PCRF所服務的用戶。
7.根據權利要求1至6中任一項所述的方法，其特征在于，所述DRA為所述用戶組內的其他用戶選擇所述PCRF包括: 所述DRA判斷為所述第一用戶選擇的PCRF與為所述用戶組內其他用戶選擇的PCRF是否相同； 如果不相同，則所述DRA通知策略和計費執(zhí)行功能PCEF重新為所述用戶組內的其他用戶進行PCRF選擇，其中，重新選擇的PCRF是為所述第一用戶服務的PCRF，所述通知中包括為所述第一用戶服務的PCRF的地址信息。
8.根據權利要求7所述的方法，其特征在于，所述DRA通知所述PCEF重新為所述用戶組內的其他用戶進行PCRF選擇之后，還包括: 所述PCEF終止與原PCRF的IP連接訪問網絡IP-CAN會話，并建立與服務所述第一用戶的PCRF之間的IP-CAN會話。
9.根據權利要求1所述的方法，其特征在于，所述DRA為所述用戶組內的其他用戶選擇所述PCRF之后，還包括: 所述PCRF根據所述用戶組的簽約用量信息為所述用戶組內的用戶開展業(yè)務進行用量監(jiān)控決策，并向策略和計費執(zhí)行功能PCEF下發(fā)用戶監(jiān)控。
10.一種策略和計費規(guī)則功能PCRF的選擇裝置，位于Diameter路由代理DRA，其特征在于，包括:接收模塊，用于接收為用戶組中第一用戶服務的PCRF發(fā)送的所述用戶組的用戶組信息；以及 選擇模塊，用于根據所述接收模塊接收到的所述用戶組信息和所述PCRF的地址信息，為所述用戶組內的其他用戶選擇所述PCRF。
11.根據權利要求10所述的選擇裝置，其特征在于，還包括: 建立模塊，用于建立所述用戶組信息和所述PCRF的地址信息的對應關系。
12.根據權利要求10所述的選擇裝置，其特征在于，還包括: 判斷模塊，用于判斷為所述第一用戶選擇的PCRF與為所述用戶組內其他用戶選擇的PCRF是否相同；以及 處理模塊，用于在所述判斷模塊判斷為所述第一用戶選擇的PCRF與為所述用戶組內其他用戶選擇的PCRF不相同的情況下，通知策略和計費執(zhí)行功能PCEF重新為所述用戶組內的其他用戶進行PCRF選擇，其中，重新選擇的PCRF是為所述第一用戶服務的PCRF，所述通知中包括為所述第一用戶服務的PCRF的地址信息。
13.一種策略和計費規(guī)則功能PCRF的選擇系統(tǒng)，其特征在于，包括PCRF、用戶簽約數(shù)據庫SPR和權利要求10至12中任一項所述的DRA，其中， 所述PCRF包括:獲取轉發(fā)模塊，用于從所述SPR獲取所述第一用戶所屬的用戶組的用戶組信息，并將所述用戶組信息發(fā)送給所述DRA ； 所述SPR包括:查詢下發(fā)模塊，用于根據所述PCRF的指令查詢并下發(fā)所述用戶組信息。
【文檔編號】H04L12/851GK103490908SQ201210192558
【公開日】2014年1月1日 申請日期:2012年6月12日 優(yōu)先權日:2012年6月12日
【發(fā)明者】毛玉欣, 周曉云, 吳錦花, 畢以峰 申請人:中興通訊股份有限公司