The logical APN feature allows multiple users to access different physical target networks through a shared APN access point. The logical APN feature reduces the amount of APN provisioning required by consolidating access all real APNs through a single virtual APN. Therefore, only the virtual APN needs to be provisioned at Control Centre, instead of each of the real APNs to be reached.

For details on System ID, refer to Peer Routing.

For details on Peer Group, refer to Peer Group Mapping and Peer Group SRK Mapping.

An example configuration is shown below:

Figure 1. Logical APN List

The Avp Condition profile is used to specify the value and condition to apply to AVP.

The following table describes the fields of Avp Condition Profile:

Figure 2. Avp Condition Profile

You can use the Avp Action Profile to perform mediation at different directions (ingress, egress). You can modify both request and response messages. You can replace, append, prepend value AVP. The value may be static or dynamically retrieved from another AVP or can be extracted as substring from another AVP.

The following table describes the AVP actions that you can perform in Avp Action Profile:

Figure 3. Avp Action Profile

The APN is composed of two parts which are as follows:

• The APN Network Identifier. This part of the APN is mandatory.

• The APN Operator Identifier. This part of the APN is optional.

The actual APN of any interface is filled-in with Called-Station-Id AVP. This table keeps a mapping of actual APNs and logical APNs configured in logical APN list.

An example configuration is shown below:

Figure 4. APN Mapping Table

Use the DOIC Profile table to define the abatement action for Diameter messages in case of Diameter peer overload or congestion.

For more information about DOIC, see Configure Throttling of Diameter Messages Using DOIC.

The following table describes the DOIC Profile table parameters:

The following abatement actions are supported:

• Forward: Forward allows the message to be sent to the destination peer, even though the peer is overloaded.

• Divert: Messages are diverted to the non-congested secondary peer as found using Peer Group SRK Mapping. If the secondary peer is congested, the next non-congested peer is used. If all peers are congested, the messages are dropped.

• Drop: Message is throttled with error response 3002

  When a message is throttled, a default result-code of 3002 and default message "Throttled due to DOIC congestion" is sent.

  The error message can be configured in Error Result Code Profile table with the Error key as Doic Throttled/Dropped.

  Default Error Message is “3002: 012 - Throttled due to DOIC congestion”

Figure 6. DOIC Profile

Use the Diameter Avp Dictionary CRD table to define the AVP name, AVP code, vendor ID, and the type.

The following table describes the parameters of the Diameter Avp Dictionary:

Figure 7. Diameter Avp Dictionary

You can use the Peer Access Control List to specify the list of peers (by realm, FQDN, and application ID) that can establish peer connections to vDRA.

Peers that are not listed with realm or host in the CRD are allowed to establish peer connections by default.

Specify the following parameters:

• Origin Host - Diameter identity or FQDN(host) of the client either in full or as a regular expression

• Origin Realm - Diameter Identity or realm of the client either in full or as a regular expression

• Authorization Action: Specifies whether the incoming client connection is allowed or denied.

• Authorization Deny - Result Code: Configurable result code. If not configured, the default value of 3010 (Unknown Application) or 3007 (Unsupported Application) is sent. Applicable only when the Authorization action is set to “Deny”

• Authorization Deny - Error Message: Configurable Message. If not configured default values are Unknown Peer or Unsupported Application.

  Applicable only when the Authorization action is set to “Deny”

• Application ID: single, comma-separated, or regular expression.

The key fields are Origin Host and Origin realm, hence it is possible to have only one row for each unique pair.

If the peer connection is rejected due to mismatch of Applications, customized result-code / error messages are not applicable in this case.

Figure 8. Peer Access Control List

Request forwarding is done using Peer Routes to discover peers. These routes are different for different interfaces. There can be multiple peer routes for a particular interface.

Figure 9. Peer Routes

One or more peers are combined into single peer group based on their realms patterns and FQDN patterns. Peer groups have respective peer routes.

Figure 10. Peer Group Mapping

All the peer groups consisting of one or more peers are listed in this table. Also various features like Session Key Routing or Destination Host Routing can be configured as Only, Never, Preferred depending upon the need. Use the DOIC Enabled column (YES/NO) to enable or disable Diameter Overload Indication Conveyance (DOIC). This option is used to throttle or divert Diameter requests towards PCRF, HSS, AAA, and OCS servers based on reporting of overloaded conditions.

Figure 11. Peer Group SRK Mapping

This table consists of a mapping of Peer Groups to Peer Routes on a particular CPS vDRA. It also has precedence and weight columns which play a vital role in load balancing behavior of CPS vDRA.

Figure 12. Peer Routing

