Testing Diameter Charging Sessions

The IN Tester system can be used to test Diameter credit control session charging against a Diameter server. The IN Tester provides support for configuring the initial request as a custom node and then the IN Tester will automatically perform update and terminate requests for the charging session as necessary to use the total units requested.

The IN Tester partially implements RFC 4006.

Due to the significant customisation of Diameter requests, Diameter event requests in the IN Tester are built from three distinct sets of information:

1. Connection and core credit control information that is not specific to the event request. Controlled by the Service Daemon this information is defined in the Service Daemon Diameter configuration and within the software code. This configuration is related to connecting to the Diameter server and is not able to be changed on a per- test-flow basis.
2. Information specific to the request, but which is part of the core Diameter credit control protocol. Controlled by the diameter node configuration this data defines what sort of request is to be made (e.g. whether it is a session or event charging request) along information such as the service context ID and rating group. This is included in the test-flow request automatically by the user interface. If writing a test flow directly in the JSON format, these fields will need to be defined manually.
3. Custom information (AVPs) that are environment and request type specific AVPs whose syntax and semantics are governed by other specifications, or entirely custom to the installed environment. The content of these custom AVPs can be documented in the IN Tester to help users fill these fields in appropriately when building tests.

The content of custom AVPs must adher to a number of very basic types:

  • Text string
  • Number
  • Non-negative number

Multiple Services Credit Control

Multiple Services Credit Control (or MSCC) is the way a single Diameter session can charge across multiple rating groups. This is supported by the standard Diameter Session tester node by selecting "Utilise Multiple Services" and choosing "yes".

You can simulate charging multiple different rating groups by charging each rating group in sequence. To do so, make your first Diameter Session node "Start New Session?" yes and "Terminate Session?" no. Then add second Diameter Session node with "Start New Session?" as no. You can chain as many Diameter session nodes together as you need, but make sure the last session is set to terminate the session.

Handling Pre-Call Failure

There are two ways in which Pre-call failure may occur. The first is if the failure result code occurs on the initial request. The second is if it happens on the first MSCC update request (in MSCC scenarios). In this second scenario the IR is successful, but the first actual request for funds is denied (or errors).

Both these scenarios are supported by the default node. The way to trigger the first scenario is to ensure "Utilise Multiple Services" is set to "no" (even if you are using MSCC) and choose the appropriate result code. You do not need to set the "Total Units to Use", but if you do it will be ignored.

In the second scenario, set "Utilise Multiple Services" to "yes", and choose the appropriate result code. In this scenario set the "total Units to Use" to -1. This special value flags the appropriate behaviour in the node and the IR is expected to be success, but a subsequent MSCC driven UR is expected to fail with the given error code.

Handling Mid-Call Failure

Mid call failure can be triggered by setting the units to use to a positive value, and setting the expected response code to the expected error code.

The node will check the correct response code is returned. It will not check that the appropriate units were used prior to the error response. To do this use an eval node subsequently and check $v->{duration} against the original duration expected (`$v->{duration} starts at the positive duration and decreases toward 0).


AVPS

required

Generic Diameter session requests which the system does not have configuration for are displayed using a raw "AVPs" field. This field is expected to list the array of AVPs to use within the Diameter Credit-Control request message. This includes the request type (i.e. whether it is an initial, update or terminate request).

As the generic Diameter session request node only supports one request, and one response, multiple nodes would need to be used to simulate a ongoing charging session with multiple Diameter request and response cycles.

The following is a template for an initial charging session request. Text in bold is the text most likely to need changing. Note that the "CC-Request-Type" is 1 for the initial request, 2 for update requests and 3 for terminate requests.

[
  {
    "name": "Session-Id_auto"
  },
  {
    "name": "CC-Request-Type",
    "value": 1
  },
  {
    "name": "CC-Request-Number",
    "value": 1
  },
  {
    "value": "200",
    "name": "Rating-Group"
  },
  {
    "value": "<b>cc@n2in.com</b>",
    "name": "Service-Context-Id"
  },
  {
    "value": [
      {
        "value": "<b>64220635462</b>",
        "name": "Subscription-Id-Data",
      },
      {
        "value": "0",
        "name": "Subscription-Id-Type"
      }
    ],
    "name": "Subscription-Id"
  },
]

* * *

Test Fields Common to all Custom Diameter Session Nodes

Subscription ID

required

All Diameter sessions require the subscriber to which the event will be applied. This is provided using the Subscription ID field. Generally this will be a subscriber's MSISDN in the same format used by the Diameter server.

Examples

  • 64 21 063 5462

Total Units to Use

required

The IN Tester will perform the necessary Diameter session request messages to charge an exact amount of units. The total units to charge, across all requests in the session, should be given here. E.g. if the session is a data charging session, and the user should use 1Mb of data, this field would be set to 1073741824 (although this may be different depending on the actual units).

This would almost always be a non-zero postive integer.

Use -1 if you wish to trigger a MSCC situation where the initial request is a success (2001), but the first update request response is a failure code. The -1 triggers this specific scenario in the node.

Use a positive value if you wish to trigger a successful session with a certain amount of units used, or trigger a mid-call failure after a certain amount of units are used (although the units used is not checked in the node itself - you would need to do this yourself in a subsequent evaluation node).

Use 0 if you wish to test for a failure response on the initial request in either MSCC or non-MSCC modes.

Examples

  • 1073741824 for 1Mb
  • 1048576 for 1Kb

Result Code

required

The type of response the IN Tester should expect to receive from the Diameter server in response to the initial request. The names displayed correspond to underlying codes:

CodeDescription
2001Success - the Diameter server granted the request for units. The total units granted will be given in the Granted Units field
3004Too Busy - the system is too busy to service the request.
4010End User Service Denied - The Diameter server has identified that the service is denied to this user, e.g. because of subscriber configuration
4011Not Applicable - the service is free to the subscriber so no further credit control is required
4012Credit Limit Reached - the subscriber has run out of money and cannot be granted the requested units
5030User Unknown - the user is not configured or active on the server platform
5031Rating Failed - An internal rating error has occurred. Possibly because there is no rating configured for the service or for the subscriber

If the Result Code value is not Success, then the IN Tester will expect the result code to be recieved as the first result when units to use is set to 0, or in a subsequent update request when units to use is set to a value (either -1 or a positive value).

Note that when receiving an error as a result code to an update request the system does not check the units to use - but it does perform update requests until it achieves the requested units - so if you want to trigger a 4012 - credit limit reached after 10000 units, then ask for units to use to be 10000 and the test will attempt to request that many units through as many update requests as it needs.

If you need to check units used, you can use an eval node subsequent to the diameter node to check the variable $v->{duration} and compare this to the original duration required (duration begins at the requested duration and is decreased until it is 0 or less than 0, or until a non-2001 response is received).