策略和计费控制(PCC)系统研究

策略和计费控制(PCC)系统研究

研究内容

[TOC "float:left"]

---

策略与计费控制(PCC)框架¹

[架构图](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规则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规则的执行先后顺序；

==特别声明：==其余指标说明请参考相关文档²

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)流程³

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条款⁴中，描述了可能诱发该流程的外部触发器事件，另外，该流程也可能由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会话。
  1. 如果H-PCRF需要相关签约信息，而本地数据库中没有这些信息；则H-PCRF向SPR发起获得这些信息的请求；

  2. SPR回应H-PCRF的请求，并提供相关的信息；如，许可的业务，Qos信息，PCC规则信息等。

     规范尚未制定

  3. 对于场景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;

  4. H-PCRF存储被选中的Qos规则和PCC规则，如果有需要，H-PCRF将选择网关控制会话将要用到的承载控制模式(Bearer Control Mode).

  5. 非漫游场景，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包括如下内容⁵：

• 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 ]
  02[ 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 ]
  02[ 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 ]

• 协议汇总⁶
  |接口|连接网元|协议|
  |:-------|:-----|:------|
  |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. 29213-9d0 Policy and Charging Control signalling flows and Quality of Service↩

5. 3GUMTS与4GLTE核心网--CS,PS,EPC,IMS↩

6. 3GUMTS与4GLTE核心网--CS,PS,EPC,IMS↩

转载于:https://www.cnblogs.com/stevensfollower/p/5586857.html