Policy Builder Configuration

Plug-in Configuration

Cisco Policy Builder provides core plug-ins for customizing and optimizing your installation.

  • Configurations set at the system level are system-wide except as noted in the bullet items below.

  • Configurations set at the cluster level apply to that cluster and the instances in it. A value set here overrides the same value set at the system level.

  • Configurations set at the instance level apply to the instance only and override the same value set at the cluster or system level.

Select the Create Child action in a Plug-in Configuration node in the Systems tree to define them. You can change any of the variables from the default, or choose not to use a plug-in, as necessary.

When you create a system from the example, the following configuration stubs appear at the cluster and instance level:

Figure 1. Create Child Action


Threading Configuration

A threading configuration utility is provided for advanced users.

Click Threading Configuration in the right pane to add the threading configuration to the system. If you are planning to run the system with higher TPS, then you need to configure Threading Configuration. For further information, contact your Cisco Technical Representative.

The Threading Plug-in having thread pools controls the total number of threads in CPS vDRA that are executing at any given time. Each of these thread pools have a queue associated with it.

The following parameters can be configured under Threading Configuration:

Table 1. Threading Configuration Parameters

Parameter

Description

Thread Pool Name

Name of the thread pool.

For more information on the thread pool names and recommended values that can be configured, refer to Threading Configuration section in the CPS vDRA Advanced Tuning Guide.

Threads

Number of threads to set in the thread pool.

Queue Size

Size of the queue before they are rejected.

Scale By Cpu Core

Select this check box to scale the maximum number of threads by the processor cores.

Async Threading Configuration

Click Async Threading Configuration in the right pane to add the configuration in the system.

Use the default values for the Async Threading Plug-in. The Async configuration controls the number of asynchronous threads.


Note


Currently, CPS vDRA does not have any asynchronous threads. However, you must add “Async Threading Configuration” and keep this table empty.

The following parameters can be configured under Async Threading Configuration.

Table 2. Async Threading Configuration

Parameter

Description

Default Processing Threads

The number of threads that are allocated to process actions based on priority.

Default Action Priority

The priority assigned to an action if it is not specified in the Action Configurations table.

Default Action Threads

The number of threads assigned to process the action if it is not specified in the Action Configurations table.

Default Action Queue Size

The number of actions that can be queued up for an action if it is not specified in the Action Configurations table.

Default Action Drop

DropOldestWhenFull: The oldest queued action is dropped from the queue when a new action is added to a full queue. Otherwise, the new action to add is ignored.

DropWhenFull: A handler for rejected tasks that silently discards the rejected task. No execution for rejected tasks.

DoNotDrop: A handler for rejected tasks that runs the rejected task directly in the calling thread of the execute method, unless the executor has been shut down, in which case the task is discarded.

Default value is DropOldestWhenFull.

Action Configurations Table

Action Name

The name of the action. This must match the implementation class name.

Action Priority

The priority of the action. Used by the default processing threads to determine which action to execute first.

Action Threads

The number of threads dedicated to processing this specific action.

Action Queue Size

The number of actions that can be queued up.

Action Drop Oldest When Full

For the specified action only:

When checked, the oldest queued action is dropped from the queue when a new action is added to a full queue. Otherwise, the new action to add is ignored.

Custom Reference Data Configuration

Configure your system, cluster, and instance for the first time to use Custom Reference Data Table plug-in. Then you can create as many tables as needed.

Click Custom Reference Data Configuration from right pane to add the configuration in the system.

  • HA example:

    • Primary Database Host/IP Address: sessionmgr01

    • Secondary Database Host/IP Address: sessionmgr02

    • Database Port: 27717

The following parameters can be configured under Custom Reference Data Configuration.

Table 3. Custom Reference Data Configuration Parameters

Parameter

Description

Primary Database Host/IP Address

IP address or a host name of the sessionmgr database.

For example, sessionmgr01.

Secondary Database Host/IP Address

(Optional) This field is the IP address or a host name of a secondary, backup, or failover sessionmgr database.

For example, sessionmgr02.

Database Port

Port number of the sessionmgr.

Note

 

Make sure that the value for this field is same as filled in for both the Primary Database Host/IP Address and Secondary Database Host/IP Address fields.

Default value is 27717.

Db Read Preference

