Diameter Events (General)
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:
The content of custom AVPs must adher to a number of very basic types:
1.
Connection and core credit control information that is not specific to the
event request.
Controlled by the
n2svcd
Service Daemon. Diameter endpoint information is specified in the DiameterApp
Application configuration, and cannot 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.
Test Fields for Generic Diameter Events
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.AVPS
[
{
"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
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. ExamplesSubscription ID
64 21 063 5462
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. ExamplesRequested Units
1
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:
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.Result Code
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
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. ExamplesGranted Units
1