- Dynamic PCC rules. Dynamically provisioned by the PCRF to the PCEF via the Gx interface. These PCC rules may be either predefined or dynamically generated in the PCRF. Dynamic PCC rules can be installed, modified and removed at any time.

M

C

- Predefined PCC rules. Preconfigured in the PCEF. Predefined PCC rules can be activated or deactivated by the PCRF at any time. Predefined PCC rules within the PCEF may be grouped allowing the PCRF to dynamically activate a set of PCC rules over the Gx reference point.

M

C

A PCC rule consists of:

- a rule name;

- service identifier;

- service data flow filter(s);

- application identifier;

- precedence;

- gate status;

- QoS parameters;

- indication for PS to CS session continuity;

- charging key (i.e. rating group);

- other charging parameters;

- monitoring key;

- sponsor identity;

- application service provider identity;

- indication of access network information reporting;

- redirect;

- traffic steering policy identifier(s)

M

PC

Gate status is set to ENABLED for dynamic (preconfigured in the SAPC) PCC rules.

Sponsor identity and Application service provider identity are not supported.

Indication for PS to CS session continuity is not supported.

Traffic steering policy identifier(s) is not supported.

The rule name shall be used to reference a PCC rule in the communication between the PCEF and the PCRF.

M

C

The service identifier shall be used to identify the service or the service component the service data flow relates to.

M

C

The service data flow filter(s) or the application detection filter shall be used to select the traffic for which the rule applies. Either service data flow filter(s) or application identifier shall exist in a PCC rule.

M

C

It shall be possible to define wildcarded service data flow filter(s), both for the dynamic and predefined PCC rules.

M

C

The application identifier shall be used to reference an application detection filter, which is predefined in the PCEF. The same application identifier value can occur in more than one PCC rule. If so, the PCRF shall ensure that there is at most one PCC rule active per application identifier value and IP CAN session at any time. NOTE 3: The application identifier can only be used for PCEF enhanced with ADC. The same application identifier value could be used for a dynamic PCC rule and a pre-defined PCC rule or for multiple pre-defined PCC rules. NOTE 4: The configuration of the application detection filter in the PCEF can include the set of information required for encrypted detection as defined in Annex X of 3GPP TS 23.203.

M

C

The gate status indicates whether the service data flow may pass (gate is open) or shall be discarded (gate is closed) in uplink and/or in downlink direction.

M

C

Gate status is set to ENABLED for dynamic (preconfigured in SAPC) PCC rules.

The QoS information includes the QoS class identifier (authorized QoS class for the service data flow), the Allocation and Retention Priority -(ARP) and authorized bitrates for uplink and downlink.

M

C

The PS to CS session continuity indicates that the service data flow may be handed over to the CS domain as defined in 3GPP TS 23.216 [40].

M

NC

The charging parameters define whether online and offline charging interfaces are used, what is to be metered in offline charging, on what level the PCEF shall report the usage related to the rule, etc.

M

C

For different PCC rules with overlapping service data flow filters, the precedence of the rule determines which of these rules is applicable. For PCC rules with application detection filter, the precedence of the rule is only relevant for the enforcement or charging of the detected application. When a dynamic PCC rule and a predefined PCC rule have the same precedence, the dynamic PCC rule takes precedence. For dynamic PCC rules that contain an application identifier, the precedence shall be either preconfigured at the PCEF or provided dynamically by the PCRF within the PCC Rules.

NOTE 5: Whether precedence for dynamic PCC rules that contain an application identifier is preconfigured in PCEF or provided in the PCC rule from the PCRF depends on network configuration.

M

PC

Application Identifier is not supported.

PCC rule also includes Application Function record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS this includes the IMS Charging Identifier (ICID) and flow identifiers.

M

C

The monitoring key for a PCC rule identifies a monitoring control instance that shall be used for usage monitoring control of the service data flows controlled by the predefined PCC rule or dynamic PCC rule.

M

PC

The SAPC supports usage monitoring for predefined PCC rules at PCEF.

If sponsored data connectivity is supported, the sponsor identity for a PCC rule identifies the 3rd party organization (the sponsor) willing to pay for the operator's charge for connectivity required to deliver a service to the end user.

M

NC

If sponsored data connectivity is supported, the application service provider identity for a PCC rule identifies the 3rd party organization (the ASP) that is delivering the service to the end user.

M

NC

If Access Network Information Reporting is supported, the value of Required-Access-Info AVP for a PCC rule identifies the Access Network Information parameters requested by the AF.

M

C

The redirect indicates whether the uplink part of the detected application traffic shall be redirected to a controlled address. The target redirect address may also be included.

NOTE 6: The redirect is applicable when application identifier exists in the PCC rule.

M

C

For dynamic PCC rules, the following operations are available:

Installation: to provision a PCC rules that has not been already provisioned.

Modification: to modify a PCC rule already installed.

Removal: to remove a PCC rule already installed.

M

C

For predefined PCC rules, the following operations are available:

Activation: to allow the PCC rule being active.

Deactivation: to disallow the PCC rule.

M

C

The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF.

M

C

The PCRF receives session and media related information from the AF and informs AF of traffic plane events.

M

C

