Testing Diameter Events

The IN Tester system can be used to test Diameter credit control event requests against a Diameter server. The IN Tester provides support for configuring each type of request as a custom node to provide more context in tests.

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


Test Fields for Generic Diameter Events

AVPS

required

Generic Diameter events 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 a direct debiting event, price enquiry etc).

As the generic Diameter event 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 a direct debiting event. Text in bold is the text most likely to need changing.

  [
    {
      "name": "Session-Id_auto"
    },
    {
      "name": "CC-Request-Type",
      "value": 4
    },
    {
      "name": "CC-Request-Number",
      "value": 1
    },
    {
      "name": "Requested-Action",
      "value": 0
    },
    {
      "name": "Subscription-Id",
      "value": [
        {
          "name": "Subscription-Id-Data",
          "value": "<b>64220635462</b>"
        },
        {
          "name": "Subscription-Id-Type",
          "value": 0
        }
      ]
    },
    {
      "value": [
        {
          "name": "CC-Service-Specific-Units"
          "value": "<b>1</b>"
        }
      ],
      "name": "Requested-Service-Unit"
    },
    {
      "value": "<b>sms@huawei.com</b>",
      "name": "Service-Context-Id"
    }
  ]

Test Fields Common to all Custom Diameter Event Nodes

Subscription ID

required

All Diameter events 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

Requested Units

required

For Diameter DIRECT_DEBITING events, the requested units is required. The type of requested units (service specific, time etc) is automatically chosen by the system based on the configuration imported into the IN Tester.

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

Examples

  • 1

Result Code

required

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

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

If the response from the Diameter server was expected to be 2001 (Success), but is not, the test will stop. If the response is expected to be any non- success error and does not match, the test will continue with a test check failure noted.


Granted Units

required

The total number of units that the IN tester should expect to see in a successful response from the Diameter server. Only provided if the Result-Code was 2001 - Success.

Examples

  • 1