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 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
Example:
After
modifying the configuration on Cluster Manager execute
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
Example:
After
modifying the configuration on Cluster Manager execute
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.
|
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 |
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 |
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 |
|
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) |
The amount of time in milliseconds for CPS to wait before retry. 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 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.
|