The PCRF shall provision PCC Rules to the PCEF via the Gx reference point

M

C

If IP flow mobility applies, the PCRF shall, based on IP flow mobility routing rules received from the PCEF, provide the authorized PCC/QoS rules to the applicable BBF.

M

NC

If NBIFOM applies, the PCRF takes the decisions as described in subclause 4.5.25.1.1.

M

NC

The PCRF PCC Rule decisions may be based on one or more of the following:

- Information obtained from the AF via the Rx reference point, e.g. the session, media and subscriber related information.

Op

C

- Information obtained from the PCEF via the Gx reference point, e.g. IP-CAN bearer attributes, request type, subscriber related information and, IP flow mobility routing rules (if IP flow mobility is supported) , NBIFOM routing rule and change of usability of an access (if NBIFOM is supported), detected application's traffic information, (if the PCEF supports Application Detection and Control feature) and 3GPP PS Data Off status (if the PCEF supports 3GPP PS Data Off feature).

Op

PC

IP flow mobility routing rules are not supported.

NBIFOM routing rule is not supported.

- Information obtained from the SPR via the Sp reference point, e.g. subscriber and service related data.

Op

C

Service related data is stored in the SAPC.

- Information obtained from the TDF via the Sd reference point, e.g. report on application’s traffic detection start/stop.

Op

C

- Information obtained from the BBERF via the Gxx reference point.

Op

NC

Gxx reference point is not supported.

- Own PCRF pre-configured information.

Op

C

If the information from the PCEF contains traffic mapping information not matching any service data flow filter known to the PCRF, and the PCRF allows the UE to request enhanced QoS for services not known to the PCRF, the PCRF shall add this traffic mapping information as service data flow filters to the corresponding authorized PCC Rule. The PCRF may wildcard missing filter parameters, e.g. missing uplink TFT address and port information in case of GPRS.

M

NC

UE Init mode for dedicated bearers is not supported.

The PCRF shall report events to the AF via the Rx reference point.

M

C

The PCRF shall inform the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision(s).

M

C

The PCRF shall be able to select the bearer control mode that will apply for the IP-CAN session and provide it to the PCEF via the Gx reference point.

M

C

Upon subscription to loss of AF signalling bearer notifications by the AF, the PCRF shall request to PCEF to be notified of the loss of resources associated to the PCC Rules corresponding with AF Signalling IP Flows, if this has not been requested previously.

M

NC

If permitted by the subscriber's profile configuration received from the SPR, the PCRF may invoke the application’s traffic detection and control at the PCEF supporting Application Detection and Control feature, by providing the corresponding PCC Rules.

Op

C

The PCRF may use one or more pieces of information defined in the clause as input for the selection of traffic steering policies used to control the steering of the subscriber's traffic to appropriate (S)Gi-LAN service functions. NOTE 2: In order to allow the PCRF to select and provision an application based traffic steering policy, the reporting of detected applications to the PCRF or any other information defined in this clause can be used. If 3GPP PS Data Off applies, the PCRF shall behave as described in subclause 4.5.29.

Op

NC

If the PCRF is, due to incomplete, erroneous or missing information (for example, QoS, SGSN address, RAT type, TFT, subscriber information) not able to provision a policy decision as response to the request for PCC rules by the PCEF, the PCRF may reject the request using a CC Answer with the Gx experimental result code DIAMETER_ERROR_INITIAL_PARAMETERS (5140).

Op

PC

SAPC may reject the request with experimental result code DIAMETER_ERROR_INITIAL_PARAMETERS (5140) or DIAMETER_AUTHORIZATION_REJECTED (5003)

If the PCRF detects that the packet filters in the request for new PCC rules received from the PCEF is covered by the packet filters of outstanding PCC rules that the PCRF is provisioning to the PCEF, the PCRF may reject the request using a CC-Answer with the Gx experimental result code DIAMETER_ERROR_CONFLICTING_REQUEST (5147).

Op

NC

UE Init mode for dedicated bearers is not supported.

If the PCRF does not accept one or more of the traffic mapping filter provided by the PCEF in a CC Request (for example, because the PCRF does not allow the UE to request enhanced QoS for services not known to the PCRF), the PCRF shall reject the request using a CC Answer with the Gx experimental result code DIAMETER_ERROR_TRAFFIC_MAPPING_INFO_REJECTEC (5144).

M

NC

The PCRF shall not combine a rejection with provisioning of PCC rule operations in the same CC Answer.

M

C

The PCRF shall indicate, via the Gx reference point, PCC rules to be applied at the PCEF.

M

C

PULL procedure (Provisioning solicited by the PCEF) : In response to a request for PCC rules being made by the PCEF, as described in the preceding section, the PCRF shall provision PCC rules in the CC-Answer

M

C

PUSH procedure (Unsolicited provisioning) : The PCRF may decide to provision PCC rules without obtaining a request from the PCEF, for example, in response to information provided to the PCRF via the Rx reference point, or in response to an internal trigger within the PCRF.

Op

C

To provision PCC rules without a request from the PCEF, the PCRF shall include these PCC rules in an RA-Request message. No CCR/CCA messages are triggered by this RA-Request.

M

C

