碼上快樂

相關內容    簡體    繁體

策略和計費控制(PCC)系統研究

本文轉載自   查看原文   2016-06-15 11:42   3827    pcrf 實現

策略和計費控制(PCC)系統研究

研究內容

[TOC "float:left"]

策略與計費控制(PCC)框架[1]

![架構圖](achitecture.png "Architecture" "width:800px;float:center")

  • 綁定機制

    綁定機制過程包含三個步驟：

    1. 會話綁定(Session Binding)

    即將 AF 會話信息和相應 PCC 規則關聯到一個 IP-CAN會話上。PCRF 執行會話綁定功能，需要考慮下面的 IP-CAN 參數：

    • UE 的IP地址
    • UE 的標
    • UE 所訪問PDN網絡的信息。

    如果UE標識信息存在,UE標識是與特定IP-CAN中相同類型的UE標識。特別指出IP-CAN網絡中UE標識和應用級UE標識可能是不同類型，PCRF需要維護、或可訪問兩個標識之間的映射關系。這樣的映射關系屬於其它規范的內容。在本研究報告中假定只支持Rx會話和IP-CAN會話之間是 1:1 映射關系。

  1. PCC規則授權

即為IP-CAN會話的PCC規則選擇QoS參數(QCI、GBR，MBR等).PCRF為IP-CAN會話的動態PCC規則執行PCC規則授權功能。需要考慮特定IP-CAN的限制條件和其它對 PCRF有效信息。每一個PCC規則會包含特定IP-CAN能夠支持的一組QoS參數.

  1. 承載綁定

即將在 IP-CAN 會話中的 PCC 規則關聯到 IP-CAN 承載上。

除GPRS應用的UE only IP-CAN承載建立模式外，對於網絡控制的IP-CAN 承載建立模式，PCEF 執行承載綁定功能。對於 GPRS 應用的 UE only IP-CAN 承載建立模式，由PCRF執行承載綁定功能。

特別指出: 對於每一個IP-CAN 會話限制於一個IP-CAN 承載的IP-CAN
網絡，這個承載綁定是隱含確定的。對於允許每一個IP-CAN 會話可以由多個IP-CAN 承載
的IP-CAN 網絡，承載綁定機制將使用下面的參數：
- 會話綁定的結果；
- 如果有 QoS 參數，則包含IP-CAN承載的QoS參數；
- 如果有，則包含業務映射信息

  • 信譽管理
  • 事件觸發

事件觸發用於描述：當某些事件發生時，PCEF和PCRF將執行什么樣的動作，什么樣的PCC規則將被激活/執行;
事件觸發通常由PCRF在PCC規則定制過程中下達(提供)給PCEF;事件觸發與一個IP-CAN會話中所有PCC規則相關聯；
事件觸發決定PCEF向PCRG通知IP-CAN承載被修改的時機；
PCRF可能下達給PCEF的事件觸發類型如下：

事件觸發 描述
PLMN改變 UE移動到另外一個運營商域
Qos改變 IP-CAN承載的Qos發送改變
Qos改變超過授權 IP-CAN承載的Qos已經改變，並且超過授權的Qos（注3）
業務映射信息的改變 IP-CAN承載的業務映射信息已經改變(注3)
IP-CAN類型改變(注1) IP-CAN承載的接入類型已經改變
發送資源丟失/恢復 IP-CAN發送資源不再可用或者再次可用

注1：該表格沒有描述每一個IP-CAN的具體事件
注3：承載綁定機制由PCRF執行時才有效
與任何事件觸發不匹配的IP-CAN承載修改，不會引起與PCRF的交互。
Qos改變觸發事件將觸發PCRF交互，以獲取IP-CAN承載Qos所有的改變值。超過授權事件觸發的Qos改變將只會觸發PCRF交互，以獲取超過授權的改變值。PCEF將檢查QCI和帶寬。

功能實體

PCC架構中主要包括PCRF,PCEF,AF,SPR,OCS和OFCS功能實體。

PCRF

PCRF包含策略控制和基於流的計費功能:

  • PCRF向PCEF提供關於服務數據流檢測、門控、基於Qos和基於流計費的網絡控制(不含Credit控制)
  • PCRF提供安全控制
  • PCRF決定服務數據流如何在PCEF中處理，保證按用戶簽約檔案的要求映射和處理PCEF用戶面業務
  • PCRF應該根據IP-CAN的限制條件、運營商策略和SPR數據獲取允許的QCI列表和相關聯的GBR、MBR限制值
  • IP-CAN會話建立時，檢查AF提供的服務信息與運營商定義的策略規則、SPR處接受的簽約信息的一致性；並據此，獲取該服務的Qos。
  • 服務信息不一致時，拒絕AP的會話請求；
  • 支持一個或多個AF的場景；
  • 根據AF的服務信息和Gx接口的請求Qos，授權Qos資源；特別指出：PCRF總是提供最大的授權Qos，即使請求的Qos低於能授權的Qos；
  • 可能使用簽約信息作為策略計費控制的基礎；簽約信息可以是應用於基於會話的服務和基於非會話的服務；
  • 根據PCEF的資源情況，通知AF相關信令路徑改變的信息；
  • 支持不同IP-CAN承載建立模式；
  • 從PCEF、SPR、AF獲取PCC決策的輸入信息，常見場景如下：
  1. PCEF可能提供的輸入信息：
  • 簽約用戶標識
  • UE的IP地址
  • IP-CAN承載的屬性參數
  • 請求類型
  • IP-CAN類型
  • 簽約用戶的位置
  • PDN標識符
  • PLMN標識符
  • IP-CAN承載建立模式
  1. SPR可能為連接到指定PDN的簽約用戶提供的輸入信息：
  • 簽約用戶允許的服務；即服務標識列表
  • 每一個允許的服務相對應的搶占優先級
  • 簽約用戶允許的Qos信息，包含簽約的保證帶寬Qos和QCI列表(MBR上限值和實時QCI的GBR上限值)
  • 簽約用戶計費相關的信息
  • 簽約用戶的分類信息
  1. AF可能提供的輸入信息：
  • 簽約用戶標識
  • UE的IP地址
  • 媒體類型
  • 媒體格式
  • 帶寬
  • 流描述信息，如源和目標IP地址，端口，協議
  • AF應用層標識
  • AF通信層服務標識
  • AF記錄信息
  • 流狀態信息(用於門狀態的決策)
  • 優先級指示，PCRF使用該指示保證相對較高優先級的應用層會話的服務；
  • 緊急會話指示
  1. 依賴於IP-CAN承載屬性，PCRF中可能預定義一些輸入信息，這些信息可能包含另外的基於網絡中計費策略的規則，不論簽約用戶是否在歸屬網絡或漫游網絡中
  2. PCC中的QCI信息是PCRF從AF或SPR獲取的，這些信息可能是SDP信息，也可能是一些與運營商策略相一致的有效的應用信息

  • 簽約信息管理

    • PCRF可能從SPR請求簽約信息建立IP-CAN會話，在請求中指定簽約用戶ID和PDN標識，並保留與PCC決策相關的簽約信息直至IP-CAN會話終止；
    • PCRF可能請求SPR簽約信息變更時，發送通知給PCRF。接受到通知，PCRF將執行必要的PCC決策，並更新PCEF中相關PCC規則；
    • 當相關的簽約信息已經被刪除，則PCRF發送取消通知給SPR

  • 非漫游場景時，HPLMN中只有一個PCRF跟UE的IP-CAN會話相關，PCRF終結於Rx和Gx接口

  • 漫游場景時，業務流是本地疏導時，可能會有兩個PCRF跟一個UE的IP-CAN會話相關；歸屬網絡H-PLMN中的H-PCRF和拜訪網絡V-PLMN中的V-PCRF

PCEF

  • 策略控制執行
  • PCC規則預配置
  • 業務數據流檢測
  • 計量統計
  • Qos控制