Describes how sessionmgr clients route read operations to members of a replica set. Select one of the following options from drop-down list:

  • Primary: All operations read from the current replica set primary member.

  • PrimaryPreferred: In most situations, operations read from the primary database host. However, if this host is unavailable, operations read from the secondary databse host.

  • Secondary: All operations read from the secondary members of the replica set.

  • SecondaryPreferred: In most situations, operations read from secondary members. However, if a secondary database host is unavailable, operations read from the primary database host.

Default value is Primary.

For more information, see http://docs.mongodb.org/manual/core/read-preference/.

Connection Per Host

Number of connections that are allowed for each database host.

Default value is 100.

Connection Per Host is a performance tuning parameter and can be changed in case of a performance issue according to the call model and hardware.

For more information on Custom Reference Data API Usage, see the CPS Operations Guide for this release.

DRA Configuration

Click DRA Configuration from the right pane in Policy Builder to add the configuration in the system.

Figure 2. DRA Configuration


The following parameters can be configured under DRA Configuration:

Table 4. DRA Configuration Parameters

Parameter

Description

Stale Session Timer Minutes

Indicates the time after which the audit RAR should be generated (in the subsequent audit RAR process cycle that runs every minute in CPS vDRA) for sessions that are stale.

Default: 180 minutes (recommended value)

Minimum: 10 minutes

Maximum: 10080 minutes

Rate Limiter

Indicates the number of audit RARs per second that should be sent out by CPS vDRA.

Minimum: 1

Maximum: 1000 (maximum number of RAR messages per second from vDRA to PCEF)

For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide.

Stale Session Expiry Count

Specifies the number of retries vDRA should do for a stale session if there is no response of audit RAR or if there is Result-Code in RAA (for audit RAR) other than 5002 or 2001.

Default: 6

Minimum: 0 (Session deleted without sending RAR)

Maximum: 10

For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide.

Binding DB Read Preference

Used to select the mode when reading from Binding DB. Use "nearest" mode for better performance of traffic that needs only read operation on Binding DB.

Default: Nearest

For information on recommended value, refer to Audit Rate Limiter section in the CPS vDRA Advanced Tuning Guide.

Stale Binding Expiry Minutes

Duration after which a binding record is validated against a session record to see if the binding should be deleted because it is stale

The timer is initialized when the session is created.

The records are deleted when binding expiry time is reached and no active session is found. Otherwise, the timer is updated so the binding record can be audited after another Stale Binding Expiry Minutes.

Default: 10080 minutes (168 hours or one week) (recommended value)

Minimum: 10 minutes

Maximum: 43200 minutes (28 days)

Stale Binding Refresh Minutes

Duration for which the expiry time of the binding database records is refreshed.

Default: 2880 minutes (48 hours or 2 days - recommended value).

Minimum: 10 minutes

Maximum: 10080 minutes (one week)

Note

 

Stale Binding Refresh Minutes should be greater than Stale Session Timer Minutes.

Important

 

Stale Binding Refresh Minutes parameter has been deprecated from CPS 19.5.0 and later releases. It is recommended to not set this value as zero.

Binding Creation, Primary Alternative System

Name of vDRA system to retry Gx CCR-i

When vDRA tries to route a Gx CCR-i request, but is unable to reach the database, the configured values of first the primary, then the secondary systems are used to route the Gx CCR-i to a different vDRA to try the database.

The retry is stopped if that vDRA also cannot reach the database.

Binding Creation, Secondary Alternative System

Name of secondary vDRA system to retry Gx CCR-i

Binding Routing, Primary Alternative System

Name of vDRA system to retry Rx AAR

When vDRA tries to route a Rx AAR request, but is unable to reach the database, the configured values of first the primary, then the secondary systems are used to route the Rx AAR to a different vDRA to try the database.

The retry is stopped if that vDRA also cannot reach the database.

Binding Routing, Secondary Alternative System

Name of secondary vDRA system to retry Rx AAR

Settings

Refer to Settings.

Rate Limits

Refer to Rate Limits.

DRA Feature

Refer to DRA Feature.

DRA Inbound Endpoints

Refer to DRA Inbound Endpoints.

Relay Endpoints

Refer to Relay Endpoints.

Settings

Click Settings check box to open the configuration pane.

The following parameters can be configured under Settings:

Table 5. DRA Configuration - Settings Parameters

Parameter

Description

Stop Timeout Ms

Determines how long the stack waits for all resources to stop. The delay is in milliseconds.

Default: 10000 ms (recommended value)

Minimum: 1000 ms

Maximum: 60000 ms (one minute)

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: 10000 ms (recommended value)

Minimum: 1000 ms