The PCRF should NOT send a new RA-Request command to the PCEF until the previous RA-Request has been acknowledged for the same IP-CAN session.

M

C

For each request from the PCEF or upon the unsolicited provision the PCRF shall provision zero or more PCC rules.

M

C

The PCRF may perform an operation on a single PCC rule by one of the following means:

Op

C

- To activate or deactivate a PCC rule that is predefined at the PCEF, the PCRF shall provision a reference to this PCC rule within a Charging-Rule-Name AVP and indicate the required action by choosing either the Charging-Rule-Install AVP or the Charging-Rule-Remove AVP.

M

C

- To install or modify a PCRF-provisioned PCC rule, the PCRF shall provision a corresponding Charging-Rule-Definition AVP within a Charging-Rule-Install AVP.

M

C

- To remove a PCC rule which has previously been provisioned by the PCRF, the PCRF shall provision the name of this rule as value of a Charging-Rule-Name AVP within a Charging-Rule-Remove AVP.

M

C

- If, for certain accesses, the PCRF performs the bearer binding, the PCRF may move previously installed or activated PCC rules from one IP CAN bearer to another IP CAN bearer. See Annex A (Normative): Access Specific Aspects (GPRS) for further details.

Op

NC

The SAPC does not perform bearer binding, as UE-Init procedures (multiple IP-CAN bearers) are not supported.

As an alternative to providing a single PCC rule, the PCRF may provide a Charging-Rule-Base-Name AVP within a Charging-Rule-Install AVP or the Charging-Rule-Remove AVP as a reference to a group of PCC rules predefined at the PCEF. With a Charging-Rule-Install AVP, a predefined group of PCC rules is activated or moved. With a Charging-Rule-Remove AVP, a predefined group of PCC rules is deactivated.

Op

C

The PCRF may combine multiple of the above PCC rule operations in a single command.

Op

C

When the UE initiates a resource modification procedure, the PCRF shall provision PCC rule(s) that are only related to the UE’s resource modification in the corresponding CCA command.

M

NC

To activate a predefined PCC rule at the PCEF, the rule name within a Charging-Rule-Name AVP shall be supplied within a Charging-Rule-Install AVP as a reference to the predefined rule. To activate a group of predefined PCC rules within the PCEF (e.g. gold users or gaming services) the PCC rule base name within a Charging-Rule-Base-Name AVP shall be supplied within a Charging-Rule-Install AVP as a reference to the group of predefined PCC rules.

M

C

To install a new or modify an already installed PCRF defined PCC rule, the Charging-Rule-Definition AVP shall be used. If a PCC rule with the same rule name, as supplied in the Charging-Rule-Name AVP within the Charging-Rule-Definition AVP, already exists at the PCEF, the new PCC rule shall update the currently installed rule. If the existing PCC rule already has attributes also included in the new PCC rule definition, the existing attributes shall be overwritten. Any attribute in the existing PCC rule not included in the new PCC rule definition shall remain valid.

M

C

When installing a new or modifying an already installed PCC rule and if the Rel11 feature is supported by both the PCEF and PCRF as described in subclause 5.4.1, the PCRF shall always include at least one uplink packet filter within a provisioned PCC rule. For PCC rules with service data flow filters for the downlink direction only, i.e. the Flow-Direction AVP set to the value DOWNLINK(1), the PCRF shall add an uplink service data flow filter to the resulting PCC rule that effectively disallows any useful packet flows in uplink direction (see subclause 15.3.3.4 in 3GPP TS 23.060 [17] for an example of such a packet filter). The Packet-Filter-Usage AVP value SEND_TO_UE (1) shall not be used for that filter.

M

NC

NOTE 2: Despite that signalling with the UE in 2G/3G only allows the network to accept or reject the UE request, the PCRF is adding an extra service data flow filter in case that the packet filters in the request for new PCC rules from the PCEF only contain downlink packet filters, by that the PCRF logic is kept agnostic to the RAT used.

M

NC

NOTE 3: The PCRF does not add an uplink service data flow filter to the resulting PCC rule if the PCRF detects that the service data flow filters in the PCC rule include a service data flow filter with unspecified direction information, i.e. Flow-Direction AVP set to value UNSPECIFIED (0).

M

NC

NOTE 4: The PCRF does not add an uplink service data flow filter to the resulting PCC rule if the PCRF detects that the service data flow filters in the PCC rule include a downlink service data flow filter with unspecified direction information, i.e. Flow-Direction AVP set to value UNSPECIFIED (0).

M

NC

Provisioning of predefined PCC rules upon invocation/revocation of an MPS service shall be done according to clause 5.3 in 3GPP TS 29.213.

M

C

For deactivating single predefined or removing PCRF-provided PCC rules, the Charging-Rule-Name AVP shall be supplied within a Charging-Rule-Remove AVP. For deactivating a group of predefined PCC rules, the Charging-Rule-Base-Name AVP shall be supplied within a Charging-Rule-Remove AVP.

M

C

The PCRF may request the PCEF to confirm that the resources associated to a PCC rule are successfully allocated. To do so the PCRF shall provide the Event-Trigger AVP with the value SUCCESSFUL_RESOURCE_ALLOCATION (22) if the event trigger is not previously set. In addition the PCRF shall install the rules that need resource allocation confirmation by including the Resource-Allocation-Notification AVP with the value ENABLE_NOTIFICATION(0) within the corresponding Charging-Rule-Install AVP