AF

  • AF是應用服務提供單元，對IP-CAN用戶面行為進行動態策略/計費控制
  • AF與PCRF通信傳輸動態的會話信息，這些信息輔助PCRF做出PCC決策
  • AF與PCRF交互具體IP-CAN信息和IP-CAN承載級事件通知
  • AF可能接收到PCRF的服務信息指示（接受或拒絕），並將這些指示轉發給UE
  • AF可能（根據端用戶的IP地址或UE標識）與多個PCRF交互通信
  • AF能夠指示PCRF獨立處理與策略控制相關的某些事件，如基於策略控制章節所描述的當前有效服務信息
  • AF可能向PCRF請求報告有關AF會話信令路徑狀態信息；當AF停止服務時，取消請求

SPR

存儲於所有簽約用戶或簽約相關的信息；PCRF使用這些信息決定基於簽約的策略和IP-CAN承載級PCC規則；SPR可以單獨部署，也可以與運營商的其他數據庫合並；目前，SPR與簽約數據庫之間的關系尚未指定；SPR可能提供下面的一些簽約信息：

  • 簽約用戶允許的服務
  • 允許服務的搶占優先級
  • 簽約用戶允許的Qos信息，包含簽約的保證帶寬Qos
  • 簽約用戶的計費相關信息，如位置信息等
  • 簽約用戶的類型
  • 可能提供簽約用戶的漫游信息，以及漫游計費要求信息

OCS && OFCS

參考點(接口)

PCC架構中主要包含Rx，Gx，Sp，Gy,Gz參考點。

Rx參考點

Rx是AF和PCRF之間的參考點，用於AF向PCRF傳遞應用層會話信息。如：

  • 用於識別業務數據流的IP filter信息，對不同的業務數據流進行策略控制和計費；
  • 用於Qos的媒體/應用帶寬要求。

Gx參考點

Gx是PCEF和PCRF之間的參考點，用於PCRF動態控制PCEF中的PCC行為，傳遞PCC決策信令，支持如下功能:

  • 發起和維護連接(IP-CAN會話)
  • PCEF向PCRF請求PCC決策
  • PCRF向PCEF提供PCC決策
  • 協商IP-CAN承載建立模式(UE Only,UE/NW)
  • 終止連接
    一個PCC決策包括一個或多個PCC規則和IP-CAN屬性值

Sp參考點

Gy參考點

Gz參考點

Sy參考點(TS 23.203 clause 7.9;TS 29.219)

  • 概述

    Sy參考點位於PCRF與OCS之間，用於從OCS傳送簽約用戶費用相關的策略統計器(Policy counter)狀態信息到PCRF,並支持如下功能：

    • PCRF從OCS請求策略統計器狀態報表，訂閱或取消訂閱費用限制報告(例如，策略統計器狀態變化的通知)
    • OCS向PCRF推送費用限制額度報表通知
    • PCRF向OCS取消費油限制額度報的通知

  • Sy參考模型
    兩種模型：



  • 簽約用戶費用額度

    OCS維護策略統計器的狀態，PCRF依據這些狀態制定策略抉擇；這種機制稱為：基於費用限額的策略抉擇。PCRF利用來源於OCS的策略統計器狀態信息作為制定策略抉擇（降級Qos(APN-AMBR)或者修改PCC/Qos/ADC規則）的輸入信息。

    當策略統計器狀態信息第一次被用於制定簽約用戶的策略抉擇時，PCRF使用== Initial Spending Limit Report Request 流程。PCRF可以向OCS請求該簽約用戶的全部或特定的策略統計器狀態信息。
    三大流程：

    • Initial Spending Limit Report Request
    • Intermediate Spending Limit Report Request
    • Final Spending Limit Report Request

    兩類信息：

    • Policy counter status report
    • Pending status of policy counter

  • 功能單元

    兩個網元：

    • PCRF PCRF制定策略抉擇時，需要考慮簽約用戶的費用狀態。因此，PCRF需要用到Initial or Intermediate Spending Limit Report Requst流程從OCS請求費用限額報告(Spending limit reporting).(詳見條款4.5.1);PCRF也可能利用== Intermediate Spending Limit Report Request == 流程取消特定策略統計器的費用限額報告；或者利用== Final Spending Limit Report Request ==流程取消所有策略統計器的費用限額報告。（詳見條款4.5.3）。
      當請求簽約用戶的費用限額報告時，PCRF應該至少有一個激活的IP-CAN會話用於發起一個Sy會話。同時，當該用戶的最后一個IP-CAN會話終止，或者沒有能夠支持費用狀態信息的IP-CAN會話時，PCRF應該終止Sy會話。
    • OCS 為了支持基於簽約用戶費用的策略抉擇功能，OCS應該提供如下三個功能：
      • 維護簽約用戶的策略統計器狀態信息
      • 當PCRF請求時，報告簽約用戶的策略統計狀態信息的值
      • 當簽約用戶的策略統計器狀態信息發生變化時，向PCRF報告這些變化

  • 費用限制流程

  1. Initial/Intermediate Spending Limit Report Request

    Direction: PCRF -----> OCS
    Purpose: Request status of policy counters/to subscirbe or unsubscribe to updates of policy counters
    Diamter Command: Spending-Limit-Request/Answer(clause 5.6)
    Information table:



    Behaviour of the PCRF:

    • PCRF need the status of Policy counter(s) which didn't been subscribed
    • PCRF will unsubscrib the status of one or more,but not all, policy counter(s)
      Content of Request:
    • SL-Request-Type AVP:
    • Policy-Counter-Identifier
      Behaviour of the OCS:

  2. Spending Limit Report

    Direction: OCS -----> PCRF
    Purpose: Notify the PCRF of changes in the status of subscribed policy counter(s)
    Diameter Command: Spending-Status-Notification-Request/Answer(in clause 5.6)
    Information tables:

    Behaviour of OCS:
    Behaviour of PCRF:

  3. Final Spending Limit Report

    Direction: PCRF -------> OCS
    Purpose:unsubscribed to any future updates of policy counters of a given subscriber
    Diameter Command:Session-Termination-Request/Answer (in RFC3588)
    Information tables:

    Behaviour of PCRF:
    no longer need status of subscribing policy counters
    Behaviour of OCS:

  • Sy協議
    • Diameter protocol
    • Transport protocol TCP/SCTP
    • Application id = 16777302
    • At CER/CRA Commands,Vendor-Specific-Application-Id {Auth-Application-Id AVP{Sy App ID}}
    • At CER/CEA Commands,Supported-Vendor-Id AVP{Vendor id =10415}and Vendor-Specific-Application-Id{Vendor-Id AVP{10415}}
    • Sy Messages/Command

策略與計費控制(PCC)規則

PCC規則定義

策略與計費控制規則(PCC Rule)，即一系列相關信息與一系列相關操作的集合(與面向對象編程中的類結構相似)，通常包含3大類信息：

  • 服務數據流檢查信息
  • 策略控制信息
  • 計費相關信息

其中： 服務數據流指，利用PCC規則中的業務數據流模板進行檢測的分組數據；

PCC規則可以分為兩類：

  • 動態PCC規則
  • 靜態預定義PCC規則

動態PCC規則通過PCRF的Gx下發給PCEF執行，PCRF可以建立、修改、刪除這類規則；預定義PCC規則由PCEF預配,PCRF只能引用這類規則；
PCC規則如下表所示：

PCC規則

PCC規則C++偽碼

  typedef int unknowType;
  struct PccRule_t
  {
    unsigned RuleID;   //Mandatory
	//Service data flow detection
	unknowType Precedence;    //Mandatory
	struct sdft_t* ServiceDataFlowTemplat;  //Mandatory
	 //Charging	
	struct AVPS_t* ChargingKey;       //Optional 
    unsigned ServiceIdentifer;        //Optional 
    enum charingMethod{online,offline,neither}; //Conditional 
    enum measurementMethod{};        //Optional 
    struct afri_t* ApplicationFunctionRecordInfomation;//Optional 
    struct silr_t* ServiceIdentiferlevelreporting;//Optional 
    //Policy control    
    bool GateStatus;  
    enum QosClassIdentifier{}; //Conditional 
    unsigned UL_Maximumbitrate; 
    unsigned DL_Maximumbitrate; 
    unsigned UL_Guaranteedbitrate; 
    unsigned DL_Guaranteedbitrate;
  };

注意： 同一個IP-CAN會話中PCC規則ID標識符是唯一的；如果動態PCC規則與預定義PCC規則相同，則后者將被前者覆蓋(替換)；

