In CPS DRA, navigate to the System and Plugin Configuration.

Configure the stack in DRA Configuration plugin.

Configure the DRA Inbound Endpoints for incoming peer connections and DRA Outbound Endpoints for outgoing peer connection.

You can choose the Transport Protocol as TCP and SCTP depending on your requirement.

You can also specify the IPv4 or IPv6 address configuration for the stack connection.

The following image shows a sample configuration.

For more information, see DRA Configuration.

Configure the Diameter applications that are required to be connected over various interfaces with CPS vDRA.

The following image is a sample of a Gx application configuration:

For more information, see Diameter Application.

Previously, vDRA supported a single application on a peer connection. In this release, vDRA supports multiple applications on a peer connection.

To configure multiple applications for a peer connection, go to vDRA Inbound Endpoints in DRA Plugin configuration. In the Applications field, select the button as shown:

Select all the applications you require.

The following example shows multiple Diameter applications for a peer connection:

Configure the Routing AVP definitions to route calls on the basis of the AVPs that are present in diameter message.

In the Routing AVP Definition page, you specify the Application name and the table for table-driven routing.

In the Diameter Application page, configure the Application Route for table-driven routing.

The following screenshots show a sample configuration:

By default, mediation feature is disabled.

To enable the mediation, log in to Policy builder, select the “Enable Mediation” checkbox in Systems > DRA Configuration > DRA Feature.

Finally, publish the configuration changes.

By default, DOIC feature is disabled.

To enable the DOIC, log in to Policy Builder, select the “Enable DOIC” checkbox in Systems > DRA Configuration > DRA Feature.

You must also enable DOIC for the group in Peer Group SRK Mapping table as described in Peer Group SRK Mapping.

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

Publish the configuration changes.

As a pre-requisite for SCTP multi-homing, you must first move the physical interfaces of Director VM inside the diameter-endpoint container.

To move the IPv4 interfaces, perform the following commands in vDRA Master CLI mode:

config diameter host dra-director-0-dra-director-52wumnq5l2yl
 interface ens3 ipv4 address 10.77.87.79 broadcast 10.77.87.255 prefix-length 24
diameter host dra-director-0-dra-director-52wumnq5l2yl interface ens3 
route default gateway 10.77.87.1 
diameter host dra-director-0-dra-director-52wumnq5l2yl interface ens5
 ipv4 address 10.225.115.199 broadcast 10.225.115.255 prefix-length 24
diameter host dra-director-0-dra-director-52wumnq5l2yl interface ens5
 route default gateway 10.225.115.1

To move the IPv6 interfaces, perform the following commands in vDRA Master CLI mode:

config diameter host dra-director-0-dra-director-52wumnq5l2yl 
interface ens6 ipv6 address 2003:3051::114 prefix-length 64
diameter host dra-director-0-dra-director-52wumnq5l2yl interface 
ens6 route default gateway 2003:3051::1
diameter host dra-director-0-dra-director-52wumnq5l2yl interface 
ens7 ipv6 address 2003:3052::114 prefix-length 64
diameter host dra-director-0-dra-director-52wumnq5l2yl interface 
ens7 route default gateway 2003:3052::1

Commit the configuration.

Destination host based routing is the basic and default routing technique used by CPS vDRA.

When the incoming diameter request contains the destination-host AVP that has the direct connection with the CPS vDRA, vDRA routes the message directly to that connected host.

Policy DRA

For Policy DRA, you must configure the binding keys for Gx sessions.

Binding helps Policy DRA route the related Gx/Rx sessions to the same PCRF or destined PCRF.

A binding database is needed to map search keys to PCRF binding information. Each binding has a search key and binding data associated with it. The supported search keys are:

• IMSI + APN

• IPv6

• IPv4

• MSISDN + APN

If the Binding Key Profile and mapping to Application ID is not configured properly, the following errors may occur:

• Gx Calls – Session binding failure in database resulting in call failures.

• Rx Calls – Binding Retrieval failure resulting in call failures.

Note	IMS DRA does not require bindings. Hence, Binding Key Profile is only valid for Policy DRA.

