Override Control

This chapter describes the Override Control feature and provides detailed information on the following topics:

Feature Summary and Revision History

Summary Data

Applicable Product(s) or Functional Area

  • ECS

  • P-GW

Applicable Platform(s)

ASR 5500

Feature Default

Disabled - Configuration Required

Related Changes in This Release

Not Applicable

Related Documentation

ECS Administration Guide

Revision History


Important

Revision history details are not provided for features introduced before releases 21.2 and N5.5.

Revision Details

Release

In this release, support is added for Execution-Time AVP in Override-Control AVP to allow the overridden parameters to be specified for a rule (static or predefined), for one or all charging actions (using a wildcard), with the ability to exclude certain rules.

21.3

First introduced.

Pre 21.2

Feature Description

Override Control (OC) feature allows the customer to dynamically modify the parameters of static or predefined rules with parameters sent by PCRF over the Gx interface.


Important

Override Control is a license-controlled feature. A valid feature license must be installed prior to configuring this feature. Contact your Cisco account representative for more information.

The Inheritance feature does not support overwriting parameters at rule/charging action level, and exclusion of more than one rule. In order to provide this flexibility and also have a generic capability on chassis, Override Control feature is introduced. This feature will define a set of custom AVPs that will enable the PCRF to override charging and policy parameters for all rules (wildcard) or a specified set of rules or charging actions.

The override values should be sent by PCRF over Gx using the custom AVPs. Override Control provides this capability while addressing the limitations with Inheritance feature like rule level control, charging action level control, exclusion of more than one rule, different override values to be specified for a subscriber, etc. So, the Override Control feature will replace the Inheritance feature.

Override Control feature can be configured at the rulebase level. The Diameter capability exchange message should indicate support for Override control feature when the override-control CLI command is configured in the rulebase configuration mode.


Important

Both Inheritance and the Override Control features are supported in this release. Note that these two features should not be enabled simultaneously. If these features are enabled by mistake, only Override Control is applied.

In 19 and later releases, support to override Group-of-Ruledefs is provided for the Override Control feature. Override sent for a group-of-ruledefs will apply to all the ruledefs defined in a group. The same Override-Rule-Name AVP is used to send Ruledef or Group-of-Ruledef interchangeably. The two AVPs — Override-Rule-Name and Override-Charging-Action-Exclude-Rule, support either a Ruledef name or a Group-of-Ruledefs name.

The Gx interface is updated to include custom AVPs for the PCRF to send override values to P-GW. These override values may be sent for all rules (wildcard) or for specific rule(s) or for charging action(s). In case the override values are sent for a charging action, a rule or some of the rules may be excluded from using the override values by sending the rules names in the Gx message. The override values will be check pointed and recovered in case of either standalone recovery or ICSR.

This Override Control feature is expected to maintain existing active calls using Inheritance post upgrade. Inheritance feature and Override Control should not be enabled simultaneously. It is necessary that Inheritance feature be turned off once Override Control feature is enabled. Override Control once enabled will apply only to new calls and does not affect the existing calls.

When multiple overrides are received from PCRF, the following is the priority in which they are applied:

  1. Rule level override control
  2. Charging action level override control
  3. Wildcard level override control

When installing a predef rule, if override control is received for that predef rule and QCI/ARP is overridden, then the new overridden QCI/ARP values are used for bearer binding of the predef rule. If the QCI/ARP is not overridden, then the values configured in charging action is used. The override charging and policy parameters received from PCRF will continue to apply for the entire duration of the call. These values may be modified by PCRF by sending the modified values with the same override control criteria (Rule name(s), Charging Action Name(s) and Exclude Rule(s)). Any change in the Override Control criteria will be interrupted as a new OC. There can only be one wildcard OC installed for a subscriber.


Important

If two or more different rules with different rule definitions are associated with the same charging action, the operator must ensure that override control sent from PCRF does not bind these rules to different bearers by overriding the QCI/ARP combination for selective rules.