PCC業務數據流模板(PCC Service Data Flow Template)可能包含任何數目的業務數據流過濾器(Service Data Flow Filter);

PCC優先順序(PCC Precedence)定義了在PCEF中進行服務數據流檢測時，同一個IP-CAN會話中已激活的PCC規則的執行先后順序；

特別聲明：其余指標說明請參考相關文檔[2]

PCC規則運行

PCC規則運行主要指：

  • 動態PCC規則的創建、激活、修改、去激活、刪除等過程
  • 預定義PCC規則的引用過程

激活

  • 激活動態PCC規則，通過Gx接口向PCEF提供PCC規則信息；
  • 激活預定義的PCC規則，通過Gx接口向PCEF提供關聯的PCC規則標識符；
  • 激活PCRF不知道的預定義PCC規則，PCEF根據運營商策略進行；

激活的PCC規則

  • 使用業務數據流模板(PCC Service Data Flow Template)檢查業務數據流(Service Data Flow)
  • 使用業務數據流模板將下行分組數據映射到承載綁定(Binder)的IP-CAN承載
  • 使用業務數據流模板檢查承載綁定的IP-CAN上的上行分組
  • 記錄業務數據流的使用數據
  • 調用與PCC規則相關的策略(如果有)

注意：

  • 預定義的PCC規則至少在一個接入點范圍內是已知的
  • 多個IP-CAN會話中，能夠為多個IP-CAN承載激活相同的預定義PCC規則
  • 包含有下行服務數據流過濾器的預定義的PCC規則，只能在每一個IP-CAN會話中激活一次
  • 只包含有上行服務數據流過濾器的預定義PCC規則，能夠在同一個IP-CAN會話的多個IP-CAN承載建立時激活；去激活該類PCC規則時，將從每一個IP-CAN承載中刪除該PCC規則
  • PCRF可以在任何時候修改一個激活的、動態PCC規則
  • PCRF可以在任何時候通過Gx接口去激活PCEF中活動的PCC規則；並在IP-CAN承載終止時，該承載上的所有活動的PCC規則，都應該不去激活，而不用PCRF顯示執行

策略與計費控制(PCC)流程[3]

IP-CAN 會話有三種顯著的場景：

  • 無網關控制會話需求，不會出現網關控制建立
  • 需要網關控制會話支持；BBERF分配一個Care of Address（CoA）給UE,並且優先建立一個網關控制會話，然后再建立使用該CoA的IP-CAN會話；
  • 需要網關控制會話支持；在PCEF發起與PCRF的IP-CAN會話之前，需要存在一個網關控制會話；當BBERF修改或pre-registration該網關控制會話時，要匹配這個網關會話內，PCEF曾發起的IP-CAN會話；每個IP-CAN會話在獨立的網關控制會話中處理；

PCRF應該根據接收到的網關控制會話建立時提供的相關信息，選擇應用第2中還是第三種場景；如果接收到的信息中，因為一個用戶用(User Identified)一個Subcription-Id AVP標識，所以當Called-Station-Id AVP中包含PDN標識時，則選用場景3；否則，選用場景2。

注意： 后續的信令流程圖中：

  • 實線表示流程是必須的
  • 虛線表示流程是在某些條件下才有的
  • 綠色框中的信令是漫游情況下才有的

IP-CAN會話建立

![](./IP-CAN Session Establishment.png)

  1. 如果有需要，BBERF首先發起一個網關控制會話流程(詳見網關控制會話建立流程 29213 4.4.1)，后續的所有IP-CAN會話都是這個網關控制會話中進行，。PCRF需要根據接收到的BBERF中的信息(Subsciption-Id AVP或Called-Station-Id AVP)決定IP-CAN應用場景2，還是場景3.
  2. PCEF接收到一個建立IP-CAN會話請求，該請求的形式取決於IP-CAN的類型；如果是GPRS類型，在一個IP-CAN會話中，GGSN接收第一個創建PDP上下文請求(Create PDP Context Request);如果是I-WLAN類型，則GW接收到一個IPSec隧道建立請求；
  3. 非漫游情況下，以及UE漫游在本地路由區的場景下，PCEF通知H-PCRF建立IP-CAN會話；通知的方式是：建立一個Gx會話，PCEF發送Diameter CCR命令給H-PCRF，CCR命令中的CC-Request-Type AVP的值設置為INITIAL_REQUESET,UE標識信息，PDN標識，UE IPv4地址和/或IPv6地址前綴，PDN連接標識(如果有),Default-EPS-Bearer-QoS，APN-AMBR。在某些IP-CAN類型中，比如GPRS，H-PCRF能夠控制IP-CAN 承載，這種情形下，PCEF也應該提供關於請求承載的新的承載標識和信息比如Qos如果IP-CAN類型支持某些特性，PCEF也應該提供相關的信息說明，比如是否支持NW-initiate承載控制流程，PCRF將IP-CAN會話的Gx會話和相關的網關控制會話關聯在一起，同時，PCRF維護PCEF和BBERF(s)中相關的PCC規則集和Qos。漫游場景不做解釋
  4. H-PCRF存儲(數據庫?內存？)通過CCR命令接收到的信息。對於場景2或場景3，PCRF還要維持Gx會話與網關控制(s)會話間的聯系。注意場景2中，當附加的PDN連接建立，Gx會話同已經建立的網關控制會話鏈接在一起。
  5. 如果H-PCRF需要簽約相關信息，而自身沒有存儲這些信息；則會向SPR發送請求，獲取這些簽約信息。(這里可以用數據庫存儲簽約信息，避免和SPR的交互)。
  6. SPR回復簽約相關信息，比如，許可服務，Qos信息和PCC規則信息
  7. H-PCRF選擇SPR回復的或者自身存儲的PCC規則，或者根據接收到的信息產生新的PCC規則。H-PCRF也可能制定策略決策；確定授權Qos和根據PCC規則描述判斷業務流允可情況。
  8. H-PCRF存儲選定的PCC規則。如果有需要，針對特定的IP-CAN，H-PCRF還要選定IP-CAN會話中需要的承載控制模式(Bearer Control Mode)；如果H-PCRF控制IP-CAN承載的綁定(Binding),H-PCRF還要存儲分配了PCC規則的IP-CAN承載的信息。如果是BBERF/PCEF控制IP-CAN承載的綁定(Binding),H-PCRF可能獲取非GBR承載(non-GBR bearers)的每個QCI類別的Qos信息。
  9. 非漫游場景下，以及UE在本地路由區域漫游的場景下，H-PCRF通過Gx接口，發送Diameter CCA命令給PCEF，該命令用於1）提供PCC規則給PCEF。2）也可能提供包含特定IP-CAN可用的承載控制模式(Bearer Control Mode),每類QCI的Qos信息。3）也可能提供事件觸發，羅列了PCC規則請求需要的事件。4）也可能提供授權的Qos，這些Qos包含了APN-AMBR和Default-EPS-Bearer-Qos,User Location信息，用戶CSG信息(If received from BBERF).。5）如果啟用了用量監控，H-PCRF也可能提供PCEF網元中的用量監控控制指標的閾值，這些閾值通過Usage-Monitoring-Infromation AVP傳輸。 對於某些類型的IP-CAN,PCRF控制IP-CAN承載,如GPRS,PCRF發起安裝了PCC規則和授權了Qos的IP-CAN承載。其他類型的承載,PCRF則只是操作這類沒有特殊指定的承載。 如果有在線計費，PCEF通過Gy接口從OCS請求信譽信息(Credit information)。如果PCRF從OCS接收到信譽重授權觸發，那么對於場景3，PCEF通過CCR消息請求PCRG提過BBERF端的觸發器。這些觸發器在CCR消息的Event-Report-Indication AVP中指定。漫游情形不討論
  10. 對於場景2或場景3，PCRF將BBERF中的Qos規則集與PCEF中的激活規則集關聯起來。
  11. PCEF安裝從PCRF接收到的PCC規則。PCEF執行授權Qos，根據PCC規則中流的狀態(Flow status)開啟或禁用服務流(Service flows).如果從每個OCI中接收了Qos信息，PCEF根據MBR參數設置上行限制(UPPER LIMIT)。這個MBR參數是PCEF分配給非GBR承載的對應QCI的值。
  12. PCEF響應IP-CAN會話建立請求。 For GPRS, the GGSN accepts the PDP Context Request based on the results of the authorisation policy decision enforcement. If the requested QoS parameters do not correspond to the authorized QoS, the GGSN adjusts (downgrades /upgrades) the requested UMTS QoS parameters to the authorized values.
    NOTE 4: The PCRF can reject the IP-CAN session establishment, e.g. the PCRF cannot obtain the subscription-related information from the SPR and the PCRF cannot make the PCC rule decisions, as described in 3GPP TS 29.212 [9].
    The PCEF can also reject the IP-CAN session establishment, e.g. there is no activated/installed PCC rule for the IP-CAN session as specified in 3GPP TS 23.203 [2].