You can configure SRK based routing in one of the following ways:

Configure Secondary Peer Fallback

Note	This configuration is valid for both Policy and IMS DRA.

In SRK based routing, you can configure routing to a set of peers. This can be used for alternate routing (secondary and tertiary routes) when the Destination Host routing fails, and for binding data to select a peer for related diameter sessions. The Session Routing Table is configured within a “Peer Group SRK Mapping” Table. If a routing with dest-host fails, CPS vDRA will try to find out secondary routes on the basis of SRK.

Once the SRK of failed peer is determined by CPS vDRA, it will try to find an UP peer that is a member of:

• A peer group matching the entire SRK label. If it finds one, it will route the message to that peer.

• If it cannot find one and it is a two-label SRK, then it will try to find an UP peer in a peer group whose label2 part of its SRK matches the label2 part of the lookup SRK (where the label 1 part may be different). If it finds one, then it will route the message to that peer.

The following screenshot shows an example of SRK configuration:

Configure Binding Retriever for Rx Calls

Note	This configuration is valid for Policy only.

Rx (AAR) Message processing: Policy DRA receives the AAR request from Application Function (AF). AAR messages does not have destination host and the destination PCRF has to be found out by vDRA using the keys such as:

1. Framed Ipv6 Address

2. Framed IP address

3. IMSI APN key

4. MSISDN APN key

Binding is created by vDRA when Gx-CCRI is received at DRA. DRA creates the bindings on the basis of CRD configurations and the availability of AVPs in Gx message. If the configured keys are present in Gx message, vDRA creates and stores the binding in Binding Database. On receiving AAR request, vDRA searches for the session stored in bindings on the basis of Rx profile, and will determine the SRK of Gx-PCRF peer. DRA will then forward the Rx request to the Rx peer having the same SRK. [ SRK will be configured as mentioned in following section ].

Configure SLF Based Routing

Note	This configuration is valid for IMS DRA only.

SLF Routing works with two major configurations and tables within CRD:

1. SLF Trigger Profile: For the incoming Diameter requests where Destination-Host is not present (or Destination-Host is present with same of DRA-Host Name) this SLF Trigger table is triggered. In this Table, there are three inputs that you need to configure:

   • Application-Id: Diameter Application ID for which the SLF Query is to happen.

   • Command-Code: Diameter Command Code for which the SLF query is to happen.

     Note	If this field is configured with a ‘*’, it indicates that SLF query is expected to happen for all the command codes for the specific application.

   • Destination-Realm: Destination-Realm of the Diameter Endpoint (that is, HSS/AAA) or the Destination Realm of vDRA.

     Based on the Input keys (Application-Id, Command-Code and Destination-Realm) configured, if all the entries (as mentioned above) matches with the incoming message then vDRA(SLF) picks the “SLF Lookup Type” and “SLF-Destination-Type” as configured in the SLF Trigger Table.

   • SLF LookupType- Currently the SLF LookupType can be configured as IMSI or MSISDN. Based on the configured value of IMSI or, MSISDN, vDRA (SLF) further makes a query towards the SLF-DB.

   • SLF Destination-Type-Based on the configured value in the ‘SLF Destination Type’, vDRA (SLF) makes a further query towards the SLF-DB.

     
     

     

     
     

2. SLF Routing: After vDRA(SLF) makes the query in SLF-DB based on SLF-LookupType and SLF-Destination-Type, an SLF-Destination is obtained.

   SLF Mapping table consists a mapping of ‘SLF-Destination’ which is obtained from the SLF database and a SLF-Session-Route-Key(SLF-SRK). In the SLF Mapping Table, based on the SLF-Destination an SLF-Session-Route-Key (SLF-SRK) is derived and further Peer group is derived for routing from the Peer-Group-Peer table as the next step for Routing.

   
   

   

   
   

CPS vDRA has the ability to use AVPs within the Diameter messages to help determine how to route the traffic.

The AVP being evaluated is customer configurable, through the CPS DRA GUI. The addition, subtraction, or modification of the evaluation AVP is dynamic and affected real time.

