In practical use, many policies are very similar, having only small differences between them. Policy tables are an available option in the policy wizard. A policy table abstracts the differences between related policies.
Using a policy table instead of creating many similar policies makes the tasks of adding new policies, modifying existing sets of policies, and checking consistency among related policies simpler and less prone to error.
Every column has a definition that contains a name, data type, and indication if the column is a key column. Every entry in the column must have the same data type. Every table must have a key column. Any data associated with a message, including fields (such as a quota or RAT type) and sub-fields (such as a user account ID or tier name), can be used as a key.
These are used to obtain the value from the policy context when using the policy table to look up a row.
The contents of the table cells. (Blank cells are not allowed in a policy table.)
Each row in a policy table can be thought of as a scenario, and each row can replace a policy. Substitutions in policy condition and action parameters can include the values in a specified policy table.
APN | Install | Remove |
---|---|---|
apn1.com | pcc_rule_1 | pcc_default_1, pcc_basic |
apn2.com | pcc_rule_2 | pcc_default_2, pcc_basic |
apn3.com, apn4.com | pcc_rule_1 | pcc_default_1 |
apn5.com, apn6.com | pcc_rule_2 | pcc_default_2 |
Figure 1 shows how to define the key column for this example in the policy wizard using the variable Request.CalledStationId.
Each policy can have zero or more policy tables. To support the use of multiple policy tables, policies refer to a policy table using an alias. Each policy can use a different alias for the same policy table. For example, a policy table named PCC rules to install and remove based on APN can be referred to in a policy as pccrules. Policies can use table cells addressed as table_name.column_name.
The following policy rule uses the defined policy table. The italicized text represent substitutions. The table references begin with pccrules.
use table ‘PCC rules to install and remove based on APN‘ called ‘pccrules‘ where the request is modifying an existing session and where the session is a credit control session and where the requested quota is one of Bucket Exceeded,OS_no_TV_volume and where the quota usage reporting reason is one of validity time expired and where the user Custom1 matches one of 101 install pccrules.install PCC rules for flow remove pccrules.remove PCC rules send notification to syslog with `100;{User.MSISDN};{User.AccountId};{User.IMSI};{Session.IMEI};{Date} {Time}; Info GalacTel : You have a new 500 minutes to enjoy your mobile Internet offer. Beyond that the flow will be reduced.; {Date} {Time};{Date} {Time};{User.Custom1};{User.BillingDay}` and severity `Emergency` accept message
The use of policy tables is not required. The decision to use a policy table may arise after you have created a series of production policy rules, if you notice that the policies differ only in a few small ways.
You can also use virtual policy tables to test policy table changes before you deploy the changes on the network. Policy tables that are used by virtual policy tables are subject to additional validations. For information about validations for policy tables used by a virtual policy table, see About Virtual Policy Tables.