Op

C

If Enh-RAN-NAS-Cause feature is supported, the PCRF may request the PCEF to report the outcome of the release of resources related to a PCC rule. To do so the PCRF shall provide the Event-Trigger AVP with the value RESOURCE_RELEASE (53) if the event trigger is not previously set. In addition the PCRF shall provide the Resource-Release-Notification AVP with the value ENABLE_NOTIFICATION (0) with the corresponding Charging-Rule-Remove AVP. If a Charging-Rule-Remove AVP does not include the Resource-Release-Notification AVP, the outcome of the resource release shall not be notified by the PCEF. The PCRF shall maintain the PCC rules for which release confirmation is required until the PCEF notifies about the resource release outcome.

Op

NC

If the provisioning of PCC rules fails, the PCEF informs the PCRF as described in Clause 4.5.12 PCC Rule Error Handling. Depending on the cause, the PCRF may decide if re-installation, modification, removal of PCC rules or any other action applies.

Op

PC

Reporting failure in RAA command is not handled.

If the PCRF is unable to create a PCC rule for the response to the CC Request by the PCEF, the PCRF may reject the request as described in subclause 4.5.1.

Op

NC

See Request for PCC Rules

If the PCRF receives a request for PCC rules for an IP-CAN session from the PCEF, or a request for QoS rules for a gateway control session from the BBERF, while no suitable authorized PCC rules are configured in the PCRF or can be derived from service information provisioned by an AF, the PCRF shall check the set of services the user is allowed to access for this APN.

M

NC

If the user is not allowed to access AF session based services, the PCRF shall check whether the user is allowed to request resources for services not known to the PCRF and whether the requested QoS and/or packet filters can be authorized. If this is the case, the PCRF shall provide a PCC rule to authorize the UE requested QoS and packet filters that were received as part of the request for PCC/QoS rules. The service data flow description shall be derived from the packet filter information.

M

NC

If the user is not allowed to request resources for services not known to the PCRF, the PCRF shall reject the request.

M

C

If the user is allowed to access AF session based services, the PCRF may, depending for example, on the user’s subscription details or operator policy, authorise the requested QoS for a timer supervised grace period (the timer started by the PCRF either by the request from the PCEF or from the BBERF) to wait for AF service information.

Op

NC

No timer is defined.

If an AF session bound to the same IP CAN session is ongoing and only preliminary service information was received within this AF session, the PCRF shall base the authorization of the requested QoS on the preliminary service information

M

C

If the preliminary service information is insufficient to construct appropriate PCC rules or no preliminary service information is available, the PCRF shall provide preliminary PCC rules to authorize the UE requested QoS and packet filters. Therefore, the preliminary PCC rules shall contain wildcarded flow description or flow description derived from possible TFTs received as part of the request for PCC/QoS rules.

M

NC

TFTs are not considered by SAPC, as only general bearer in UE-init mode is supported.

The PCRF may apply a dedicated charging key value to indicate to the charging subsystem that the charging key is preliminary and may be corrected later on.

Op

NC

With the dedicated charging key, the PCRF instructs the charging subsystem to recalculate the applicable charge for the time when the dedicated charging key value was applied once the dedicated charging key value is replaced with some other value in a new provisioning of PCC rules. For example, if online charging applies, Session Charging with Unit Reservation (SCUR) can be used.

M

NC

If the PCRF receives AF service information while the timer-supervised grace period is running, the PCRF shall stop the timer and may derive authorized PCC rules from this service information and update or replace the preliminary PCC rules that were previously provided for the UE requested QoS and packet filters, for instance by choosing service specific QoS parameters and charging keys.

M

NC

Immediate installation (no timer) is done on general bearer.

If the timer expires and the PCRF has not received any AF service information, the PCRF should downgrade or revoke the authorization for the preliminary PCC/QoS rules (previously provided for the UE requested QoS and packet filters) in accordance with the policy for services not known to the PCRF. The PCRF should adjust the charging keys within the PCC rules and should downgrade the authorized QoS to the allowed value for the services not known to the PCRF, if required.

M

NC

Immediate installation (no timer) is done on general bearer.

For the case where the BBERF requests QoS rules from the PCRF, the PCRF derives the QoS rules from the PCC rules and provisions the QoS rules to the BBERF according to clause 4a.5.2.

M

NC

Gxx is not supported.

If the IP flow mobility is supported and the tariff depends on what access network is in use for the service data flow, then the PCRF may set the charging key of the PCC rule in accordance with the access network in use.

M

NC

The PCRF may provide one or several event triggers within one or several Event-Trigger AVP to the PCEF using the PCC rule provision procedure. Event triggers may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Although event trigger reporting from PCEF to PCRF can apply for an IP CAN session or bearer depending on the particular event, provisioning of event triggers will be done at session level.

Op

C

The Event-Trigger AVP may be provided in combination with the initial or subsequent PCC rule provisioning.

Op

C