Trigger Condition for Table-driven Routing:

• After Destination-Host based routing (first priority) and SRK routing (second priority) conditions are not met, vDRA goes for Table-driven routing as third priority.

• Typically, for Table-driven Routing to trigger, a Diameter message contains a Destination-Realm AVP, but no Destination-Host AVP. So, If the Dest-Host AVP is absent, empty, or equal to the DRA FQDN, then we skip Dest-Host routing altogether and proceed directly to Table-Driven routing.

Note	For IMS-DRA only, the router will try to do the SLF routing ( if all conditions are met ), before moving to table-driven routing.

vDRA can parse and has the ability to route based on the following AVPs:

• 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 are also supported. The following configuration is required in Policy Builder:

1. Application Route: For more information, see Basic Configuration.

2. Routing AVP definitions: For more information, see Basic Configuration.

3. Search table group configurations: For more information, see Search Table Groups.

4. CRD configuration: For more information, see Custom Reference Data Tables.

You can use CPS vDRA to set rate limiting of traffic coming from and going towards a particular peer. You can configure this for both Ingress and Egress traffic. Rate limit is currently supported at peer level and message level.

1. Configure the Message Rate Limit Profile CRD table.

   Create the rate limit profile with the rate limit profile name, application ID, command code, message type, and message rate limit. For more information, see Search Table Groups – Message Rate Limit Profile table.

   
   

   

   
   

2. Configure the Peer Rate Limiting CRD table.

   Define the peer group, peer fqdn, message direction (ingress or egress), rate limit profile (created in step 1), peer rate limit, discard behavior (whether to silently drop or send error message). For more information, see Search Table Groups – Peer Rate Limit Profile table.

   If you want the discard behavior sent in the error answer, also configure the Result Code, Error String to be sent in the answer.

   
   

   

   
   

CPS vDRA generates several internal errors that are not generic, for example, errors such as Timeout triggered, Peer not found, DB error, and so on.

You can configure error codes and error messages for internally generated errors in CPS vDRA.

To configure this error code, add entry in the Error Result Code Profile table as shown in the following image:

For a particular Application ID, if DRA generates an internal error, the error code defined in this table along with the Error Message is sent back in the answer.

If the result code is not configured and the Experimental Result Code is present, then the Experimental Result-Code is sent back in the answer along with Vendor-Id AVP. Between the Result-Code and the Experimental Result code, the Result-code is of higher priority.

You can set the different request timeout durations for different application ID and peer group. In CPS vDRA, timeout is the amount of time that vDRA waits for the answer from the destination.

To configure this feature, add an entry in the Peer Group Answer Timeout table. The timeout value is in milliseconds.

The default timeout is 1.7 seconds. You can also override the timeout for specific interface in this table as shown in the following image:

CPS vDRA has capabilities to route messages based on weight and precedence of the peer. Perform the following steps to define the peer load balancing:

1. Configure the Peer Routes table:

   • This table defines the name of the Peer Routes that are then used in the Peer Routing table.

   • This table is mainly used in Table-driven routing where the peer route is derived from the application table-driven rule tables.

   
   

   

   
   

2. Configure the Peer Group Mapping table. This table defines the mapping of peers and realm with peer group.

   • Once the peer group is derived, CPS vDRA looks up this table to find the peers that belong to the derived peer group. Once DRA lists the peers in the peer group, it tries to match these peers with the Active Peer list, that is, peers which are currently connected to CPS vDRA.

     If multiple peers are up in a peer group, CPS vDRA load balances the traffic in a round-robin manner according to peer weight.

     The peer weight range is 0-1000 and the default weight is 100. If a peer weight is 0, then that peer is skipped.

     For example, if there are two peers up in a peer group with weights 100 and 200 respectively, then CPS vDRA load balances traffic between the two peers in the ratio of 33% and 67% respectively.

   • This table is applicable to SRK and Table driven routing only and is not used in Destination Host routing.

   
   

   

   
   