In 20 and later releases, the status of Override Control can be checked based on whether OC is enabled or disabled for the call. This is useful to trace calls for which Override Control is not installed and can also be used for debugging purposes. The OC status will be displayed based on the following conditions:

  • If for any call, override control is installed for a static rule, status will be displayed as ON.

  • If for any call, override control is installed for any pre-defined rule in rulebase and even if these particular pre-defined rule(s) are not yet activated through PCRF, status will be displayed as ON.

  • If inheritance is enabled for calls, status will be displayed as OFF.

Per Subscriber Traffic Steering

In this release, an addional capability is added to the Override Control feature to dynamically route/mark traffic on a per subscriber basis. Override Control functionality will now support the policy parameters in charging action for post processing rules — Nexthop Address (IPv4 address only) and TOS. Diameter AVPs are also added in support of this feature.

The following are limitations for this feature:
  • Override Control supports only IPv4 Nexthop Address in this release.
  • If invalid value of Nexthop Address or TOS is received, then the complete Override Control message will be discarded.
  • Currently there is no way to withdraw an already applied Override Control message. This can only be modified.
  • This feature does not support Group-of-Ruledefs in Override Control.
  • This feature enables customers to steer specific subscribers to different services using a unique Nexthop address. This could alternatively be accomplished using a unique VLAN ID as well. Due to the current implementation, this feature does not provide support of VLAN ID on Override Control eventhough VLAN ID can be received in OC message, and the packet can still be routed to default VLAN.

For information on how to configure the Override Control feature, refer to the section Configuring Override Control Feature in the Enhanced Charging Service Configuration chapter of this guide.

Override Control Name for OC Identification

For identification of OC, PCRF uses one or a combination of the following key parameters:

  • Rule names

  • Charging-action names

  • Exclude-rule names

There is no unique identifier available for identification of OC for a particular subscriber session. In release 20, a new Diameter AVP "Override-Control-Name" is defined in the Override-Control grouped AVP. The OC name specified in the AVP is used as the unique key to identify OC for any further updates like OC modification or deletion.

To meet the new AVP requirement, "with-oc-name " keyword has been added to the existing override-control CLI command under rulebase configuration. If the override-control with-oc-name CLI is configured in rulebase, only OCs with Override-Control-Name AVP are supported and the OCs without name are rejected.

If Override-Control-Name AVP is received when the override-control CLI command is configured i.e. OC install is supported without OC name, appropriate error is reported in error logs, OC is dropped and OC failure statistics is incremented. Similarly if override-control with-oc-name CLI is configured and OC is received without the name AVP, appropriate error is reported, OC is dropped and OC failure statistics is incremented. On receiving an OC without name, installed OC list (without name) is searched for secondary identification criteria. If no OC with same rule/charging-action/exclude rule list is found, it is installed as a different OC.

Also, for OCs with the name, operator can add rule/charging-action/exclude rule to the existing OC in the same category. That means, the rules can be added to a rule level OC, CA names can be added to a CA level OC, and exclude rules can be added to a wildcard or CA level OC.

OCs received with Override-Control-Name AVP are uniquely identified by the OC name. When the Override-Control-Name AVP is not present in Override-Control AVP, the OCs are identified based on the secondary identification criteria, i.e., the list of rule names, charging-action names, and exclude-rule names as these were the criteria before this feature change.

During rulebase change, the feature to support OC name will be controlled based on the configuration of new rulebase. After rulebase change OC will be accepted as per the CLI configured in new rulebase. This is the only scenario where for a single call session, OC can be installed with both OC name and without OC name.

When software upgrade is done on a standby setup where same rulebase is configured with the CLI override-control with-oc-name , then no calls are dropped and OC installation status will remain the same as before upgrade. If new call is established after upgrade and OC is installed with OC-name then this will be applied on new call.

During the downgrade, OC-name will be dropped and OCs will be recreated assuming Rule/CA/Exclude rule name list as the primary key for unique identification.

Wildcard/CA Level Overrides with Exclude Rule List

The current design allows adding Exclude Rules to a wildcard or CA level OC. In releases prior to 20, whenever a wildcard level override or CA level override is sent after another wildcard or CA override, the two wildcards or CAs were not merged. The gateway considers only the latest override at wildcard level or CA level to be applied for OC. In release 20 and beyond, the two wildcards or the two CAs received will be merged including the Exclude Rule lists defined within. Through this change, all the rules in the Exclude Rule lists under both overrides will be excluded from being applied in OC.