IP-CAN會話終止

IP-CAN會話終止的情況比較復雜，分為3類：

  • UE發起的IP-CAN會話終止
  • PCEF發起的IP-CAN會話終止
  • PCRF發起的IP-CAN會話終止

每種類型都包含兩種情況，AF在HPLMN中或AF在VPLMN中；這里只討論AF在HPLMN中的情況。

  • UE發起的IP-CAN會話終止(AF在HPLMN中)


在下列流程中，V-PCRF漫游場景中包含的網元，H-PCRF在非漫游場景中扮演了PCRF的角色。

  1. 如果是場景3，BBERF接收到一個移除IP-CAN會話請求；如果是場景2，這個請求對BBERF而言是透明的；不論是場景2還是場景3，PCEF都會接收到IP-CAN移除請求.該移除請求的形式，取決於IP-CAN的類型；對於GPRS類型而言，GGSN接收一個刪除PDP上下文請求(Delete PDP Context Request),該請求刪除在IP-CAN會話中的最近一個PDP上下文(last PDP Context).對於I-WLAN類型而言，GW接收一個終止IPSec隧道的請求。
  2. 如果是場景3，BBERF發起網關控制終止流程
  3. 非漫游場景下，PCEF通過Gx接口發送Diameter CCR命令給H-PCRF，發起IP-CAN會話終止流程。PCEF發送的CCR請求命令中，CC-Request-Type AVP的值設置為TERMINATION_REQUEST。如果啟用了用量監控功能，PCEF通知H-PCRF資源的消費情況；漫游場景暫不討論
  4. H-PCRF標記/記錄那些與將要被刪除的IP-CAN會話的IP流(IP flow)綁定的AF會話。
  5. 非漫游場景下，H-PCRF通過發送CCA命令給PCEF，通告Gx會話終止情況。
  6. PCEF發送Remove IP-CAN Session Request響應。Remove IP-CAN Session Response響應的形式/方式，取決於IP-CAN的類型（和會話發起中描述的一樣，這里不翻譯了)

For GPRS, the GGSN sends a Delete PDP Context Response for the last PDP context within an IP-CAN session. For I-WLAN, the GW sends an IPSec tunnel termination response. Step 6 may be executed in parallel with step 3 or 3a (as applicable)

  1. H-PCRF發送ASR命令給H-AF，告之會話取消情況。
  2. H-AF回應ASA命令
  3. H-AF發送STR命令給H-PCRF，指示會話已經終止。
  4. H-PCRF發送STA命令給H-AF，響應AF的指示。
  5. 對於場景2，IP-CAN會話被終止時，網關控制與Qos規則供給流程(條款4.4.3 Gateway Control and Qos Rules Provision)將被發起，該流程用於移除與被終止的IP-CAN會話相聯系的所有Qos規則。這種情形適用於網關控制會話還要持續為其他IP-CAN會話服務的場景。注意：(一個網關控制會話中可能有多個IP-CAN會話)。
  6. 如果SPR向PCRF訂閱了相關事件通知，H-PCRF需要發送會話取消事件的通知請求給SPR。如果同一APN的用戶的所有IP-CAN會話都被終止，H-PCRF需要存儲可用的剩余用量(這些用量在SPR中分配)。注意：在步驟5之后的任意時刻，步驟12都可能執行。
  7. SPR響應步驟12中H-PCRF的請求。注意： 步驟12和步驟13中請求和響應的具體形式，3GPP協議目前還沒有標准。

  • UE發起的IP-CAN會話終止(AF在VPLMN中)暫不討論

  • PCEF發起的IP-CAN會話終止(AF在HPLMN中)


    1. PCEF檢測到有IP-CAN 會話或者IP-CAN 承載終止的要求
    2. 如果是在場景3中，PCEF將發送Remove IP-CAN Session Request給BBERF,如果是在場景2中，這個請求對BBERF而言將是透明的；在這兩種場景下，PCEF都發送一個Remove IP-CAN Session Reuqest請求來移除IP-CAN會話。而這個請求的具體形式/方式，則取決於IP-CAN的類型，它可能是由一個IP-CAN會話中，每一IP-CAN承載的多個分開的請求組成。

    For GPRS, the GGSN sends a separate Delete PDP Context Requests for each of the PDP contexts within an IP-CAN session. For I-WLAN, the GW sends an IPSec tunnel termination request.注意,出現幾十遍了，不翻譯這貨。

    1. 如果在場景3中，BBERF初始化的網關控制會話終止流程將被發起。
    2. PCEF接收到Remove IP-CAN Session Request請求的響應，

    For GPRS, the GGSN sends a separate Delete PDP Context Requests for each of the PDP contexts within an IP-CAN session. For I-WLAN, the GW sends an IPSec tunnel termination request.注意,出現幾十遍了，不翻譯這貨。

    1. 步驟5-7，與UE發起的會話終止流程的步驟3-5相同
    2. 步驟5-7，與UE發起的會話終止流程的步驟3-5相同
    3. 步驟5-7，與UE發起的會話終止流程的步驟3-5相同
    4. 步驟8-14，與UE發起的會話終止流程的步驟7-13相同
    5. 同上
    6. 同上
    7. 同上
    8. 同上
    9. 同上
    10. 同上

  • PCEF發起的IP-CAN會話終止(AF在VPLMN中)暫不討論

  • PCRF發起的IP-CAN會話終止(AF在HPLMN中)


    1. H-PCRF檢查到IP-CAN會話終止需求
    2. 在非漫游場景中，H-PCRF發送RAR命令給PCEF請求終止IP-CAN會話，該RAR命令中必須包含Session-Release-Cause AVP.
    3. PCEF移除所有和將要被終止的IP-CAN會話相關的PCC規則
    4. 非漫游場景中，PCEF發送RAA命令響應RAR請求
    5. PCEF應用IP-CAN指定的流程，終止IP-CAN會話
    6. -17 與PCEF發起的非漫游場景中的步驟3-14一樣

  • PCRF發起的IP-CAN會話終止(AF在VPLMN中)暫不討論

IP-CAN會話修改