3. Configure the Peer Routing table.

   This table requires the following inputs:

   • Peer Route – derived from the Peer Route table

   • System Id – the current system ID of the CPS vDRA system

   • Peer Group – derived from the Peer Group Mapping table

   The outputs of this table are:

   • Precedence

   • Weight

   Weight and Precedence are used to load balance the traffic among peers.

   
   

   

   
   

CPS vDRA has the capability of retrying messages to multiple connected peers, in case the destination peer is not up. Retry mechanism works completely on the basis of SRK.

To configure message retries, you need to configure the Message Retry Profile table.

You can configure message retry on the basis of the following inputs:

• Peer Group

• Application Id

• Command Code

• Result-Code

The outputs of this table are:

• Number of retries

• Experimental RC

When the retry criteria matches, then:

1. First, the retry is done on any connected peer in the same peer group.

2. If no peer is found in the same peer group, the next priority is given to the peers in the peer group having the same SRK as the peer group to which the request was originally sent.

3. If the above condition also fails to find a peer, the last priority is given to the peers in the peer group that share the same second label as that of the original peer group.

Note	CPS vDRA uses the Peer Group Mapping table to find the peer in the same peer group. Hence, the Peer Group Mapping table configuration is a prerequisite.

At the end, if no peer is found, retries stop. The retry also stops when the number of retries is exhausted and no response is received.

You can now specify a reserved MCC range so that vDRA validates a parsed IMSI for SLF routing against a configured list of reserved MCC. If the IMSI matches a reserved IMSI, the value is ignored for SLF routing.

Configure the Reserved IMSI CRD table with columns for MCC Start Range and MCC End Range.

For more information, see Reserved IMSI.

In DRA, configure the MCC Start Range and MCC End Range.

Any calls within Reserved IMSI range are either routed by alternate means such as table-driven routing or result with an error.

Previously, in vDRA, the SLF lookup Type in the SLF trigger table had options only to support two types of lookup, that is, IMSI, MSISDN.

You can now specify Primary and Secondary Lookup Keys in the SLF Trigger Profile Table.

First, configure the columns in the CRD table as shown:

In the SLF Trigger Profile, you can select the Primary Lookup key from the drop down list. Similarly, you can select the Secondary Lookup key.

You can configure CRDs to modify the result code of AVPs and overwrite them with a specified value.

1. Define the AVPs in the Diameter Avp Dictionary as shown in the following example for ResultCode:

   

2. Add the condition that is used to match AVPs with a particular result code. In this example, ResultCodeIs3xxx matches the result code AVP with regular expression 3.* and checks for any 3xxx result code.

   

3. Define the action to be performed in the Avp Action Profile. In this case, ChangeResultcode is used to overwrite AVP values with the value 3002.

   

4. Add the mediation rule in the Message Mediation Profile.

   In the following example, the mediation rule is considered on answer in ingress direction, when application is 16777251, command is 318, and condition profile ResultCode3xxx is met. When all criteria are satisfied, the “ChangeResultCode” action profile is applied.

   

Define mediation rules to hide topology.

1. Define the AVPs in the Diameter Avp Dictionary as shown in the following example for OriginHost and OriginRealm:

   

2. Define the action to be performed in the Avp Action Profile. In this case, Hiding is used to overwrite the Origin Host AVP with the value “dra” and to overwrite the Origin Realm AVP with the value “dra.cisco.com”.

   

3. Add the mediation rule in the Message Mediation Profile.

   In the following example, mediation rule is considered on request and answer in egress direction. It is applicable to all application, all commands, all peer groups and all message types (request/answer). When criteria satisfied, the “Hiding” action profile is applied.

   

When endpoints are not proxy-aware, PCRF may send an RAR to the vDRA without Destination Host AVP because it is not proxy friendly.

In such cases, you can configure vDRA to modify the Destination-Host of the RAR based on a regex match of the Diameter Session-ID.

1. Define the AVPs in the Diameter Avp Dictionary as shown in the following example for DestinationHost and SessionId:

   

