The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
In CPS, a 'Service' it what is assigned to a subscriber (in USuM) to define how that subscriber is treated. Some basic examples of services would be a 'GOLD' user might get a high upload/download speed whereas a 'BRONZE' user would get a low one. Other examples would include having one type of user be redirected to a portal when their Quota is exhausted whereas another type would only have their speed downgraded.
As the Service maps as closely as possible to how a Service Provider wants to classify their customers, the Service in CPS is flexibly defined to allow configuration at different levels.
A service is effectively just a 'code' to label the service and a collection of Service Options which contain the definition of what a service 'is'.
What a Customer Service Representative assigns to a subscriber to describe the user's plan.
Multiple services can be assigned to a single subscriber
If multiple services are assigned to a subscriber, the service options are combined between all assigned services.
Therefore, there is no logical difference between a subscriber with:
Provides the concrete values which can be re-used for multiple services.
For example, one subscriber might have one service option which describes the values for 10 MB Upload/Download speed and another subscriber which describes 1 MB Upload/Download speed. Continuing the example from above, 10 MB could be assigned to a GOLD service and 1 MB could be assigned to BRONZE.
What values are configurable in a Service Option are setup by the Use Case Template object. The Use Case Template can provide defaults to the Service Option or hide values in Service Configuration objects not necessary for certain use cases.
If a Service Configuration's value is not defined in a Service Option, the value from the Use Case Template is used.
The low-level configuration objects used by the CPS code to drive functionality. These objects are used to drive functionality in the system. The whole point of the Service > Service Option > Use Case Template chain of functionality is to flexibly configure these Service Configuration objects which the code uses to drive system logic.
These objects are defined by the CPS code.
Types of service configurations:
PriorityConfiguration: Only one allowed to be active at a time. If multiples priority configurations are added, highest priority is used.
These are used in cases where only a single value makes sense. For example, when sending an 'Accept' message, we can only have one template and multiples do not make sense.
Objects of this type always have a priority field. If multiple priority configurations are added, the highest priority object is used.
Example: AccessAcceptConfiguration, RegisterMacAddress
GroupConfiguration (most common): Only 1 per 'Group Name' are allowed to be active. If multiple configurations are added highest priority per 'Group Name' is used.
These are used in cases where a configuration only makes sense for a single 'group' (key). For example, if it makes sense to control the upload/download speed based on the network type (cell, Wi-Fi, and so on) a service configuration to control network speed with a group set for cell/Wi-Fi would allow multiple service configurations to be added.
Note | RADIUS-based policy control is no longer supported in CPS 14.0.0 and later releases as 3GPP Gx Diameter interface has become the industry-standard policy control interface. |
These objects always have a group field as well as a priority field. For each unique group value, the highest priority is used.
Example: IsgServiceConfiguration, All Diameter Configurations, OneTimeUsageCharge
ServiceConfiguration: Multiples allowed. If multiple configurations are added, all are used. 'Modify' functionality in PB for Use Case Options/Service Options can override values conditionally.
Example: AutoChargeUpAccounts, AutoProvisionQuota, BalanceRateConfiguration
Use case templates are the building blocks of the Cisco Policy Builder Service Model architecture.
Defines the Service Configuration objects to be set by a Service Option.
Provide default values and/or hide values which do not need to be set by a use case
Optionally, contains 'Initiators' (Conditions) which define when the template is active.
Created by an advanced user (usually Engineering/AS).
Makes Service Option and Service creation easier.
For example, a Use Case Template set up to create different upload or download speeds includes a 'DefaultBearer' QoS Service Configuration object. The user creating a Use Case Template can default and/or hide the values for 'ARP' and other values not directly related to upload or download speed. This allows the creation of the Service Option to be much simpler.
A copy of the Use Case Options is created while copying a Use Case Template.
A new parameter -DshowUseCaseInitiatorTabFirst can be added in pb.conf (/etc/broadhop/pb/) file on pcrfclient01/02 to re-order the Use Case Template and Use Case Option tabs. This parameter also renames Use Case Template and Use Case Option tabs to Actions tab.
By default, -DshowUseCaseInitiatorTabFirst is set to true (does not required to be added in pb.conf file by default).
If set to true, the tabs will be displayed in the following order:
For backward compatibility, the configuration parameter -DshowUseCaseInitiatorTabFirst in pb.conf (/etc/broadhop/pb/) file on pcrfclient01/02 can be set to false.
This parameter also renames Actions tab back to Use Case Template and Use Case Option tabs.
A child of Use Case Template used to add or modify Service Configurations objects when certain conditions occur.
Provides a way to separate Service Configurations within a use case based on conditions.
Contains the same functionality of a Use Case Template.
Adds or modifies new service options from parent Use Case Template.
While copying a Use Case Option, all the corresponding children Use Case Options get copied as well.
For example, if a user's upload or download speed should be decreased when they are out of quota, a Use Case Option is added with a condition indicating the user is out of quota. The service configurations in the use case options can have a higher priority than those in the use case template to override the normal values. The service option then allows setting both the normal upload or download speed and the upload or download speed when the user is out of quota.
The following diagram illustrates how a 'Service Configuration' object called PredefinedRule can be flexibly configured as part of a service. For those unfamiliar, a predefined rule is just an identifier sent to PCEF which controls a users upload or download speed (QoS) among other things.
In this case, the service gold is assigned a Service Option called 10MB Fair Use. This service option results in a rule being passed to PCEF called 10MB by default and switching the rule to 5 MB when the users quota is depleted.
Notice that it would be easy to add another service option for 20MB Fair use, and so on.
The Use case template defines the low-level information that a 'PredefinedRule' be created of priority five. This rule is default and always present. Additionally, a Use Case Option defaults that another PredefinedRule of priority ten be added. The higher priority results in the new rule name being switched when quota is depleted.
Instead of using a Use Case Option to define what happens when a user is depleted, they set up another Use Case Template.
This could have an advantage if a customer wanted services for a large combination of values (10 MB default with any combination of 1 MB - 9 MB depleted speed). Also, to support a use case where the end user could be independently assigned a default speed and a depleted or downgrade speed. A service for 10 MB default and 5 MB depleted would also be functionally equivalent.
This flexibility in the service model allows mapping CPS closely to the Service Providers concept of a service.
The following screens set up the example seen in the previous section. Service 'Gold' with two separate service options. The 'Predefined Rule' that is part of the setup is just an example, so not all fields on the Predefined Rule are described.
For example, a 'Rule Name' is a label and can be assigned to a subscriber on a PCEF. PCEF is responsible for defining what the rule 'means'. In this example, we make the assumption that PCEF has rules set up for '10_MB' and '5_MB' which control the users QoS (Quality of Service - effectively upload or download speed) to 10 MB upload or download and 5 MB upload or download respectively.
Note | The subtle difference between 10 MB and '10_MB' is to ensure that it is clear which name is used for internal reference and which is sent to PCEF. |
The following parameters can be configured under Service:
Parameter |
Description |
||
---|---|---|---|
Code |
This is what is saved on the subscriber. It defaults to 'default'. This value is the link between the Services assigned a subscriber in Control Center and the Service in Policy Builder. This value is not updated if existing users have it assigned, as the 'link' is be broken. Instead, the name is updated. |
||
Name |
This is the name displayed in Control Center. |
||
Enabled |
If this value is unchecked, the service is not evaluated by the Policy Engine and is not displayed in Control Center. Default value is checked (true). |
||
Suppress in Portal |
If this value is checked, this Service is not displayed in the Portal. This is specific for SP Wi-Fi call flows. Default value is unchecked (false).
|
||
Balance Service |
If this value is checked, the Service runs through balance processing. This results in one database read or write against the balance database. Performance improves (due to fewer database read or writes). For the services which don't rely on Balance or Quota, this value is unchecked. Default value is checked (true). |
||
Add to Sub Accounts |
If this value is checked, this service is considered to be also assigned to any 'subaccounts' associated to the main subscriber. This is useful if you had a family plan where the QoS is controlled at the main subscriber level and 'trickles down' to the family sub accounts rather than being set at each individual level. Default value is unchecked (false). |
This table displays a read-only version of the service options associated to the Service. Service Options can be added or removed to the service.
Parameter |
Description |
---|---|
Name |
The name of the associated Service Option. |
Use Case Template |
The name of the associated use case template. |
Add |
Allows adding another Service Option to this service. The Add dialog shows the Use Case Template > Service Option hierarchy on the left and a preview of the parameters set by the Service Option or Use Case Template on the right. |
Remove |
Removes a Service Option from the Service. |
Up or Down Arrow |
Allows moving a Service Option up or down. This only affects the ordering of service options in the list and does not functionally affect the resolution of services. |
This hyperlink shows a consolidated list of the Service Configuration Parameters from the Use Case Template and Service Options. This view is useful for simple service options or use case templates. However, since it does not show the distinction between different Service Configuration objects. Hence, it can be difficult to read for more complicated configurations.
The service option dialog allows setting the concrete values for service configuration parameters used in the Use Case Template. The groups under service options are Use Case Templates. Adding a new Use Case Template adds a new group under Service Options so you can provide concrete values for the Use Case Templates.
The following parameters can be configured under Service Option:
Parameter |
Description |
||
---|---|---|---|
Name |
This is the name of the service option which is referenced by the Service. |
||
Use Case Template |
This is a link that allows quickly seeing the associated Use Case Template and going straight to this Use Case Template.
|
||
Service Configurations |
|
||
PreDefinedRule Parameters |
These are the parameters being overridden from the use case template. |
||
Add |
This allows adding a parameter from the Use Case Template even if it is not marked as 'Allow Override'. It also allows customizing a parameter that didn't exist previously in the Use Case Template or was removed from the Service Option. |
||
Remove |
This allows removing a parameter from the Service Option. This means that the value specified for the Use Case Template's version of this parameter is used. |
||
Display Name |
This column shows the 'Display Name' of the parameter. This name can be updated by either the Service Option or the Use Case Template to make it clearer for users to understand what this value does. The 'true' name of the field can be seen by hovering over the cell. |
||
Value |
This is the value of the parameter which should be set. If there is a value set in the 'Pull Value From…' column, this value is used as the default and overridden with the 'Pull Value From…' information. |
||
Pull Value From... |
This allows setting this value dynamically through AVP's, Custom Reference Data or the 'Policy State'. For more information, refer to Table 2. |
Parameter |
Description |
||
---|---|---|---|
Subscriber AVP Code |
This allows pulling values from AVPs on the subscriber. This field now also supports AVP's on the subscriber's session and 'Policy Derived AVP's added in policies. |
||
Custom Reference Data Column |
This allows pulling the value from the Custom Reference Data table's column specified.
|
||
Bind to Session/Policy State |
This allows pulling the value from the state of the system. This uses any of the preconfigured 'Policy State Data Retrievers' that are plug-in code that know how to get a certain value from the system. |
||
Dynamic Reference Data Key |
This allows pulling the value from other reference data configuration (Policy Builder or CRD, for example, Account Balance Templates) as value for the use case attribute. Currently, only Account Balance Template type attributes are supported. The intended Account Balance Template code can be configured in the text field. Both Policy Builder and CRD Balance templates can be pulled using this field. Policy Builder templates are checked first, if not found then CRD templates are searched. |
Use case templates form the basis of a service and are in general more complicated than creating a service or service option. For more information on creating Use Case Templates, contact your Cisco Technical Representative.
The following parameters can be configured under Actions (Use Case Template) tab:
Use Case Initiators are groups of conditions that indicate whether or not the Service Configuration objects within this use case template are used. If no use case initiators are specified, the Service Configuration objects will always be added.
The following parameters can be configured under the Use Case Initiators tab.
The following sections describe the input variables that can be configured for the following conditions:
This condition indicates that a custom reference data table exists in the Policy Builder configuration with one or more Column Names mapped to a unique Attribute Value pair. Any column marked as Use in conditions can be used.
In order to protect a customer reference column's integrity, once it has been created and published, it cannot be changed.
The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
tableName |
The custom Reference Table Name. |
code |
The custom AVP column Name. |
value |
The custom AVP column’s value. |
This condition indicates that a custom reference data table exists in the Policy Builder configuration with one or more Column Names not mapped to a unique Attribute Value pair. Any column, which is not marked as Use in conditions cannot be used.
In order to protect a customer reference column's integrity, once it has been created and published, it cannot be changed.
The input variables that can be exposed for this condition in the Policy Builder GUI are the same as described in A Customer Reference Data AVP Exists.
This condition indicates that a valid Diameter Gx 3GPP session exists in the Policy Builder configuration for a given subscriber. The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
msisdn |
The subscriber identity in the Subscription-Id AVP being msisdn. |
imsi |
The subscriber identity in the Subscription-Id AVP being imsi. |
framedIpv6 |
The Ipv6 prefix allocated for the user. |
framedIp |
The Ipv4 address allocated for the user. |
sessionId |
The unique Id of the session generated by PCEF |
commandCode |
The unique Command Code to identify the Gx Request/Response Type – CCR/CCA or RAR/RAA. |
requestType |
The type of the request (initial, update, termination). |
destRealm |
The destination realm derived from the Origin-Realm of CCR-I and used in PCRF RAR request. |
destHost |
The destination host derived from the Origin-Host of CCR-I and used in PCRF RAR request. |
ratType |
Identifies the radio access technology that is serving the UE. |
appId |
The Unique Application Identifier to identify the Gx Session. |
mccmnc |
Concatenated value of Mobile Country Code (mcc) and Mobile Network Code. |
calledStationId |
The address the user is connected to. For GPRS the APN. |
lac |
Extracted from either the 3GPP-User-Location-Info AVP, which provides details of where the UE is currently located, or the RAI AVP, which contains the Routing Area Identity of the SGSN where the UE is registered. |
rac |
Extracted from either the 3GPP-User-Location-Info AVP, which provides details of where the UE is currently located, or the RAI AVP, which contains the Routing Area Identity of the SGSN where the UE is registered. |
sac |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
ci |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
tgppRatType |
3GPP-RAT-Type AVP. Indicates the Radio Access Technology that is currently serving the UE. |
eventTriggers |
NA |
outofCredit |
An OUT_OF_CREDIT trigger reported by Event-Trigger AVP. |
cgi |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Ecgi |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Tai |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Sai |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Tac |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Eci |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
Imeisv |
International Mobile Equipment Identifier along with Software Version. Extracted from User-Equipment-Info-Value AVP. |
networkRequestSupport |
Network-Request-Support AVP. Indicates whether or not the UE and access network supports the network requested bearer control mode. |
Nai |
The Network Access Identifier. |
bearerControlMode |
Bearer-Control-Mode AVP. Indicates the PCRF selected bearer control mode. |
sgsnIpAddress |
3GGP-SGSN-Address AVP. Indicates the Ipv4 address of the SGSN. |
ipcanType |
IP-CAN-Type AVP. Indicates the type of Connectivity Access Network in which the user is connected. |
Mnc |
Extracted from either the 3GPP-User-Location-Info AVP, which provides details of where the UE is currently located or the RAI AVP, which Contains the Routing Area Identity of the SGSN where the UE is registered. |
Mcc |
Extracted from either the 3GPP-User-Location-Info AVP, which provides details of where the UE is currently located, or the RAI AVP, which contains the Routing Area Identity of the SGSN where the UE is registered. |
Rai |
Extracted from either the 3GPP-User-Location-Info AVP, which provides details of where the UE is currently located, or the RAI AVP, which contains the Routing Area Identity of the SGSN where the UE is registered. |
qosUpgrade |
Qos-Upgrade AVP. Indicates whether the SGSN Supports the QOS Upgrade or not. |
sgsnIpv6Address |
3GPP-SGSN-IPv6-Address AVP. Indicates the Ipv6 address of the SGSN. |
targetApn |
Called-Station-Id AVP. The same as called Station Id condition. |
globalCiCode |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
globalAreaCode |
Extracted from 3GPP-User-Location-Info AVP. Provides details of where the UE is currently located. |
imeiTac |
Same as Imeisv extracted from User-Equipment-Info-Value AVP. |
Mac |
Extracted from User-Equipment-Info-Value AVP. The identification and capabilities of the terminal. |
Eui64 |
Extracted from User-Equipment-Info-Value AVP. The identification and capabilities of the terminal. |
modifiedEui64 |
Extracted from User-Equipment-Info-Value AVP. The identification and capabilities of the terminal. |
qosNegotiation |
Qos-Negotiation AVP. Indicates if the PCRF is allowed to negotiate the QoS. |
Offline |
Offline AVP. Defines whether the offline-charging interface from the TDF shall be enabled. |
Online |
Online AVP. Defines whether the offline charging interface from the TDF shall be enabled. |
Ipv4AnGWAddress |
IPv4 Gateway Address. |
Ipv6AnGWAddress |
IPv6 Gateway Address. |
mpsEpsPriority |
Value of the mspEpsPriority set. |
tgppMsTimeZone |
3GPP-MS-TimeZone AVP. Indicates the offset between universal time and local time in steps of 15 minutes of where the MS currently resides. |
accessNetworkChargingAddress |
Access-Network-Charging-Address AVP. Indicates the IP Address of the network entity within the access networks performing charging (e.g. the GGSN IP address). |
usageReportET |
NA |
Meid |
Extracted from User-Equipment-Info-Value AVP. The identification and capabilities of the terminal. |
Bsid |
Base Station Identifier. |
chargingCharacteristics |
3GPP-Charging-Characteristics AVP. The Charging Characteristics applied to the IP-CAN session. |
chargingCharacteristicsBits |
Extracted from 3GPP-Charging-Characteristics AVP. The Charging Characteristics applied to the IP-CAN session |
appName |
Application Name. |
This condition indicates that a valid Diameter Gy v8 3GPP session exists in the Policy Builder configuration for a given subscriber. The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variables |
AVP Used/Description |
---|---|
Msisdn |
Subscription-Id-Data AVP. The identification of the subscription (IMSI, MSISDN, etc.). |
sessionId |
The unique Id of the session generated by PCEF. |
requestType |
CC-Request-Type AVP. The type of the request (initial, update, termination). |
requestNumber |
CC-Request-Number AVP. The number of the request for mapping requests and answers. |
destRealm |
Destination-Realm AVP. The destination realm derived from the Origin-Realm of CCR-I and used in PCRF RAR request. |
destHost |
Destination-Host AVP. The destination host derived from the Origin-Host of CCR-I and used in PCRF RAR request. |
ratType |
3GPP-RAT-Type AVP. Indicates the Radio Access Technology is currently serving the UE. |
appId |
Auth-Application-Id AVP. Used to advertise support of the Authentication and Authorization portion of an application. |
ggsnIpAddress |
GGSN-Address AVP. PGW Address Used. |
Apn |
Called-Station-Id AVP. Access Point Name Network Identifier. |
sgsnMccmnc |
3GPP-SGSN-MCC-MNC AVP. Serving node PLMN Identifier. |
userLocationInfo |
3GPP-User-Location-Info AVP. User Location Information. |
sgsnIpAddress |
SGSN-Address AVP. S-GW Address used. |
sharedBucketReservationStatus |
A boolean that indicate whether or not the sharedBucketReservation Status is set. |
selectionMode |
3GPP-Selection-Mode AVP. APN Selection Mode. |
chargingCharacteristics |
3GPP-Charging-Characteristics AVP. The Charging Characteristics applied to the IP-CAN session. |
charingRuleBaseName |
Charging-Rule-Base-Name AVP. Charging Rule Base Name. |
eventTimeStamp |
Event-Timestamp AVP. Corresponds to the exact time the accounting is requested. |
chargingCharecteristicsBits |
Extracted from 3GPP-Charging-Characteristics AVP. The Charging Characteristics applied to the IP-CAN session. |
appName |
Application Name. |
chargingID |
3GPP-Charging-Id AVP. Charging ID. |
userName |
User-Name AVP. Contains the identification of the user. |
The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
Connected |
A Boolean, which indicates whether a successful Sh Connection between PCRF and HSS is established, and a success Response (Diameter Result Code 20001) was received for the Sh requests (UDR/SNR). |
This condition indicates that a valid Diameter Sy v11 session exists in the Policy Builder configuration for a given subscriber.
The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
destRealm |
Destination realm for Sy. |
destHost |
Destination host for Sy. |
failureReason |
The reason for failure in case Sy session is not established due to error (Last error code only). |
destQueue |
Destination queue (Internal field to know which policy director instance pick the request for processing). |
retryTime |
Retry timer in case connection fails. |
lastSLReqType |
Last spending limit request type. |
lastSyResultCode |
Last Sy result code. |
syCountersIdentifierAndStatus |
Sy counter identifier and status. |
subscriberAccState |
Subscriber account status. |
slaReceived |
A Boolean, set to true when a successful SLA-Initial is received. |
sessionId |
The unique id of the session. |
connected |
A Boolean, which indicates whether a successful Sy peer connection is established or not. |
This condition indicates that a custom policy AVP that has been derived out of PolicyState exists in the system. The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
code |
A derived AVP Name from the PolicyState. |
value |
A derived AVP value from the PolicyState. |
The following AVPs are treated as Policy-Derived AVPs:
This condition indicates that a custom policy AVP that has been derived out of PolicyState does not exist in the system.
The input variables that can be exposed for this condition in the Policy Builder GUI are the same as those described in A Policy Derived AVP Exists.
This condition indicates APN bearer details as received in ADTM (Advanced Dynamic Traffic Management) attribute exists in PCRF. The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
stage |
Stage string as received in ADTM Attribute notification from UDC FE. Valid value is string. |
ackMode |
Acknowledge mode QCI as received in ADTM Attribute notification from UDC FE. Valid value is an Integer. |
unackMode |
Unacknowledge mode QCI as received in ADTM Attribute notification from UDC FE. Valid value is an Integer. |
logicalAPN |
Logical APN string as received in ADTM Attribute notification from UDC FE. Valid value is string. |
frontEndId |
Front End ID string as received in ADTM Attribute notification from UDC FE. Valid value is string. |
priority |
Priority value as received in ADTM Attribute notification from UDC FE. Valid value is an Integer. |
This condition indicates no APN bearer details exist in ADTM (Advanced Dynamic Traffic Management) attribute exists in PCRF. The input variables that can be exposed for this condition in the Policy Builder GUI are the same as described in An APN Bearer Details exists.
This condition indicates that a valid network session exists in the Policy Builder configuration for a given subscriber. The network session exists irrespective of the interface type – Gx/Gy/Sh/Sy.
The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
Mac Address |
The mac address present in the session. |
User Id |
User Identifier – Can be msisdn or extracted from Network Access Identifier. |
Framed IP |
Framed-IP-Address AVP. The Ipv4 address allocated for the user. |
Start Time |
When the session starts. |
Access Type |
How the subscriber is accessing network. |
Imsi |
The subscriber identity in the Subscription-Id AVP being imsi. |
Msisdn |
The subscriber identity in the Subscription-Id AVP being msisdn. |
Cell Site Id |
The ID of the cell tower. |
End Time |
If the session is set to end, this gets set. |
Framed IPV6 Prefix |
Framed-IPv6-Prefix AVP. The Ipv6 prefix allocated for the user. |
Msbm Initialized |
NA |
Credential Id |
The Subscriber Profile Repository credential. |
Spr Version |
Version loaded from SPR in case an update is needed. |
Current Session Duration |
How long the session has been going. |
Next Evaluation Date |
The time when CPS will wake itself up and re-evaluate the session if another message is not received. |
Expiration Date |
Used on soft delete to note when the session should be cleaned up |
This condition indicates that a valid network session does not exist in the Policy Builder configuration for a given subscriber. The network session does not exist irrespective of the interface type – Gx/Gy/Sh/Sy.
The input variables that can be exposed for this condition in the Policy Builder GUI are the same as described in There Exists a Network Session.
This condition provides option to check for total of ACK mode, UNACK mode and combined for the subscriber across all the existing APNs.
The following condition input variables can be exposed in the Policy Builder GUI:
Condition Input Variable |
AVP Used/Description |
---|---|
totalAckMode |
Total ACK mode bearers (count) across all existing APNs for a subscriber. Valid value is an Integer. |
totalUnAckMode |
Total UNACK mode bearers (count) across all existing APNs for a subscriber. Valid value is an Integer. |
totalCount |
Total number of bearers (count) across all existing APNs for a subscriber. Valid value is an Integer. |
The documentation tab allows writing notes about the implementation which can be referred to later.
Custom Reference Data tables allow defining custom derived data for your installation and making decision based upon that data.
For example, a customer may not want to directly assign each subscriber a service so they get the appropriate QoS, instead, they want to derive the QoS based on data we get from the subscribers session. Custom Reference Data tables are the way to do that. Then (as per the previous section) we can wire the derived data directly into the service with the “Bind Field…” or “Pull Value From…” options.
The following screens have a simple example setup. The example is that we want to derive the PCEF Rule Name based on the users APN (Access Point Name) and RAT (Radio Access Technology) name.
The logic is as follows:
APN |
RAT |
Rule Name |
Rule Name Depleted |
---|---|---|---|
Cisco |
3G |
10_MB |
5_MB |
Cisco |
Wi-Fi |
20_MB |
5_MB |
Cisco |
* |
5_MB |
1_MB |
CiscoTest |
3G |
1_MB |
5_KB |
CiscoTest |
Wi-Fi |
2_MB |
50_KB |
* |
* |
1_MB |
500_KB |
The * (asterisk) can be read as a wildcard, but the table should match the 'most specific' entry. So, if my APN and RAT are Cisco and 3G, match the first row, not the 3rd row (Cisco, *) or the last row (*,*).
Note | These values are for example purposes only. Things like the RAT type value have been simplified to make the example easier to understand. |
Note | RADIUS-based policy control is no longer supported in CPS 14.0.0 and later releases as 3GPP Gx Diameter interface has become the industry-standard policy control interface. |
Search table groups allow grouping multiple Custom Reference Data Tables together logically, only executing the searching when needed. It also allows ordering the execution of tables so that tables can reference output of one table group in another to provide consistent and expected results. Additionally, Search Table Groups allows multiple different tables to populate the same AVPs in different ways.
The following parameters are configured under Search Table Group:
Parameter |
Description |
---|---|
Name |
The name of the Search Table Group. |
Evaluation Order |
The order in which groups get evaluated, starting with 0 and going higher. |
Results Columns |
|
Table Search Initiators (OR Together) |
This section controls whether or not the Search Table Group and all tables below will be executed. When you add multiple Initiators to the Search Table Group, the search is activated when ANY one of these initiators are true, as indicated by the caption “(OR Together)”. For more information, refer to table in section Use Case Initiators. |
Policy Builder can be thought of as defining the 'schema' for the Custom Reference Data and the Control Center is responsible for filling out the schema.
Note | Cisco recommends creating Custom Reference Data Tables under Search Table Groups. This allows you to specify the order in which the tables are searched and provide the default values if nothing is found. It is possible to re-parent a Custom Reference Data Table to another Search Table Group. |
The following parameters can be configured under Custom Reference Data Table:
Parameter |
Description |
---|---|
Name |
This is the name of the table that is stored in the database. It must:
For example, logical_apn = GOOD, logicalAPN = BAD, no_spaces. |
Display Name |
This is the name of the table that is displayed in Control Center. |
Cache Results |
This indicates whether the tables are cached in memory. This must be checked for production. |
Activation Condition |
This is the Custom Reference Data Trigger, which must be true before evaluating this table. This can be used to have multiple tables create the same data depending on conditions or to improve performance if tables are not required to be evaluated based on an initial condition. |
Svn Crd Data |
When enabled, indicates that the CRD table is an SVN CRD table and CRD data for the table is fetched from CRD CSV file present in SVN data source. When disabled, indicates that the CRD table data needs to be fetched from Mongo database. |
Best Match |
If checked, look-ups occur within a CRD table in the following order:
For more information, refer to Best Match. |
Evaluation Order |
This indicates the order the tables within the search table group should be evaluated. Starting with 0 and increasing. |
Columns |
Columns correspond to the schema for each column you are creating for this custom reference data table.
|
Valid Values |
These are the valid values which are allowed in Control Center (creates a list box).
|
Validation |
The validation set here is checked by the Control Center before allowing a row to be added.
|
Runtime Binding |
|
CRD best match uses a hierarchical structure to perform match. The hierarchical structure is based on the input columns that is, key columns. The order of the input column is important in this hierarchy.
The data in the CRD table is cached in memory according to the hierarchy described in the following section:
Values in the first column are the root of the hierarchy. Number of unique values in the first column creates those many hierarchies. Then under the root, the values of the second key column similarly create those many children, and so on, and so forth, for other columns in the order.
While performing the best match, the value for the first column is used to select the root of the hierarchy. Once the root is selected, then the next match is performed only under the selected hierarchy so on, and so forth, for the children. At any level, first exact match is performed, if that fails then the pattern match is performed. Once the root or the child is selected, next search for the remaining column is restricted only to that hierarchy.
For example, if there are four columns in a best match table that is, {A,B,C,D} out of which key columns are {A,B,C} and output column is D and the table has the following values:
A |
B |
C |
D |
---|---|---|---|
1 |
2 |
3 |
4 |
1 |
* |
3 |
5 |
1 |
* |
* |
6 |
* |
2 |
3 |
7 |
This results in the hierarchy as follows:
{1= {2= {3=4} {*= {3=5} {*=6} {*= {2= {3=7}
In the hierarchy, following input {4,6,3} results in no output. 4 matches "*" hierarchy thereby restricting the next input key to have only value 2 and the other key to have only value 3.
Regex Example:
Regex can be assigned priority by using numbers such as, "match1=" instead of "match=". The higher the number, higher is the priority.
Test1 |
"a" |
"b" |
"*" |
Test2 |
"a" |
"b" |
"c" |
Test3 |
"*" |
"b" |
"d" |
Test4 |
"*" |
"*" |
"*" |
Test5 |
"a" |
"c" |
"*" |
Test6 |
"*" |
"*" |
"7" |
Test7 |
"a" |
"match=[a-zA-Z]" |
"*" |
Test8 |
"a" |
"7" |
"match=[a-zA-Z]" |
Test9 |
"a" |
"match=[a-zA-Z]" |
"1" |
Test10 |
"a" |
"match=[a-zA-Z]" |
"2" |
Test11 |
"Internet" |
" match=P03.*" |
"2001" |
Test12 |
"Internet" |
"match3=P03-Sy.*" |
"2001" |
Test13 |
"Internet" |
"match2=P03-S.*" |
"2001" |
Test14 |
"Internet" |
"match2=P03-[abc].*" |
"2001" |
Test15 |
"Internet" |
"match1=P03-.*" |
"2001" |
Test16 |
"Internet" |
"match3=P03-Gy.*" |
"2001" |
("a", "b", "4") |
("Test1") |
("a", "b", "c") |
("Test2") |
("7", "b", "d") |
("Test3") |
("7", "b", "e") |
("Test4") |
("a", "c", "4") |
("Test5") |
("a", "c", "7") |
("Test5") |
("a", "3", "7") |
("Test6") |
("a", "dd", "7") |
("Test6") |
("a", "7", "7") |
("Test6") |
("a", "W", "79") |
("Test7") |
("a", "7", "a") |
("Test8") |
("a", "W", "1") |
("Test9") |
("a", "W", "2") |
("Test10") |
("Internet", "P03", "2001") |
("Test11") |
("Internet", "P03-Sy", "2001") |
("Test12") |
("Internet", "P03-S", "2001") |
("Test13") |
("Internet", "P03-a", "2001") |
("Test14") |
("Internet", "P03-", "2001") |
("Test15") |
("Internet", "P03-Gy", "2001") |
("Test16") |
A custom reference Data Trigger is group of conditions that can be used to decide whether to evaluate a table or not. This can be used to derive the same data in different ways depending on conditions.
Refer to Use Case Initiators as it is identical in function of setting up conditions and only different in what it is used for.
To enable a trigger for Out of Credit (OOC) and Retrieval of Credit (ROC) events, you must configure the Gx Out of Credit Retriever event in the session_action_mapping_gx CRD table. The configuration is used in conjunction with the other columns in the Session_Actions_Gx table in Control Center to derive the actions in the Session_Action output column.
Two parameters have been provided in the Gx PreConfiguredRule, TableDrivenChargingRule, and TableDrivenPredefinedChargingRule service configuration objects to expose installed PCC rules to the policy engine to be used for policy decisions in the CRD. These parameters are described below:
Use In Rule Status Condition – Controls whether or not the PCC rule reported status AVPs are created. By default, this parameter is set to true for PreConfiguredRule and TableDrivenChargingRule, and to false for TableDrivenPredefinedChargingRule.
Use in Rule Install Condition – Controls whether or not the PCC rule installed AVPs are created. By default, this parameter is set to false.
Note | To expose installed PCC rules to the policy CRD, you must set this parameter to true. |
These parameters are shown in the following two figure as they appear in the TableDrivenChargingRule and PreConfiguredRule service configuration objects.
<avp name="Charging-Rule-Report"> <avp name="Charging-Rule-Name" value="DTL3300"> </avp> <avp name="PCC-Rule-Status" value="0"> </avp> </avp>
You must also configure your CRD table by binding the <RuleName>_installed column with RI-<RuleName> and by binding the <RuleName>_Status column with RS-<RuleName>.