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.
The Diameter Configuration section allows for the configuration of the diameter plug-in. We recommend configuring the diameter plug-in at system level.
In order to define a Diameter Configuration at system level you need to perform the following steps:
In order to define a Diameter Configuration at cluster level you need to perform the following steps:
Select and expand your cluster name. If no cluster has been created, create one by selecting the Cluster action.
The following parameters can be configured under Diameter Configuration.
Parameter |
Description |
||
---|---|---|---|
Default Gx Stale Session Timer Minutes |
This timer is armed every time a message is received or sent for any given Gx session. When the timer expires (or more precisely within the next minute after the timer expires) a Gx RAR having the Re-Auth-Request-Type AVP set to AUTHORIZE_ONLY (0) message is triggered for that Gx session. If a Gx RAA is received having Result-Code AVP value set to DIAMETER_UNKNOWN_SESSION_ID (5002) or DIAMETER_UNABLE_TO_COMPLY (5012) the Gx session is deemed as stale and removed from the PCRF internal database. On any activity over Gx interface (RAR/CCR) the timer is reset. Default value is 180 minutes.
|
||
Use V9 Event Trigger Mapping |
This option allows for a different set of list of valid values and their interpretation to be used for the Event-Trigger enumerated AVP in order to accommodate the change that occurred in the Gx specification between 3GPP TS 29.212 v9.5 (and prior) and 3GPP TS 29.212 v9.7 (and following including v10 v11 and v12). Default value is checked. List of valid values is provided in Table 2.
|
||
Rel8 Usage Monitoring Supported |
This option allows for the Gx usage monitoring feature to be supported even when the PCEF advertises support for Rel8 feature under Supported-Features AVP in Gx CCR-i. Default value is checked. |
||
Rel15 Ext Bw Nr Supported |
When checked, it enables the support for 3GPP Rel-15 Extended BW-NR feature. PCRF sends response to AF/PCEF with Rel-15 Extended BW-NR feature bit set when the feature is enabled and AF/PCEF has also set the bit in the request message. PCRF sends extended QoS AVPs only if the configuration is enabled. When unchecked, it disabled the support for 3GPP Rel-15 Extended BW-NR feature. Default value is unchecked (disabled). |
||
Stale Session Configuration |
When a new row is added in “Stale Session Configuration” table the default value for the GX_TGPP SD_V11 and SY_V11 Stale session timer is 180 minutes.
If GX_TGPP Stale Session Timer value is not configured in this table, then the value is selected from the retained/old variable “Default Gx Stale Session Timer Minutes”. If there are multiple values configured against any interface then the lowest among all would be considered as the stale session timer. |
||
DRMP Prioritization |
When enabled allows you to configure different message processing priorities based on the DRMP value received in the incoming request. |
Note | If Gx stale session timer is set for both “Default Gx Stale Session timer Minutes” and “Stale Session Configuration” then the value configured Under “Stale Session Configuration” would take the precedence. |
Interpretation - Use V9 Event Trigger Mapping is checked |
Value |
Interpretation - Use V9 Event Trigger Mapping is not checked |
---|---|---|
SGSN_CHANGE |
0 |
SGSN_CHANGE |
QOS_CHANGE |
1 |
QOS_CHANGE |
RAT_CHANGE |
2 |
RAT_CHANGE |
TFT_CHANGE |
3 |
TFT_CHANGE |
PLMN_CHANGE |
4 |
PLMN_CHANGE |
LOSS_OF_BEARER |
5 |
LOSS_OF_BEARER |
RECOVERY_OF_BEARER |
6 |
RECOVERY_OF_BEARER |
IP_CAN_CHANGE |
7 |
IP_CAN_CHANGE |
QOS_CHANGE_EXCEEDING _AUTHORIZATION |
11 |
QOS_CHANGE_EXCEEDING _AUTHORIZATION |
RAI_CHANGE |
12 |
RAI_CHANGE |
USER_LOCATION_CHANGE |
13 |
USER_LOCATION_CHANGE |
NO_EVENT_TRIGGERS |
14 |
NO_EVENT_TRIGGERS |
OUT_OF_CREDIT |
15 |
OUT_OF_CREDIT |
REALLOCATION_OF_CREDIT |
16 |
REALLOCATION_OF_CREDIT |
REVALIDATION_TIMEOUT |
17 |
REVALIDATION_TIMEOUT |
UE_IP_ADDRESS_ALLOCATE |
18 |
UE_IP_ADDRESS_ALLOCATE |
UE_IP_ADDRESS_RELEASE |
19 |
UE_IP_ADDRESS_RELEASE |
DEFAULT_EPS_BEARER _QOS_CHANGE |
20 |
DEFAULT_EPS_BEARER _QOS_CHANGE |
AN_GW_CHANGE |
21 |
AN_GW_CHANGE |
SUCCESSFUL_RESOURCE _ALLOCATION |
22 |
SUCCESSFUL_RESOURCE _ALLOCATION |
RESOURCE_MODIFICATION _REQUEST |
23 |
RESOURCE_MODIFICATION _REQUEST |
PGW_TRACE_CONTROL |
24 |
PGW_TRACE_CONTROL |
UE_TIME_ZONE_CHANGE |
25 |
UE_TIME_ZONE_CHANGE |
USAGE_REPORT |
26 |
TAI_CHANGE |
TAI_CHANGE |
27 |
ECGI_CHANGE |
ECGI_CHANGE |
28 |
CHARGING_CORRELATION _EXCHANGE |
CHARGING_CORRELATION _EXCHANGE |
29 |
APN_AMBR_MODIFICATION _FAILURE |
USER_CSG_INFORMATION _CHANGE |
30 |
USER_CSG_INFORMATION _CHANGE |
DEFAULT_EPS_BEARER _QOS_MODIFICATION_FAILURE |
31 |
NA |
NA |
33 |
USAGE_REPORT |
34 |
DEFAULT_EPS_BEARER _QOS_MODIFICATION_FAILURE |
|
35 |
USER_CSG_HYBRID _SUBSCRIBED_INFORMATION _CHANGE |
|
36 |
USER_CSG_HYBRID _UNSUBSCRIBED _INFORMATION_CHANGE |
|
37 |
ROUTING_RULE_CHANGE |
|
39 |
APPLICATION_START |
|
40 |
APPLICATION_STOP |
|
42 |
CS_TO_PS_HANDOVER |
|
43 |
UE_LOCAL_IP_ ADDRESS_CHANGE |
|
44 |
HENB_LOCAL_IP_ ADDRESS_CHANGE |
|
45 |
ACCESS_NETWORK_ INFO_REPORT |
This feature provides a mechanism for the OAM (PCRF) protection in case more traffic than can be handled is received. It provides a way to prioritize the incoming messages and selectively process them.
The following parameters can be configured under Inbound Message Overload Handling:
Parameter |
Description |
||
---|---|---|---|
Default Priority |
Default priority to be assigned to an incoming message if no specific one is defined in the Message Handling Rules table. Default value is 0. |
||
Message Sla Ms |
This is the Service Level Agreement in milliseconds. This defines the number of milliseconds associated with an incoming event/message within which Policy Director (load balancer) has to submit it to Policy Server (QNS) for processing failing which the Default Discard Behavior is applied. Default value is 1500 ms. If Inbound Message Overload Handling check box is not selected under Diameter Configuration, you can define inboundMessageSlaMs and inboundMessageQueueSize in /etc/broadhop/qns.conf file. If inboundMessageSlaMs is not defined in qns.conf file, then default value of 9000 is used. Example: -DinboundMessageSlaMs=2000 After modifying the configuration on Cluster Manager execute reinit.sh or copytoall.sh scripts for applying the changes on all VMs as described in the CPS Installation Guide for VMware for this release. If InboundMessage Overload Handling check box is selected under Diameter Configuration, then the value configured in Policy Builder is used. This time must be configured less than the timeout configured on the PGW/PCSF. |
||
Inbound Message Queue Size |
Number of messages waiting to be processed before the inbound overload feature is activated. Default value is 1000. If Inbound Message Overload Handling check box is not selected in Diameter Configuration, you can define inboundMessageSlaMs and inboundMessageQueueSize in /etc/broadhop/qns.conf file. If inboundMessageQueueSize is not defined in qns.conf file, then default value of 1000 is used. Example: -DinboundMessageQueueSize=5000 After modifying the configuration on Cluster Manager execute reinit.sh or copytoall.sh scripts for applying the changes on all VMs as described in the CPS Installation Guide for VMware for this release. If InboundMessage Overload Handling check box is selected under Diameter Configuration, then the value configured in Policy Builder is used.
|
||
Default Instance Rate Limit |
This defines the Rate at which incoming messages are staggered before being submitted to the Policy Server. Default value is 0. |
||
Gx Emergency Message Priority |
Default priority assigned to messages related to an emergency session. Default value is 1. |
||
Default Discard Behavior |
Default behavior to be applied to an incoming message if no specific one is defined in the Message Handling Rules table. |
||
Apply Discard Behavior For Emergency Messages |
Indicates if Emergency Messages can be discarded under overload conditions. Default value is not checked. |
||
Rx Message Prioritization |
Defines Rx eMPS message handling priority under overload condition based on Rx AAR MPS-Identifier and Reservation-Priority AVPs. |
||
Message Handling Rules |
Defines specific inbound message overload handling rules based on different criteria. For more information refer to Table 3. |
Note | If Inbound Message Overload Handling check box is not selected in Diameter Configuration, you can define inboundMessageSlaMs and inboundMessageQueueSize in /etc/broadhop/qns.conf file. For more information refer to Table 1. |
Parameter |
Description |
---|---|
MPS Identifier |
MPS-Identifier indicates that an AF session relates to an MPS session. It contains the national variant for MPS service name. For example, NGN GETS. |
Reservation Priority |
The AF may specify the Reservation-Priority AVP at request level in the AA-Request in order to assign a priority to the AF session as well as specify the Reservation-Priority AVP at the media-component-description AVP level to assign a priority to the IP flow. The Reservation-Priority AVP present at request level only should be used under Rx Message Prioritization table. |
Priority |
A user defined priority based on MPS-Identifier and Reservation-Priority combination. The Message priority defined in Rx Message Prioritization table should be unique per row. Higher Priority messages will be processed first compared to lower priority messages. |
Parameter Type |
Attribute |
Description |
---|---|---|
INPUT |
Diameter Client |
Diameter client defined under Diameter Clients section. This field is optional, but is used so that different clients (based on realms) can have different priorities. For more information, refer to Diameter Clients. |
Protocol |
Specific application id value to be used for scoring. This is to match Auth-Application-Id AVP value. For more information refer to Table 4. |
|
Command Code |
Specific command code value to be used for scoring. This is to match the Command-Code field. These command codes map to different types of Diameter messages (CCR = 272 RAR = 258 etc). Default value is 0. |
|
Request Type |
Specific request type value to be used for scoring. This has to match the value of the CC-Request-Type AVP for Gx CCR messages.
Request type has to match the value of the Rx-Request-Type AVP for Rx AAR messages. Request type has to match the value of SL-Request-Type AVP for Sy SLR messages. The possible values are: It has to be set to zero if the incoming message does not have a request type AVP. For example, Rx STR does not have a request type AVP or Rx-Request-Type AVP might not be present in Rx AAR as it is not a mandatory AVP per 3GPP TS 29.214. |
|
OUTPUT |
Priority |
Priority value assigned to the message. Higher numerical value has the higher priority Default value is 0. |
Per Instance Tps |
Transactions per second limit per process. This is the TPS that these messages are limited to. Note that this is per CPS process so if there are 20 Policy Server VM's with 1 Policy Server java process the total TPS is this number x 20. The actual system's transaction per second limit can be calculated using the following formula Per Instance Tps x Number of instances per VM x Number of VMs Default value is 0. |
|
Discard Behavior |
Behavior to be applied to an incoming message. |
Attribute |
Description |
---|---|
GY_V8 |
Standard Gy application as per 3GPP TS 32.299 |
GX_SCE |
Custom Gx implementation |
RF_V10 |
Not supported |
RF_VERIZON |
Not supported |
RX_TGPP |
Standard Rx application as per 3GPP TS 29.214 |
SH_TGPP |
Standard Sh application as per 3GPP TS 29.329 |
SY_V11 |
Standard Sy application as per 3GPP TS 29.219 |
GX_HUAWEI |
Custom Gx implementation |
SD_V11 |
Standard Sd application as per 3GPP TS 29.212 |
GX_TGPP (default) |
Standard Gx application as per 3GPP TS 29.212 |
GXX_TGPP |
Not supported |
GX_ALLOT |
Custom Gx implementation |
RX_CLIENT |
Local MINE adapter |
GY_V8_PROXY |
Gy proxy implementation as per RFC 3588 |
GX_TGPP_PROXY |
Gx proxy implementation as per RFC 3588 |
SY_TGPP_PROXY |
Sy proxy implementation as per RFC 3588 |
SY_OCS |
Sy Proxy from OAM (PCRF) end |
GY_RECHARGE_WALLET |
Support Gy client functionality with external OCS (ECUR model only) |
SY_PRIME |
Custom Sy implementation as per RFC 3588 |
RX_TGPP_PROXY |
Rx proxy implementation as per RFC 3588 |
SY_OCS_SERVER |
OCS Sy server endpoint conforming to 3GPP TS 29.219 |
This feature provides support for inter-working with a DRA that is not configured in topology hiding mode. This is required because while the DRA advertises its own origin host and realm values when the diameter connection is established all the diameter application messages feature the actual host's origin host and realm (i.e. PCEF TDF AF). PCRF needs a way to figure out which particular DRA connection should use in order to deliver a message to the desired host.
While selecting the peer that is used to deliver the request (with or without using the Next Hop Routes table) load balancing across the peers having the same rating is done. Load balancing starts from the peers having highest rating and covers all the peers in a round robin manner. If none is UP load balancing is tried with the peers having the second highest rating and again covers all the peers in a round robin manner and so on.
Note | Next Hop Routes table is used only for PCRF initiated requests. The response messages for any incoming request is always delivered on the same connection where the request was received or not delivered at all. This is in order to avoid asymmetric routes. |
The DRA should explicitly advertise support for a Diameter application other than Relay. The Relay application having Application Identifier 0xffffffff is not supported.
The following parameters can be configured under Next Hop Routing table:
Parameter |
Description |
||
---|---|---|---|
Next Hop Realm |
DRA realm name as received in Origin-Realm AVP in CER or CEA message.
|
||
Next Hop Hosts |
DRA hosts name list as received in Origin-Host AVP in CER or CEA message.
|
||
Application Id |
Diameter application id advertised as being supported by the DRA. It contains information that identifies the particular service that the service session belongs to. |
||
Destination Realms Pattern |
Actual destination realm name pattern as received in Origin-Realm AVP in AAR message. The pattern needs to follow the standard Java regular expression syntax described here. |
||
Destination Host Pattern |
Actual destination host name pattern as received in Origin-Host AVP in AAR message. The pattern needs to follow standard Java pattern conventions. The pattern needs to follow the standard Java regular expression syntax described here. |
While populating the Next Hop Routes table, we recommend that you create only one entry for each Next Hop Realm value - Application Id value pair while all the DRA host names are provided as a list under Next Hop Hosts field. This is not a requirement though.
Note |
|
CPS supports grouping of realms and application identifiers using wildcarding and assigns it to a group of next hop peers. CPS routes outgoing messages by selecting the peer with highest priority.
An example configuration for Grouping and Wildcarding in the Next Hop Routing table is shown below:
Destination Realm and Destination Hosts are used to map with the Peer configuration as defined in the Diameter Stack. The figure given below shows the mapping of the message containing the Realm from a peer to a protocol or interface. For more information on peer configuration refer to Diameter Stack Configuration.
Message Timeout and Retry Configuration table can be configured under Diameter Configuration plug-in in Policy Builder.
This table allows for the configuration of different message timeout value and retry behavior using the combination of Application Id, Command Code and (experimental) result code parameters.
Note | Sh Interface (Auth-Application-Id 16777217) message retry information can be configured using: Only one of the two retry configuration options should be used for Sh Interface. |
The following parameters can be configured in the Message Timeouts and Retry Configuration table.
Parameter |
Description |
||
---|---|---|---|
Application Id |
The Diameter Application ID (Auth-Application-Id) on the message which is to be retired. Default: 0 |
||
Command Code |
The Diameter command code of the message which is to be retried. Default: 0 |
||
Result Code |
This is the result code received in the diameter response for which the user wants to retry. The values configured should be a valid diameter result code value or an experimental result code value. For example, 3002 (DIAMETER_UNABLE_TO_DELIVER) received in RAA. Permanent failure result codes 5xxx and successful result codes 2xxx should not be configured (where, x denotes a valid number). However, if configured CPS, will retry for it.
Default: 0 |
||
Is Experimental |
If this check-box is selected, it means that the value configured in the Result Code column is an Experimental-Result-Code value. This is necessary because there are few values which are the same for both experimental-result-code and result-code. Default: Not selected |
||
Action |
The action for the CPS platform to take after the Diameter Response is received. The options are Retry or None.
Default: None |
||
Action Timer (Ms) |
The amount of time in milliseconds for CPS to wait before retry. For more information, refer to 1. Default: 0 |
||
Retry Count |
The number of times to retry when the action is “Retry”.
Default: 1 |
||
Retry on Alternate |
Configures CPS to retry on any alternate peer configured in Policy Builder. Default: Not selected |
||
Backoff Algorithm |
The back-off algorithm used while determining the actual delay between retry attempts. Currently, only one option (CONSTANT_INTERVAL) is supported.
Default: CONSTANT_INTERVAL |
If the timeout and retry count is not configured than the default values (diameter.default.timeout.ms and diameter.default.retry.count) defined in /etc/broadhop/qns.conf are used.
The diameter.default.timeout.ms and diameter.default.retry.count parameters configured in qns.conf file are taken into consideration only in case of timeout (result code = 7000) and do not impact the behavior in any other case (result code other than 7000).
If no values are defined in the qns.conf file than the default values of diameter.default.timeout.ms=3000 and diameter.default.retry.count=1 are used. If Result Code = 7000 is defined in the Message and Retry Configuration table in Policy Builder, than this configuration takes precedence over qns.conf file parameters.
CPS can be configured to take specific action over Gx and Sy based on response received on Sy/Sd interfaces. CPS can be configured to continue (default) terminate or re-initiate the session.
The following parameters can be configured in the Result Code Based Action Configuration table.
When Gx features for OneGxRulePerFlow is enabled then the gateway triggers simultaneous Gx-CCR-Us for APPLICATION-START within a short time span. This causes a burst of CCR-U message on CPS. Because of the burst, CPS fails to process all the CCR-U message due to "cache out of date" errors and sends DIAMETER_UNABLE_TO_DELIVER errors to gateway. So in order to support the processing of all the CCR-U messages, Message Buffering Configuration can be used.
Message Buffering Configuration can be configured under Diameter Configuration plug-in in Policy Builder.
The following parameters can be configured under Message Buffering Configuration:
Parameter |
Description |
---|---|
Buffer Timeout In Milliseconds |
The time in milliseconds to hold the diameter messages in the buffer after the buffering has been triggered for a particular session ID. Default value is 15 ms. |
Max Buffered Messages Per session |
Maximum number of messages that are held in the message buffer for a particular session ID. Default value is 64. |
Disable Early Processing |
Disable the early processing of buffered message before the configured buffer-timeout (15 ms). If the message buffering has started then CPS triggers an early timeout (after 5 ms) and check the buffer status. If the buffer has single message or contains messages without any holes (in correct sequence) then it sends the first message to Policy Server (qns) node for processing. Default value is unchecked. |
Allow Gaps In Buffer |
Do not drop the messages from the message buffer when a hole/gap is detected while processing the buffered messages (i.e. after ordering the buffered message it detects that certain messages are missing). Default value is unchecked. |
Message Buffering Table |
This table is used to specify the criteria for buffering the messages. CPS buffers only those messages that have a matching entry in this table. For more information on parameters, refer to Table 2. |
Parameter |
Description |
||
---|---|---|---|
Application Id |
Application ID of the interface whose message are to be buffered. For example, 16777238 for Gx messages. |
||
Command Code |
Command code of the diameter message for the above application ID. For example, 272 for CCR messages. |
||
Origin Realm Pattern |
Origin-realm from the diameter request message to check for message buffering. It supports pattern matching as per the JAVA regular expression. This is an optional field and if not configured then CPS applies the configuration to any realm for the matching application ID and Command Code. |
||
Origin Host Pattern |
Origin-host from the diameter request message to check for message buffering. This is an optional field and if not configured then CPS applies the configuration to any host for the matching application ID and Command Code.
|
||
Buffer Start Avp Code |
Diameter AVP code for the AVP that would trigger the start for buffering the messages. For example, 1006 is the diameter AVP code for Event-Trigger AVP. |
||
Buffer Start Avp Type |
A drop-down list to select the data-type of the AVP to trigger buffering of message. This is required for correctly extracting the AVP value. |
||
Buffer Start Avp Value |
The possible values for the diameter AVP for starting the buffering of message. List supported to configure multiple values. |
||
Order Avp Code |
The diameter AVP code for the AVP whose value can be used for sequencing/ordering the buffered message while sending them to Policy Server (qns) node for processing. |
||
Order Avp Type |
A drop-down list to select the type of the Order AVP for extracting its value. CPS currently supports only numeric values for ordering the buffered messages. |
Buffered messages are lost if the diameter-endpoint (qns process) on LB node goes down.
All the CCR-U messages in the burst are processed sequentially, that is, only after a CCA-U is sent out for a CCR-U message then the next CCR-U message is taken up for processing.
CPS initiated messages (for example, Gx RAR) are not considered for buffering and are sent out as they are triggered. Also, if terminate message (for example, Gx CCR-T) is received in between a message burst then CPS drops all further messages from the buffer after processing the terminate message.
As the buffered messages are processed sequentially the response time (towards PCEF) increases. For example, for a burst of 64 simultaneous CCR-U messages, CCA-U for the last message (that is, CCR-U message with highest sequence number) is after a duration of 64*20+15 ms (approx. 1300 ms).
The response time (towards PCEF) for normal messages (not received in a burst but matches the message buffering criteria) has an impact of at least 5 ms (the early processing time). For example, if CCR-U processing takes 20 ms then for a single user plane CCR-U message, the minimum response time is 25 ms.
If CPS receives negative response from Policy Server (qns) node while processing a buffered message then CPS stops processing the message buffer for that session and drops all further buffered messages.
While processing a buffered message if Policy Director (lb) node does not get a response from Policy Server (qns) node within the configured time (SLA) then it drops all the remaining messages from the message buffer of that session. The SLA time is calculated from the time the message was sent from Policy Director (lb) to Policy Server (qns) node and the time that the message spends while waiting for processing in the message buffer.
CPS checks only for 3GPP vendor ID while matching the diameter AVP code defined for Buffer start AVP and Order AVP. If vendor ID is not available in the received AVP then it is assumed to be of default 3GPP vendor ID.
While processing the buffered messages, if another burst of CCR-U messages is received then CPS appends those messages to the existing buffer. In doing so if the buffer size reaches the Max Buffered Messages per session then CPS drops those messages.
CPS maintains the order only for buffered messages. Order is not checked for messages across multiple message bursts for same session.
PolicyDRA Health Check is used to initiate a dummy AAR message that results in querying the binding database allowing the PCRF to take corrective action based on the response.
PolicyDRA Health Check is configured under Diameter Configuration plug-in in Policy Builder. Select PolicyDRA Health Check and Binding Db configuration to enable the feature.
The following parameters can be configured under PolicyDRA Health Check:
Parameter |
Description |
---|---|
Binding Db |
When selected, it enables the feature. When unselected, the feature is disabled. |
Alarm Config |
When selected, it enables the generation of alarms or traps. When unselected, the alarms are not generated.
|
This section allows for the creation of the stacks that will handle the diameter traffic. Depending on your particular requirements one or more stacks can be created.
In order to define a Diameter stack at system level you need to perform the following steps:
In order to define a Diameter stack at cluster level you need to perform the following steps:
The following parameters can be configured under Diameter Stack:
Parameter |
Description |
||
---|---|---|---|
Name |
Local stack name. This is only used within the Policy Builder GUI to identify the diameter stack. |
||
Realm |
Local realm for the diameter stack. This value is going to set as Origin-Realm AVP value in all the diameter messages originated from this stack. |
||
Accept Undefined Peer |
This allows for any incoming diameter peer connection request to be accepted by the stack provided the peer realm is provisioned under inbound realms. For more details on Inbound Peers check Inbound Peers. Default value is checked.
|
||
Local End Points |
This configures other stack parameters. |
||
Local Host Name |
The host local name where this stack is going to be created.
|
||
Instance Number |
Indicates the Instance number of the Policy Server process on Policy Director for which this entry applies. On a Policy Director each Policy Server process is assigned an Instance Number. |
||
Advertised Diameter FQDN |
This value is going to be set as Origin-Host AVP value in all the diameter messages originated from this stack. The Advertised Diameter FQDN value needs to map to a valid IP address because that IP address is going to be set as Host-IP-Address AVP value in CER/CEA. As per RFC 3588 Host-IP-Address is a mandatory AVP in CER/CEA. |
||
Listening Port |
The port the stack will be listening to on the host identified by Local Host Name attribute. Default value is 3868. |
||
Local Bind Ip |
Allows the stack to bind to a different IP than the one that Local Host Name value maps to. When provisioned Local Bind Ip value overrides the Local Host Name value. |
||
Transport Protocol |
Allows you to select either 'TCP' or 'SCTP' for the selected diameter endpoint. Default value is TCP. |
||
Multi Homing Hosts |
This is a comma separated list of IP addresses that CPS will use to start the diameter stack with multi-homing enabled for SCTP transport. Diameter stack with TCP transport will still use the existing 'Local Bind Ip' field to specify any specific IP address for TCP stack. CPS will use the 'Local Bind Ip' to bring up SCTP stack and use it along with the ‘Multi Homing Hosts' to start the SCTP transport with multi-homing support.
|
This section allows for the provisioning of the different timers available at diameter stack level.
The following parameters can be configured under Settings:
Parameter |
Description |
---|---|
User Uri As Fqdn |
Sets the Origin-Host AVP value in CER/CEA to the user URI value instead of FQDn value. Default value is not set. |
Stop Timeout Ms |
Determines how long the stack waits for all resources to stop. The delay is in milliseconds. Default value is 10000. |
Cea Timeout Ms |
Determines how long it takes for CER/CEA exchanges to timeout if there is no response. The delay is in milliseconds. Default value is 10000. |
Iac Timeout Ms |
Determines how long the stack waits before retrying the communication with a peer that has stopped answering DWR messages. The delay is in milliseconds. Default value is 5000. |
Dwa Timeout Ms |
Determines how long it takes for a DWR/DWA exchange to timeout if there is no response. The delay is in milliseconds. Default value is 10000. |
Dpa Timeout Ms |
Determines how long it takes for a DPR/DPA exchange to timeout if there is no response. The delay is in milliseconds. Default value is 5000. |
Rec Timeout Ms |
Determines how long it takes for the reconnection procedure to timeout. The delay is in milliseconds. Default value is 10000. |
This section allows for provisioning of the necessary information needed to parse the Cisco vendor specific SN-Transparent-Data AVP value.
The following parameters can be configured under Auto Provision Avp Parser:
Parameter |
Description |
---|---|
AVP Name |
The AVP name whose value needs to be parsed using the field separator and value separator. For example “abcd=xyz##lmno=pqrst” |
Field Separator |
String value used as a token to split pairs of attribute and values. In the above example # is the field separator. |
Value Separator |
String value used as a token to split pairs of attribute and values. In the above example = is the value separator. |
This section allows for the provisioning of the diameter peers that are allowed to initiate connections towards PCRF. The PCRF does not initiate diameter connections with these peers.
Peer name and peer realm are independently checked against the two tables.
The following parameters can be configured under Inbound Peers:
Parameter |
Description |
||
---|---|---|---|
Peers |
Defines which peer names are allowed to initiate connections towards PCRF. |
||
Local Host Name |
Identifies the local host name of the Policy Director (load balancer) that identifies and allows an incoming connection from the Peer. |
||
Instance Number |
Indicates the assigned number of the Policy Server (QNS) process that initiates a connection with the Outbound Peer.
Default value is 0. |
||
Rating |
Priority assigned to this peer for delivering a PCRF initiated request. The higher the rating value the higher is the priority assigned to the peer. Default value is 1. |
||
Port Range |
Should be specified only when the underlying transport connection Is SCTP and not required when the same is TCP. |
||
Response Timeout |
Cisco recommends not to use this parameter. |
||
Name Pattern |
Origin-Host AVP value in CER needs to validate against this pattern in order for the connection to be established. If that does not happen the CER is silently discarded and the TCP connection is reset by PCRF. Name pattern check does not happen if Accept Undefined Peer option described in Diameter Stack Configuration is checked. The Name Pattern needs to follow the standard Java regular expression syntax described here. |
Parameter |
Description |
||
---|---|---|---|
Realms |
Defines which peer realms are allowed to initiate connections towards PCRF. |
||
Peer Type |
Not used with inbound realms. |
||
Processing Protocol |
Mapping between the realm name and the specific PCRF logic that should be applied for the message. For more information on processing protocol refer to Table 4. |
||
Rating |
Priority assigned to this realm for delivering a PCRF initiated request. This is only used with SY_PRIME processing protocol. Default value is 0.
|
||
Stats Alias |
Whatever the statistics that gets generated for the respective realm gets the name that is configured in “Stats Alias” appended to those statistics. This is applicable for com.broadhop.message mbean statistics only. |
||
Name Pattern |
Origin-Realm AVP value in CER needs to validate against this pattern in order for the incoming message to be processed. If that does not happen the message is silently discarded and the TCP connection is reset by PCRF. The Name Pattern needs to follow the standard Java regular expression syntax described here. |
In Message Timeout and Retry Configuration, diameter response timeout is defined using the combination of Application Id and Command Code parameters.
When PCRF is configured to work with a DRA the actual system's host name does not need to be provisioned in the Peers table for the message to be answered.
When PCRF is configured to work with a DRA the actual system's origin realm name does need to be provisioned in the Peers table for the message to be processed. If it is not provisioned then PCRF shall send an error response containing the Result-Code AVP with value DIAMETER_APPLICATION_UNSUPPORTED (3007).
This section allows for the provisioning of the diameter peers to which the PCRF initiates the diameter connections.
Peer name and peer realm are independently checked against the two tables.
The following parameters can be configured under Outbound Peers:
Parameter |
Description |
||
---|---|---|---|
Peers |
Defines the peers to which CPS can initiate connections. |
||
Local Host Name |
Identifies the local host name of the Policy Director (load balancer) that initiates a connection with the said Peer. |
||
Instance Number |
Indicates the assigned number of the Policy Server (QNS) process that allows an incoming connection from the Peer. Default: 0 |
||
Rating |
Priority assigned to this peer for delivering a PCRF initiated request. The higher the rating value the higher is the priority assigned to the peer. Default: 1 |
||
Port Range |
Should be specified only when the underlying transport connection is SCTP and not required when the same is TCP. However in mixed mode where both SCTP and TCP co-exist then it is mandatory to provide port range values for both TCP and SCTP peers in order to avoid any conflicts on using local ports on same host. |
||
Response Timeout |
Cisco recommends not to use this parameter. |
||
Name |
Peer host name. Peer host name needs to be mapped to a valid IP address or the diameter connection is not initiated. By default the connection is initiated on the standard diameter port (3868). If a different port needs to be used than the peer name shall be defined using the host:port format. Default value is “default”.
|
||
Transport Protocol |
Allows you to select either 'TCP' or 'SCTP' for the selected diameter stack instance. Default value is TCP. |
||
Multi Homing Hosts |
This is a comma separated IP addresses list that CPS uses to start the client connections towards external diameter peer. If either TCP/SCTP or both TCP and SCTP are configured in the Outbound Peers (Peers) table then client connections to the peers are initiated based on whether the PD instance is started as a ‘SCTP’ or ‘TCP’ stack. Mixed mode of client and stack running on both ‘TCP’ and ‘SCTP’ is not currently supported by diameter.
|
Parameter |
Description |
||
---|---|---|---|
Realms |
Defines the realms to which CPS can initiate connections. |
||
Peer Type |
This indicates which diameter server to use when there are multiple target servers for the same protocol. This is only used with SY_PRIME processing protocol. |
||
Processing Protocol |
Mapping between the realm name and the specific PCRF logic that should be applied for the message. For more information on processing protocol refer to Table 4. |
||
Rating |
Priority assigned to this realm for delivering a PCRF initiated request. This is only used with SY_PRIME processing protocol. Default value is 0.
|
||
Stats Alias |
Whatever the statistics that gets generated for the respective realm gets the name that is configured in “Stats Alias” appended to those statistics. This is applicable for com.broadhop.message mbean statistics only. |
||
Name |
Origin-Realm AVP value in CER needs to validate against this pattern in order for the incoming message to be processed. If that doesn't happen the message is silently discarded and the TCP connection is reset by PCRF. The Name Pattern needs to follow the standard Java regular expression syntax described here. |
In Message Timeout and Retry Configuration, diameter response timeout is defined using the combination of Application Id and Command Code parameters.
When PCRF is configured to work with a DRA the actual system's host name does not need to be provisioned in the Peers table for the message to be answered.
When PCRF is configured to work with a DRA the actual system's origin realm name does need to be provisioned in the Peers table for the message to be processed. If it is not provisioned than PCRF shall send an error response containing the Result-Code AVP with value DIAMETER_APPLICATION_UNSUPPORTED (3007).
The following restrictions are applicable while configuring CPS for SCTP:
When using SCTP as a transport protocol, CPS selects the 'Multi Homing Hosts' values along with the 'local bind ip' defined in local endpoints. But for TCP transport protocol CPS ignores the 'Multi home hosts' value.
When using SCTP as a transport protocol, CPS selects the 'Multi Homing Hosts' values along with 'Outbound Peers' defined in 'Peers' table. But for TCP transport protocol CPS ignores the 'Multi Homing Hosts' value.
Configuring Port-Range for SCTP outbound peers is mandatory. We also recommend using non-overlapping port ranges across different PDs within same Policy Director (load balancer) node while configuring multiple PDs.
For example:
PD1 (qns-2 process in the Policy Director (load balancer) VM) 12000-12500
PD2 (qns-3 process in the Policy Director (load balancer) VM) 13000-13500
PD3 (qns-4 process in the Policy Director (load balancer) VM) 14000-14500
The Diameter Agent in CPS currently supports only the PROXY mode of operation (for more information, see RFC 6733 – Diameter Base Protocol at https://tools.ietf.org/html/rfc6733). In Proxy mode, all relevant messages that are received by the CPS node (based on the applied filter on which the message is to be proxied) are forwarded to the given agent.
Policy Builder currently supports proxy functionality for Gx, Gy, and Rx interfaces. Messages reaching CPS may be proxied to an alternate realm based on the "Application-ID" and/or the "Command-Code" within the incoming message. As part of the Diameter agent's configuration (described in Diameter Agent Configuration), the specified realm translates to a destination realm, and a destination node is selected based on outbound peers and priority/rating.
The filter information on which the Application/message needs to be proxied by CPS is provided by configuring a Use Case Template containing the DiameterAgentInfo service configuration (described in DiameterAgentInfo Service Configuration Object Setup) as part of the configured service.
A diameter agent is defined with a name and an associated realm, and is then used when configuring the DiameterAgentInfo service configuration object.
Step 1 | Log in to Policy Builder. |
Step 2 | Select the Reference Data tab. |
Step 3 | In the left pane, select Diameter Agents. |
Step 4 | In the Summary pane, click Diameter Agent under Create Child. |
Step 5 | In the
Diameter
Agent pane, type the
Name and the
Realm for the agent.
|
This section describes how to configure the DiameterAgentInfo service configuration object.
Step 1 | In Policy Builder, select the Services tab. | ||||||||||||
Step 2 | In the left pane, select Use Case Templates. | ||||||||||||
Step 3 | Select Summary and from right side pane, click Use Case Template under Create Child. | ||||||||||||
Step 4 | In the Name field, type a name for the template. | ||||||||||||
Step 5 | select the
Actions tab, and then click
Add under
Service Configurations.
| ||||||||||||
Step 6 | In the Select Service Configuration dialog box, scroll down to the proxy section, select DiameterAgentInfo, and click OK. | ||||||||||||
Step 7 | Configure the
DiameterAgentInfo parameters as described in the following table:
|
The Diameter Clients section allows for the creation of different clients identified by their realm. The clients defined in this section can be further used while configuring a policy so that different clients get different service configuration objects.
Login into Policy Builder.
Select Reference Data tab.
From the left pane, select Diameter Clients.
Select Summary.
Create the specific client that corresponds to your interface. If there is no specific client for your interface select the generic Diameter Clients.
Provide values for at least the mandatory attributes.
Note | The mandatory fields are marked with a “*” on the upper left corner of the field name label. |
Once you have done that you can use the diameter client to filter the service objects that are going to be used in a policy.
More details about each client field and attribute will be provided in the following sections dedicated to each type of client.
Login into Policy Builder.
Select Services tab
From the left pane, select Services.
Expand Service Options tree.
Select and expand your service option.
Select the service option object.
Select the Value cell corresponding to the Diameter Client Display Name.
Click the “…” button.
Select the Diameter Client from the popup window.
Click OK.
For more details about how to define a service option refer to Services.
Note | If your service configuration object does not have a Diameter Client attribute it means it is not diameter related and it cannot be filtered out based on diameter client. |
Note | The diameter client feature is mainly for use with inbound realms. No validation is done as to whether a realm is unique for a specific client type. If multiple clients are defined for the same realm the behavior may be unpredictable. The interface specific diameter clients are built on top of the generic Diameter Clients. They add specific behavior and this is why they should always be used in the context of the specific interface. |
This generic diameter client object is supposed to be used for any interface that does not have a matching specific diameter client.
The following parameters can be configured under generic Diameter Client:
Parameter |
Description |
||
---|---|---|---|
Name |
The client name that is going to be used to reference this particular client in the service configuration object. |
||
Realm Pattern |
The pattern that peer realm name should match in order for this diameter client to be used. The pattern needs to follow the standard Java regular expression syntax described here. The first choice for Realm Pattern value should always be the exact peer realm name whenever possible. |
||
Extract Avps |
See Extract Avps |
||
Override Supported Features |
Currently, not supported.
|
||
Copy Current Diameter Client |
This action creates a new diameter client that is an exact copy of the current diameter client. The only difference between the original and the copy is that “-Copy” is appended to the name of the copy. The Copy action works exactly the same for all types of diameter clients. |
This specific diameter client object is supposed to be used only in relation with the Gx interface. It adds Gx specific features to the generic diameter client already described in Diameter Clients.
The following parameters can be configured for Basic Options under Gx Client:
Parameter |
Description |
||||
---|---|---|---|---|---|
Add Subscriber Id |
Adds Subscription-Id grouped AVP in Gx CCA-i message with one of the following Subscription-Id-Type AVP value and Subscription-Id-Data AVP value depending on the selection. The values will be copied from the incoming Gx CCR-i message if available. |
||||
Rx PCC Rule Flow Direction Behavior |
Controls how the Flow-Direction AVP value under Flow-Information grouped AVP is derived. This option is only used for Rx dedicated bearers.
|
||||
Emergency Called Station Ids |
The list of APNs that are allowed to initiate IMS emergency calls as per procedures described in 3GPP TS 29.212. |
||||
Sending Delayed Message Wait Time Ms |
This parameter specifies the amount of time the Gx RAR will be delayed after Gx CCA is sent when "Gx Triggered Session-Release-Cause in RAR" is enabled. Default value is 500 milliseconds. |
||||
Controls Session Lifecycle |
Decides whether all the other sessions bound to the current Gx session get terminated upon Gx session termination. Default value is checked. |
||||
Load By Imsi |
If checked, attempts to load the session by IMSI (Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_IMSI (1)). Default value is unchecked. |
||||
Load By Nai |
If checked, attempts to load the session by NAI (Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_NAI (3)). Default value is unchecked. |
||||
Load By Msisdn |
If checked, attempts to load the session by MSISDN (Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_E164 (0)). Default value is unchecked. |
||||
Imsi Based Nai |
If checked, the subscriber is identified by PCRF using “IMSI based NAI”, where the identity is represented in NAI form as specified in RFC 4282 [5], and formatted as defined in 3GPP TS 23.003 [6], clause 19.3.2. The IMSI based NAI is sent within the Subscription-Id AVP with the Subscription-Id-Type set to END_USER_NAI at IP-CAN session establishment. Default value is unchecked. |
||||
Load By Framed Ip |
If checked, attempts to load the session by IPv4 address (Framed-IP-Address AVP value). Default value is unchecked. |
||||
Load By Ip V6 Prefix |
If checked, attempts to load the session by IPv6 address (Framed-IPv6-Prefix AVp value). Default value is unchecked. |
||||
Session Chained |
If checked, it does not attempt to terminate the Gx session by sending a Gx RAR to PCEF. Default value is unchecked. |
||||
Remove Realm In User Id Mapping |
If checked, removes the realm from the NAI (if present) before attempting to load the session by username. For more details on NAI see RFC 2486. Default value is unchecked. |
||||
Exclude Sponsor Identity Avp |
If checked, it does not add the Sponsor-Identity AVP to the Charging-Rule-Definition grouped AVP. This option is used only in case the PCEF advertised support for SponsoredConnectivity feature under Supported-Features AVP. Default value is unchecked. |
||||
Load By Called Station Id |
If checked, attempts to load the session by IMSI and APN. In order for this option to be effectively used 'Load By Imsi' option (described above) needs to be checked. Default value is unchecked. |
||||
Re-install Rule on Monitoring Key Change |
If checked, attempts to reinstall a charging rule in case the only AVP value that changed for a PreConfiguredRule is the monitoring key value. |
||||
Limit with Requested QoS on modification failure |
If checked, authorizes bound QoS between retained and calculated QoS after CPS has received QoS modification failure event from PCEF. Default value is checked. |
||||
Enforce Missing Avp Check |
The default value of this new attribute is TRUE (checked); that is, CPS will perform missing AVP validations and send DIAMETER_MISSING_AVP (5005) result in the answer message. However, if this attribute is FALSE (unchecked), CPS will not perform the missing AVP validation. |
||||
One Gx Rule Per Flow |
This parameter applies only to the dynamic charging rules over Gx that are generated by CPS due to the APPLICATION_START event trigger received over the Sd interface for ADC rules. If checked, CPS creates one dynamic charging rule over Gx per flow information received in the Application-Detection-Info AVP over the Sd interface. CPS also creates a unique TDF-Application-Identifier over Gx for each of these rules. So, each generated rule has a unique TDF-Application-Identifier and only one Flow-Information AVP. If unchecked, CPS generates only one rule per TDF-Application-Identifier received over the Sd interface. This one rule has all the Flow-Information AVPs. The TDF-Application-Identifier over Gx is same as over Sd. Default value is unchecked. |
||||
Selective Muting |
If checked, CPS selectively mutes the flow corresponding to a TDF-Application-Identifier on the dedicated bearer after it receives the first Application_Start event trigger on the dedicated bearer from PCEF. For default bearer, CPS selectively mutes the flow corresponding to a TDF-Application-Identifier after it receives the Application_Start event trigger on the default bearer from PCEF and maximum limit is reached on the dedicated bearer.
After CPS receives Application_Stop event trigger from PCEF for a specific TDF-Application-Identifier (with TDF-App-Instance-ID=0), CPS removes that rule from the dedicated bearer and installs the rule on the default bearer and unmutes all the rules related to that Sd TDF-Application-Identifier on the default bearer.
|
||||
Re-Install Predefined Rules on Rulebase Change |
Indicates whether all the existing predefined rules that are applicable for the session are re-installed if there is a Rule-Base change. Select this option if you want all the predefined rules (that are applicable to the session) to be re-installed if the Rule-Base changes due to any reason. If unchecked, whenever there is a Rule-Base change, CPS only notifies the changes (if any) in predefined rules to PCEF and does not re-install all the existing predefined rules.
Use this checkbox only in consultation with Cisco Technical Representative. |
||||
Gx triggered Session-Release-Cause in RAR |
When enabled, any Gx initiated session termination is responded to with a RAR immediately after CCR/CCA exchange with the PCEF. The RAR contains the Session-Release-Cause AVP. When disabled, any Gx initiated session termination response from the PCRF in the CCA-U contains the Session-Release-Cause AVP. This is the default behavior.
|
||||
Enhanced Gx-RAR Behavior |
When enabled the desired behavior will be exhibited for call flows. Default value is disabled for backward compatibility. |
Priority |
Criteria |
Flow-Direction AVP Values |
---|---|---|
1 |
Flow-Description AVP value contains “permit in” |
UPLINK (2) |
2 |
Flow-Description AVP value contains “permit out” |
DOWNLINK (1) |
3 |
FlowStatus AVP value is ENABLED (2) |
BIDIRECTIONAL (3) |
4 |
FlowStatus AVP value is ENABLED_UPLINK (0) |
UPLINK (2) |
5 |
FlowStatus AVP value is ENABLED_DOWNLINK (1) |
DOWNLINK (1) |
The following is the list of AVPs for which CPS will perform the missing AVP validation if Enforce Missing Avp Check check box is selected:
Mandatory AVPs: Origin-Host, Destination-Realm, CC-Request-Type, CC-Request-Number
Conditional AVPs for session establishment: Subscription-Id (Subscription-Id-Type, Subscription-Id-Data), IP-CAN-Type, RAT-Type , Framed-IP-Address OR Framed-IPv6-Prefix (one must be present), AN-GW-Address (If IP-CAN-TYPE = '3GPP-EPS' or '3GPP2')
Conditional AVPs for session modification: These AVPs are required based on the event trigger type.
SGSN_CHANGE Event Trigger: 3GPP-SGSN-Address or 3GPP-SGSN-IPv6-Address
Applicable only to 3GPP-GPRS access types and 3GPP-EPS access types with access to the P-GW using Gn/Gp.
QOS_CHANGE Event Trigger: Bearer-Identifier, QoS-Information
When IP-CAN-Type is 3GPP-GPRS and if the PCRF performs bearer binding, the Bearer-Identifier AVP shall be provided to indicate the affected bearer. QoS-Information AVP is required to be provided in the same request with the new value.
RAT_CHANGE Event Trigger: RAT-Type
The new RAT type must be provided in the RAT-Type AVP.
PLMN_CHANGE Event Trigger: 3GPP-SGSN-MCC-MNC
IP_CAN_CHANGE Event Trigger: IP-CAN-Type
The RAT-Type AVP must also be provided when applicable to the specific IP-CAN Type (for example, 3GPP IP-CAN Type).
RAI_CHANGE Event Trigger: RAI
Applicable only to 3GPP-GPRS and 3GPP-EPS access types.
USER_LOCATION_CHANGE Event Trigger: 3GPP-User-Location-Info
Applicable only to 3GPP-GPRS and 3GPP-EPS access types.
USER_LOCATION_CHANGE Event Trigger: 3GPP2-BSID
Applicable only to 3GPP2 access types.
OUT_OF_CREDIT Event Trigger: Charging-Rule-Report, Final-Unit-Action
REALLOCATION_OF_CREDIT Event Trigger: Charging-Rule-Report
AN_GW_CHANGE Event Trigger: AN-GW-Address
UE_TIME_ZONE_CHANGE Event Trigger: 3GPP-MS-TimeZone
LOSS_OF_BEARER, RECOVERY_OF_BEARER, SUCCESSFUL_RESOURCE_ALLOCATION: Charging-Rule-Report
DEFAULT _EPS_BEARER_QOS_CHANGE: Default-EPS-Bearer-QoS
ECGI_CHANGE or TAI_CHANGE Event Trigger: 3GPP-User-Location-Info
ACCESS_NETWORK_INFO_REPORT Event Trigger:
3GPP-User-Location-Info, if Required-Access-Info = USER_LOCATION
3GPP-MS-Timezone, if Required-Access-Info = MS_TIMEZONE
APPLICATION_START or APPLICATION_STOP Event Trigger over Gx: TDF-Application-Identifier
StarOS 16 introduces optional custom behavior for handling overlapping Gx transactions so that the potential race conditions that can occur on Gx interface are to be handled deterministically.
This feature introduces a new error indication to allow the transaction originator to determine if a re-attempt of the transaction is appropriate. The PCRF shall send an error response to the PCEF containing the Experimental-Result-Code AVP with Cisco specific value DIAMETER_PENDING_TRANSACTION (4198) if the PCRF expects a response to a pending request that it initiated. The PCRF shall also have the ability to retry the request message for which it received an error response containing the Experimental-Result-Code AVP with Cisco specific value DIAMETER_PENDING_TRANSACTION (4198).
Refer to the CISCO StarOS 16 and CISCO ASR5500 documentation for more details.
Default value (if enabled) is 1.
Max Pending Transaction Retry Count does not include the initial request. For example, in the above case the system will send a initial message and if it fails, it will send the same message 1 more time (retry).
Note | PCRF will cache and retry only one message per Gx session. If due to Rx IMS session interaction multiple Gx RAR messages are being evaluated while another Gx RAR message is already pending than PCRF will not reply on the Rx IMS session. |
The default monitoring key name format used to track the usage when the AF provides sponsored data connectivity to the subscriber is:
_<Sponsor-Id>_< Rx-Session-No>
where:
<Sponsor-Id>: Sponsor-Identity AVP value under the Sponsored-Connectivity-Data grouped AVP.
<Rx-Session-No>: Counts how many Rx sessions have bound so far to the Gx session by the time the current Rx session is created. This is an attribute of the Rx session stored on PCRF side and it doesn't change during the Rx session lifetime. The value starts from zero and it increases with one for each new Rx session that binds.
This feature allows for customization of the monitoring key name. The monitoring key name matching the Sponsor-Identity AVP value and Application-Service-Provider-Identity AVP value will be used instead of the default one.
This option is used only in case the PCEF advertised support for SponsoredConnectivity feature under Supported-Features AVP.
Override Boost with Throttle for Similar Priority: This provides an option to over-ride Throttle with Boost for same priority values received in Dynamic-PCC-Request-QoS.
Atomic Update of QCI and ARP: This check box has been added to support QCI and ARP atomicity. When checked, on receiving boost request, ARP gets modified only when QCI is modified.
CPS now supports the ability to split Flow Information received from the Traffic Detection Function (TDF) in a CCR-Update across multiple Charging Rules and sent over the Gx interface.
This release provides the ability for CPS to distribute the TFTs across multiple CRNs. The distribution of TFTs keeps the Uplink and Downlink flows together in the same CRN. The number of TFTs per CRN is configurable. By default, CPS is configured to allow 8 TFTs per CRN.
Parameter |
Description |
---|---|
Count of TFT’s in one Charging Rule |
One TFT is equivalent to or denotes one Flow-Description AVP received in the message. |
Here, you can set the maximum number of flows that can be configured on the default and dedicated bearer (per QCI).
The following parameters can be configured:
Note | These parameters apply only to the dynamic charging rules over Gx that are generated by CPS due to the APPLICATION_START event trigger received over the Sd interface for ADC rules. |
Parameter |
Description |
---|---|
Max Number of Flow Descriptions on a default bearer (per QCI) |
This parameter defines the maximum number of flows that can be installed on a default bearer per QCI. So, on receiving the APPLICATION_START event trigger over the Sd interface, CPS installs the corresponding flows over the Gx interface and QCI maps to that of the default bearer. Essentially, this is the limit of flows per QCI that CPS can accept from TDF over the Sd interface. Once this limit is reached, CPS ignores any more flows received from TDF, that is, CPS does not install any rules for those flows. Default value is 64. |
Max Number of Flow Descriptions on a dedicated bearer (per QCI) |
On receiving the APPLICATION_START event trigger from PCEF, CPS removes the default bearer rule and installs the dedicated bearer rule for the received Gx TDF-Application-Identifier. So, QCI for the new rule maps to a dedicated bearer. This parameter defines the the maximum number of flows per QCI that can be installed on a dedicated bearer. Once this limit is reached, CPS ignores the APPLICATION_START event trigger received over the Gx interface and there is no rule or flow installed on the dedicated bearer. Default value is 16. |
Upon failure of installation of any/all of the TFTs across one or both CRNs, a configurable retry timer is activated with a configurable number of retries for the TFTs marked as “INACTIVE”. The number of retries and the timer interval between each retry is configurable.
Parameter |
Description |
---|---|
Retry Interval |
The delay between retry attempts. The default interval is 10 seconds. Also, by default, the value is capped at 15 secs (configurable). If value is less that 15 seconds, then the retries will be scheduled at second level granularity. If value is greater than 15 seconds, then granularity is of 1 minute (overdue retry events are checked every minute rather than each second). |
Max Retry Attempts |
The maximum times retry is attempted for a rule. Default value is 3 attempts. |
Backoff Algorithm |
The back-off algorithm used while determining the actual delay between retry attempts. Currently only one option is supported: Constant Interval: Causes the configured retry interval to be used (without any change) for delay for all retry attempts (other options like exponential back-off where retry interval increases exponentially are currently not supported/implemented). |
Upon failure to install TFTs even after retry, all remaining flows are removed (if there were any successfully installed)followed by termination of the Sd Session. After a refresh, CPS attempts to re-establish the Sd-Session. CPS also marks the failed flows as INACTIVE.
CPS can reject incoming CCR-I messages with DIAMETER_REDIRECT_INDICATION (3006) error by acting as a redirect agent (RFC 3588). This decision to redirect a request is configured using an STG or CRD. CPS expects the STG or CRD to include a Redirect Request Column (of type True or False). There is no restriction on the condition that determines the redirect behavior.
The following parameters can be configured under Redirect Requests:
Parameter |
Description |
---|---|
Redirect Request Column |
The result column (True/False) from the CRD used to determine if the session needs to be redirected. If result column specified here evaluates to True, session is redirected, else it continues as usual. |
Redirect Host |
The list of Redirect-Host AVP values to be included in the response. If there are more than one hosts listed, all the hosts are included in the response. |
Redirect Max Cache Time (in seconds) |
The Redirect-Max-Cache-Time AVP value (in seconds) to be included in the response. |
Redirect Host Usage |
|
Note | The below procedure is a sample configuration based on APN and Billing plan. |
Step 1 | Log into Policy Builder. |
Step 2 | Select the Reference Data tab. |
Step 3 | Click Custom Reference Data Tables and select Search Table Groups. |
Step 4 | Under Actions, click Search Table Groups. |
Step 5 | Enter a name for the STG. |
Step 6 | Under Result Columns, click Add and enter a Name, Display Name, and select the check box under Use In Condition. |
Step 7 | Click Custom Reference Data Table under . |
Step 8 | Enter a Name and Display Name for the CRD Table. |
Step 9 | Under
Columns, click
Add and enter the following parameters as shown in
the following figure:
For apn, make sure you select Bind to Session/Policy State Field, click select and select Gx APN. Similarly, for billing_plan, select Bind to Subscriber AVP code and enter the name or code for the AVP that represents the subscriber's billing plan (for example, billingplan). |
Step 10 | Save the PB configuration. |
When a Gx session is established, the Supported-Features AVP value is checked for Pending Transactions bit in accordance with 3GPP TS 29.212. The AVP value is stored in the Gx session.
This feature is disabled by default. Select the Pending Transaction Retry check box to enable the feature.
On enabling this feature, make sure to disable the Cisco Pending Transaction Retry feature.
If the Pending Transaction Retry check box is unchecked (that is, disabled) in Policy Builder, the system defaults to 3GPP handling of race conditions or pending transactions.
The following parameters can be configured under Pending Transaction Retry:
Parameter |
Description |
---|---|
Back Off Algorithm |
Default value is Constant_Interval. |
RAR Retry Interval (MilliSeconds) |
Retry time interval (milliseconds) after which same RAR is retried after receipt of Pending Transactions (4144) Experimental Result code in RAA. Default value is 1000 milliseconds. |
Time (MilliSeconds) to hold CCR-U processing |
Time interval (milliseconds) during which CCR-U processing is withheld till pending RAA is received from PCEF. Default value is 1000 milliseconds. |
Time (MilliSeconds) to wait for CCR-U retry |
Time interval (milliseconds) during which CPS should wait for PCEF to initiate a CCR-U retry after sending a RAA with Pending Transactions (4144) Experimental Result code. Default value is 1000 milliseconds. |
Max No of additional RAR's to be stored |
Number of RARs generated during pending transactions situations that need to be held and retried in sequence. Additional maximum RARs that can be stored is three. If this value is more that three, Policy Builder displays configuration violation error message. Default value is 1. If set to 0, additional RAR's are discarded. |
AVPs that are required for policy decisions are extracted from the diameter message. The AVPs are specified by their path within the diameter message. Additionally, nested AVPs (each level delimited with ".") can also be extracted with or without qualifiers.
Once extracted, the AVPs are then available for use in Initiator conditions or as key AVP in CRD tables for policy decisions. The AVPs are not stored with the session. Thus, if some policy is enabled because of a received message, and if there is a subsequent trigger message that does not contain that AVP, the initiator conditions will fail and the policy is reverted.
If the AVP to be extracted appears multiple times, each of the instance will be extracted and made available as a policy AVP. Initiator conditions can be written for one or more of these instances. Each condition will check all the available instances for evaluation. Thus if there are multiple instances, multiple conditions (if configured) can be true for the same AVP but with different values.
Name: Enter a logical name for the extracted AVP. This name will be used in Initiator conditions and CRD tables to identify the extracted AVP. This is a mandatory parameter.
Avp Path: Enter the complete AVP path. This is a mandatory parameter.
Command Code: If Command Code is specified, CPS attempts to extract the AVPs from only that command (and skip the rest). This is an optional parameter.
For the above example, given a CCR with Event-Trigger AVPs, CPS extracts each Event-Trigger AVP instance and adds it to the current policy state.
CPS supports override of Supported-Features with configured value (instead of internally calculated value). The override Supported-Features value can be defined in a CRD table. If the value is configured, CPS compares (bitwise AND) the incoming PCEF advertised value with the configured value and uses the result as the negotiated value. This negotiated value is included in the response message.
If the Override functionality is not enabled or table evaluation provided under the Override Supported-Features does not return a result, CPS falls back to the internal Supported-Features calculation.
Note | CPS does not validate the configured Feature-List value. If wrong value is configured, CPS still evaluates negotiated features based on this wrong value and can enable features which CPS does not actually support. |
The following parameters can be configured:
Parameter |
Description |
---|---|
Search Table Group |
The STG to lookup for determining the configured Supported-Features (for override). |
Vendor Id |
The Result column from the selected STG that corresponds to Vendor-Id AVP value. |
Feature List Id |
The Result column from the selected STG that corresponds to Feature-List-Id AVP value. |
Feature List |
The Result column from the selected STG that corresponds to Feature-List AVP value. |
Note | Multiple entries can be configured, which are evaluated in order. |
For an Rx call a different Rx dedicated bearer is created for each Media-Sub-Component grouped AVP in the incoming Rx AAR message. This feature allows for customization of the Rx dedicated bearer name based on the AF-Application-Identifier AVP value and Media-Type AVP value received in Rx AAR message.
The default Rx dedicated bearer name format is: _<Rx-Session-No>_<MCD-No>_<Flow-Number>_<partialRulename>_<Media-Type>
<Rx-Session-No>: Counts how many Rx sessions have bound so far to the Gx session by the time the current Rx session is created. This is an attribute of the Rx session stored on PCRF side and it doesn't change during the Rx session lifetime. The value starts from zero and it increases with one for each new Rx session that binds.
<MCD-No>: Media-Component-Number AVP value under Media-Component-Description grouped AVP for the current Media-Sub-Component grouped AVP.
<Flow-Number>: Flow-Number AVP value for the current Media-Sub-Component grouped AVP.
<partialRulename>: Partial Rule Name value matching the current Af Application Id and Media Type values for the current Media-Sub-Component grouped AVP or “AF” if no match.
<Media-Type>: Media-Type AVP value for the current Media-Sub-Component grouped AVP.
Note | Only the <partialRulename> part can be customized. |
This specific diameter client object is supposed to be used only in relation with the Rx interface. It adds Rx specific features to the generic diameter client already described in Diameter Clients.
The parameters described in the following table can be configured for the Rx client:
Parameters |
Description |
||
---|---|---|---|
Session Binding Attribute |
Allows the Rx sessions initiated by this client to bind to the Gx session by other attribute than the IP address as per 3GPP TS 29.214. For more information refer to Table 2. |
||
Flow Description Source Ip Evaluation |
|||
STA Hold Time Ms |
This parameter is used to define the timer by which the STA is held back. Once the timer expires even if the CCR-U is not received, STA is sent to the AF and the rxSession is removed. Default value is 4000 milliseconds. |
||
CCR-U Wait Time (in seconds) |
CCR-U timer is started for every request (default bearer boost/spawning of dedicated bearer) from AF if the CCR-U is configured in Policy Builder and CUSTOM_DPCC_STATUS_REPORT(200) is armed in AAR request. There is a separate timer event for different Rx client. This timer is stopped by PCRF when CCR-U is received from P-GW. Also in case when P-GW does not respond to Gx-RAR then CCR-U timer is stopped on receiving internal Gx-RAA (result-code=7000) message. CCR-U timer is helpful in informing AF if the QoS requested through AF is updated on P-GW. In case of default bearer QoS boost/throttle request from AF, there is no notification sent by the P-GW to PCRF. In this case PCRF internally runs this CCR-U time which on expiry sends an update (through Rx_RAR having DPCC-Status AVP) to AF that QoS request is served. There is no default value for this timer. If you want to start CCR-U timer, then you need to configure through Policy Builder. The maximum value is 15 seconds. |
||
Sending Delayed Message Wait Time Ms |
This parameter is used to configure wait timer for sending delayed messages. Default value is 500 milliseconds. In case of multiple Media-Component-Descriptions being received in an AAR message by CPS, where one of them is rejected after evaluating for Rx Authorization, CPS sends a successful AAA for the accepted Media-Component-Descriptions and also creates a scheduled event for sending a delayed Rx RAR for rejected Media component. This Rx RAR is sent to AF based on Sending Delayed Message Wait Time configured. |
||
Emergency URN List |
The list of URNs that are used to indicate that a AF session relates to emergency traffic as per procedures described in 3GPP TS 29.214. For more information refer to Wildcard URN. See Emergency URN List. |
||
Override AF App Id with URN for Emergency sessions |
When selected, CPS overrides the AF-Application-Identifier AVP value with the Service-URN AVP value for emergency calls. This option is provided in order to overcome the lack of AF-Application-Identifier AVP value in Rx AAR in case of IMS emergency calls. The default setting is unchecked. |
||
Validate Flow-Description AVP Value |
When selected, CPS validates the Flow-Description AVP values received as part of Media-Sub-Component based on restrictions provided in the 3GPP 29.214 Release 11 specification. If the Flow-Description value does not comply with the format specified then the AAR request is rejected with FILTER_RESTRICTIONS (5062) value in Experimental-Result-Code. When unchecked, CPS does not validate the Flow-Description AVP value and simply forwards it is as is to PCEF as part of generated rules. The default setting is unchecked. |
||
29.213 standard QoS for preliminary service |
When checked, CPS supports the QoS handling for Preliminary Service Status. So, on receiving Service-Info-Status AVP as preliminary service information from AF, CPS generates the dynamic PCC rule and assign QCI and ARP values of the default bearer to these PCC rule to avoid signaling to the UE. When unchecked, CPS ignores the Service-Info-Status AVP value and derive the ARP and QCI values as per the QoS derivation algorithm defined in 3GPP TS 29.213 specification. The default setting is unchecked. |
||
NetLoc: Report ANI on rule failure |
When checked, CPS always sends the ANI to AF on receiving ANI event from the PCEF. So, in case of bearer release that is either in Rx_RAR (when few rules are impacted) or in Rx_STA when all the rules are impacted, PCRF adds the ANI (access network information) towards AF. When unchecked, CPS does not report ANI to the AF every time the ANI event is received from PCEF. In case of Rx session termination by PCRF that is, when PCRF sends Rx ASR to the AF; PCRF sends the ANI in the Rx STA message even if AF has not asserted the Required-Access-Info AVP for ANI in the Rx STR message.
The default setting is unchecked. |
||
Hold STA if RAN-NAS-Cause enabled |
When RAN-NAS-Cause feature is enabled, CPS sends access network information and RAN-NAS-Release-Cause to AF in STA. So, when this check box is selected, CPS waits for this information from the PCEF and does not send STA till it receives the CCR-U from the PCEF. The default setting is checked (TRUE).
|
||
Auto Increment Precedence Avp |
When selected, CPS automatically increments the precedence AVP value by 1 for every Rx charging rule that is installed as part of any Rx session that is using this Rx client within the same Gx session. For example, Gx session (Gx1) has one Rx session (Rx1). When Rx1 is created, two charging rules are installed and they are assigned precedence values 1 and 2. A second Rx session (Rx2) starts for Gx1 and also installs two Rx charging rules. These rules are assigned precedence values 3 and 4. The precedence values are stored in the Gx session in the rxPrecedenceCounter attribute. Using this option overrides any other Rx charging rule precedence settings (for example, any that may have been configured for the RxSponsoredDataChargingParameters service option).
You can use the Precedence Start Value and Precedence End Value options to set lower and upper limits for the precedence AVP values. If you do not set these options, the starting precedence value is set to 1 and is incremented to 9223372036854775807. The default setting is unchecked. |
||
Remove Rule On Rule Deactivation |
When selected, CPS manages the expiration of Rule-Deactivation time triggers. On expiration of the installed Rule-Deactivation time, CPS initiates removal of the inactive dynamic rules and tear-down of the existing Rx session. The default setting is unchecked (false). |
||
Authorize Sponsor Data Connectivity |
When selected, CPS validates the sponsor ID received in AAR request. If the received sponsor ID is unauthorized, CPS returns UNAUTHORIZED_SPONSORED_DATA_CONNECTIVITY (5067) code in AAA. The default setting is unchecked (false). |
||
Enforce Unique AF-Charging-Identifier |
When selected, CPS enforces a unique AF-Charging-Identifier across all Rx sessions within a given subscriber or network session. During an Rx session establishment, if there is already an Rx session (within the subscriber or network session) containing the same AF-Charging-Identifier value, CPS rejects the new Rx session with DUPLICATED_AF_SESSION (5064) experimental result code. The default setting is unchecked. |
||
Prefer command level AF-Application-Identifier |
The AF-Application-Identifier AVP present in the AAR message indicates the particular service that the AF session belongs to. This AVP can be present at the command level and within the Media-Component-Description AVP. When selected, and if the AF-Application-Identifier is sent both at command level and within the Media-Component-Description AVP, the AF-Application-Identifier AVP value present at the command level is considered. The default setting is unchecked, that is, the AF-Application Identifier provided within the Media-Component-Description AVP is considered. |
||
Send timezone and location info |
When selected, CPS sends time zone and location information in Rx AAA, STA, and Rx RAR response messages provided that 3GPP-MS-TimeZone AVP and 3GPP-User-Location-Info AVP are already received in the CCR message. To receive the updated time zone and location information in the messages, CPS should arm the UE_TIME_ZONE_CHANGE event trigger and USER_LOCATION_CHANGE event trigger in the service option under Event-Trigger configuration.
|
||
Trigger RAR when all rules fail (for SRVCC) |
When selected, CPS can trigger RAR instead of ASR when all rules fail with rule failure code PS_TO_CS_HANDOVER. The default setting is unchecked. |
||
Reject AAR with Invalid Service Info for missing Media-Type |
When selected, if Media-Type is found to be missing in any Media-Component-Descriptions in Rx_AAR, CPS rejects the Rx_AAR with Experimental-Result-Code= INVALID_SERVICE_INFORMATION (5061). The default setting is unchecked. |
||
Precedence Avp Lower And Upper |
|||
Precedence Start Value |
When selected, CPS automatically increments the precedence AVP value by 1 for every Rx charging rule that is installed as part of any Rx session using this Rx Client, within the same Gx session. The precedence values are stored in the Gx session in the rxPrecedenceCounter attribute. This value is optional, but when used, must be greater than 0 and less than the Precedence End Value. |
||
Precedence End Value |
The upper limit of the precedence values for Rx charging rules that are installed. When this value is reached, the rxPrecedenceCounter is reset to the Precedence Start Value. This value is required when using the Precedence Start Value. It must be greater than the start value. |
||
Netloc Access Not Supported Configuration |
|||
Session Binding Overriding |
See Table 2. |
||
Rule Failure Mapping Table |
By default, the table is empty and unchecked (for backward compatibility) but if you want to override the default behavior, then you need to configure all the error codes received over Gx via CCR-U or RAA message for which Rx RAR needs to be sent. You can create two tables for mapping rule-failure-code to specific-action (for sending in Rx RAR) and rule-failure-code to abort-cause (for sending in Rx ASR). If you have checked Rule Failure Mapping Table checkbox and did not configure any mappings then neither default Specific Action nor Abort Cause is applied for any of the Failure Code. If you have not checked Rule Failure Mapping Table checkbox then default Specific Action and Abort Cause is applied.
|
||
Request Gx RAA for Event-Triggers |
By default, the table is empty and unchecked (for backward compatibility). This configuration is used to determine the Gx event triggers that CPS should subscribe in Gx RAR (dummy RAR) before it processes the media information that it has received in Rx AAR message. The event triggers are determined based on a CRD table (dummy RAR table) whose input columns are bound to Rx media details (for example, Media-Type, AF-Application-Id, and so on) and output columns specify the event-trigger numbers that are to be subscribed/enabled on PCEF. The evaluation of this CRD table per media (Media-Component-Description) is defined through Rx STG lookup binding configuration under Rx Profile. The Rx CRD AVP names to extract Event-Triggers list is used to specify the Rx CRD AVP names. These Rx CRD AVPs are created based on the output column mapping defined for the CRD table (dummy RAR table) under Rx STG lookup binding (AVP name defined under Output column AVP pairs). |
||
Extract Avps |
See Extract Avps. |
||
Override Supported Features |
Session Binding Attribute value |
Description |
---|---|
IP Address (default) |
Attempts to bind by |
IMSI and APN |
IMSI value and APN value from incoming request. |
MSISDN and APN |
MSISDN value and APN value from incoming request. |
IMSI And IP Address |
IMSI value, IP address value, and IPv6-Prefix value from incoming request. On receiving Rx session request, keys are generated for IMSI and IP Address or IMSI and IPv6-Prefix combination to load the session based on these keys. |
“IMSI and APN” and “MSISDN and APN” session binding attribute values are provided in order to support non 3GPP TS 29.214 compliant Rx clients.
CPS supports wildcard service URN. For example if sos.* is configured under Emergency URN List in Policy Builder and when Service-URN is received from AF with “sos” “sos.fire” “sos.police” and “sos.ambulance” and so on. indicating an emergency session CPS applies special policies that are configured for Emergency sessions.
Select the Rx Client name created.
Click Add near the Emergency URN List box. A new window Add Values is displayed.
Type the name of the emergency URN that you want to add in the Value to Add (String) text box and click Add.
Click OK. In the example shown below, three URNs entries are added. To remove an URN from this list select the URN to be removed and click Remove.
Note | As shown in the example, '*' has been used for wildcarding. CPS uses standard Java pattern characters for Emergency URNs. The pattern needs to follow the standard Java regular expression syntax described here. |
CPS supports to send NetLoc-Access-Support AVP in Rx AAA or STA message based on the current IP-CAN-Type or the values of Rat-Type AVP and AN-Trusted AVP. This is in accordance with the section 4.4.6.7 of the 3GPP 29.214.
To enable this, Netloc Access Not Supported Configuration has been added under Rx Client.
By default, this configuration is disabled. This means that PCRF will not check for NetLoc access support based on IP-CAN-Type or Rat-Type AVP and AN-Trusted AVP.
If this configuration is enabled but there are no entries in the two tables associated with it, then PCRF will not check for NetLoc access support based on IP-CAN-Type or Rat-Type AVP and AN-Trusted AVP.
The following table provides description related to the two tables under this configuration:
Table Name |
Description |
---|---|
List Of Ip Can Type |
This is the list of IP-CAN-Type values for which NetLoc access is not supported. For valid values of the IP-CAN-Type, refer the 3GPP specification 29.212. This table only takes integer values as input. Default value is -1. An entry with value = -1 must not be used for validation of NetLoc access. |
List Of Rat Type |
This is the list of Rat-Type AVP & AN-Trusted AVP values for which NetLoc access is not supported. For valid values of the Rat-Type & AN-Trusted, refer the 3GPP specification 29.212. This table only takes integer values as input. Default value is -1. Rat Type entry with value = -1 must not be used for validation of NetLoc access. An Trusted entry with value = -1 means that the AN-Trusted value does not care for this entry. |
When the PCRF receives a request to report the access network information from the AF in an AAR command or in an STR command triggered by the AF, the PCRF tries to determine whether the access network supports the access network information reporting based on the currently used IP-CAN type or the values of RAT-Type AVP and AN-Trusted AVP.
PCRF first searches the list of configured IP-CAN-Type and if no match is found in the IP-CAN-Type list, then it searches the list of Rat-Type and AN-Trusted. If there is a match in any one list i.e. either the currently used IP-CAN-Type matches or current value of the Rat-Type and AN-Trusted matches, then the PCRF responds to AF with an AAA or STA command including the NetLoc-Access-Surpport AVP set to the value of 0 (NETLOC_ACCESS_NOT_SUPPORTED); otherwise, it immediately configures the PCEF to provide such access network information.
This specific diameter client object is supposed to be used only in relation with the Gy interface. It adds Gy specific features to the generic diameter client already described in Diameter Clients.
The following parameters can be configured under Gy Client:
Parameters |
Description |
||
---|---|---|---|
Load By Realm And User Id |
If checked attempts to load the session by realm (Origin-Realm AVP value) and User Id. Default value is unchecked. |
||
Load By Apn And User Id |
If checked attempts to load the session by APN (Called-Station-Id AVP value) and User Id. Default value is unchecked. |
||
Gy As Primary |
This check box controls whether you want to run the Gy as primary (for example, for Gy only call model) or secondary (for example, Gx + Gy call model). gyAsPK parameter in qns.conf file is also used to run Gy as primary or secondary. This flag is system wide parameter. In case you want to run Gy only call model and Gx + Gy call model both on the same system, the qns.conf parameter cannot be used. The new check box field added under Gy Client is backward compatible with qns.conf parameter settings. For example, if -DgyAsPK=true parameter is configured in qns.conf file, the check box is overwritten with the value configured in qns.conf file. To run both Gy only and Gx + Gy call model on same system:
|
||
Extract Avps |
See Extract Avps |
||
Override Supported Features |
Currently, not supported.
|
Both of the above mentioned flags help in binding the Gy session to correct Gx session when multiple Gx sessions exist for the same user.
In both cases User Id is:
User Id |
AVP Value |
---|---|
IMSI |
Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_IMSI (1) |
MSISDN |
Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_E164 (0) |
NAI |
Subscription-Id-Data AVP value under Subscription-Id grouped AVP where Subscription-Id-Type AVP value is END_USER_NAI (3) |
Note | When gyAsPK flag set to true in qns.conf file (/etc/broadhop), it loads the Gy session using the Gy session ID as the primary key. In CPS 12.1.0, CPS 13.1.0, and CPS 14.0.0 and higher releases, this parameter is enforced on all Gy messages. In other CPS releases, the parameter is ignored on CCR-I's, and the session is loaded by secondary keys specified in the Gy client. If there are no keys configured for the Gy client, CPS uses the default: IMSI and MSISDN from the Gy message. Default value is false. |
This specific diameter client object is supposed to be used to access the Sy Server.
The following parameters can be configured under Sy Client:
Parameter |
Description |
---|---|
Name |
The client name that is going to be used to reference this particular client in the service configuration object. |
Realm Pattern |
The pattern that peer realm name should match in order for this diameter client to be used. The pattern needs to follow the standard Java regular expression syntax described here. The first choice for Realm Pattern value should always be the exact peer realm name whenever possible. |
Counter Lookahead Interval |
Dynamic calculation of policy counters events that are subjected to an update for the interval specified. If the look ahead interval is specified, CPS evaluates all policy counters and if a policy counter is about to expire before the interval, CPS sends the policy-counter-stats. Default value is 180 minutes. |
Extract Avps |
See Extract Avps |
The Diameter Defaults section provides global default values for different modules of the system.
In order to define a Diameter Default you need to perform the following steps:
This feature allows the Service Provider to extend the Diameter dictionary with new vendor specific AVPs along with a source for that AVP and a destination where the AVP is going to be used.
The feature itself consists of two components:
This table allows for the definition of the custom AVP with all the standard attributes of an AVP.
The following parameters can be configured under Custom Avp Table:
Parameter |
Description |
||
---|---|---|---|
AVP Name |
Any string that is used to identify this custom AVP. |
||
Avp Code |
AVP Code combined with Vendor Id field identifies the attribute uniquely.
|
||
Vendor Id |
It indicates the Vendor Id of the AVP. The following are the supported Vendor Ids: |
||
Vendor Code |
Vendor Id value as assigned by IANA. The Vendor Id bit known as the Vendor-Specific bit indicates whether the optional Vendor Code field is present in the AVP header. When set the AVP Code belongs to the specific vendor code address space. |
||
Mandatory Bit |
Indicates whether support of the AVP is required. If this Bit is checked then Diameter Client Server Proxy and Translation Agent must support the handling of this AVP. |
||
Protected Bit |
Indicates the need for encryption for end-to-end security. If this bit is checked indicates that AVP data is encrypted for end-to-end security. |
||
Vendor Id Bit |
Indicates whether the optional Vendor-ID field is present in the AVP header. |
||
Data Type |
Any valid basic AVP data format |
This table allows for the mapping between the source and the destination for the custom AVP (defined in the previous section). Multiple attributes can be used to identify both the source for the custom AVP value as well as the destination where the AVP is going to be used.
The following mappings are supported:
Custom AVP to Custom AVP Mapping
The following parameters can be configured under Custom AVP to Custom AVP Mapping:
Parameter |
Description |
---|---|
Source Avp |
Name of AVP that has to be looked up for possible mapping. |
Source App Id |
The Application Interface Id (Gx) in numeric format (16777238) on which the Source AVP is received. |
Source Cmd Code |
The command code of the message on interface Source APPID that contains the Source AVP. |
Source Cmd Type |
|
Origin Host |
This field contains the identification of the source point of the operation. |
Origin Realm |
This field contains the identification of the realm of the operation originator. |
Target Avp |
AVP Name that is actually mapped to Source AVP. |
Target App Id |
Target Application Identifier (Sy - 16777302 - for this release). |
Target Cmd Code |
The command code of the message that goes on Target APPID and have Target AVP. |
Target Cmd Type |
The message having Target Command Code request or a response. |
Destination Host |
This field contains the identification of the destination point of the operation. |
Destination Realm |
This field contains the realm of the operation destination. |
Response value for Source Cmd Type and Target Cmd Type is not currently supported.
3gpp / spr AVP to 3gpp AVP Mapping
The following parameters can be configured under 3gpp / spr AVP to 3gpp AVP Mapping:
Parameter |
Description |
---|---|
Source Avp |
Name of AVP that has to be looked up for possible mapping. |
Is SPR AVP? |
Check if the source is an SPR attribute. The Source AVP originates from a Source Command or from Subscriber profile in Subscriber Profile Repository. Default value is unchecked. |
Source App Id |
The Application Interface Id (Gx) in numeric format (16777238) on which the Source AVP is received. |
Source Cmd Code |
The command code of the message on interface Source APPID that contains the Source AVP. |
Source Cmd Type |
|
Origin Host |
This field contains the identification of the source point of the operation. |
Origin Realm |
This field contains the identification of the realm of the operation originator. |
Target Avp |
AVP Name that is actually mapped to Source AVP. |
Target App Id |
Target Application Identifier (Sy - 16777302 - for this release). |
Target Cmd Code |
The command code of the message that goes on Target APPID and have Target AVP. |
Target Cmd Type |
The message having Target Command Code request or a response. |
Destination Host |
This field contains the identification of the destination point of the operation. |
Destination Realm |
This field contains the realm of the operation destination. |
Response value for Source Cmd Type and Target Cmd Type is not currently supported.
3GPP / SPR AVP to Custom AVP Mapping
The following parameters can be configured under 3GPP / SPR AVP to Custom AVP Mapping:
Parameter |
Description |
---|---|
Source Avp |
Name of AVP that has to be looked up for possible mapping. |
Is SPR AVP? |
Check if the source is an SPR attribute. The Source AVP originates from a Source Command or from Subscriber profile in Subscriber Profile Repository. Default value is unchecked. |
Source App Id |
The Application Interface Id (Gx) in numeric format (16777238) on which the Source AVP is received. |
Source Cmd Code |
The command code of the message on interface Source APPID that contains the Source AVP. |
Source Cmd Type |
|
Origin Host |
This field contains the identification of the source point of the operation. |
Origin Realm |
This field contains the identification of the realm of the operation originator. |
Target Avp |
AVP Name that is actually mapped to Source AVP. |
Target App Id |
Target Application Identifier (Sy - 16777302 - for this release). |
Target Cmd Code |
The command code of the message that goes on Target APPID and have Target AVP. |
Target Cmd Type |
The message having Target Command Code request or a response. |
Destination Host |
This field contains the identification of the destination point of the operation. |
Destination Realm |
This field contains the realm of the operation destination. |
Response value for Source Cmd Type and Target Cmd Type is not currently supported.
This feature allows for different PCC rules to be installed on a per time-of-day basis. Based on the defined schedules PCRF will look ahead one scheduled interval every time the policy is re-evaluated and will schedule for each PCC rule an activation time using the Rule-Activation-Time AVP and de-activation time using the Rule-Deactivation-Time AVP.
The ToD Schedule can be referenced only from a PreDefinedRule, PreDefinedRuleBase or a PreConfiguredRule service configuration object.
In order to use a ToD Schedule in a Service Option you need to perform the following steps
For more details about how to define a service option refer to Services.
This section supports the Sd solicited reporting scenario when the TDF-Information grouped AVP is not sent from the PCEF to the PCRF in a Gx CCR-i. For more information on Sd solicited reporting refer to 3GPP TS 29.212.
The following parameters can be configured under Sd Push Rules:
Parameters |
Description |
---|---|
Sync TSR |
Select to enable TSR in sync mode. |
Time To Live in Cache (ms) |
When Sd Sync mode is enabled, determines how long the Gx CCA-I response is stored in the session before retracting the stored response to be sent to PGW after Sd TSR/TSA exchange occurs between PCRF and TDF. This value is recommended to be higher than the PGW timeout. |
Parameter Type |
Message |
Attribute |
AVP |
---|---|---|---|
Input |
Gx CCR-i |
Gx Realm |
Origin-Realm |
Gx Host Pattern |
Origin-Host |
||
Output |
Sd TSR |
TDF Realm |
Destination-Realm |
TDF Host |
Destination-Host |
Note |
|
This section provides default values to be used for Gx default bearer QoS parameters as well as some specific behavior related to default bearer QoS.
The following parameters can be configured under Gx Profile:
Parameter |
Description |
---|---|
Push Pre Configured Rule Options |
Controls whether the configured default bearer QoS will be installed on the default bearer or on the secondary bearers. |
Logical Apn |
Allows for a default APN name to be defined. This APN name is going to be further used as an input into the AF Application Id Validation feature described below. The APN value will be set based on the available data and the priorities described below. |
Gx Client QoS Exclusion List |
Gx client names that are allowed not to have a default bearer QoS installed. In case a default bearer QoS has not been configured in the policy and the Gx client name has not been added to this list an error response will be sent to the PCEF containing the Result-Code AVP value DIAMETER_ERROR_BEARER_NOT_AUTHORIZED (5143). |
Grant Requested QoS |
Controls whether the requested QoS should be granted or not as the default bearer QoS. Default value is unchecked. |
Grant Requested Qos Over Global Qos |
If this option is selected then the requested QoS should be granted even if the global QoS is provisioned. There are three type of QoS first is taken from service second is from default QoS and third one is from request. If this flag is checked then requested QoS will take priority over default QoS. Default value is unchecked. |
Global Default Granted QoS |
|
Qci |
The QoS class identifier identifies a set of IP-CAN specific QoS parameters that define QoS excluding the applicable bitrates and ARP. It is applicable both for uplink and downlink direction. The QCI values 0 10 – 255 are divided for usage as follows |
Max Req Bandwidth UL |
It defines the maximum bit rate allowed for the uplink direction. |
Max Req Bandwidth DL |
It defines the maximum bit rate allowed for the downlink direction. |
Guaranteed Bit Rate UL |
It defines the guaranteed bit rate allowed for the uplink direction. |
Guaranteed Bit Rate DL |
It defines the guaranteed bit rate allowed for the downlink direction. |
Apn Agg Max Bit Rate UL |
It defines the total bandwidth usage for the uplink direction of non-GBR QCIs at the APN. |
Apn Agg Max Bit Rate DL |
It defines the total bandwidth usage for the downlink direction of non-GBR QCIs at the APN. |
Enable Pending Policy Evaluation |
When selected, pending policy calculation is enabled for one look ahead in advance. Default value is unchecked. |
Select the Arp type from the drop-down list to open parameters for the corresponding selection. ARP is used to indicate the priority of allocation and retention.
The following parameters can be configured under Arp:
Selection |
Parameters |
Description |
---|---|---|
Allocation Retention Priority |
Priority Level |
The priority level is used to decide whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). The AVP can also be used to decide which existing bearers to pre-empt during resource limitations. The priority level defines the relative importance of a resource request. Values 1 to 15 are defined with value 1 as the highest level of priority. |
Preemption Capability |
If it is provided within the QoS-Information AVP the AVP defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. If it is provided within the Default-EPS-Bearer-QoS AVP the AVP defines whether the default bearer can get resources that were already assigned to another bearer with a lower priority level.
|
|
Preemption Vulnerability |
If it is provided within the QoS-Information AVP the AVP defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. If it is provided within the Default-EPS-Bearer-QoS AVP the AVP defines whether the default bearer can lose the resources assigned to it in order to admit a pre-emption capable bearer with a higher priority level.
|
|
Application QoS Policy |
AF Application Identifier Pattern |
It contains information that identifies the particular service that the AF service session belongs to. This information may be used by the PCRF to differentiate QoS for different application services. You can specify regular expressions for this parameter as needed. |
Media Type |
Applicable Media-Type (session level or specific to Media-Component-Description). The list includes Audio Video Data Application Control Text Message and Other. |
|
Reservation Priority QoS Policy |
Reservation Priority |
The Reservation Priority includes the priority value of the related priority service. The Reservation Priority is populated with a default value if the priority value is unknown. |
Base MPS QoS/Base MPS QoS Gx |
Qci |
The QoS class identifier identifies a set of IP-CAN specific QoS parameters that define QoS excluding the applicable bit rates and ARP. It is applicable both for uplink and downlink direction. The QCI values 0 10 – 255 are divided for usage as follows: |
MPS QoS |
MPS Id |
The MPS Id contains the national variant for MPS service name indicating an MPS session. |
Media Type |
Applicable Media-Type (session level or specific to Media-Component-Description). Select from drop-down list. The list includes Audio Video Data Application Control Text Message and Other. |
Use this checkbox to enable the functionality for supporting old event-trigger value (26) for the usage report. This configuration will be applicable only when CPS is configured to use R10 event-trigger values by unchecking the 'Use V9 Event Trigger Mapping' flag in Diameter Configuration.
Peers using Event-Trigger value (26) for USAGE_REPORT
The following table contains the list of realm and host entries for which CPS will support old event-trigger value (26) for USAGE_REPORT.
The parameters can be configured under Relaxed USAGE_REPORT Event-Trigger Handling:
Parameter |
Description |
---|---|
Realm Pattern |
The pattern that peer realm name should match in order for this diameter client to be used. The pattern needs to follow the standard Java regular expression syntax described here. |
Host Pattern |
Host name pattern as received in Origin-Host AVP in AAR message. The pattern needs to follow standard Java pattern conventions. The pattern needs to follow the standard Java regular expression syntax described here. |
Use this check box to receive APN-AMBR_FAILURE_MODIFICATION events from PCEF.
The following parameters can be configured under QoS retry on APN-AMBR_FAILURE_MODIFICATION:
Parameter |
Description |
---|---|
Number Of Retry |
Number of retries to push calculated QoS information. |
QoS Retry Options |
In the case GGSN sends APN-AMBR_FAILURE_MODIFICATION report to CPS, following are the retry options in which CPS sends the QoS information:
|
Action On QoS Retry Exhaust |
CPS retries sending the QoS information "n” times, to avoid looping. After exhaustion of the retries, following are the options:
|
Time To Trigger Release RAR In Minutes |
CPS sends RAR with Release Cause value as UNSPECIFIED_REASON after the time configured in Time To Trigger Release RAR expires. |
Time To Reset QoS Retry Counter In Minutes |
Once CPS receives APN-AMBR_FAILURE_MODIFICATION, CPS sets next reset timer to value configured in Time to Reset QoS Retry Counter. If CPS does not receive APN-AMBR_FAILURE_MODIFICATION within this specified time, CPS resets the retry count to 0. |
This section provides default values to be used if MPS feature is needed to support eMPS priority. The MPS Profile provides MPS attributes required for priority service provisioning. The priority level value from Service configuration takes precedence over MPS Profile value.
Note | There must be at least one Mps Profile defined under Mps Profiles. |
The following parameters can be configured under Mps Profile:
Parameter |
Description |
---|---|
Ims Apn |
List of IMS APNs for which the MPS feature is supported. This field can accommodate several Ims Apn that are used to match with the incoming service request for priority service. The values that are received by the Default Bearer QoS are looked up for a suitable Ims Apn match. If the APN value of a Gx session request matches IMS APN IMS signaling priority from EMPS service is used as priority level. |
Mps QoS |
For information on parameters under Mps QoS refer to Table 1. |
For additional information on 3GPP specifications refer to http//www.3gpp.org/DynaReport/29212.htm.
The above link is compliant with Release 11.
This section provides default and specific values to be used by the different QoS parameter mapping functions at PCRF as per 3GPP TS 29.213. This section also provides a mechanism to authorize the Rx IMS sessions.
Prefer answer Codec-Data: Select Prefer answer Codec-Data if you want the default priority to be given to the answer codec (when both answer and offer are present within the AAR). By default, this option is unchecked (not selected).
Disable Always On EMPS Service: If the checkbox is selected, then the feature Always On EMPS Service gets disabled otherwise the feature works by default (when the checkbox is not selected).
Default QoS Policy
Provides the values to be used during the derivation of the Maximum Authorized Data Rates Authorized Guaranteed Data Rates Maximum Authorized QoS Class per IP flow or bidirectional combination of IP flows in the PCRF and for calculating the Maximum Authorized/Guaranteed Data Rates QCI and ARP in the PCRF whenever the “as set by the operator” phrase is used in the algorithm description.
For description of different parameters under Default QoS Policy refer to Table 1.
Rx Sync Mode
The following tables describes parameters under the Rx Sync Mode:
Parameters |
Description |
---|---|
Sync AAR |
Select to enable AAR in sync mode. |
Sync STR |
Select to enable STR in sync mode. |
Time To Live in Cache Millis |
When Rx Sync mode is enabled, determines how long the Rx AAR/STR response is stored in the session before retracting the stored response to be sent towards PCSCF after Gx RAR/RAA exchange occurs between PGW and PCRF. This value is recommended to be higher than the PCSCF timeout. |
MPS QoS Policy
Provides a way to derive QoS attributes for MPS sessions based on some other AVP values.
For description of different parameters under MPS QoS Policy refer to Table 1.
Note | A Media-Type having an empty label shall be used only to get the output values to be used for default bearer QoS. |
Application QoS Policy
Provides a way to derive Rx dedicated bearers QoS attributes based on AF-Application-Identifier AVP value as per 3GPP TS 29.213.
For description of different parameters under Application QoS Policy refer to Table 1 and Table 1.
Codec QoS Policy
Provide a way to derive Rx dedicated bearers QoS attributes based on Codec-Data AVP value as per 3GPP TS 29.213.
For description of different parameters under Codec QoS Policy refer to Table 1 and Table 1.
The additional parameters Codec Data Pattern and Codec Details Pattern contains codec related information known at the AF. This information is encoded as per 3GPP 29.214 specifications
The first line of the value of the Codec-Data AVP consists of either the word uplink or the word downlink (in ASCII) followed by a new-line character. The semantics of these words are the following:
uplink indicates that the SDP was received from the UE and sent to the network.
downlink indicates that the SDP was received from the network and sent to the UE.
The second line of the value of the Codec-Data AVP consists of either the word offer, the word answer, or the word description.
The rest of the value consists of the SDP line(s) in ASCII encoding separated by new-line characters, as specified in IETF RFC 4566. The first of these line(s) is an m line. The remaining lines are any available SDP a and b lines related to that m line.
Restrictions
You should not configure 'Codec QoS Policy' table with ambiguous entry. If multiple rows are configured which matches same 'Codec-Data' and 'Codec-Details' values then CPS will fetch first matched row.
Codec-Data column value is mandatory in Policy Builder configuration while adding entry in the 'Codec QoS Policy' table.
CPS considers the first Codec-Data AVP if AAR request has multiple 'Codec-Data' AVPs.
By default, CPS uses the first Codec-Data AVP with offer or answer on the second line if the AAR request has multiple Codec-Data AVPs. If Prefer Answer is set to true, CPS uses the first Codec-Data AVP with answer on the second line, or the first Codec-Data AVP with offer if there is no Codec-Data AVP with answer.
CPS considers only the first media format in the m= line.
If multiple Codec-Data AVPs are reported in multiple AAR messages for a single Rx session then CPS will consider the first Codec-Data AVP value received in first AAR message for selecting QoS policies.
For example:
uplink offer m=audio 50000 RTP/AVP 116 107 97 115 111 110 a=rtpmap116 AMR-WB/16000 a=rtpmap107 AMR-WB/16000 a=rtpmap97 AMR/8000 a=rtpmap115 AMR/8000 a=rtpmap111 telephone-event/16000 a=rtpmap110 telephone-event/8000 a=currqos local none a=currqos remote none a=desqos mandatory local sendrecv a=desqos optional remote sendrecv a=sendrecv a=ptime20 a=maxptime240
Example:
Consider you want to configure “Codec Data Pattern 98" and “Codec Details Pattern AMR/8000”.
There are multiple combination you can configure. Some examples are given below :
With ExactMatch:
With wildcards
AM.*80 indicates that String that has AM and any number characters and 80. It does not mean that string should start with AM and end with 80.
If you want to specify starting and ending characters explicitly then you should use '^' for starting (say ^77 value should start with 77) and '$' for ending (say AM.*80$ value should end with 80); you should configure the 'Codec Data Pattern' and 'Codec Details Pattern' column as per the standard Java regular expression syntax.
Suppose you configure multiple rows matching the same values; for example, as shown in the following figure, both rows can be matched with values “Codec-Data 98 and Codec-Details AMR/8000." In this case, CPS will select the first matched row.
Reservation Priority QoS Policy
Provides a way to derive Rx dedicated bearers QoS attributes based on Reservation-Priority AVP value as per 3GPP TS 29.213.
For description of different parameters under Reservation Priority QoS Policy refer to Table 1 and Table 1.
Af Application Id Validation
Provides a way to authorize the Rx IMS sessions. In case there's not a match between the AVP values below in the table the PCRF shall send an error response to the AF containing the Experimental-Result-Code AVP with value REQUESTED_SERVICE_NOT_AUTHORIZED (5063) as per 3GPP TS 29.214.
Interface |
AVP Value |
Gx |
Refer to Logical APN attribute under Gx Profile. |
Rx |
AF-Application-Identifier |
Media-Type |
Note |
|
You can get access to these features by creating child objects to your Rx profile object.
Note | There should be at least one object of each type for any Rx profile object or the results will be unpredictable. The Policy Builder GUI does not enforce this restriction though. |
The Sponsored Data Charging Parameters allows you to configure specific charging parameters for the Sponsored Data scenarios depending on some AVPs from the incoming Rx AAR. These parameters are going to be set under Charging-Rule-Definition grouped AVP.
The required charging parameters are as follows:
To map the above mentioned parameters the following keys are used:
These keys are applicable for Sponsored Data Charging Parameters only.
The mapping configuration for the charging parameters is configured under
.In the Sponsor Data Charging table, you can define the parameter values in all the columns including the values for the key parameters such as - Sponsor Identity App Service Provider Identity and Media Type.
Defines the default values for the sponsor data charging parameters under Charging-Rule-Definition grouped AVP to be used in case there's no match in the Sponsor Data Charging. This configuration is optional. Default value is unchecked.
The following parameters can be configured under Sponsor Data Charging:
Parameter |
Description |
---|---|
Service Identifier |
The identity of the service or service component the service data flow in a PCC rule relates to. |
Rating Group |
The charging key for the PCC rule used for rating purposes. |
Online |
It defines whether the online charging interface from the PCEF for the associated PCC rule is enabled. The default charging method provided by the CPS takes precedence over any pre-configured default charging method at the PCEF. |
Offline |
It defines whether the offline charging interface from the PCEF for the associated PCC rule is enabled.The default charging method provided by the CPS takes precedence over any pre-configured default charging method at the PCEF. |
Metering Method |
The Metering-Method AVP (AVP code 1007) is of type Enumerated and it defines what parameters shall be metered for offline charging. The PCEF may use the AVP for online charging in case of decentralized unit determination and having three values
|
Reporting Level |
The Reporting-Level AVP is of type Enumerated and it defines on what level the PCEF reports the usage for the related PCC rule.There are three types of reporting levels
|
Precedence |
This determines the order in which the service data flow templates are applied at service data flow detection at the PCEF. A PCC rule with the Precedence AVP with lower value shall be applied before a PCC rule with the Precedence AVP with higher value. |
Sponsor Identity |
Sponsor-Identity AVP value under the Sponsored-Connectivity-Data grouped AVP. |
App Service Provider |
App Service Provider Id is same as Sponsor-Identity. It is an AVP under the Sponsored-Connectivity-Data grouped AVP. |
Media Type |
Applicable Media-Type (session level or specific to Media-Component-Description). Select from drop-down list. The list includes Audio Video Data Application Control Text Message and Other. |
The Dynamic Rule Charging Parameters allows you to configure different charging parameters for the Rx dedicated bearers. Charging parameters are defined for dynamic PCC rules so that the service provider can properly charge for the traffic. For each Media-Sub-Component grouped AVP under Media-Component-Description grouped AVP in an AAR request PCRF installs a dynamic charging rule. The charging parameters for these dynamic PCC rules are not included in the AAR message so they are pulled out from the configuration.
In the Charging Parameters table, you can define the parameter values in all the columns including the values for the key parameters such as - AF Application Identifier Pattern and Media Type.
The AF Application Identifier Pattern parameter contains information that identifies the particular service that the AF service session belongs to. This information may be used by the PCRF to differentiate QoS for different application services. You can specify regular expressions for this parameter as needed.
Defines the default values for the charging parameters under Charging-Rule-Definition grouped AVP to be used in case there's no match in the Charging Parameters table. This configuration is optional. Default value is unchecked.
For description of different parameters under Dynamic Rule Charging Parameters refer to Table 1.
Note |
|
In the Rx STG lookup binding you can define the STG that is based on Rx media information (such as, media-type, af-application-id, and so on) and specify the mappings for binding the CRD columns to input and output AVPs.
CPS evaluates the CRD tables defined under Rx STG lookup binding using the media information available in the rx-sessions after the evaluation of all CRDs by the framework.
The following parameters can be configured under Rx STG lookup binding:
Parameter |
Description |
---|---|
Name |
The name of the Rx STG lookup binding. |
Stg Reference |
Reference to the Search Table Group containing the CRD tables that defines parameters for Rx specific media information. |
List Of Input Column Avp Pairs |
Defines the mapping between the AVP Names and the key Columns defined in the selected STG. These AVPs are inputs while evaluating the CRD table in STG. |
List Of Output Column Avp Pairs |
Defines the mapping between the AVP Names and the output columns defined in the STG selected. These mapping indicate how the output column's values are mapped to AVPs after the CRD is evaluated.
|
Evaluation of STGs defined in Rx STG lookup binding (evaluated for each media in the Rx session) creates multiple Rx CRD result AVP for each configured output column. Along with the code and CRD output value, this result AVP also stores the media component details such as, Media-Component-Number, Media-Type and Rx session-id. This information can be used for creating conditions (for example, An Rx CRD result Avp exists).
CPS can be configured to selectively re-attempt to install rules that fail to install or activate. Upon receipt of a Charging-Rule-Report indicating the failure to install or activate one or more rules CPS will evaluate the failed rules and take further action.
CPS decides whether to reinstall a failed rule based on the Rule Retry Profile configured for the rule. The configuration of this Rule Retry behavior takes place in the Rule Retry Profile screen in Policy Builder.
Step 1 | Login to Policy Builder. | ||||||||||||||||||||
Step 2 | Go to . | ||||||||||||||||||||
Step 3 | From the right
pane, click
Rule
Retry Profile under
Create
Child to open a Rule Retry Profile.
The following parameters can be configured for each Rule Retry Profile:
If there is still time to retry a rule installation (First Retry Time + Max Retry Interval <= Current Time) then the rule status and failure code are not updated immediately such that no policy change based on rule failure status is triggered. |
This table is used to override the attributes Retry Interval, Backoff Algorithm, Max retry Attempts, and Max Retry Interval of generic profile which is already available.
CPS uses the following columns to select a row from this table:
Note |
|
This parameter is used to derive SyRealm from CRD. User has to select CRD output column so that SyRealm value is pulled from the CRD table. If there is no Sy realm value derived from this field, then CPS tries to get the realm information from local Sy session.
The CRD output column values takes precedence over local Sy session.
Each type of Service Configuration Object Rule in CPS (PreDefinedRule PreDefinedRuleBase PreConfiguredRule) can be associated with the Rule Retry Profile created in the previous section.
Step 1 | In Policy Builder select the Services tab. |
Step 2 | From the left pane select Services. |
Step 3 | Expand Service Options tree. |
Step 4 | Select and expand your service option. |
Step 5 | Select the service option object. |
Step 6 | In the Service Option screen select the Service Configuration object. A Rule Retry Profile can be referenced only from a PreDefinedRule, PreDefinedRuleBase or a PreConfiguredRule service configuration object. |
Step 7 | Select the Value cell corresponding to the Retry Profile. |
Step 8 | Click the “…” button. |
Step 9 | Select the Rule Retry Profile from the popup window then click OK. |
Step 10 | Click
OK.
For more details about how to define a service option refer to Services chapter. |