This command enables
or disables Override Control (OC) feature. The Diameter capability exchange
message should indicate support for OC feature when this CLI command is
enabled.
Product
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.
ACS
Privilege
Security
Administrator, Administrator
Mode
Exec > ACS
Configuration > Rulebase Configuration
active-charging service
service_name
> rulebase
rulebase_name
Entering the above
command sequence results in the following prompt:
[local]host_name(config-rule-base)#
Syntax
Syntax Description
[ default | no ] override-control[ align-with-gor | with-oc-name [ align-with-gor ]]
default
Configures this
command with its default setting.
Default: Disabled
In 20 and later releases: 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.
no
If previously
enabled, disables Override control in the current rulebase.
align-with-gor
Resolves ambiguity
when same ruledefs are defined in multiple Group of Ruledefs.
with-oc-name
This optional
keyword specifies to use OC-name as the unique key to identify an OC for a
subscriber session.
Default: Disabled
In releases prior to
20, PCRF uses a combination of the following key parameters for identification
of OC.
-
Rule names
-
Charging-action
names
-
Exclude-rule
names
There is no unique
OC name or ID to identify the OC for a particular subscriber session. In
release 20, a new Diameter AVP "Override-Control-Name" is defined in the
Override-Control grouped AVP. This OC name is used as the unique key to
identify OC for any further updates like OC modification or deletion.
This keyword
"with-oc-name"
is added to the
override-control CLI command to support
Override-Control-Name AVP in the Override-Control AVP. 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 AVP 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. Then 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 AVP, 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. Any new call which is
established after upgrade and OC is installed with-oc-name then this will be
accepted and applied on new call. Any calls which were established pre-upgrade
will accept OC without name and will be identified uniquely by
rule/charging-action/exclude rule.
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.
Usage Guidelines
Use this command to
enable or disable Override Control feature and also specify to use Rule/CA list
as unique key to identify OC for a session. This feature is available at the
rulebase level and is license controlled. The Diameter capability exchange
message should indicate support for Override control feature when this CLI
command is enabled.
Inheritance feature
does not support overwriting parameters at Rule level and charging action level
and supports exclusion of only 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.
Important:
In this release,
both Inheritance and the Override Control features will be supported. Note that
both these two features should not be enabled simultaneously. If by mistake,
both these features are enabled, only Override Control is applied.
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 effect existing calls.
Override Control
feature allows the customer to dynamically modify the parameters of static or
predefined rules with parameters sent by PCRF over the Gx interface.
When multiple
overrides are received from PCRF, the following is the priority in which they
are applied:
- Rule level override control
- Charging action level
override control
- 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.
Feedback