Maximum: 60000 ms (one minute)

Iac Timeout Ms

Determines how long the stack waits before initiating a DWR message exchange on a peer connection from which no Diameter messages have been received. The timeout value is in milliseconds.

Default: 5000 ms (recommended value)

Minimum: 1000 ms

Maximum: 30000 ms (30 seconds)

Dwa Timeout Ms

Determines how long the stack waits for a DWA message in response to a DWR message. If no Diameter message (DWA or other message) is received on the peer connection during the first timeout period, the stack counts a failure, sends another DWR message, and restarts the Dwa timer. If no Diameter messages are received during the second timeout period, the stack counts a second failure. After two consecutive failures, the stack considers the peer connection as failed, and closes the connection.

The delay is in milliseconds.

Default: 10000 ms (recommended value)

Minimum: 1000 ms

Maximum: 60000 ms (one minute)

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: 5000 ms (recommended value)

Minimum: 1000 ms

Maximum: 30000 ms (30 seconds)

Rec Timeout Ms

Determines how long it takes for the reconnection procedure to timeout. The delay is in milliseconds.

Default: 10000 ms (recommended value)

Minimum: 1000 ms

Maximum: 60000 ms (one minute)

Drain Timeout Ms

Indicates the time that a peer connection remains open for responses to be sent to peers even if DPR is sent or received by vDRA.

If a DPR is sent or received by vDRA, vDRA does not route requests to the disconnecting peer connection via any routing (Dest-Host, SRK, Binding, Table-Driven). However, responses and in-flight requests sent to the corresponding peers till the duration of Drain Timeout. This allows vDRA to gracefully shut down when any remote peer sends a DPR so as to minimize the diameter message loss.

Default: 2000 ms

Maximum: Must be less than Dpa timeout Ms

Note

 

When vDRA initiates DPR and the remote end PCRF/PGW disconnects TCP connection immediately after sending DPA, response for the in-flight requests are dropped before reaching the configured drain timeout value.

The following figure illustrates the timers in peer detection:

Figure 3. vDRA Peer Detection Failure
Binding DB Audit

The Binding DB Audit automatically deletes stale records from the binding DBs. When a Gx session record is created, binding records for the session binding keys are also created. When each binding record is created, the binding record expiry time is initialized to the sum of the session creation time and the Stale Binding Expiry Minutes (that you can configure in Policy Builder).

A binding record is deleted when the corresponding session record is deleted. A binding may become stale if it cannot be deleted when its associated session record is deleted (this occurs typically due to database communication failures). The binding records are audited using a binding audit background process. If the audit process finds a binding record with an expiry time in the past, the binding record is checked for staleness by checking the session database for the corresponding session record. If an active session record is found, the binding record expiry time is updated with sum of current time and the Stale Binding Expiry Minutes. If an active session is not found, the binding is considered stale and is deleted. Note that the binding audit process does not perform any Diameter signaling with the GW before deletion.

The following figures illustrate the working of binding DB:

Figure 4. DRA Binding Audit, Stale Binding Cleanup

Rate Limits

Rate limit per process instance on Policy Director (lb) VM can be managed using this configuration.

Default is unchecked, that is, no rate limits for Diameter traffic (recommended setting).

If enabled, the following parameters can be configured under Rate Limits:

Table 6. DRA Configuration - Rate Limits

Parameter

Description

Rate Limit per Instance on Policy Director

Allowable TPS on a single instance of policy server (QNS) process running on the Policy Director.

Minimum: 1

Maximum: 5000

Note

 

Contact your Cisco representative for usecase-specific recommended values.

Result-Code in Response

Indicates the error code that must be used while rejecting requests, due to rate limits being reached.

Default: 3004

Error Message in Response

Select the check box to drop the rate-limited messages without sending error response.

If the check box is not selected, then the rate limited message are dropped with error response as configured.

Drop Requests Without Error Response

Select the check box to drop rate limited messages without sending error response.

If the check box is unchecked, then the rate limited messages are dropped with error response as configured.

To accommodate configuration to either drop the request or send an error response, a column Discard Behavior can be added under Peer Rate Limit Profile. The column may have one of the two possible values:

  • Send Error Response

  • Drop Message

Default: Unchecked (recommended setting)

For more information, refer to Peer Rate Limit.

Important

 
If both Rate Limit Error Code and Rate Limit Error String are provided along with Rate Limit Action as "Drop Message", the Rate Limit Action will take precedence and the other two fields will be ignored.