有兩種IP-CAN會話修改的情形：

  • 網絡發起的IP-CAN會話修改(Network-initiated IP-CAN Session Modification)
  • PCEF發起的IP-CAN會話修改(PCEF-Initiated)

  1. 網絡發起的IP-CAN會話修改

    網絡發起的IP-CAN會話修改由分為兩種情況：1)BBERF,PCEF兩者和PCRF之間的交互(PCC/Qos規則通過PUSH模式提供)，導致IP-CAN會話修改；2)PCRF,AF與SPR之間的交互，導致的IP-CAN會話修改;該情況比較復雜，暫時不討論

    下圖展示了PCC/Qos規則和/或PCRF中事件觸發的Qos授權導致的會話修改流程。


    1. H-PCRF接收到一個內部或外部的觸發器(觸發條件？BOSS系統？等各種可能觸發因素)，而重新評估某個IP-CAN會話PCC規則和策略決策。在3gpp 29213 4.3.1.2條款[3:1]中，描述了可能誘發該流程的外部觸發器事件，另外，該流程也可能由PCEF訂閱事件觸發。
    2. H-PCRF選擇安裝、修改或移除IP-CAN會話的某個或某些PCC規則。H-PCRF也可能通過定義Qos授權和啟用(/停用)PCC規則的服務流，更新策略決策。如果PCEF控制IP-CAN承載的綁定，H-PCRF可能增加或修改該IP-CAN會話中每個可能的QCI類別的Qos信息。
    3. H-PCRF存儲更新后的PCC規則；（如何存儲，何種方式?）
    4. 這一步驟只適用兩種情形：1）當承載控制模式(Bearer Control Mode-BCM)被指定為UE-only；2）H-PCRF決定UE/NW

  2. PCEF發起的會話修改


  1. 對於場景2和場景3，BBERF可能發起網關控制和Qos規則請求流程(詳見3gpp 29213 條款4.4.2)
  2. PCEF可能接收到IP-CAN會話修改的請求。IP-CAN會話修改請求可能是由於UE資源變化引發的(詳見，上一節).也可能是一個新的IP-CAN承載建立信令引發的。也可能是一個特定的事件(UE請求PDN連接);或者是外部觸發器。
  3. PCEF通知H-PCRF IP-CAN會話修改；PCEF發送CCR命令給H-PCRF，CCR命令中必須包含CC-Request-Type AVP並且該AVP的值為"UPDATE_REQUEST".如果IP-CAN會話被修改，IP-CAN會話中的IP-CAN承載也將被修改，PCEF通過Event-Trigger AVP,PCC規則名及規則狀態AVP-Charging-Rule-Report AVP,對特定的、導致IP-CAN會話修改的事件提供支持。在UE發起資源修改請求流程中，根據合適情況，PCEF將包含Packet-Filter-Information AVP,Packet-Filter-Opertion AVP,Qos-Information AVP.
  4. 如果H-PCRF需要簽約相關信息，但本地數據庫中又沒有這些信息時，PCRF會發送一個請求到SPR，請求這些簽約相關信息。
  5. SPR回復PCRF相關的簽約信息，如許可的業務和PCC規則等。注意步驟4和5，當前3gpp協議未做規范。
  6. 如果AF請求相關事件的通知，H-PCRF需要發送Diameter RAR命令給AF，並且命令中包含Specific-Action AVP集，用來說明導致這個請求發起事件的細節。
  7. 如果步驟6執行。AF可能執行特殊的流程

e.g. for IMS refer to 3GPP TS 23.228[x], replies with a Diameter RAA and may provide updated service information within. Additionally, the AF may terminate the Rx session as per clause 4.3.1.2.3.

  1. 如果AF會話的所有業務數據流(Service data flows)被刪除，該AF會話將被終止；
  2. 同步驟8
  3. 同步驟8
  4. 同步驟8
  5. H-PCRF選擇或者生產PCC規則並安裝。H-PCRF也可能標識/標記那些需要被修改或刪除的現有PCC規則。PCC規則可能是與AF會話相匹配的任何規則，也可能是PCRF中不匹配任何AF會話的規則。(什么意思？？？？)。H-PCRF也可能制定策略決策以獲得授權Qos和決定PCC規則中描述的業務數據流是否啟用/停用。
  6. 非漫游場景中，H-PCRF通過CCA命令向PCEF提供PCC規則。如果有需要，H-PCRF也根據IP-CAN的類提供承載控制模式選擇(Bearer Control Mode)。PCRF也可能向其他網元提供一系列事件觸發器。PCRF也可能提供通過APN-AMBR AVP和Default-EPS-Bearer-Qos AVP提供Qos信息。
  7. PCEF安裝、修改或刪除PCC提供的規則。PCEF也執行Qos授權，並根據PCC規則相關狀態啟用/停用業務流(Service flows).
  8. PCEF也可能發起IP-CAN會話信令，或者給步驟2中接收到的IP-CAN會話修改請求做出任何IP-CAN會話信令應答。
  9. 如果PCRF被請求確認分配給PCC規則的資源是否成功分配成功，PCEF發起的IP-CAN會話修改流程將從步驟3開始，重新執行。
  10. 對應場景2和場景3，BBERF也可能發起網關控制和Qos規則供給流程(詳見3GPP 29213 條款4.4.3)

網關控制會話(Gateway Control Session)

目前，有兩種類型的網關控制(Gateway Control)會話：

  • 只能為單個IP-CAN會話提供服務的網關會話(如S-GW/BBERF通過S5/S8接口與PDN-GW連接的情形，詳見23.402)；

注：簡單理解：1對1類型

  • 能夠為來自同一個UE關注地址(Care-of address of the UE怎么翻譯)？的所有IP-CAN會話提供服務的網關會話(如UE通過S2c接口與PDN-GW連接的情形，詳見TS23.402)

簡單理解：1對多類型

IP-CAN會話建立和初始化附着(Initial Attach)都會發起網關控制會話。對於第一類網關會話，PCRF利用請求中接收到的PDN 標識符(PDN Identifier)標記網關控制會話(GC Sesion)與IP-CAN會話的一一對應關系。

訪問網絡(Access network 漫游？)可能支持BBERF改變的移動性。新的BBERF將依據為新訪問類型定義的流程建立一個新的網關控制會話(GC session)並且PCRF應該管理這些新的會話與將失效的IP-CAN會話間的關系，這是切換流程（Handover procedure）的一部分功能。

注：就是說，漫游時，會重新建立網關會話與IP-CAN會話的1對1關聯，那么漫游前的1對1關聯將失效，這個切換過程就涉及到網關會話與IP-CAN會話的管理，而這個爛攤子，就交給了PCRF來收拾。

