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.

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.

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.

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.

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.

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

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.

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.

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

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

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

• Override Control

  • Supported parameters

    • Charging Parameters

    • Policy Parameters

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

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

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