Here is the list of the available combinations for rate limiting:

Table 7. Rate Limiting Combinations

Rate Limiting Type

With Error Code

With Error Code and Error Message

Without Error Code (Drop)

Instance Level

Yes

Yes

Yes

Peer Level Egress

Yes

Yes

Yes

Peer Level Egress with Message Level

Yes

Yes

Yes

Egress Message Level (No Peer Level RL)

Yes

Yes

Yes

Peer Level Ingress

Yes

Yes

Yes

Peer Level Ingress with Message Level

Yes

Yes

Yes

Ingress Message Level (No Peer Level RL)

Yes

Yes

Yes

DRA Feature

Click DRA Feature check box to open the configuration pane.

The following parameters can be configured under DRA Feature:

Table 8. DRA Features

Parameter

Description

Gx Session Tear Down On5065

By default, Gx Session Tear Down On5065 flag is enabled (recommended setting).

When the PCRF responds with a Experimental Result Code of 5065 in AAAnswer on Rx Interface, DRA deletes its internal binding and session created for the transaction.A RAR with appropriate Session-Release-Cause AVP will also be sent to the PCEF.

Important

 
When using this flag, there will always be a database query to fetch Gx session id. So this means that the database transactions will linearly increase with AAR traffic on Rx Interface.

Update Time Stamp On Success R A A

When this check box is selected, session timestamp will be updated on receipt of success RAA (Result-Code: 2001) from PCEF. 1

Default is checked (recommended setting).

Important

 
When using this flag, there will always be a database query to fetch Gx session id. So this means that the database transactions will linearly increase with AAR traffic on Rx Interface.
1 The time stamp is updated on generation of Stale RAR. Also, if a success RAR/RAA(2001) comes after generation of Stale RAR, then the Stale RAR counter is reset.

DRA Inbound Endpoints

The following parameters can be configured under DRA Inbound Endpoints:

Table 9. DRA Configuration - DRA Inbound Endpoints Parameters

Parameter

Description

Vm Host Name

Host Name of the VM that hosts this CPS vDRA endpoint.

Ip Address

Address on which this CPS vDRA endpoint should bind to.

Realm

Realm of the CPS vDRA endpoint.

Fqdn

Fully Qualified Domain Name of the CPS vDRA end point.

Transport Protocol

Allows you to select either TCP' or 'SCTP' for the selected DRA endpoint.

Default value is TCP.

If the DRA/relay endpoint is to be configured for SCTP, the Transport Protocol should be selected as SCTP for those endpoints.

Multi-Homed IPs

This is a comma separated list of IP addresses that CPS vDRA 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 vDRA 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.

Note

 
While using SCTP multi-homing functionality review the Linux network and gateway configurations for supporting multiple networks on different subnets. CPS supports Centos 6 release and reverse path filtering kernel parameter (rp_filter) values can be set for allowing packets from different subnets on Policy Director VMs. The default behavior in Centos 6 is to discard the packets in such scenarios.

The configuration for multi-homing is validated by netstat command on lb01:

netstat -apn | grep 3898

Application

Refers to 3GPP Application ID of the interface.

You can select multiple applications on a peer connection.

For example, S6a and SLg on a single IPv4/SCTP Multi-homed peer connection.

Enabled

Check to enable the endpoint.

Base Port

Refers to the port on which the CPS vDRA listens for incoming connections.

An example configuration is shown below:

Figure 5. DRA Inbound Endpoints - Example Configuration


Relay Endpoints

The following parameters can be configured under Relay Endpoints:

Table 10. DRA Configuration - Relay Endpoints Parameters

Parameter

Description

Vm Host Name

Host Name of the VM that hosts this Relay endpoint.

Instance Id

Instance Identifier is the ID of the current Instance.

Ip Address

Address on which this DRA endpoint should bind to.

Port

Port is the listening port for this instance.

Fqdn

Fully Qualified Domain Name of the DRA end point.

Enabled

Check to enable endpoint.

An example configuration is shown below:

Figure 6. Relay Endpoints - Example Configuration


Diameter Application

Sd Application

For Sd, an Application Routing table is used to map specific diameter command codes and CC-Request-Types to a table, typically, an Sd New Session table for routing Sd TSRs to a peer route. The Sd New Session CD table will choose a peer route based on the Destination-Realm. The peer route will then point to a Peer-Group which contains multiple peer connections to a TDF and the DRA will load balance among the TDF peer connections in the Peer Group.