Disabling Override Control

The current implementation of OC does not allow disabling an already enabled/configured OC or reverting few parameters of a previously installed OC. It can only be modified but cannot be completely disabled. In release 20, operator is provided with the flexibility to disable an installed OC or overridden parameters associated with the installed OC.

Disabling OC is supported through the use of a new Diameter AVP "Disable-Override-Control". This AVP indicates that override parameters for the subscriber will be removed completely or per parameter basis. This is a grouped AVP containing the following sub-attributes:

  • Override-Control-Name: Specifies the name of the Override-Control. This AVP may be included more than once if multiple overrides need to be disabled.

  • Disable-Override-Control-Parameter: Specifies the Override Control parameter to be disabled. This AVP may be included more than once if multiple parameters need to be disabled.


Important

Enable/Disable OC is a license-controlled feature. Contact your Cisco account representative for more information.

This feature allows disabling of installed overrides at three different levels:

  • Wildcard Disable: If Disable-Override-Control AVP is received without any OC name or parameters, all installed OCs (with or without name) will be removed.

  • OC level Disable: This level will be supported only for calls where overrides with name have been installed.

    • If OC names are specified in Disable-Override-Control AVP with no parameter specified, all installed OCs with given OC name will be deleted.

    • If Disable OC is received for a call where OC name support is not enabled through the override-control with-oc-name CLI command, and the grouped AVP for disable OC contains OC name, proper error log will be generated.

  • Parameter level Disable: If parameters are specified in Disable-Override-Control AVP, these parameters will be reverted to static values for all the OCs if no OC names are present or for the specified OCs.

    • If OC names are present, overridden values for the given parameters will be removed from the given list of OCs.

    • If no name is present, overridden values for the given parameters will be removed from all the installed OCs.

Limitations:

Checkpointing of Disable OC to standby chassis does not occur. So, if session manager goes down before the Disable OC request has been processed, OC will not be disabled.

Wildcard Support for Override-Control AVP

This feature allows the operator to send partial rule-names, partial charging-action names and partial exclude-rule names through Override-Rule-Name, Override-Charging-Action-Name and Override-Charging-Action-Exclude-Rule-Name AVPs respectively. The rules, charging-actions or exclude-rule names matching the partial string can be overridden or excluded accordingly.

With the previous implementation of Override-Control feature, wildcard is not supported in these existing AVPs. If PCRF want to exclude 100 rules, then including 100 Override-Charging-Action-Exclude-Rule AVPs in CCA message will impact the efficiency and capacity. To address this problem, the Override-Control AVP wildcard support feature is introduced.

The delimiter “<*>” is used to send the partial names over Gx interface. The following string patterns can be added to the Override-Rule-Name, Override-Charging-Action-Name and Override-Charging-Action-Exclude-Rule-Name AVPs:

  • Pattern<*> means, the names start with partial string and end with anything

  • <*> Pattern means, the names start with anything and end with partial string

  • <*> Pattern<*> means, the names contain partial string

For example, Charging-Action-Name: <*>SPDATA01


Important

This feature is backward compatible with releases prior to 21 only when the delimiter “<*>” is not used. If this delimiter is used, it will be considered as the full rule name/charging action name/exclude rule name as the support for partial string does not exist.

Support for Execution-Time AVP

In 21.3 and later releases, the support for Execution-Time AVP allows the overridden parameters to be specified for a rule (static or predefined), for one or all charging actions (using a wildcard), with the ability to exclude certain rules. These overrides are sent by the PCRF using the AVP construct in a CCA or RAR message.

As part of this feature, the P-GW supports the following two new AVPs within the proprietary Override-Control grouped AVP:

  • Execution-Time (AVP code 132025): This AVP is of type Time. It indicates the Unix Epoch at which the provided Override-Control instance takes effect.

  • Override-Control-Pending-Queue-Action (AVP code 132078): This AVP of type ENUM with allowed values FLUSH (0) and RETAIN (1). It indicates the action the gateway takes on the Pending-OC-Queue.

