策略與計費控制(PCC)流程與信令流程

該文為3GPP TS23.203-be0 條款6-7譯文

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

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會話建立

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)

7. H-PCRF發送ASR命令給H-AF，告之會話取消情況。
8. H-AF回應ASA命令
9. H-AF發送STR命令給H-PCRF，指示會話已經終止。
10. H-PCRF發送STA命令給H-AF，響應AF的指示。
11. 對於場景2，IP-CAN會話被終止時，網關控制與Qos規則供給流程(條款4.4.3 Gateway Control and Qos Rules Provision)將被發起，該流程用於移除與被終止的IP-CAN會話相聯系的所有Qos規則。這種情形適用於網關控制會話還要持續為其他IP-CAN會話服務的場景。注意：(一個網關控制會話中可能有多個IP-CAN會話)。
12. 如果SPR向PCRF訂閱了相關事件通知，H-PCRF需要發送會話取消事件的通知請求給SPR。如果同一APN的用戶的所有IP-CAN會話都被終止，H-PCRF需要存儲可用的剩余用量(這些用量在SPR中分配)。注意：在步驟5之后的任意時刻，步驟12都可能執行。
13. 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.注意,出現幾十遍了，不翻譯這貨。

3. 如果在場景3中，BBERF初始化的網關控制會話終止流程將被發起。
4. 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.注意,出現幾十遍了，不翻譯這貨。

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

• 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條款[^4]中，描述了可能誘發該流程的外部觸發器事件，另外，該流程也可能由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.

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

  規范尚未制定

  6. 對於場景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;

  7. H-PCRF存儲被選中的Qos規則和PCC規則，如果有需要，H-PCRF將選擇網關控制會話將要用到的承載控制模式(Bearer Control Mode).
  8. 非漫游場景，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

9. BBERF安裝並執行接收到的Qos規則
10. 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)

  漫游情形不討論