An example configuration is shown below:

Figure 7. Diameter Application - Sd Application Example


The following parameters are configured under Sd Application:

Table 11. Sd Application Parameters

Parameter

Description

Name

Name of the Sd application.

Application Id

16777303, 3GPP specified Application Identifier for Sd interface.

Vendor Ids

Vendor Identifiers that are required to be supported on Sd interface.

Tgpp Application check box

If this check box is selected, indicates this is a 3GPP defined application interface.

Application Route table

Name

Identifier of the route.

Priority

Indicates the priority of the route.

Command Code

Indicates value of command code AVP within the message.

Cc Request Type

Indicates if the Credit Control Request type is Initial(1)/Update(2) or Terminate(3).

Destination Host Null

If this check box is selected, indicates if Destination Host will be null in messages received for this application.

Action Tables

Identifies the request routing table for this interface and message.

Gx Application

For Gx, an Application Routing table is used to map specific diameter command codes and CC-Request-Types to a table. When “Destination Host Null” is checked, it means Destination-Host AVP is null. It will then check for table driven routing.

An example configuration is shown below:

Figure 8. Diameter Application - Gx Application Example


C-DRA attempts to do Dest-Host routing before doing table driven routing. If the Dest-Host AVP is absent, empty, or equal to the CDRA FQDN, then we skip Dest-Host routing altogether and proceed to Table-Driven routing.

The following parameters are configured under Gx Application:

Table 12. Gx Application Parameters

Parameter

Description

Name

Name of the Gx application.

Application Id

16777238, 3GPP specified Application Identifier for Gx interface.

Vendor Ids

Vendor Identifiers that are required to be supported on Gx interface.

Tgpp Application check box

If this check box is selected, indicates this is a 3GPP defined application interface.

Application Route table

Name

Identifier of the route.

Priority

Indicates the priority of the route.

Command Code

Indicates value of command code AVP within the message.

Cc Request Type

Indicates if the Credit Control Request type is Initial(1)/Update(2) or Terminate(3).

Destination Host Null

If this check box is selected, indicates the message will contain a Destination-Host.

Action Tables

Identifies the request routing table for this interface and message.

Rx Application

Identifies the request routing table for this interface and message.

Figure 9. Diameter Application - Rx Application Example


The following parameters are configured under Rx Application:

Table 13. Rx Application Parameters

Parameter

Description

Name

Name of the Rx application.

Application Id

16777236, 3GPP specified Application Identifier for Rx interface.

Vendor Ids

Vendor Identifiers that are required to be supported on Rx interface.

Tgpp Application check box

If this check box is selected, indicates this is a 3GPP defined application interface.

Application Route table

Name

Identifier of the route.

Priority

Indicates the priority of the route.

Command Code

Indicates value of command code AVP within the message.

Cc Request Type

Not supported for Rx interface.

Destination Host Null

If this check box is selected, indicates if Destination Host will be null in messages received for this application.

Action Tables

Identifies the request routing table for this interface and message.

Routing AVP Definition

Gx Session

An example configuration is shown below:

Figure 10. Routing AVP Definition - Gx Session


Rx Session

An example configuration is shown below:

Figure 11. Routing AVP Definition - Rx Session


Rx New Session Rules - CRD Table

An example configuration is shown below:

Figure 12. Rx New Session Rules - CRD Table


Gx New Session Rules - CRD Table

For Gx, an Application Routing table is used to map specific diameter command codes and CC-Request-Types to a table, typically, for routing Gx CCR-Is. The Gx CCR-I should be routed based on a logical APN and the Origin-Host attribute. Regular expression matching of logical APNs and Origin-Hosts can also be configured. The implementation should be flexible to allow CRDs to be configured for routing of other attributes such as Destination-Realm and Origin-Realm.

An example configuration is shown below:

Figure 13. Gx New Session Rules - CRD Table


Sd New Session Rules - CRD Table

An example configuration is shown below:

Figure 14. Sd New Session Rules - CRD Table


Logical APN List - CRD Table

An example configuration is shown below:

Figure 15. Logical APN List - CRD Table


Dynamic AVP Retriever for Routing

DRA supports routing messages based on the following AVPs from request message:

  • Destination-Host

  • Destination-Realm

  • Origin-Host

  • Origin-Realm

  • APN (from Called-Station-ID)

  • IMSI (from Subscription-ID)

  • MSISDN (from Subscription-ID)