NOTE 1: There are event triggers that will only take effect when additional information is provided. The PCRF may provide the additional information together with the event trigger or in subsequent PCC rule provisioning. The PCEF will only report those event triggers when the related data is available.

Op

C

The PCRF may add new event triggers or remove the already provided ones at each request from the PCEF or upon the unsolicited provision from the PCRF. In order to do so, the PCRF shall provide the new complete list of applicable event triggers including the needed provisioned Event-Trigger AVPs in the CCA or RAR commands.

Op

C

The PCRF may remove all previously provided event triggers by providing the Event-Trigger AVP set to the value NO_EVENT_TRIGGERS. When an Event-Trigger AVP is provided with this value, no other Event-Trigger AVP shall be provided in the CCA or RAR command.

Op

C

If no Event-Trigger AVP is included in a CCA or RAR operation, any previously provisioned event trigger will be still applicable. Unless otherwise stated for a certain event trigger, the PCRF shall be able to modify the data related to an event trigger without providing again a previously provisioned event trigger if such event trigger is still armed.

M

C

When the PCRF receives the CC-Request, it shall acknowledge this message by sending a CC-Answer to the PCEF.

M

C

The PCRF may request the removal of the PCC rules by using the PCC rule provisioning procedures in clause 4.5.2 to remove all PCRF-provisioned PCC rules and deactivate all PCC rules predefined within the PCEF.

Op

C

When Enh-RAN-NAS-Cause feature is supported, the PCRF removing PCC rules using the RAR command shall maintain locally the PCC rules that were marked as requiring release confirmation until the PCEF reports RESOURCE_RELEASE (53) event trigger as described in subclause 5.3.7.

NOTE: This is done to allow the PCRF to notify the AF when there is an abnormal termination of the bearer. The PCRF does not have to retry the removal of these PCC Rules.

Op

NC

The PCRF may either completely remove these PCC rules from the IP CAN session or reinstall them (for example, by changing the QoS or charging information) within the IP CAN session.

Op

C

If the selected Bearer Control Mode (BCM) is UE-only, and the PCRF receives a trigger for the removal of all PCC rules from the AF, the following steps apply. In order to avoid race conditions, the PCRF should start a timer to wait for the UE-initiated resource release message. If a UE-initiated resource release is performed before timer expiry, the PCRF will receive an Indication of IP-CAN Bearer Termination Implications according to Clause 4.5.6 and shall then not perform the removal of the PCC rules. Otherwise, if the timer expires, the PCRF shall remove/deactivate the affected PCC rules that have been previously installed/activated.

M

PC

UE-Init mode for dedicated bearers is not supported.

No timer is used for general bearer.

If the selected BCM is UE-only, and the PCRF decides to remove one or more PCC rules due to an internal trigger or trigger from the SPR, the PCRF shall instantly remove/deactivate the affected PCC rules that have been previously installed/activated.

M

C

A RAR with PCC Rules is sent towards the PCEF

The PCRF may request the IP-CAN session termination in the following instances:

- If the PCRF decides to terminate an IP CAN session due to an internal trigger or trigger from the SPR, the PCRF shall send an RAR command including the Session-Release-Cause AVP to the PCEF. The PCEF shall acknowledge the command by sending an RAA command to the PCRF and.

M

C

- The PCRF may also decide to terminate an IP CAN session upon receiving CCR command with a CC-Request-Type AVP set to the value "UPDATE_REQUEST" from the PCEF (e.g. when usage quota reached). In that case, the PCRF shall send a CCA command including the Session-Release-Cause AVP to the PCEF.

Op

NC

Session-Release-Cause only supported for RAR, not CCA

The PCRF derives the selected Bearer-Control-Mode AVP based on the received Network-Request-Support AVP, access network information, subscriber information and operator policy.

M

C

SAPC decides the mode selection taking into account the information received in Network-Request-Support AVP

If the selected bearer control mode is UE_NW, the PCRF shall decide what mode (UE or NW) shall apply for every PCC rule.

M

C

SAPC decides that NW is applied for the whole IP-CAN session.

For operator-controlled services, the UE and the PCRF may be provisioned with information indicating which mode is to be used.

Op

NC

When applicable for the IP-CAN type, at IP-CAN session establishment, if the PCEF provided the Network-Request-Support AVP, the selected bearer control mode shall be provided within the Bearer-Control-Mode AVP to the PCEF using the PCC Rules provision procedure. At IP-CAN session modification, if the PCEF provided the Network-Request-Support AVP, the PCRF shall also provide the Bearer-Control-Mode AVP with the new value if the selected bearer control mode has changed. The selected value will be applicable for the whole IP-CAN session.

M

C

If the RuleVersioning feature is supported and the PCRF included a Content-Version AVP as part of the Charging-Rule-Definition AVP when installing or modifying a PCC rule for both the PULL and PUSH modes, then if the resource allocation for the corresponding PCC rule was unsuccessful, the PCEF shall include the Content-Version AVP as part of the Charging-Rule-Report AVP. Depending on the value of the Rule-Failure-Code AVP, and when applicable, depending also on the value of the Content-Version AVP, for PULL and PUSH mode, the PCRF may decide whether retaining of the old PCC rule, re-installation, modification, removal of the PCC rule or any other action applies.