The available fields are Boolean fields and can be edited by selecting the check boxes.

Note	It is expected a minimum of one row to be configured with the value “DefaultProfile”. This will be used in case there is nothing configured for an application Id. For this “DefaultProfile”, “imsiAPN” and “FramedIPv6Prefix” should be enabled.

Note	The field MSISDN APN Key Enabled is a place holder only. Modifying this field will not have an effect on the application behavior.

Figure 13. Binding Key Profile

Figure 14. AppId Key Profile Mapping

The Binding Key Profile column is tied to the Profile Name column from the previous CRD and takes the available Profile Name in the system.

There are two application Identifiers that have been provisioned in the system which are Gx and Rx and can be tied to the same or different Bind Key Profile as the case may be.

To determine the abatement action from the DOIC Profile table (for throttling or diverting Diameter requests), you require a Message class. You can query the Message class from the Message Class Profile table.

The Message Class Profile table takes inputs such as Ingress Peer Group, Application Id, Command Code, Message/Request Type and provides the Condition Profile and Message Class. Message Class can be one of P0, P1, P2, P3, P4.

Figure 15. Message Class Profile

CPS vDRA supports configurable retries, so that the specific behavior of CPS vDRA in congestion scenarios can be configured.

Configurable retry mechanism (i.e., number of retries) per:

• Application ID

• Peer Group

• Answer Timeout error occurred

• Error Result Code of Response

This should be in the form of a CRD and applied to a peer group. The user can use the SRK peers to select an alternate peer.

If all SRK peers fail, the user should use one alternate CPS vDRA if it connects to the SRK. If the SRK matches exactly, CPS vDRA would look for the second label match of SRK like clusterb.dc1 and clusterc.dc1 and retry the message to other peer group.

Figure 16. Message Retry Profile - Control Center

Wild card match is supported for Peer Group, Application Id, Command Code, Result Code columns. For example, 300.* supports all RC starting with 300.

• * is supported to allow all RC.

• * is supported for all peer groups.

• Match = GX_DC_.* is supported for groups starting with GX_DC

RC = 7000 is interpreted as retry for timeout.

Experimental result code is for future purposes and value in that column has no effect on retry processing.

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

Refer to Message Retry Profile for configuration in Search Table Group.

CPS vDRA supports message mediation profile for following use cases:

• Store an AVP from the request and insert it into the answer. The answer is forwarded from an endpoint or an error generated by CPS vDRA. The known use case for this is storing the MSISDN from a request from the OCS (Sy SNR, Gy RAR) and inserting it in the answer to the OCS. The endpoint cannot handle all cases since the DRA can generate the error response in case of request timeout or inability to route the request to a peer. The MSISDN is in the Subscription-ID AVP.

• Remove an AVP from a request or answer.

Figure 17. Message Mediation Profile - Control Center

CPS vDRA support for the following use cases:

1. Configurable answer timeout for initial try and subsequent retries for the following parameters:

   • Application ID

   • Peer Group (to which request is sent)

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

   • Timeout value (in milliseconds)

2. Default value if unspecified is 1700 milliseconds.

Peer group answer timeout is applicable for every message routed using:

• Destination host routing

• SRK routing

• Table driven routing

Sample peer group answer timeout is shown below:

Figure 18. Peer Group Answer Timeout

Wild card match is supported for application_id, peer_group, command code. * indicates all application_id, peer_group.

The following rules have been applied for answer timeout:

• Default timeout for any message routed from CPS vDRA is 1700 ms.

• In case of retry, if an alternate group is chosen for routing, corresponding timeout for the peer group is applied.

For Policy Builder related configuration, refer to Peer Group Answer Timeout.

Further to peer level rate limit, CPS vDRA provides the granularity of limiting diameter traffic at message level for each peer. Message level rate limit always works in conjunction with peer level rate limit and is an additional control in peer level rate limit configuration. Since message level rate limit works in conjunction with peer level rate limit, all the fields specified for peer level rate limit are applicable to message level rate limit.

Message Rate Limit Profile table is used to get the condition for such rate limiting. User can define the type of message, command code and the application for which the limiting has to be implemented.

Figure 19. Message Rate Limit Profile

Sample CRD data looks like this:

Figure 20. Error Result Code Profile

• For any CPS vDRA error or message timeout, CPS vDRAhas the ability to map the error to a Result-Code value and an error message string for the Error-Message AVP.

• Errors include things like "binding not found", "message timeout", "no peer connections".

• The Result Code value is sent in the Result-Code AVP in the response.

• The error message string is sent in the Error-Message AVP in the response.