Regular-expression matching and combinations of AVPs is supported. This requirement is not applicable across all messages on different interfaces. The following table shows applicability of the AVP's at a message and interface level.

Table 14. Regular-expression Matching and Combinations of AVPs

Interface

Message

Origin Host

Origin Realm

Destination Host

Destination Realm

APN

(Called-Station-ID)

IMSI

MSISDN

Gx

CCR-I

Yes

Yes

Yes

Yes

Yes

Yes

Yes

CCR-U

No

No

No

No

No

No

No

RAR

No

No

Yes

No

No

No

No

Sd

TSR

Yes

Yes

Yes

Yes

No

No

No

CCR-I

Yes

Yes

Yes

Yes

No

No

No

CCR-U/T

No

No

Yes

No

No

No

No

RAR

No

No

Yes

No

No

No

No

Rx

RAR

No

No

Yes

No

No

No

No

Dynamic AVP Retrievers are used mostly used in Custom Reference Data where data has to be fetched from messages at runtime.

Configure Dynamic AVP Retriever

The following sample configuration shows how to retrieve the AVP and bind it to a Key Column in the CRD.

Procedure

Step 1

Select the column name from the Columns table and click select near Bind to Session/Policy State Field to open the Please select an object... dialog box.

Note

 

You can use Bind to Session/Policy State Field only for those columns in the Columns table where Key column has been selected.

Step 2

Select the required object from the dialog box and click OK.

Figure 16. Adding AVPs


Step 3

Repeat these steps to add additional AVPs.


Custom Reference Data Tables

Search Table Groups

Peer Rate Limit Profile

This is a Search Table Group whose key columns are Peer Group, Peer FQDN or Origin Host in the message and Message Direction.

Using this search table group, the user can configure a maximum rate for each of the configured and defined diameter peers. It also allows the user to configure a maximum rate for each server process.

The peer rate limit is shown below:

Figure 17. Peer Rate Limit - STG
  • Peer Group: This is the group of peers classified together using Peer Group and Peer Group Peer values initiating the message.

  • Peer FQDN: The origin host of the peer. A specific diameter peer with its Fully Qualified Domain Name can be specified in this field or use wildcards specified by * in this field for any peer or matching peers like hss*.

  • Direction: Message direction (Ingress and Egress).

    • Ingress: Any diameter messages received by CPS vDRA from diameter peer. The routing decision by CPS vDRA will be taken after the ingress side rate limiting has been applied.

    • Egress: Any diameter messages forwarded/routed by CPS vDRA to diameter peer. The egress side rate limiting will be applied after the routing decision has been taken by CPS vDRA.

  • Peer Rate Limit: This field is to specify the threshold in TPS above which the diameter messages are discarded. This can be left empty if none of the messages are to be dropped or only message level rate limit is to be applied.

  • Rate Limit Profile: Profile Name applicable for this Peer Group and Peer, if specified. This profile maps to Rate Limiting at message level. This field enables the rate limit at per message/command code level. See Message Rate Limit Profile for more details.

  • Rate Limit Result Code: The result code sent by CPS vDRA for response message towards diameter peer when Discard Behavior is configured as Send Error Answer. In case Discard Behavior is configured as Drop Message, this field is ignored.

  • Error String: The string specified in this field is populated by CPS vDRA in AVP Error Message for response message towards diameter peer when Discard Behavior is configured as Send Error Answer. In case Discard Behavior is configured as Drop Message, this field is ignored. This is an optional field when Discard Behavior is configured as Send Error Answer.


Note


If both Rate Limit Error Code and Rate Limit Error String are provided along with Rate Limit Action as "Drop Message", the Rate Limit Action takes precedence and the other two fields will be ignored.

For more information, see Peer Rate Limit Profile.

Peer Group Mapping

Figure 18. Peer Group Mapping - STG


For more information, see Peer Group Mapping.

Message Retry Profile

Message retry profile has been added.

Figure 19. Message Retry Profile - STG


  • Peer Group: Peer group for which the retry has to be happen.

  • Application Id: Application Id of the diameter applications.

  • Command Code: Command Code of the message.

  • Result Code: Result code received from PCRF for timeout. The value is 7000.

  • Experimental RC: Indicates whether result code is experimental or not. This is for future purpose and value in this has no effect on the message retry functionality.

  • Number of Retries: Number of retries for the message.

For more information, see Message Retry Profile.

Message Mediation Profile