Op

NC

NOTE: When the PCRF receives PCC-Rule-Status set to INACTIVE, the PCRF does not need request the PCEF to remove the inactive PCC rule.

Op

C

PCEF shall be able to perform PCC rule request as instructed by the PCRF. To do so, the PCRF shall provide the Event-Trigger AVP with the value REVALIDATION_TIMEOUT (17) if the event trigger is not previously set, and in addition the Revalidation-Time AVP when set by the PCRF.

M

C

PCRF shall be able to provide a new value for the revalidation timeout by including Revalidation-Time in CCA or RAR. The PCRF may provide the Revalidation-Time AVP together with the event trigger REVALIDATION_TIMEOUT or in a subsequent PCC rule provisioning.

M

C

PCRF shall be able to stop the revalidation timer by disabling the REVALIDATION_TIMEOUT event trigger.

M

C

The PCRF may control at what time the status of a PCC rule changes.

Op

C

The SAPC sends Rule-Activation-Time together with Rule-Deactivation-Time and never sets a date or time in the past. The SAPC does not set a Rule-DeActivation-time that occurs before the Rule-Activation-Time.

The 3GPP-MS-TimeZone AVP, if available, may be used for the PCRF to derive the Rule-Activation-Time and Rule-Deactivation-Time.

Op

C

The PCC rules including Rule-Activation-Time and Rule-Deactivation-Time shall not be applied for changes of the QoS or service data flow filter information.

M

C

It is done by configuration of policies in the SAPC.

The PCRF may modify a currently installed PCC rule, including setting, modifying or clearing its deferred activation and/or deactivation time.

Op

C

When modifying a dynamic PCC rule with a prior and/or new deferred activation and/or deactivation time, the PCRF shall provide all attributes of that rule in the Charging-Rule-Definition AVP, including attributes that have not changed.

M

C

The PCRF may indicate, via the Gx reference point, the need to apply monitoring control for the accumulated usage of network resources on an IP-CAN session basis. Usage is defined as volume or time of user plane traffic

Op

C

Monitoring for traffic volume and traffic time can be performed in parallel.

M

NC

Time Usage Monitoring not supported

The data collection for usage monitoring control shall be performed per monitoring key, which may apply for a single Service Data Flow, a set of Service Data Flows or for all the traffic in an IP-CAN session.

M

C

If the usage monitoring of an IP-CAN session level is enabled, the PCRF may request the PCEF to exclude a single service data flow or a set of service data flows from the usage monitoring of IP-CAN session level.

Op

NC

If the PCRF requests usage monitoring control and if at this time, the PCRF is not subscribed to the "USAGE_REPORT" Event-Trigger, the PCRF shall include the Event-Trigger AVP, set to the value "USAGE_REPORT", in a CC-Answer or RA-Request

M

C

The PCRF shall not remove the "USAGE_REPORT" Event-Trigger AVP while usage monitoring is still active in the PCEF.

M

C

At IP-CAN session establishment and modification, the PCRF may provide the applicable thresholds, volume threshold, time threshold or both volume threshold and time threshold, for usage monitoring control to the PCEF, together with the respective monitoring keys. To provide the initial threshold for one or more monitoring key(s), the PCRF may include the threshold in both RA-Request or in the response of a CC-Request initiated by the PCEF.

Op

PC

Time Usage Monitoring not supported

During the IP-CAN session establishment, the PCRF may receive information about total allowed usage per PDN and per UE from the SPR, that is, the overall amount of allowed traffic volume that are to be monitored per PDN and UE and/or total allowed usage for Monitoring key(s) per PDN and UE.

Op

C

In order to provide the applicable threshold for usage monitoring control, the PCRF shall include a Usage-Monitoring-Information AVP per monitoring key.

M

C

The threshold level shall be provided in its Granted-Service-Unit AVP. Threshold levels may be defined for:

- the total volume only; or

- the uplink volume only; or

- the downlink volume only; or

- the uplink and downlink volume; or

- the time.

M

PC

Time Usage Monitoring not supported

The PCRF shall provide the applicable volume threshold(s) in the CC-Total-Octets, CC-Input-Octets or CC-Output-Octets AVPs and/or time threshold in the CC-Time AVP of the Granted-Service-Unit AVP.

M

PC

Time Usage Monitoring not supported

The monitoring key shall be provided in the Monitoring-Key AVP

M

C

The PCRF may provide multiple usage monitoring control instances.

Op

C

The PCRF shall indicate if the usage monitoring instance applies to the IP-CAN session or to one or more PCC rules. For this purpose, the Usage-Monitoring-Level AVP may be provided with a value respectively set to SESSION_LEVEL or PCC_RULE_LEVEL

M

C

The PCRF may provide one usage monitoring control instance applicable at IP-CAN session level and one or more usage monitoring instances applicable at PCC Rule level.

Op

C

If the IP-CAN level usage monitoring is enabled and if the service data flow(s) need to be excluded from IP-CAN session level usage monitoring, the PCRF shall provide an indication of exclusion from session level monitoring associated with the respective PCC rule(s) by including the Monitoring-Flags AVP with the bit 0 set in the corresponding Charging-Rule-Install AVP when the PCRF installs or updates the PCC rule(s). If the exclusion is enabled, the PCRF may disable the exclusion again by including the Monitoring-Flags AVP with the bit 0 not set in the corresponding Charging-Rule-Install AVP.