Both the AVPs are included in the Override-Charging-Action-Parameters grouped AVP.

How It Works

The Execution-Time AVP is an optional AVP in the Override-Control grouped AVP, sent in RAR/CCA message by the PCRF. It is valid for Rule-level, Charging-action level, and Wildcard-level OC.

Whenever Override-Control AVP is sent in RAR/CCA message from PCRF, and:

  1. it does not contain the Execution-Time AVP, then the existing OC application procedure is adopted for backward compatibility. In other words, the OC parameter is applied immediately by the PCEF.

  2. it contains Execution-Time AVP which is in the “Past”, then it is treated as if no Execution-Time AVP was sent and the OC parameter is applied immediately by the PCEF.

  3. it contains Execution-Time AVP which is in “Future”, then the PCEF marks the OC as “Pending” and installs the OC when the Execution-Time is reached.

Session Recovery and ICSR

The Pending OCs are recovered on intra/inter chassis session recovery. The PCEF checkpoints Execution-Time using the existing framework that is used for check-pointing of other OC parameters. When the Session Manager restarts or ICSR switchover occurs, timer is started for each of the recovered OC with Execution-Time AVP. The value of this new timer is equal to the time left for the OC to be activated or applied on the call.

If the timer expires during the recovery, then the OC is applied immediately after the recovery.

During downgrade from N to N-1 build, the pending OCs on currently active N chassis are not check-pointed to the standby N-1 chassis.

Flushing the Pending OCs

The PCEF decides whether to flush or retain already pending OCs for a subscriber, based on the presence or absence of the Override-Control-Pending-Queue-Action AVP.

On receiving a new OC (with or without Execution-Time AVP) in a new RAR/CCA message, the PCEF flushes all the previous pending OCs for that subscriber. The PCEF either buffers or applies the newly received OC, based on the presence or absence of the Execution-Time AVP respectively. This behavior is the default behavior.

When the requirement is that the Pending OCs should not be flushed, the new AVP, Override-Control-Pending-Queue-Action, is sent within at least one of the Override-Control AVPs in the RAR/CCA message, as shown in the following figure.

Adding OC in the Pending Queue

The PCEF processes all the instances of Override-Control grouped AVPs received from PCRF in RAR/CCA message. If an Override-Control AVP has an Execution-Time AVP with “Future” time stamp, the PCEF marks it “Pending” for that subscriber. If an OC is received with Execution-Time AVP and there is already an OC pending with same OC identifier, then the newly received OC is merged with the pending OC. The Execution-Time of the merged OC is that of the newly received OC.

The Override-Control grouped AVP received without the Execution-Time AVP, or with Execution-Time already in “Past”, is not added in the list; in other words, it is applied immediately.

The following figure describes the adding of OC in Pending Queue.



Installing the Pending OC

The PCEF also stores the Execution-Time of all such Pending OCs so that, when the Execution-Time of an OC is reached, the OC is applied to the subscriber as described in the following figure.

Limitations

Following are the known limitations and restrictions of the Support for Execution-Time AVP feature:

  • The Execution-Time AVP is supported only for OC without name.

  • The maximum time for which an OC can be buffered is 44 days.

  • There is no hard limit on number of OCs that can be buffered for a subscriber. However, the decision to buffer an OC depends on the availability of the system resources.

  • The OCs with same identifier and different future Execution-Time is merged in the order in which PCEF processes them, and may not be same as the order of occurrence in RAR/CCA. The resultant OC has the Execution-Time of the OC which gets processed at the end.

Configuring Override Control

This section describes how to configure the Override Control feature to override charging and policy parameters for all rules (wildcard) or a specified set of rules or charging actions.


Important

Override Control is a license-controlled feature. A valid feature license must be installed prior to configuring this feature. Contact your Cisco account representative for more information.

Use the following configuration to configure the Override Control feature at rulebase level:


Important

In this release, both Inheritance and the Override Control features are supported. Note that these two features should not be enabled simultaneously. If by mistake, these features are enabled, only Override Control is applied. 

configure 
   active-charging service  service_name 
      rulebase  rulebase_name 
         [  default | no ] override-control [ with-oc-name ] 
         end