The message mediation profile is used to provide support for mediation of AVPs in Diameter request and answer.

  • For Diameter requests, only remove is supported.

  • For Diameter answers, the following actions are supported:

    • "remove" meaning remove all matching AVPs in the request.

    • "copy" meaning copy from the request if no AVPs are present in the answer.

      • If the AVP is present in answer, no action is performed.

    • "overwrite" meaning first remove and then copy from the request.

      • Check if the AVP is present in answer, if so remove and add from request.

      • If AVP is not present in answer, copy from request.

A new Message Mediation Profile STG has been added:

Figure 20. Message Mediation Profile - STG


  • Application Id: Application ID of the Diameter applications.

  • Command Code: Command code of the message.

  • Message Type : Request/Answer for which the rule has to be applied.

  • Avp Code : AVP code of the Diameter message.

  • Vendor Id : AVP vendor ID.

  • Avp Action : Provides options for copy/remove/overwrite.


Note


Application ID, Command Code, AVP Code and Vendor Id are used as key, so no duplicate rows could be defined for this combination and the same AVP action. For example, you cannot define both "remove" and "Copy from request" for the same set of Application ID, Command Code, AVP Code and Vendor Id.


Best Match check box needs to be checked if you want to use the wildcard feature.

For more information, see Message Mediation Profile in Custom Reference Data Tables chapter.

Peer Group Answer Timeout

New search table Peer Group Answer Timeout has been added.

Figure 21. Peer Group Answer Timeout - STG


  • Application Id: Application Id of the diameter applications.

  • Peer Group: Peer group for which the timeout is applied.

  • Command code (to enable different timeouts for different Diameter commands)

  • Timeout: Timeout in milliseconds.

For more information, see Peer Group Answer Timeout.

Error Result Code Profile

Error result code profile can be used to map errors to Result-Code value and an error message string for the Error-Message AVP. It also provides support for configurable error result codes.

Figure 22. Error Result Code Profile - STG


Valid values is the place where all the valid error values can be configured in STG so that they are visible in CRD drop-down.

  • ApplicationId: Application ID for which the mapping of Result-Code has to be done.

  • Error: Internal error list.

  • ResultCode: Result Code to be sent in answer.

  • ExpResultCode: Experimental result code to be sent in answer. Vendor-Id will be sent in Answer only for Experimental result-Code.

  • ErrMsg: Error message AVP sent in answer.


Note


Experiment result code will be sent when Result-Code is not configured. If both Result-Code and experimental Result-Code are present, Result-Code would take precedence.


For more information, see Error Result Code Profile.

Gx Session Routing

Gx Session Routing table is required for "table driven routing". Here an example for Gx New Session Rules is provided. If table driven routing is required for Rx or Sd, user needs to create similar tables for Sd and Rx as well.

Figure 23. Gx Session Routing


For more information, see Gx New Session Rules.

Custom Reference Data Tables

APN Mapping

This table provides information related to APN Mapping. The read-only APN Mapping are shown below:

Figure 24. APN Mapping - CRD Table


  • Called-Station-Id: This is the AVP from which APN is derived. This also is the key column for this table. It is bound to the session or Policy State field as shown in the snapshot.

  • Logical_APN: This is the mapped logical name that is used for referencing and processing the message within the system.


Note


For sample data configuration, refer the CPS Control Center Interface Guide for Full Privilege Administrators for this release.


Peer Access Control List

You can use the Peer Access Control List to specify the list of peers (by realm, FQDN, and applications) that can establish peer connections to vDRA so that unknown peers are not permitted to create Diameter peer connections.

Figure 25. Peer Access Control List

Peer Routes

This tables provides the information related to Peer Routes available in the system. The read-only peer routes are shown below:

Figure 26. Peer Routes - CRD Table


Peer Group SRK Mapping

This table provides the information related to Peer Groups in the system. The read-only peer groups are shown below:

Figure 27. Peer Group - CRD Table


  • Peer Group: Name of the peer group.

  • Session Routing Key: Routing token for this Peer Group.

  • Destination Host Routing Rule: Defines Routing behavior of this group.

Peer Routing

This table provides the information related to peer routing in the system. The read-only peer routings are shown below:

Figure 28. Peer Routing - CRD Table


  • Peer Route: Identifier of this Peer Route.

  • System ID: System Identifier for this VM.

  • Peer Group: Identifier of the Peer group on this peer Route.

  • Precedence: of the peer group on this Peer Route.

  • Weight: Weight of the peer group on this Peer Route.

Binding Key Profile