這些應用場景將涉及不同的信令流程；下面的信令流圖中，V-PCRF描述了漫游場景，H-PCRF則扮演了非漫游場景中的PCRF。這個信令流圖描述的IP-CAN會話受緊急呼叫業務(Emergency Service詳見3GPP TS 29212)的限制。

  • 網關控制會話建立(Gateway Control Session Establishment)


    1. BBERF接收到一個建立網關控制會話的消息或指示。對於場景2，BBERF檢測到UE已經分配了一個本地IP地址，UE將使用該IP地址作為MIP注冊中的關注地址(Care-of Address詳見3GPP TS 23.402條款6.3)對於場景3，BBERF檢測UE請求建立IP-CAN會話(詳見3GPP TS 23.402 條框4.5.5和5.6.1)或者BBERF重定時，重新恢復某個APN(23.402條款5.7.1 5.7.2)，或者UE請求重注冊該BBERF(詳見條款 23.402 9.3.1)
    2. 對於非漫游場景，BBERF發送CCR命令給H-PCRF，發起一個網關控制會話，CCR命令中的CC-Request-Type AVP設置為INTIAL_REQUEST.BBERF提供UE標識信息，IP-CAN類型，用戶位置信息和用戶CSG信息。對於場景2，BBERF還要提供分配給UE的CoA；對於場景3，BBERF還要提供PDN標識和PDN連接標識，如果同一個APN有多個PDN連接，一個會話連接指示器(Session-Linking-Indicator)將用於指示會話鏈必須被推遲(Deferred),BBERF還可能提供APN-AMBR和Default-EPS-Bearer-Qos;對於某些適用的IP-CAN類型，BBERF還要附加提供Network-Request-Support AVP，用來指命是否支持NW-initiated流程。
    3. H-PCRF存儲接收到的CCR請求信息，並根據這些信息決定網絡場景屬於場景2，還是場景3.如果是場景2，H-PCRF可能調整/合並同一個UE在已經建立的Gx會話中的UE標識信息；如果是場景3，H-PCRF將鏈接網關控制會話和已經建立的Gx會話，並執行如下操作：
    • 如果Session-Linking-Indicator已經接收到會話鏈路必須延遲(Deferred)的指示，則延遲會話鏈路，直到接收到相關IP-CAN會話建立或修改完成的信息。
    • 如果沒有接到延遲相關指示，則立即鏈接網關控制會話和已經建立的Gx會話。
    1. 如果H-PCRF需要相關簽約信息，而本地數據庫中沒有這些信息；則H-PCRF向SPR發起獲得這些信息的請求；
    2. SPR回應H-PCRF的請求，並提供相關的信息；如，許可的業務，Qos信息，PCC規則信息等。

    規范尚未制定

    1. 對於場景2，H-PCRF可能根據適當情況安裝Qos規則；對於場景3，H-PCRF將執行如下動作：
    • At IP-CAN session establishment, if the session linking was not deferred, select or generate and store PCC Rule(s) in preparation for the anticipated Gx session and derive the QoS rules from them. If the session linking was deferred, the PCC rules are not generated;
    • At BBERF relocation and at pre-registration, if the Session-Linking-Indicator was not received or indicates that the session linking has to be performed immediately, prepare for the installation of QoS rules, derived from the active PCC rules, at the target BBERF;
    1. H-PCRF存儲被選中的Qos規則和PCC規則，如果有需要，H-PCRF將選擇網關控制會話將要用到的承載控制模式(Bearer Control Mode).
    2. 非漫游場景，H-PCRF通過發送CCA命令給BBERF，作為網關控制會話的應答。PCRF回復的信息中，可能包含如下內容：
    • 對於某些IP-CAN類型而言，則應包含被選中的承載模式(BCM)
    • 如果NW-initiated流程可用，則應包含本地路由域可用的Qos規則和訪問情形時可用的PCC規則
  • 如果承載控制模式為UE-only,則應包含 the QoS rules that correspond to the request from the V-PCRF for the home routed case or the PCC rules that correspond to the request from the V-PCRF for the visited access csse
  • For the case 2a, the QoS rules when the available QoS rule are not related to any IP-CAN session.
  • 包含可用的Default-EPS-Bearer-QoS and APN-AMBR when applicable
  • 包含事件觸發器列表The event triggers
  1. BBERF安裝並執行接收到的Qos規則
  2. BBERF發送一個建立網關控制會話響應(Establish Gateway Seesion Control Response)應答網關控制會話請求(Gateway Control Session Request).

  • 網關控制與Qos規則請求(GateWay Control and Qos Rules Requst)

    該內容分為漫游和非漫游情形，非漫游情形暫不討論


    1. 網關控制會話中，BBERF可能被觸發，然后報告一個事件，或者獲取Qos規則，或者同時執行這兩件事。
    2. BBERF發送一個Diameter CCR命令給H-PCRF，向PCRF報告一個事件或者獲取Qos規則；該命令中CC-Request-Type AVP的值被設置為UPDATE_REQUEST.
    3. H-PCRF存儲從CCR接收到的信息，並獲取更新的Qos規則和事件觸發器列表。
    4. H-PCRF通過Diameter CCA命令，向BBERF提供已更新的Qos規則和事件觸發器；也可能只有在事件報告成功接收時，CCA命令應答CCR請求。
    5. BBERF安裝從PCRF接收到的Qos規則和事件觸發器；這將導致承載綁定(Bearer binding)，承載綁定是根據相關規則執行的。BBERF也可能根據Qos規則相關的流狀態(flow status)啟用/禁用業務流(Service flow)門控??????;激活Qos規則將可能引發BBERF發送附加的，前面提到的Diameter CCR命令給PCRF,指示Qos規則激活失敗。

  • 網關控制和Qos規則提供(Gateway Control And Qos Rule Provision)

  • 網關控制會話終止(Gateway Control Session Termination)

  • 多BBERF信令流(Multiple BBERF Signalling Flows)

    漫游情形不討論

PCRF更新簽約信息

PCRF向AF請求業務信息

AF向PCRF下發業務信息

AF向PCRF訂閱信息狀態

PCRF向AF上報訂閱狀態

綁定機制

概述

綁定機制就是將會話信息和承載業務數據流(Service Data Flow)的IP-CAN承載關聯起來的機制。在3GPP TS 23.203中定義了綁定機制的三個步驟：

  1. 會話綁定 會話綁定是PCRF從AF或者PCEF接收到會話信息(Rx會話或Gx會話)，並使之關聯到一個IP-CAN會話的功能。PCRF應支持標識出該會話相應的PCC規則。該綁定需要考慮IP-CAN參數，如用戶的 IP地址、用戶標識等有關信息。
  2. PCC規則授權和Qos規則生成
    PCC規則授權，例如為PCC規則選擇QoS參數（GBR,MBR等）。PCRF應支持為綁定步驟中選擇的AF會話的動態PCC規則執行規則授權，同時，PCRF也要支持為沒有AF會話的IP-CAN會話執行PCC規則的授權。PCRF需支持根據具體IP-CAN網絡的限制條件和其它有效信息（如業務信息、用戶簽約數據、運營商的策略以及MS能力），來確定IP-CAN能夠支持的QoS參數集。
  3. 承載綁定 承載綁定是將PCC規則關聯到IP-CAN會話內的一個IP-CAN承載上。如果授權QOS發生改變，PCRF應支持對已存在的綁定進行重新評估（例如，執行承載綁定過程），並根據評估結果決定是否需要綁定到一個新的IP-CAN承載。
    除非特別指定承載綁定功能位於PCRF，否則由PCEF來執行承載綁定。

會話綁定功能根據接收到的會話信息(Session Informations)決定相關聯的IP-CAN會話；根據會話信息和IP-CAN會話信息，PCC規則授權和Qos規則生成功能執行策略規則並構造合適的PCC規則和Qos授權信息；最后，承載綁定功能選擇IP-CAN承載，安裝PCC規則和Qos規則到該承載的某個已知IP-CAN會話中。

在某個IP-CAN會話事件中(如IP-CAN會話建立)，即使沒有會話綁定功能/步驟，PCC規則授權和Qos規則生成，以及承載綁定功能都可以發生。

會話綁定(Session Binding)

會話綁定功能就是將AF會話信息或PCEF會話信息和IP-CAN會話關聯起來。

當PCRF通過RX接口接收到AF的帶有業務信息(Service Information)的AA-Request請求時，PCRF應該執行會話綁定，並將AF會話信息(或者PCC規則)中詳盡的業務IP流(descirbed Service IP flows)與一個已存在的IP-CAN會話關聯起來。關聯過程中，需要比對/匹配用戶IP地址(User Ip Address)。IP地址要是來自Rx接口的Frame-IP-Address AVP ，或來自Gx接口的Frame-IPv6-Prefix AVP。如果可能，還要比對會話的UE標識(UE Identity--該標識在Subscription-Id AVP中)以及PDN信息(PDN Information--該信息在Called-Station-Id AVP中) 。

The PCRF will determine that the UE has an IP-CAN session if the IP address (IPv4 or IPv6) received over the Rx interface matches the IPv4 address or IPv6 prefix received via one or more of the following interfaces: Gx interface and S9 interface, and if the UE identity is used to assist the association, the UE identity received over the Rx interface matches the UE identity received via one or more of the following interfaces: Gx interface and S9 interface.

NOTE 1: In case the UE identity in the IP-CAN and the application level identity for the user are of different kinds, the PCRF needs to maintain, or have access to, the mapping between the identities. Such mapping is not subject to specification within this TS.

NOTE 2: An IPv6 address provided over Rx matches an IPv6 prefix provided over Gx or S9 if the IPv6 address belongs to the IPv6 (sub-)network prefix.

會話綁定的結果是，將當前AF會話分配到對應的IP-CAN會話；如果PCRF無能執行會話綁定，PCRF應該產生一個帶負值的(Negative response)AA-Answer命令應答AF.

PCC規則授權與Qos規則生成

1）當PCRF通過Rx接口接收來着某個AF的會話信息(Session Informationg),2）或當PCRF通過Gx/S9接口接收到來着PCEF的IP-CAN會話事件(建立，修改等)通知，3）或當PCRF通過Gxa/Gxc接口接收到BBERF的IP-CAN事件,PCRF將執行PCC規則授權與Qos規則生成.。另外，通過內部PCRF觸發器(Internal PCRF triggers---PCRF中包含和修改的策略)已提供給BBERF的動態Qos規則(dynamic Qos Rules)和已提供給PCEF的動態PCC規則(dynamic PCC Rules)也可能引發PCRF執行PCC規則授權和Qos規則生成。

如果PCRF接收到來着BBF的任何傳輸映射信息(traffic mapping information)不能匹配任何業務數據流過濾器(Service data flow filter),當UE的簽約概要(Subscriber profile)允許基於授權的簽約(Subscription based authorization)，PCRF也可能執行PCC和/或Qos規則授權。在這種情況下，PCRF將會按業務數據流過濾器信息(service data flow filter)對待接收到的傳輸映射信息(traffic mapping information)。