M

NC

The PCRF may provide a Monitoring-Time AVP to the PCEF for the monitoring keys(s) in order to receive reports for the accumulated usage before and after the monitoring time occurs within the report triggered by the events defined in 4.5.17.1-4.5.17.5. In such a case, there may be two instances of Granted-Service-Unit AVP within Usage-Monitoring-Information AVP per monitoring key. One of them indicates the threshold levels before the monitoring time occurs, and the other one, which includes Monitoring-Time AVP, indicates the subsequent threshold levels after the monitoring time occurs. The detailed functionality in such a case is defined by 4.5.17.6.

Op

NC

If the PCRF wishes to modify the threshold level for one or more monitoring keys, the PCRF shall provide the thresholds for all the different levels applicable to the corresponding monitoring key(s).

M

C

If the PCRF wishes to modify the monitoring key for the session level usage monitoring instance, it shall disable the existing session level monitoring usage instance following the procedures defined in 4.5.17.3 and shall provide a new session level usage monitoring instance following the procedures defined in this clause.

M

C

The PCRF may enable the new session level usage monitoring instance and disable the existing session level usage monitoring instance in the same command.

Op

NC

When the accumulated usage is reported in a CCR command, the PCRF shall indicate to the PCEF if usage monitoring shall continue for that IP-CAN session, usage monitoring key, or both as follows:

- If monitoring shall continue for specific level(s), the PCRF shall provide the new thresholds for the level(s) in the CC-Answer using the same AVP as before (CC-Total-Octets, CC-Input-Octets CC-Output-Octets or CC-Time AVP AVP within the Granted-Service-Unit AVP);

- otherwise, if the PCRF wishes to stop monitoring for specific level(s) the PCRF shall not include an updated threshold in the CCA command for the stopped level(s) , that is, the corresponding CC-Total-Octets, CC-Input-Octets, CC-Output-Octets or CC-Time AVPs shall not be included within Granted-Service-Units AVP.

M

C

When usage monitoring is enabled, the PCRF may request the PCEF to report accumulated usage for one or more enabled monitoring keys regardless if a usage threshold has been reached by sending to the PCEF within the Usage-Monitoring-Information AVP the Usage-Monitoring-Report AVP set to the value USAGE_MONITORING_REPORT_REQUIRED.

Op

C

The PCRF shall only require PCEF to report accumulated usage for one or more monitoring keys in a CC-Answer when the PCEF has not provided accumulated usage in the CC-Request for the same monitoring key(s).

M

C

To specify the usage monitoring key for which usage is requested the PCRF shall include the usage monitoring key within the Monitoring-Key AVP within the Usage-Monitoring-Information AVP.

M

C

To request usage be reported for all enabled usage monitoring keys the PCRF shall omit the Monitoring-Key.

M

NC

The PCRF shall process the usage reports and shall perform the actions as appropriate for each report.

M

C

When the time based usage monitoring is supported, the PCRF may optionally indicate to the TDF, along with other usage monitoring information provided, the Inactivity Detection Time within the Quota-Consumption-Time AVP.

Op

NC

Usage monitoring not supported in TDF interactions

Upon receiving the reported usage from the PCEF, the PCRF shall deduct the value of the usage report from the total allowed usage for that IP-CAN session, usage monitoring key, or both as applicable,

M

C

and the PCRF may also derive the PCC rules based on the remaining allowed usage or reported usage and provision them to the PCEF

Op

C

In order to support IMS Restoration procedures (refer to 3GPP TS 23.380 [33]), PCRF needs to convey the AF address to the PCEF. In order to do so, in case AF provisions information about the AF signalling flows between the UE and the AF, as defined in 3GPP TS 29.214 [10] Section 4.4.5a, the PCRF shall install the corresponding dynamic PCC rules (if not installed before) by triggering a RAR message

M

C

The PCRF shall provide the Charging-Rule-Install AVP including the Charging-Rule-Definition AVP(s). The Charging-Rule-Definition AVP shall include in the Flow-Information AVP the signalling flows between UE and the AF. The Charging-Rule-Definition AVP shall also include the AF-Signalling-Protocol AVP set to the value corresponding to the signalling protocol used between the UE and the AF.

M

C

In case AF de-provisions information about the AF signalling flows between the UE and the AF, as defined in 3GPP TS 29.214 [10] Section 4.4.5a, the PCRF shall remove the corresponding dynamic PCC rules by triggering a RAR message. The PCRF shall provide the Charging-Rule-Remove AVP including the corresponding Charging-Rule-Name AVP(s).

M

C

When the NetLoc feature is supported, if the AF requests the PCRF to report the access network information and if the PCRF cannot determine that access network information cannot be provided as described in subclause 4.4.6.7 of 3GPP TS 29.214 [10], the PCRF shall provide the requested access network information indication (e.g. user location and/or user timezone information) to the PCEF as follows:

• If the PCRF is installing or modifying a PCC rule, the PCRF shall include the Required-Access-Info AVP within the Charging-Rule-Definition AVP of an appropriate installed or modified PCC rule;