This table provides the information related to binding key profile in the system. The read-only keys are shown below:

Figure 29. Binding Key Profile - CRD Table


  • Profile Name: This is the name given to the Bind profile that is associated with keys that are either enabled and/or disabled.

  • MSI APN Key Enabled: Enabling this field would mean that bindings will be stored in IMSI APN collections in bindings database.

  • MSISDN APN Key Enabled: Enabling this field would mean that bindings will be stored in MSISDN APN collections in bindings database.

  • Framed IPv6 Enabled: Enabling this would mean binding data would be stored in “ipv6bindings” collection.

  • Framed IPv4 Enabled: Enabling this would mean binding data getting stored in “ipv4bindings” collection.

Refer to Binding Key Profile for configuration in Control Center.

AppId Key Profile Mapping

This table stores the mapping between Application Identifiers and Bind Key Profile Names. The Application Identifiers are pre-provisioned for two Application Identifiers as Gx and Rx. Similarly, the BindingKeyProfile is also tied to the Profile Name column of the “BindingKeyType_Profile” table:

Figure 30. AppId Key Profile Mapping- CRD Table


Message Rate Limit Profile

This table gives a provision to configure Message Rate Limits at a profile level.

Figure 31. Message Rate Limit Profile - CRD Table


  • Profile Name: Unique Identifier for a profile.

  • Application ID: Application Identifier for this row. 3GPP App Ids only are allowed here.

  • Command Code: Command Code of the message that is applicable on the said interface specified by Application Id above.

  • Message Type: Initial/Update/Terminate or None for messages that do not have them. The message request type should be same as specified for the command code in Policy Builder under Diameter Application.

  • Rate Limit: This field is to specify the threshold in TPS above which the diameter messages are discarded. This value should be more than the Peer Rate Limit in order for message level rate limit to be applied.

  • Profile Name: Unique Identifier for a profile.

Refer to Message Rate Limit Profile for configuration in Control Center.

Reserved IMSI

You can configure the Reserved IMSI CRD table to validate a parsed IMSI for SLF routing against a configured list of reserved MCC ranges.

The CRD has two main columns : MCC Start range and MCC End Range. The MCC consists of the first three digits of an IMSI.

If the IMSI matches a reserved IMSI, the value is ignored for SLF routing.

You can provide support up to ten distinct (non-overlapping) MCC ranges as Reserved IMSIs.

The DRA/SLF ignores AVPs that contain such IMSIs, and continues searching other AVPs in the Diameter request, for a valid address to be used for address resolution.

The following image shows a sample Reserved IMSI configuration:

Figure 32. Reserved IMSI


Trusted Realm Profile

Trusted Realm Profile is used for topology hiding. The CRD includes the following columns:

  • Trusted Profile Name: Profile Name having a trusted realm mapped to it.

  • Trusted Realm: Realm for which Topology Hiding is not required.

Figure 33. Trusted Realm Profile

Protected Realm Trusted Profile Mapping

Protected Realm Trusted Profile Mapping is used for topology hiding. The CRD includes the following columns:

  • Protected Realm: Realm that is protected (topology hiding is required).

  • Profile Name: Profile having realms that are trusted for this protected realm and that do not require topology hiding.

Figure 34. Protected Realm Trusted Profile Mapping

MME Alias Map

MME Alias Map is used for topology hiding. The CRD includes the following columns:

  • MME FQDN: FQDN of MME that requires topology hiding.

  • Alias1: Mandatory. An alias identity used for the protected host that belongs to an MME in the network.

  • Alias 2: Optional. Alternate Alias that can be used for Topology Hiding for the given MME FQDN.

  • Alias 3: Optional. Alternate Alias that can be used for Topology Hiding for the given MME FQDN.

Figure 35. MME Alias Map

HSS Aliases

HSS Aliases is used for topology hiding. The CRD includes the following columns:

  • HSS Alias FQDN: Alias FQDN used to replace a protected HSS FQDN.

  • Shared Alias: Boolean variable used to indicate whether the Alias FQDN is shared across multiple HSS servers or not.

Figure 36. HSS Aliases

HSS Alias Map

HSS Alias Map is used for topology hiding. The CRD includes the following columns:

  • HSS FQDN: FQDN of HSS peer.

  • Alias1: Required field which is derived from HSS Alias CRD.

  • Alias2: Optional. Alias for the HSS FQDN.

  • Alias3: Optional. Alias for the HSS FQDN.

Figure 37. HSS Alias Map