策略与计费控制(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)

  漫游情形不讨论