PCRF分配合適的Qos參數(QCI,ARP,GBR,MBR等)給每一個PCC或者Qos規則。

當會話綁定(Session Binding)成功后，PCRF將授權受影響的PCC規則和Qos規則。通過授權，PCRF將決定一個用戶(User)是否有權訪問請求的業務(Requested Services)，其訪問受條件約束。1）如果PCC規則和Qos規則被創建或修改；2）如果會話信息未被授權；PCRF將發送一個帶負值的AA-Answer命令給AF.

PCRF分配合適的QCI給每一個PCC或Qos規則。IP-CAN(?會話？承載？)指定限制信息或其他適用信息(users subscription information,operator policies)給考慮范圍內/受影響的PCRF.每個PCC或Qos規則將接受一個IP-CAN支持的QCI。當Qos規則起源於相關PCC規則時，PCRF應該確保針對同一個業務數據流，Qos規則與PCC規則授權的一致性。

漫游情況，暫不討論：

In roaming scenarios, the V-PCRF may further authorize the rules received from the H-PCRF based on local operator policy. Depending on the local policy, the V-PCRF may change the authorized QoS for the affected rules. If local authorization of the rules fails, the V-PCRF shall issue a negative answer to the H-PCRF.

承載綁定

承載綁定功能負責將IP-CAN會話中的某個IP-CAN承載與PCC規則和Qos規則關聯起來。承載綁定時從外部獲取，規則和業務數據流模板(Service data flow template)需要的Qos信息。被選定的IP-CAN承載與PCC/Qos規則指明的承載必須有相同的QCI和ARP。（通過QCI和ARP匹配承載和規則）。

承載綁定功能(Bearer Binding Function --BBF)位於BBERF或PCEF.（BBERF或PCEF實現BBF）.

PCRF通過Gx接口提供需要被安裝、修改或刪除的PCC規則給PCEF;如果該Gx會話與網關控制會話(Gateway Control Session)有關聯，PCRF應該通過Gxa/Gxc接口提供將要被安裝、修改或刪除的Qos規則。

BBF應該能夠檢測/識別規則里標明的Qos類別標識(class identifier --QCI)和ARP，並且將這些規則與具有相同Qos類別標識和ARP的IP-CAN承載綁定在一起。BBF還要評估是否有可能使用已存在的IP-CAN承載之一；評估是否有需要發起IP-CAN承載修改。如果沒有可用的已存在IP-CAN承載，BBF應該發起適合的IP-CAN承載建立。

== 注意 ==： 對於一個IP-CAN,每個IP-CAN會話只能有單個IP-CAN承載的情況，承載是隱含的。所以，找到了IP-CAN會話，就等同於成功執行了承載綁定。
== 注意 ==： 規則的MBR>GBR時，規則處理方式/流程由操作策略（比如，為SDF維護一個獨立的IP-CAN承載，用來阻止相互競爭的SDF間出現不公平競爭）決定。
== 注意 ==： QCI和ARP(包括Priority-Level,Pre-emption-Capability 和Pre-emption-Vulnerability)被用於承載綁定。根據操作策略(Operator policy),僅QCI和ARP Priority-Level能夠用於承載綁定。在這種情況下，操作策略被用於決定/判斷相同的QCI和ARP Priority-Level是否有包含不同的規則，或者不同的Pre-emption-Capability and Pre-emption-Vulnerability 是否被綁定於同一個承載。

對於一個IP-CAN，如果BBF沒有獲取到關於UE用於發送上行IP流的IP-CAN承載的信息，綁定機制將假設：對於雙向業務數據流(bi-directional service data flows)，上行數據包(Packets)和下行數據包都是用同一個IP-CAN承載傳輸。

不論何時，業務數據流模板(Service data flow template),Qos授權或者協商傳輸映射信息(Negotiated traffic mapping information)發生變化，現有的承載綁定都應該被重新評估。對於業務數據流，重新評估可能要求同另外一個IP-CAN承載進行新的綁定。

PCC/Qos規則執行期間，如果包/報文過濾器(Packet filters)被提供給UE,BBF將提供具有相同內容的包過濾器，這些包過濾器包含於Flow-Description 或 Flow-Information AVP的SDF模板過濾器中，這些AVP來自於PCRF並由Gx/Gxx接口傳輸。由網絡提供給UE的包過濾器的表現形式或格式與訪問系統相關(Access-system),並且因訪問方式(accesses)而不同；也可能因Gx/Gxx接口上的SDF模板過濾器而不同。PCRF可能控制/管制供給給UE的包過濾器，比如，那些過濾器應該被發送給UE（詳見 3GPP TS 29.212).

每種類型的IP-CAN的具體要求，在IP-CAN具體附件中定義/描述。承載綁定功能可能位於PCRF(例如，附件D中描述的GPRS運行UR只有IP-CAN承載建立模式).選擇承載綁定位於那個功能模塊，基於PCRF選擇的承載控制模式。（PCRF中選擇的承載控制模式，影響了承載綁定是位於PCRF還是PCEF).

Qos參數映射

概述

在PCC交互過程中，需要Qos參數映射功能。參數映射功能分布在AF,PCRF,PCEF和UE網元中。Qos參數映射功能的目標是解決Qos參數在不同網元中用不同的格式表示的Qos參數能夠用一種規定的協議/格式交互。Qos信息的示例:

  • 會話描述語言(SDI)的一部分。例如，SDP
  • IP Qos 參數；
  • 訪問特定Qos參數

PCRF尋址/定位(PCRF Addressing)

當同一個網絡域中，包含多個PCRF實體時，需要PCRF發現流程。這種情況下，需要一個叫DRA的附件功能網元。所有PCRF發現流程，都涉及DRA功能網元。

相關概念

  • IP-CAN (IP-Connectivity Access Network)即IP連接訪問網絡
  • IP-CAN 類型 GPRS WLAN I-WLAN WIFI X-DSXL 3G UMTS LTE
  • IP-CAN 會話 IP-CAN承載(bearer)：定義了速度，延遲，誤碼率(BER)等屬性的IP傳輸通道。
    IP-CAN會話(session)：用戶終端與IP網絡之間的關聯。該關聯通過終端的IP的地址及可用的終端ID信息來標識。一個IP-CAN會話包含一個或多個IP-CAN承載。對多個IP-CAN承載的支持取決於IP-CAN的類型。只要終端IP地址與IP網絡維持連接，IP-CAN會話就會一直存在。
  • IP-CAN 承載
  • Gx會話
  • 網關控制會話(Gateway Control Session)

PCC如何實現策略控制

  • 門控 阻止或允許屬於一個業務數據流的分組通過指定的端點
  • Qos控制
    1. 業務級別的Qos控制 授權和執行業務數據流授權的最大Qos
    2. IP-CAN級別的Qos控制 授權和執行IP-CAN承載授權的最大Qos
    3. 事件報告 通知或響應應用事件，從而觸發用戶面新的行為；報告與GW(PCEF)中資源相關的事件
    4. IP-CAN承載建立 支持網絡發起的IP-CAN承載建立過程

門控

Qos控制

EPC中的Qos包括如下內容[4]：

  • QCI----Qos Class Identifer,Qos分類識別碼
  • ARP----Allocation and retention priority,分配和保持優先
  • GBR----Guaranteed Bit Rate,保證的比特速率
  • MBR----Maximum Bit Rate,最大比特速率
  • AMBR----Aggregate Maximum Bit,聚合最大比特速率，分為UE-AMBR和APN-AMBR
  1. Qos參數映射
  2. Qos參數更新
  3. Qos策略執行
  4. 無AF場景動態Qos策略控制

PCC如何實現基於流的計費

  • 計費控制

PCRF根據用戶訪問網絡、用戶種類、用戶位置、服務數據流信息(Qos)、運營商計費策略等信息確定相適應的費率和計費模型(及計費方法、計量方法)，並通過PCC規則通知PCEF,PCEF根據PCC規則執行相應的計費功能；並將產生的使用報告發送(通知)給在線計費系統(OCS)和或離線計費系統(OFCS).

  • 報告機制

PCEF統計(計量)各個IP-CAN承載使用信息，並將其報告給在線計費系統或離線計費系統。計費信息報告是對每一個IP-CAN承載基於服務數據流檢測和測量的結果。