• When both Result Code and Exp Result Code are configured in this table, Result Code will take precedence. In case Result Code is not configured in this table, Exp Result Code will be sent with Vendor-ID.

Gx New Session Rules table is used by CPS vDRA when performing Table Driven routing. CPS vDRA could derive the "Peer Route" from this table, when the incoming message has no destination host to be routed to. From peer route, CPS vDRA derives further route where the request could be sent. This table supports both wildcard and exact match for the various parameters. The "Peer Route" used in this table should be defined in "Peer Routes" table. Here an example for Gx New Session Rules is provided. Similar tables can be created for Rx or Sd.

Figure 21. Gx New Session Rules

In this table, there are three input keys: Application Id, Command Code and Destination Realm. If all these input keys are matched from the Diameter incoming requests and trigger condition for the SLF trigger table is matched, then CPS vDRA derives the Primary Lookup Type (IMSI/MSISDN) and SLF Destination Type as output of SLF trigger table. Then a query is made in the SLF Database using the Primary Lookup Type (IMSI/MSISDN) and SLF-Destination-Type.

This table is used in the case when the Diameter Request does not contain any “Destination-Host” AVP or, in case the “Destination-Host” AVP comes with the Diameter Host Name of CPS vDRA.

Figure 22. SLF Trigger Profile

Based on Application ID 16777251, Command Code 316 and Destination Realm of ims.mnc286.mcc311.3gppnetwork.org, Primary Lookup Type selected is IMSI and SLF Destination Type is selected as S6a-HSS. This Primary Lookup Type and SLF Destination Type is used to query SLF database for the configured lookup type.

This table contains the mapping of SLF destination and the SRK of peer groups where the message could be routed. The SLF destination is derived from SLF subscriber database.

Figure 23. SLF Routing

This table is used for table driven routing of S6/Sh messages when the destination host is not available in the incoming request and there is no match SRK found in SLF Trigger table/SLF Mapping table. Keys used for deriving the peer route are Origin Host, Origin Realm, Destination Host, Destination Realm, MSISDN, IMSI and the output is Peer Route.

An S6 Table Driven Rules example configuration is given.

Figure 24. S6/Sh Table Driven Rules

CPS vDRA provides range-based routing based on MSISDN and IMSI values so that Diameter requests are routed to the correct HSS or AAA server. Range-based routing occurs if the destination-host routing, binding-based routing and SLF-based routing fails.

• vDRA checks whether the primary lookup type is IMSI or MSISDN and also checks whether the IMSI/MSISDN value present in the request matches against the range configured in CRD.

• The primary lookup type is evaluated first and if it fails, the secondary lookup type is evaluated.

• If primary lookup type evaluation fails and if the secondary lookup type is not configured, the request is routed with table-driven routing (if configured).

• If both the primary lookup type credential and the secondary lookup type evaluation fail, the request is rejected or routed with table driven routing (if configured).

vDRA matches the request against the Range Based Routing table and based on the result of the credential match, SRK routing is initiated.

Figure 25. Range Based Routing

The IMSI Range is used in range-based routing to configure the range of IMSI values.

Examples:

• For configuring numeric range between 9840510345 to 984059999: Lower bound: 9840510345, Upper bound: 9840598823

• For configuring regex for numbers in range 9840500000 to 9840599999: Lower bound: match=98405[0-9]*, Upper bound : <leave it empty>

• For configuring regex for numbers in range 9840501333 to 9840502999: Lower bound: match=984050(1|2)[3-9]* , Upper bound : <leave it empty>

• For configuring regex for numbers in range 9840500000 to 9840599999: Lower bound: match=98405(([2-7][0-9]*)|(8[0-8][0-4][0-5][0-6])|(1[0-9][2-9][3-9][4-9])), Upper bound : <leave it empty>

Figure 26. IMSI Range

The MSISDN Range is used in range-based routing to configure the range of MSISDN values.

Examples:

• For configuring numeric range between 9840510345 to 984059999: Lower bound: 9840510345, Upper bound: 9840598823

• For configuring regex for numbers in range 9840500000 to 9840599999: Lower bound: match=98405[0-9]*, Upper bound : <leave it empty>

• For configuring regex for numbers in range 9840501333 to 9840502999: Lower bound: match=984050(1|2)[3-9]* , Upper bound : <leave it empty>

• For configuring regex for numbers in range 9840500000 to 9840599999: Lower bound: match=98405(([2-7][0-9]*)|(8[0-8][0-4][0-5][0-6])|(1[0-9][2-9][3-9][4-9])), Upper bound : <leave it empty>

Figure 27. MSISDN Range