Notes:

  • The override-control CLI command will be visible only when the license to configure the Override Control feature is installed.

  • By default, this feature is disabled. If this command is configured, the Override Control feature will be enabled. When enabled, it is necessary to turn off the Inheritance feature.

  • The with-oc-name optional keyword specifies to use OC-name as the unique key to identify an OC for the session. If with-oc-name option is not configured in rulebase, OC will be identified using the Rule/CA and exclude rule as keys. This is the default behavior.

For more information on this command, see the Command Line Interface Reference.

Verifying the Override Control Configuration

To verify your configuration, in the Exec Mode, enter the following command: 

show active-charging subscribers callid <callid> override-control

To verify the Override Control status, in the Exec Mode, enter the following command. The status displays ON when OC is installed and OFF when OC is removed. 

show active-charging sessions all

Monitoring and Troubleshooting the Override Control feature

This section provides information on the show commands available to support this feature.

show active-charging rulebase statistics name <rulebase_name>

The output of this CLI command has been modified to show information related to pending OCs at rulebase-level. Following is a partial sample output: 
show active-charging rulebase statistics name cisco

    Override Control Statistics:
       Total number of Installs Received:                 6
       Total number of Installs Succeeded:                1
       Total number of Installs Failed:                   1
       Install Pending:
         Total:                                           4
         Merged:                                          1
         Flushed:                                         1
         Failed:                                          1
       Total number of Disables Received:                 0
       Total number of Disables Succeeded:                0
       Total number of Disables Failed:                   0
       Total number of Subscribers:                       1

show active-charging service all

The following fields are newly added to the output of this show command:

  • Override Control
    • Supported parameters

      • Charging Parameters

      • Policy Parameters

show active-charging sessions full all

The output of this show command is changed to indicate how many Overrides were received and how many are currently active for the subscriber. The following fields are new in this release:

  • Override Control

    • Installs Received

    • Installs Succeeded

    • Installs Failed

  • Total Override Control

As part of Support for Execution-Time AVP feature, the output of this CLI command has been further modified to show information related to pending OCs at subscriber-level. Following is a partial sample output: 
show active-charging sessions full all
.
.
.
Override Control:
    Installs Received:              2
    Installs Succeeded:             1  Installs Failed:             0
    Install Pending:
      Total  :                      2
      Merged :                      0
      Flushed:                      0
      Failed :                      0
    Disables Received:              0
    Disables Succeeded:             0  Disables Failed:             0
 
No Charging ruledef(s) match the specified criteria
No Firewall ruledef(s) match the specified criteria
 
  Post-processing Rulestats : No Post-processing ruledef(s) match the specified criteria
Dynamic Charging Rule Name Statistics: n/a
Total Dynamic Rules:             0
Total L7 Dynamic Rules:          0
Total Predefined Rules:          0
Total ADC Rules:                 0
Total Firewall Predefined Rules: 0
Total Override Control:          0
Total Override Control Pending:  3

show active-charging subscribers callid <callid> override-control

This command is added to display the override being applied for the subscriber.

show active-charging subscribers callid <call_id> override-control pending

As part of the Support for Execution-Time AVP feature, this new show command has been introduced to check the pending OCs at subscriber-level. Following is a sample output: 
show active-charging subscribers callid 00004e21 override-control pending 
CALLID: 00004e21
Override Control : 
  Rule Name : 
                      qci2
  Charging Parameters:
    Rating Group     : 100
    Offline Enabled  : TRUE
  Execution-Time     : <Day Month DD HH:MM:SS GMT YYYY>
Override Control : 
  Rule Name : 
                      qci1
  Charging Parameters:
    Rating Group     : 100
    Offline Enabled  : TRUE
  Policy Parameters:
    QCI              : 4
    ARP Byte         : 81
    MBR UL           : 25000
    MBR DL           : 13000
    TOS UL           : af23 (22)
    TOS DL           : af23 (22)
    NEXTHOP ADDR     : 10.20.10.10
    CF State       : 0
  Execution-Time     : <Day Month DD HH:MM:SS GMT YYYY>