PCC實現

本研究主要實現策略與計費控制(PCC)架構中如下功能實體及接口：

  • PCRF實體 包含：PCC規則激活、修改、去激活；AF查詢、訂閱、通知；SPR查詢、通知、交互;基於流的計費；Qos控制等；計量統計；事件觸發機制等；
  • Gx接口
  • Rx接口
  • PCC系統監控維護功能

Gx接口

PCRF與PCEF通過Gx接口實現通信交互，Gx接口利用Diameter協議實現。3GPP定義了Gx接口的4個Gx消息，分別是信用控制請求命令，信用控制應答命令，重新鑒權/授權請求命令，重新鑒權/授權應答命令；

  • 信用控制請求命令(CC-Request Command)
    CC-Request(CCR)命令由PCEF--->PCRF:

    • 為承載請求PCC規則
    • 指示承載或PCC規則相關事件
    • 指示IP-CAN承載或會話的終結

    == 注意 ==

    CCR Command-code = 272
    CCR Command-Flags "R" = 1

    CCR消息格式:

    ::= < Diameter Header: 272, REQ, PXY >
    < Session-Id >
    { Auth-Application-Id }
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { CC-Request-Type }
    { CC-Request-Number }
    [ Destination-Host ]
    [ Origin-State-Id ]
    *[ Subscription-Id ]
    *[ Supported-Features ]
    [ Network-Request-Support ]
    [ Packet-Filter-Information ]
    [ Packet-Filter-Operation ]
    [ Bearer-Identifier ]
    [ Bearer-Operation ]
    [ Framed-IP-Address ]
    [ Framed-IPv6-Prefix ]
    [ IP-CAN-Type ]
    [ 3GPP-RAT-Type ]
    [ RAT-Type ]
    [ Termination-Cause ]
    [ User-Equipment-Info ]
    [ QoS-Information ]
    [ QoS-Negotiation ]
    [ QoS-Upgrade ]
    [ Default-EPS-Bearer-QoS ]
    0    2[ AN-GW-Address ]
    [ 3GPP-SGSN-MCC-MNC ]
    [ 3GPP-User-Location-Info]
    [ 3GPP-MS-TimeZone ]
    [ Called-Station-Id ]
    [ PDN-Connection-ID ]
    [ Bearer-Usage ]
    [ Online ]
    [ Offline ]
    *[ TFT-Packet-Filter-Information ]
    *[ Charging-Rule-Report]
    *[ Event-Trigger]
    [ Event-Report-Indication]
    [ Access-Network-Charging-Address ]
    *[ Access-Network-Charging-Identifier-Gx ]
    *[ Usage-Monitoring-Information ]
    *[ Proxy-Info ]
    *[ Route-Record ]
    *[ AVP ]

  • 信用控制應答命令(CC-Answer Command)

    CC-Answer(CCA)命令由PCRF-->PCEF:

    • CCR消息回應
    • 為承載/會話提供PCC規則和事件觸發
    • 為IP－CAN會話提供可選擇的承載控制模式

    == 注意 ==

    CCR Command-code = 272
    CCR Command-Flags "R" = 0

    CCA 消息格式：

    ::= < Diameter Header: 272, PXY >
    < Session-Id >
    { Auth-Application-Id }
    { Origin-Host }
    { Origin-Realm }
    [ Result-Code ]
    [ Experimental-Result ]
    { CC-Request-Type }
    { CC-Request-Number }
    *[ Supported-Features ]
    [ Bearer-Control-Mode ]
    *[ Event-Trigger ]
    [ Event-Report-Indication ]
    [ Origin-State-Id ]
    *[ Redirect-Host ]
    [ Redirect-Host-Usage ]
    [ Redirect-Max-Cache-Time ]
    *[ Charging-Rule-Remove ]
    *[ Charging-Rule-Install ]
    [ Charging-Information ]
    [ Online ]
    [ Offline ]
    *[ QoS-Information ]
    [ Revalidation-Time ]
    [ Default-EPS-Bearer-QoS ]
    [ Bearer-Usage ]
    *[ Usage-Monitoring-Information ]
    *[ CSG-Information-Reporting ]
    [ User-CSG-Information ]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    *[ Failed-AVP ]
    *[ Proxy-Info ]
    *[ Route-Record ]
    *[ AVP ]

  • 重新鑒權/授權請求命令(Re-Auth-Request Command)

    Re-Auth-Request(RAR)命令由PCRF-->PCEF:

    • 利用PUSH方式提供Qos/PCC、事件觸發和事件報告指示
    • 如果PCRF執行了承載綁定，PCC規則將在承載層面提供

    == 注意 ==

    RAR Command-code = 258
    RAR Command-Flags "R" = 1

    RAR 消息格式：

    ::= < Diameter Header: 258, REQ, PXY >
    < Session-Id >
    { Auth-Application-Id }
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Destination-Host }
    { Re-Auth-Request-Type }
    [ Session-Release-Cause ]
    [ Origin-State-Id ]
    *[ Event-Trigger ]
    [ Event-Report-Indication ]
    *[ Charging-Rule-Remove ]
    *[ Charging-Rule-Install ]
    [ Default-EPS-Bearer-QoS ]
    *[ QoS-Information ]
    [ Revalidation-Time ]
    *[ Usage-Monitoring-Information ]
    *[ Proxy-Info ]
    *[ Route-Record ]
    *[ AVP]

  • 重新鑒權/授權應答命令(Re-Auth-Answer Command)

    Re-Auth-Answer(RAA)命令由PCEF-->PCRF:

    • RAR消息回應

    == 注意 ==

    RAA Command-code = 258
    RAA Command-Flags "R" = 0

    RAA 消息格式：

    ::= < Diameter Header: 258, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    [ Result-Code ]
    [ Experimental-Result ]
    [ Origin-State-Id ]
    [ IP-CAN-Type ]
    [ RAT-Type ]
    0*2[ AN-GW-Address ]
    [ 3GPP-SGSN-MCC-MNC ]
    [ 3GPP-User-Location-Info ]
    [ 3GPP-MS-TimeZone ]
    *[ Charging-Rule-Report]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    *[ Failed-AVP ]
    *[ Proxy-Info ]
    *[ AVP ]

  • 協議匯總[4:1]
    |接口|連接網元|協議|
    |:-------|:-----|:------|
    |S6a|MME<-->HSS|Diameter/SCTP/IP/L2/L1|
    |S7(Gx)|PCRF<-->P-GW(PCEF)|Diameter/SCTP/IP/L2/L1|
    |S9|V-PCRF<->H-PCRF|Diameter/SCTP/IP/L2/L1|
    |Rx|PCRF<-->AF|Diameter/SCTP/IP/L2/L1|

用戶數據存儲

UE未附着時，核心網網元MME,SGW和PGW中不存在該UE相關的任何信息；
UE只包含自身IMSI和密鑰CK/IK；HSS中有UE的簽約信息IMSI,MSISIDN,CK/IK,簽約UE-AMBR等

參考文檔
  • 23815-500 Charging implications of IMS architecture
  • 29209-680 Policy control over Gq interface
  • 29212-9i0 Policy and Charging Control (PCC) over Gx Refernce point
  • 29214-9g0 Policy and Charging Control over Rx reference point
  • 29215-9d0 Policy and Charging Control (PCC) over S9 reference point

  1. 23203-be0 Policy and charging control architecture ↩︎

  2. SR_68-2010_策略和計費控制(PCC)系統技術研究 ↩︎

  3. 29213-9d0 Policy and Charging Control signalling flows and Quality of Service ↩︎ ↩︎

  4. 3GUMTS與4GLTE核心網--CS,PS,EPC,IMS ↩︎ ↩︎


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 策略與計費控制(PCC)流程與信令流程 策略與計費控制規則(Policy and Charging Control Rule-PCC Rule)解析及模板樣例 推薦系統：推薦系統研究筆記 系統研究Airbnb開源項目airflow UE4的聯網系統研究 2018 基於深度學習的推薦系統研究綜述 一款基於Zigbee技術的智慧魚塘系統研究與設計 電機控制器的算法與策略研究 免費寬帶認證計費系統 yh-radius 開源計費系統
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM