Diameter Configuration
The Diameter Configuration section allows for the configuration of the diameter plug-in. We recommend configuring the diameter plug-in at system level.
At System Level
In order to define a Diameter Configuration at system level, you need to perform the following steps:
- Login into Policy Builder.
- Select Reference Data tab.
- From the left pane, select Systems.
- Select and expand your system name.
- Select Plugin Configurations.
- Select Diameter Configuration.
At Cluster Level
In order to define a Diameter Configuration at cluster level you need to perform the following steps:
- Log in into Policy Builder.
- Select Reference Data tab.
- From the left pane, select Systems.
- Select and expand your system name.
-
Select and expand your cluster name. If no cluster has been created, create one by selecting the Cluster action.
- Select Plugin Configurations.
- Select Diameter Configuration.
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 |
Inbound Message Overload Handling
This feature provides a mechanism for the OAM (PCRF) protection when the configured value of handling incoming messages exceeds. It provides a way to prioritize the incoming messages and selectively process them.
The following parameters can be configured under Inbound Message Overload Handling window:
Parameter |
Description |
||
---|---|---|---|
Default Priority |
Default priority to be assigned to an incoming message if no specific priority is defined in the Message Handling Rules table. Default value is 0. |
||
Message Sla Ms |
Service Level Agreement (SLA) in milliseconds, defines the number of milliseconds that are associated with an incoming event or message within which Policy Director (load balancer) has to submit it to Policy Server (QNS) for processing. In case the configured duration times out, the Default Discard Behavior is applied. Maximum time (in millisec) that a message has in an inbound message handling queue waiting for a worker thread. Configuring this value avoids processing a message to time out by a remote peer. An SLA time that is too large can result in wasted processing on messages already timed out on a remote peer (i.e. PGW) and creation of stale sessions. An SLA time that is too small can result in dropping the messages that could have been successfully processed. Default value is 1500 ms.
If you have not selected Inbound Message Overload Handling check box under Diameter Configuration, you can define Example: After modifying the configuration on Cluster Manager execute If you select Inbound Message Overload Handling check box under Diameter Configuration, then the value you configured in Policy Builder is used. The "Message Sla Ms" time out configuration value should be less than the timeout value in PGW or 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 under Diameter Configuration, define Example:
After
modifying the configuration on Cluster Manager execute
If InboundMessage Overload Handling check box is selected under Diameter Configuration, then the value you configured in Policy Builder is used.
|
||
Default Instance Rate Limit |
Use this parameter to trigger the overload protection handling. If this is configured to value x TPS, then whenever x exceeds CPS applies message handling rules to additional requests. 0 (default) TPS indicates no limit.
Default value is 0. |
||
Gx Emergency Message Priority |
Default priority assigned to messages related to an emergency session. This parameter categorizes Gx messages as emergency priority based on APN. Emergency priority messages are queued ahead of non-emergency service messages for quick servicing and prevent them from being dropped using overload controls. If the queue is full, the lowest-priority message is dropped. Recommended Value: Regex match of SOS APNs for emergency priority classification. Set emergency priority to highest for priority handling in Policy Server (QNS) Inbound Message Queue. Default value is 1. |
||
Default Discard Behavior |
Default behavior to be applied to an incoming message if no specific priority is defined in the Message Handling Rules table.
Default value is MESSAGE_DROP. |
||
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. When Rx Message Prioritization is enabled and if MPS-Identifier and Reservation-Priority AVPs are available in Rx_AAR, then the messages are not dropped even in overload condition. Depending on the message Priority defined in table, the message can be moved to the front in the inbound queue. This feature indicates that, the Rx_AAR is prioritized based on MPS-Identifier and Reservation-Priority AVPs configured only. If the inbound message doesn’t have these parameters included, the message is not prioritized. Prioritization of messages is only applicable to incoming request messages. For more information on parameters, see Table 2. |
||
Message Handling Rules |
Defines specific inbound message overload handling rules based on different criteria. For more information, see Table 3. |
Note |
If you do not select Inbound Message Overload Handling check box in Diameter Configuration, you can define inboundMessageSlaMs and inboundMessageQueueSize in /etc/broadhop/qns.conf file. For more information, see 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. MPS-Identifier value = <NS (National Security) Specific To Deployment> |
Reservation Priority |
The AF specifies 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 available at the request level only is used under Rx Message Prioritization table. Range: Any number Example: 10 |
Priority |
A user defined priority based on MPS-Identifier and Reservation-Priority combination. Make sure that the Message priority defined in Rx Message Prioritization table and should be unique per row. Higher Priority messages are processed first compared to lower priority messages. Range: Any number (User priority) Example: 10 |
Note |
Rx Message Prioritization table does not supports multiple values in a single column. Rx Message Prioritization table must be configured with unique combination for each row. |
Parameter Type |
Attribute |
Description |
---|---|---|
INPUT |
Diameter Client |
(Optional) This field is used to configure different priorities for different clients based on realms. For more information, see Diameter Clients. |
Protocol |
Specific application id value to be used for scoring. This value is used to match Auth-Application-Id AVP value. For more information, see Table 4. |
|
Command Code |
Specific command code value to be used for scoring. This value is used 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 value should match the value of the CC-Request-Type AVP for Gx CCR messages.
Default value is 0. Request type should match the value of the Rx-Request-Type AVP for Rx AAR messages.
Request type should match the value of SL-Request-Type AVP for Sy SLR messages. The possible values are:
It has to be configured 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 is unavailable 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. For example, 10, 20, 100, 200, 300, 500 and so on. |
Per Instance Tps |
Transactions per second limit per process. This value 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. For example, 1000, 2000, 5000 and so on. |
|
Discard Behavior |
Behavior to be applied to an incoming message.
Default value is MESSAGE_DROP. |
Note |
A Diameter message even if prioritized under an overload condition could be dropped by CPS if one of the following conditions are met:
|
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 |
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 |
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 |
Note |
When a Diameter Stack with a diameter realm is imported with unassigned protocol, the default value of GX_TGPP is used. |
Stale Session Message Handling Configuration
This feature enables CPS application to act according to the configuration when request processing crosses the given SLA time period for the incoming request. When the feature is enabled the request or responses which are crossing the configured SLA are dropped.
By default, stale session message handling is disabled. To enable this configuration, you need to configure the Stale Session Message Handling configuration in Policy Builder and publish the changes.
Note |
The configuration changes are reflected at the run time and no process restart is required. |
The following table describes the parameters under Stale Session Message Handling Configuration.
Parameter |
Description |
---|---|
End to End Sla Ms |
Maximum time in milliseconds the CPS system must take for request processing. The request processing time for this value must be LB > QNS > DB > QNS > LB round trip. Default: 2000 ms |
Include Request LB queue time in QNS SLA |
When checked, LB - QNS request queue time is considered in QNS SLA when enabled. Default value is disabled. |
Note |
|
Next Hop Routing
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 |
The order in which the DRA hosts are provisioned in the Next Hop Hosts field for any given next hop route is not relevant. The DRA host having the highest rating (priority) value is used. In case multiple hosts have the same rating one is randomly selected. Refer to Diameter Stack Configuration for more details about host rating. Outbound realm rating of next hop is not considered except for SY_PRIME. |
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
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 retries 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) |
Default: 0 |
||
Retry Count |
The number of times to retry when the action is “Retry”.
Default: 1 |
||
Retry on Alternate Node |
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 then 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, then 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, then this configuration
takes precedence over qns.conf file parameters.
Result Code Based Action Configuration
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.
Parameter |
Description |
||||||
---|---|---|---|---|---|---|---|
Application Id |
The diameter interface in numeric format (Auth-Application-Id) on which the message is received. For example Sy (16777302) and Sd (16777303). Currently only Sd and Sy interfaces are supported. Default: 0 |
||||||
Command Code |
The diameter message type. For example SLR (8388635) in case of Sy and RAR (258) in case of Sd. Default: 0 |
||||||
Realm |
New key added as Sy client realm. If the realm value is not specified, then the realm key is not be considered (CPS only performs
action on key |
||||||
Request Type |
The request type of the message for Sy interface. For example INITIAL_REQUEST (0) INTERMEDIATE_REQUEST (1). For Sd Request Type is not valid. Default: 0 |
||||||
Result Code |
The result-code received in the response for which the action over Gx and/or Sy/Sd is to be taken. 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 to be taken over the Sy/Sd interface when the response is received. Possible actions are Continue/Terminate/Reinitiate.
|
||||||
Action Over Gx |
The action to be taken over the Gx interface when the response is received. Possible actions are None/Terminate/Reauthorize. Currently Action over Gx is not supported for Sd RAR.
The Gx Network Device Manager would then perform the ReAuthorization by sending RAR over Gx interface. On receiving RAA the action over Sy interface would then be performed. If the Gx session is stale and we receive DIAMTER_UNKNOWN_SESSION_ID the Sy session would then be automatically terminated irrespective of the action configured on Sy interface.
|
Message Buffering Configuration
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.
CPS goes through all the rows one by one and verifies whether configured AVP exist in the incoming message and buffers the message accordingly. |
||
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. |
Memory Impact
-
The memory usage of diameter endpoint process (qns process on lb) may be increased when it starts buffering messages for multiple sessions.
Configuration and Restrictions
-
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
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.
|
||
Enable Proxy |
When checked, it makes sure P-Bit is set and Destination-Host AVP is not set for the outgoing AAR messages for PAS Health check. Default value is unchecked. |
Note |
To improve the performance when PolicyDRA Health Check is enabled, you must configure ‘RxClientSessionKey’ key as the Lookaside Key Prefix so that memcache is used and full database scan is avoided. This is highly recommended for higher capacity systems. |
Diameter Messages Action on Threshold in LB
When Diameter Messages Action on Threshold in LB check box is enabled and Diameter Message Count Threshold for PD is configured with value greater than 0, the Policy Director processes keep track of messages being handled at process level and when number of messages being tracked crosses the configured Diameter Message Count Threshold for PD, the messages are dropped or responded with DiameterBusy.
Diameter Messages Action on Threshold in LB configuration is optional. When this configuration is not used, all the messages are sent from LB (Policy Director) to Policy Engines.
-
The following parameters can be configured under Diameter Messages Action on Threshold:
Table 14. Diameter Messages Action on Threshold Parameter
Description
Diameter Interface
Diameter Interface in Diameter message selected from drop-down list.
Command Code
Command code in Diameter message.
When Command Code is set to 0, it applies to all Command Codes of the Application ID configured in the row.
Request Type
CCR Request type.
Default value is 0.
When Request Type is set to 0, it applies all the CCR Request types, namely Initial(1), Update(2) and Terminate(3). For non-CCR messages default 0 is must be set.
Action
What action to take when the Diameter message is received at LB (Policy Director) when outstanding Diameter messages have reached the Message Count Threshold.
Possible Values: MESSAGE_DROP and DIAMETER_TOO_BUSY
Default value is MESSAGE_DROP.
-
Diameter Message Count Threshold for PD: This value defines the maximum number of a Diameter Inbound/Outbound messages per PD (Policy Director) process from the table Diameter Messages Action on Threshold in LB. Default value is 0.
-
Max TPS per PD: Defines maximum TPS supported per PD process. Default value is 0.
-
Default Discard Behavior: Describes the action to be taken when a Diameter request message is received in LB and rate limiter acquire fails. Possible values include MESSAGE_DROP and DIAMETER_TOO_BUSY. Default value is MESSAGE_DROP.
Note
If DIAMETER_TOO_BUSY is selected from the drop-down list, at very high TPS, it can lead to higher CPU consumption on Policy Director (LB) VM. This can lead to performance degradation. Cisco recommends using MESSAGE_DROP.
Session Id Handling Configuration
Session Id Handling Configuration provides an option to parse part of the Diameter session ID attributes and store them in session AVP.
The following table describes parameters that can be configured under Session Id Handling Configuration.
Parameter |
Description |
---|---|
Diameter Interface |
Diameter Interface DM for which the Session ID handling is required. |
Input Regex |
Provide an inverse regex to derive the new AVP. Example: Consider the Session ID is pcef01.dstest01.2b4.gx;375030;1285311481;BB2001@MCC2001. To get the Gw_Version BB2001@MCC2001, write an inverse regex ".*;.*;.*;" which returns BB2001@MCC2001 as value. |
Output Policy AVP Name |
Policy derived AVP name to be stored. |
Save to Session |
Save the policy derived AVP to session. |
Origin Realm |
Origin-realm from the diameter request message to parse the session ID. |
Origin Host |
Origin-host from the diameter request message to parse the session ID. |
Gx Offline Stale Session Cleanup
Important |
This feature is only enabled for deployments with arbitervip running on pcrfclient VMs. |
Stale session builds up due to network issues, timeout at PAS and so on. As a result CPS starts rejecting new sessions due to capacity or session license limit. The offline Stale Session cleanup helps to remove the stale sessions having duplicate IMSI and AON combination.
Execute the following command in the pcrfclient where the application is running to stop the application:
monit stop stale-session-cleaner-helper
Execute the following command in the pcrfclient where the application is not running to restart the application:
monit restart stale-session-cleaner-helper
The following table lists parameters in the /etc/broadhop/stale-session-cleaner/stale-session-cleaner.conf file
:
Parameter |
Description |
---|---|
-Dadmin.primary.host |
VM name which hosts the primary member of the PCRF Admin replica-set. Any sessionmgr VM names. Default value is localhost. Example: sessionmgr01 |
-Dadmin.secondary.host |
VM name that hosts a secondary member of the PCRF Admin replica-set. If the primary Admin member fails, the Stale Session Cleaner tries to connect to this secondary member. Any sessionmgr VM names. Default value is localhost. Example: sessionmgr02 |
-Dadmin.port |
Port of the PCRF Admin replica-set. Possible values can be Integers. Default value is 27017. Example: 27721 |
-Dmemcache.host |
The Host on which memcache is running on. Strings in the following format: Default value is localhost. |
-Dmemcache.port |
The Port number of memcache. Possible values are Integers. Default value is 11211. |
-Dtps.per.shards |
Maximum number of executions per second per shard. Possible values are Integers. Default value is 200. |
-Dmongo.query.batch.size |
Number of records in the results for each query to the Session replica-set. Possible values are Integers. Default value is 1000. |
-Dfactor.count.audit.log |
If the number of deleted sessions reaches a multiple of this parameter’s value, it performs audit log. For example, if the parameter value is 100, then the deleted count is printed in the logs on 100 deletions, 200 deletions, 300 deletions, and so on. Possible values are Integers. Default value is 10000. |
-Dsession.count.threshold |
Specify the minimum count of session at which the utility triggers stale session cleanup. Possible values are Integers. Default value is 15000000. |
-Dsession.threshold.timer |
The frequency in minutes where utility monitors session threshold breach to start deletion of stale session. Possible values are Integers. Default value is 5. |
-Dsession.cache.update.timer |
The frequency in minutes where utility updates the latest session ID in the local cache. This parameter should be in the multiple of "session.threshold.timer." Possible values are Integers. Default value is 30. |
-Dnumber.of.shards |
Total number of shards for the Session replica-sets. Possible values are Integers. Default value is 80. |
-Dlogback.configurationFile |
The path to the log configuration file. Any directory path with a logback file for the application. Default value is /etc/broadhop/logback-stale-session-cleaner.xml. |
Cleaning Stale Session
Important |
This feature is only enabled for deployments with arbitervip running on pcrfclient VMs. The services for the application are running on pcrfclient from first deployment, but the application does not start unless the arbitervip is present on the pcrfclient VM. The default value for admin database is 127.0.0.1. Application only starts to delete stale sessions when admin database is correctly configured. |
Stale session build up due to network issues when CPS is processing bulk traffic. Stale sessions are observed when there is an increase in incoming request and timeouts are observed. Session replica-sets are piled-up with the sessions and once the session capacity limit is breached, CPS start rejecting new session requests.
The existence of stale sessions in session replica sets results in storage of duplicate sessions, i.e. multiple sessions from a subscriber UE to the same APN. This feature is to identify the duplicate sessions (match with same IMSI + APN) in regular intervals and keep the latest session and remove the older duplicate sessions to make sure that there is no additional overhead in call processing.
Note |
Enabling/disabling this feature does not have any impact on existing stale session functionality. This utility cleans the stale sessions without sending RARs to the gateway. This utility does not deletes corresponding records from SK database. |
The following table lists parameters in the /etc/broadhop/stale-session-cleaner/stale-session-cleaner.conf file:
Parameter |
Description |
||
---|---|---|---|
-Dadmin.primary.host |
VM name which hosts the primary member of the PCRF admin replica-set. Any sessionmgr VM names. Default value is localhost. Example: Possible Values: Primary Admin database name |
||
-Dadmin.secondary.host |
VM name that hosts a secondary member of the PCRF admin replica-set. If connecting to primary admin member fails, the Stale Session Cleaner tries to connect to this secondary member. Any sessionmgr VM names. Default value is localhost. Example: Possible Values: Secondary Admin database name |
||
-Dadmin.port |
Port of the PCRF admin replica-set. Default value is 27017. Example: Possible Values: Integers (port number) |
||
-Dmemcache.host |
The hostnames on which memcache is running on. Comma separated memcached server hostnames. Utility distributes memcached keys among the specified servers based on consistent hashing.
Default value is pcrclient01,pcrfclient02. Example: Possible Values: Strings in the following format: |
||
-Dmemcache.port |
The port number of memcache. Default value is 11211. Example: Possible Values: Integers |
||
-Dtps.per.shards |
The number of parallel tasks for scanning and cleaning the sessions.
Default value is 200. Example: Possible Values: Integers |
||
-Dmongo.query.batch.size |
The number of records to return in each batch of the response from the MongoDB instance. Default value is 1000. Example: Possible Values: Integers |
||
-Dfactor.count.audit.log |
It prints the logs if the number of deleted sessions reaches a multiple of this parameter’s value. For example, if the parameter value is 100, then the deleted count is printed in the logs on 100 deletions, 200 deletions, 300 deletions, and so on. Default value is 10000. Example: Possible Values: Integers |
||
-Dsession.count.threshold |
Session clean up is kicked in after total active session count is greater than Default value is 15000000. Example: Possible Values: Value must always be greater than total active sessions |
||
-Dsession.threshold.timer |
The frequency in minutes where utility monitors session threshold breach to start deletion of stale session. Default value is 5. Example: Possible Values: Integers |
||
-Dsession.cache.update.timer |
The frequency in minutes where utility updates the latest session ID in the local cache. This parameter should be in the multiple
of Default value is 30. Example: Possible Values: Integers |
||
-Dnumber.of.shards |
Total number of shards for the session replica-sets. Default value is 80. Example: Possible Values: Integers |
||
-Dlogback. configurationFile |
The path to the log configuration file. Default value is /etc/broadhop/logback-stale-session-cleaner.xml. Example:
Possible Values: Any directory path with a logback file for the application. |
||
-DdbPassword |
Configure the database password if MongoDB Authentication is enabled. Example: -DdbPassword=encryptedDbPassword Make sure to restart the Stale session utility after mongo db password change procedure. For more information on MongoDB Authentication, see:
|
Memory and Performance Impact
-
Logs require a maximum of 1.5 GB (stale-session-audit.log) and 1 GB (stale-session-cleaner.log) disk space.
-
The utility JVM process requires 4 GB of additional memory over base pcrfclient VM requirement to run.
-
You must configure a minimum and maximum value of -Xms4g and -Xmx8g for JVM memory in /etc/broadhop/stale-session-cleaner/jvm.conf file.
-
Minimum four additional cores are required for the pcrfclient VM. This number of additional CPU cores depends on the number of shards and TPS per shard.
For example, in a CPS setup, if there are 88 shards and each shard handles 200 TPS, so a total of 17600 TPS is being processed. Then, it is recommended to add 4 cores.
-
Enabling the utility requires additional 15% of CPU usage on each sessionmgr VM.
-
The utility requires requires additional 2 GB memory space and 10% of one CPU (pcrfclient) core for memcache.
-
Memcache server memory allocation depends on the number of unique keys that are saved in memcache with 200 bytes needed for each such entry. When multiple memcache instances are specified then data is distribured among those and memory requirement for each instances must be calculated based on expected number of records that are saved in that instance. The default and minimum required memory allocation for each memcache instance is 2 GB. Memory needed by memcache instance is in addition to the memory required for VMs.
Configuration and Restrictions
Note |
|
Starting and Stopping the Service
-
Execute the following command in the pcrfclient where the application is running (and arbitervip is present) to stop the application:
monit stop stale-session-cleaner-helper
-
Execute the following command in the pcrfclient where the application (and arbitervip is present) is not running to restart the application:
monit restart stale-session-cleaner-helper