• Otherwise, if the PCRF is removing PCC rules based on the AF requests, the PCRF shall include the Required-Access-Info AVP within the Charging-Rule-Remove AVP associated with the corresponding PCC rules being removed.

M

C

The SAPC does not check either the IP-CAN type or RAT-Type values to determine if the access network supports or not the access network information reporting.

The PCRF shall also provide the ACCESS_NETWORK_INFO_REPORT event trigger within Event-Trigger AVP (if this event trigger is not yet set).

M

C

For the QoS Rule(s) based on preliminary service information as described in 3GPP TS 29.214 [10] the PCRF may assign the QCI and ARP of the default bearer to avoid signalling to the UE. These QoS Rules shall not include the Packet-Filter-Usage AVP within the Flow-Information AVP included in the QoS-Rule-Definition AVP. These QoS rule(s) may be provisioned by the PCRF without corresponding PCC rule(s).

M

NC

If the ACCESS_NETWORK_INFO_REPORT event trigger is set, upon installation, modification and removal of any PCC rule(s) with the Required-Access-Info AVP in a Gx RAR command, and if the PCEF determines that the access network does not support the access network information reporting based on the currently used IP-CAN type or the RAT type and the value of AN-Trusted AVP, the PCEF shall immediately inform the PCRF by including the NetLoc-Access-Support AVP with the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED) in the RAA command. Otherwise, the PCEF shall apply appropriate IP CAN specific procedures to obtain this information. When the PCEF then receives access network information through those IP CAN specific procedures, the PCEF shall provide the required access network information to the PCRF as follows:

- If the user location information was requested by the PCRF and was provided to the PCEF, the PCEF shall provide the user location information within the 3GPP-User-Location-Info AVP and the time when it was last known within User-Location-Info-Time AVP (if available).

- If the user location information was requested by the PCRF and was not provided to the PCEF, the PCEF shall provide the serving PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP.

- If the time zone was requested by the PCRF, the PCEF shall provide it within the 3GPP-MS-TimeZone AVP.

M

C

In addition, the PCEF shall provide the ACCESS_NETWORK_INFO_REPORT event trigger within Event-Trigger AVP.

M

C

During bearer deactivation, when the NetLoc feature is supported, the PCEF shall provide the access network information to the PCRF by including the user location information within the 3GPP-User-Location-Info AVP (if requested by the PCRF and if provided to the PCEF), the information on when the UE was last known to be in that location within User-Location-Info-Time AVP (if user location information was requested by the PCRF and if the corresponding information was provided to the PCEF), the PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP (if the user location information was requested by the PCRF but it is not provided to the PCEF) and the timezone information within the 3GPP-MS-TimeZone AVP (if requested by the PCRF).

M

C

During IP-CAN session termination procedure, the PCEF shall, if ACCESS_NETWORK_INFO_REPORT event trigger is set, provide the access network information to the PCRF by including the user location information within the 3GPP-User-Location-Info AVP (if it was provided to the PCEF), the information on when the UE was last known to be in that location within User-Location-Info-Time AVP (if it was provided to the PCEF), the PLMN identifier within the 3GPP-SGSN-MCC-MNC AVP (if the user location information was not provided to the PCEF) and the timezone information within the 3GPP-MS-TimeZone AVP.

M

C

The PCRF may instruct the PCEF to detect application (s) by providing the Charging-Rule-Install AVP (s) with the corresponding parameters as follows: the application to be detected is identified by the TDF-Application-Identifier AVP, which is either provided under Charging-Rule-Definition AVP for dynamic PCC Rules or pre-provisioned for the corresponding predefined PCC Rule, and in such a case only Charging-Rule-Name/Charging-Rule-Base-Name is provided.

Op

C

If the PCRF requires to be reported about when the application start/stop is detected, it shall also subscribe to the APPLICATION_START and APPLICATION_STOP Event-Triggers.

M

C

The PCRF may also mute such a notification about a specific detected application by providing Mute-Notification AVP within the PCC Rule.

Op

C

The corresponding TDF-Application-Identifier AVP shall be included under Application-Detection-Information AVP.

M

C

When the Event trigger indicates APPLICATION_START, the Flow-Information AVP for the detected application may be included under Application-Detection-Information AVP, if deducible. The Flow-Information AVP, if present, shall contain the Flow-Description AVP and Flow-Direction AVP. The TDF-Application-Instance-Identifier, which is dynamically assigned by the PCEF in order to allow correlation of APPLICATION_START and APPLICATION_STOP Event-Triggers to the specific Flow-Information AVP, if service data flow descriptions are deducible, shall also be provided when the Flow-Information AVP is included. Also, the corresponding Event-Trigger (APPLICATION_START or APPLICATION_STOP) shall be provided to PCRF. When the TDF-Application-Instance-Identifier is provided along with the APPLICATION_START, it shall also be provided along with the corresponding APPLICATION_STOP.

Op

C

The PCRF then may make policy decisions based on the information received and send the corresponding updated PCC rules to the PCEF, and corresponding QoS rules to the BBERF, if applicable.

Op

PC

BBERF interactions are not supported