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. |
||
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. |
![]() 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. |
Inbound Message Queue Size |
Number of messages waiting to be processed before the inbound overload feature is activated. Default value is 15000. |
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. |
Emergency Message Priority |
Default priority assigned to messages related to an emergency session. Default value is 0. |
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. |
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 2. |
Parameter |
Description |
---|---|
inboundMessageSlaMs |
This parameter specifies 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 for processing failing which the Default Discard Behavior is applied. If inboundMessageSlaMs is not defined in qns.conf file then the default value of 1500 is used. Example:
After
modifying the configuration on Cluster Manager execute
|
inboundMessageQueueSize |
This parameter specified the number of messages waiting to be processed before the inbound overload feature is activated. If inboundMessageQueueSize is not defined in qns.conf file then the default value of 15000 is used. Example:
After
modifying the configuration on Cluster Manager execute
|
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 is to match the value of the CC-Request-Type AVP only for CCR messages.
|
|
OUTPUT |
Priority |
Priority value assigned to the message. Higher numerical value will be having 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 |
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 will advertise its own origin host and realm values when the diameter connection is established all the diameter application messages will 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 will always be delivered on the same connection where the request was received or will not be 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, 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. 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.
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 |
||
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.
|