2. Define the action to be performed in the Avp Action Profile. In this case, ExtractHostFromSessionId is used to overwrite the DestinationHost AVP with the value dynamically derived from the regex string:

   SubString("${SessionId}", "([^;]+);.*" , 1)

   The session ID is taken from the message, then regex ([^;]+);.* is applied on the session ID and host is extracted.

   For example, if the session ID is “pcef;1450914337;172.30.96.2;0”.

   Regex ([^;]+);.* is applied on session ID and it will get 2 groups:

   • group1= “pcef”

   • group2 = “1450914337;172.30.96.2;0”

   Hence, the Destination Host is set with value pcef.

   

3. Add the mediation rule in the Message Mediation Profile.

   In the following example, mediation rule is considered on Gx RAR in ingress direction. When all the criteria are met, the “ExtractHostFromSessionId” action profile is applied. Action will set the DestinationHost AVP just after receiving message.

   

You can define a prefix for an AVP.

1. First, define the AVPs in the Diameter Avp Dictionary as shown in the following example for the AVP, DestinationHost:

   

2. Define the PrependLabel profile in the Avp Action Profile that adds the prefix "core-" to the DestinationHost AVP.

   

3. Add the mediation rule in Message Mediation Profile as shown in the following example.

   In this example, the mediation rule is applied on s6 AIR request message in egress direction. When the peer group also matches hss-g, it will apply the “PrependLabel” action profile. Action will add the prefix “core-“ to destination host.

   

vDRA can throttle Diameter requests based on the message priority sent in the Diameter request using the architecture described in RFC 7944 Diameter Routing Message Priority (DRMP).

To configure vDRA to use DRMP, perform the following steps as described in Configure Throttling of Diameter Messages Using DOIC. Ensure you use the DRMP AVP in the Diameter Avp Dictionary table.

With this configuration, messages with Message Class P0 are not throttled in either rate limiter or by DOIC. For the rest of the messages, the throttling is applied as configured in DOIC table or in rate limiter.

Rate limiter currently throttles message regardless of the message class/ DRMP value. However, it will not throttle the message with message class P0.

You can configure vDRA to recognize Diameter messages as Enhanced Multimedia Priority Services (eMPS) based on Diameter Application-Id, Command-Code, and AVP values.

An eMPS request is marked as a Priority 0 (or P0 in message classification) request and is not throttled or dropped.

1. Specify the AVP in the Diameter Avp Dictionary as shown in the following example:

   

2. Specify the AVP condition in the Avp Condition Profile table.

   

3. In Message Class Profile, configure the Message/Request Type as ‘None’, Message Class as P0, and Ingress Peer Group as ‘*’, so that the message is treated as eMPS irrespective of the type of message (request or response) and the peer group it is sent to.

   

Configure topology hiding for the S6a/d Diameter application (Diameter interface between the MME/SGSN and the HSS).

1. Configure a trusted realm profile: Define the name of a Trusted Profile and associate a realm which can be trusted with it.

   

2. Configure the Protected realm (where vDRA is to provide the topology hiding) and link it to the trusted profile.

   Depending on the requests, if the destination/origin realm is trusted, vDRA skips the topology hiding. If the realm is not trusted, vDRA provides topology hiding.

   

3. In the MME Alias Map, define the MME FQDN, which needs to be protected, and bind it to the Aliases that are used for topology hiding.

   

4. Define all the HSS Aliases that are used for HSS topology hiding by vDRAin the HSS Aliases table. Specify whether the defined alias is shared or not by multiple protected HSSs.

   

5. In the HSS Alias Map, map the protected HSS FQDN with the HSS ALIAS defined in previous HSS Aliases table. These aliases are used for the topology hiding of the protected HSSs.

   

CPS vDRA provides a REST API that you can use to manually disconnect peer connections from vDRA. To disconnect a single peer connection, you need to provide the peer connection key information in the API method.

200 OK
{
    "success": {
        "code": 0,
        "message": "Request completed successfully"
    }
}

404 Not Found

{
    "error": {
        "code": 2014,
        "message": "Data for key <peer-connection-key> is not found"
    }
}

Policy DRA requires a full-mesh topology to be able to send traffic between different sites. In a multi-site DRA network, relay connections are required between every pair of relay endpoints.