In this section:
Node Counter Data Measurements
The Ribbon Signaling Systems DSC provides node counter data measurements. DSC node counters are reported to the DSC Node file, as shown in the example provided in the following figures.
Note
To view the comma-delimited data measurements file retrieved from the DSC, save the file using a .csv file extension (comma-separated variables file type) and import into a spreadsheet.
DSC Node Counter Statistics File Example
DSC Node Counter Statistics File Example (continued)
The Instance represents the object in the application that is generating the statistics and is a string with the format <a> <b>, as follows:
<DSC Instance Name> <DSC Node Name>
DSC node names are based on configuration data. When a DSC node name is modified, a new record (row) is created in the data measurements file.
In the preceding data measurements example, the Instance is defined as:
a : DSC Instance Name = DSC-Macketh
b : DSC Node Name = sport.satellite.com
Note
Data measurements for an active or inactive DSC node may appear in the DSC Node file as zero entries in all fields. A DSC node which does not generate any node counter data appears in the DSC Node file with zero entries.
The data measurement fields are listed and described in the following table.
Node Counter Data Measurement Fields
Name | Type | Description |
|---|---|---|
Requests Received | Count | Requests received from any Diameter ADN. |
Requests Sent | Count | Requests sent to any Diameter ADN. |
Answers Received | Count | Answer messages without the error bit set (“successful” answers) or redirect answers (with the error bit set and appropriate result code) received from any Diameter ADN. Counts answers that are not errors, and also counts redirects (that are errors, but indicate a partial success). |
Answers Sent | Count | Answer messages without the error bit set (“successful” answers) or redirect answers (with the error bit set and appropriate result code) sent to any Diameter ADN. Counts answers that are not errors, and also counts redirects (that are errors, but indicate a partial success). |
Messages Received | Count | Messages received from any Diameter ADN. In most configurations this represents messages received from “outside” the DSC; in some cases this counts bytes between DSC Nodes that communicate using any Diameter ADN. |
Messages Sent | Count | Messages sent to Diameter ADNs, except message in transit at the moment counts are reported. Note that messages received and messages sent should be the same in almost all cases, since message discards are quite rare (an error message is still a message). |
Bytes Received | Count | Bytes received from any Diameter ADN. |
Bytes Sent | Count | Bytes sent to every Diameter ADN. |
Request Timeouts | Count | Number or requests that generate an error answer because of a timeout (no answer received). |
Average Processing Time | Average | Time in milliseconds measured from when a message (of any type) is received from a Diameter ADN until it is placed on the transmit queue of a Diameter ADN (possibly from another DSC Node Instance within the same DSC Node). One message is sampled every time a timer expires. |
Processing Time Sampled Messages | Count | Number of messages sampled to determine the Average Processing Time. |
Average Queuing Time | Average | Time in milliseconds measured from when a message (of any type) is placed on the transmit queue of a Diameter ADN until it is sent to the transport layer of that Diameter ADN (possibly from another DSC Node Instance within the same DSC Node). One message is sampled every time a timer expires. |
Queuing Time Sampled Messages | Count | Number of messages sampled to determine the Average Queuing Time. |
Average Transaction Time | Average | Average length of a transaction (between request received and answer sent) in milliseconds. Reported by the DSC Node Instance that first received the message from a Diameter ADN. A timer runs in each DSC Node Instance. When the timer expires the next received request gets its transaction time measured and the timer is restarted. |
Transaction Time Sampled Messages | Count | Number of messages that were sampled for Transaction Time Average. |
| SCTP Retransmission Data Chunks | Count | Number of SCTP data chunks retransmitted on all ADNs connected to this node with SCTP associations. The number is the sum of numbers from all related ADNs. |
| Requests Discarded | Count | The number of request messages discarded in the indicated DSC Node. |
| Answers Discarded | Count | The number of answer messages discarded in the indicated DSC Node. |
Generating Round Trip Statistics
The DSC system compiles statistics on round trip delays for each type of Diameter request message transmitted to an ADN. Round trip delays on outbound transactions are calculated and categorized according to destination and command type. Standard statistics intervals (for example, 5 minutes, 30 minutes, or 1 day) apply to the delay measurement.
Diameter messages are routed by the DSC application. Diameter response messages traverse backwards through the request path, which provides a mechanism to correlate a reply to the original request for the calculation of round trip delays.
Common fields within the Diameter base message are used to categorize messages by request type. Diameter request messages are categorized by the application ID, command code, and the destination.
The classification of round trip delays for a request message fall into two different categories, transaction and sub-transaction, as follows:
- a transaction round trip delay accounts for a complete outgoing transaction (request and response) and is defined as the difference between:
- the time a received request message is processed by the routing tables and is ready for transmission.
- the time a corresponding response message is ready to return to the originating ADN connection.
- a sub-transaction round trip delay is defined as the difference between:
- the time a request message is ready for transmission to an ADN connection.
- the time a corresponding response message is received from an ADN connection
Two methods are used to determine which incoming Diameter messages are traced for outgoing round trip delay measurements. The first method applies a DSC Node attribute to control the round trip delay measurement for all messages from an ADN. Alternatively, the Routing Table Modification commands to control round trip delay measurements for individual messages from an ADN.
The DSC Node attribute Round Trip Accounting controls round trip delay measurements for all messages received from ADNs. The attribute is available in the DSC Node General Configuration screen of the WebUI and functions as follows:
- Enabled: enables round trip accounting statistics for all incoming messages from all ADNs.
- Disabled: disables round trip accounting statistics for all incoming messages from all ADNs.
Note
The default setting for Round Trip Accounting is disabled.
The Routing Table Modification commands, rta on and rta off, control round trip delay measurements for individual messages received from ADNs. The Routing Table Modification commands are summarized in the following table:
Routing Table Modification Command for Round Trip Accounting
| Command | Description |
|---|---|
| rta on | Enables round trip accounting for transactions and sub-transactions when applied to a request or answer message from an ADN. The DSC Node attribute Round Trip Accounting is disabled. |
| rta off | Disables round trip accounting for transactions and sub-transactions when applied to a request or answer message from an ADN. The DSC Node attribute Round Trip Accounting is enabled. |
Note
The Round trip Accounting attribute is used in combination with the Routing Table Modification commands to control round trip delay measurements for individual ADNs.
To enable Round Trip accounting for all messages
To enable Round Trip accounting for messages from an ADN
Diameter Instance Names
The Diameter Instance name definition for round trip statistics is defined for transaction and sub-transaction accounting, as follows:
For transaction round-trip accounting, the format is: DSC_NAME DSC_NODE DEST:APPID:CCODE.
For sub-transaction round-trip accounting, an outbound ADN name is appended: DSC_NAME DSC_NODE DEST:APPID:CCODE:ADN
The following Instance name components are defined:
- DSC_NAME: the 'DSC Name' attribute associated with each DSC Instance.
- DSC_NODE: the 'Name' attribute associated with the DSC Node.
- DEST: the Destination of the Request message.
- APPID: the Application ID of the Request message.
- CCODE: the Command Code of the Request message.
- ADN: the 'Name' attribute associated with the Adjacent Diameter Node.
Note
The statistics system enters overflow mode if the number of unique Instance names exceeds 50,000.
Diameter Request Types
Round trip statistics are created according to the request type. A request type is assigned to each Diameter request from peers. The components of each request type are used to form the Instance name.
Request types are determined by the application ID, command code, and destination. In the case of a CCR or NCR request, the command code is further discriminated by the CC-Request-Type or NC-Request-Type AVPs.
The components that determine a request type are as follows:
- Application ID
- defines the APPID field in the Instance name.
- if the Application ID is not found in DSC Definitions -> Application ID Definitions, then the string 'A#' is used, where '#' is the application ID as a decimal number.
- Command Code
- defines the CCODE field in the Instance name.
- if the command code is found in DSC Definitions -> Command Code Definitions, then the 'Name' field corresponding to the command code is used as the CCODE field.
- if the command code is not found in DSC Definitions -> Command Code Definitions, then the string 'C#' is used for CCODE, where '#' is the Command Code as a decimal number.
if the request is a CCR (command code 272), then the CC-Request-Type AVP (Diameter AVP code 416) is examined to distinguish different types of CCR where one of the strings in the following table is used for CCODE:
CCR Command Codes CCR-I CC-Request-Type 1 INITIAL_REQUEST CCR-U CC-Request-Type 2 UPDATE_REQUEST CCR-T
CC-Request-Type 3 TERMINATION_REQUEST CCR-E CC-Request-Type 4 EVENT_REQUEST CCR-# A currently undefined CC-Request-Type "#" is the decimal value of CC-Request-Type AVP CCR No CC-Request-Type AVP is present
If the request is an NCR (command code 330), then the NC-Request-Type AVP (Diameter AVP code 595) is examined to distinguish different types of NCR where one of the strings in the following table is used for CCODE:
NCR Command Codes NCR-I NC-Request-Type 1 INITIAL_REQUEST NCR-U NC-Request-Type 2 UPDATE_REQUEST NCR-Q
NC-Request-Type 3 QUERY_REQUEST NCR-# A currently undefined NC-Request-Type "#" is the decimal value of NC-Request-Type AVP NCR No NC-Request-Type AVP is present
- Destination
- defines the value of the DEST field in Instance name
- Destination-Host - if the value exists in the request message:
- the DEST portion of the instance string has the format: H:DestHost, where 'DestHost' is the value of the Destination-Host AVP.
- the DEST portion of the instance string has the format: H:DestHost, where 'DestHost' is the value of the Destination-Host AVP.
- Destination-Realm - if Destination-Host does not exist in the request message:
- the DEST portion of the instance string has the format: R:DestRealm, where 'DestRealm' is the Alias value of the Realm, if the Realm is listed under the DSC Definitions -> Realm Definition.
- the value of the Destination-Realm AVP
- AVP value - conversion operations are performed on AVP values used in the Instance name (AVP values are ASCII or UTF-8 encoded):
- the following characters are removed:
- '\0' (null character)
- ',' (delimiter for CSV file)
- ':' (field delimiter for Instance name)
- '\n' (new line, delimiter for statistics records)
- the following characters are removed:
- characters 'A' through 'Z' are converted to lower case.
- AVP value - conversion operations are performed on AVP values used in the Instance name (AVP values are ASCII or UTF-8 encoded):
Round Trip Data Measurement Types
Statistics contain data measurement types that are generated for each Diameter message. A Diameter message generates one transaction Instance, and one or more sub-transaction Instances resulting from the ADN component of the Instance name.
Note
Rejected or filtered requests, along with discarded answers, are not included in the round trip data measurements.
Transaction and sub-transaction round-trip statistics are categorized by the following data measurement types:
- Success
- Redirect
- UTD
- Other
Each data measurement type includes the following parameters: Messages, Delay, Delay O100, Delay O500, and Delay O1000 values. Transaction round trip statistics also includes a parameter for sub-transactions.
For sub-transaction round trip accounting, the following data measurement types are defined:
- Success: accounts for sub-transactions that results in a 2xxx reply.
- Redirect: accounts for sub-transactions that result in an explicit redirection to another destination (for example, DIAMETER_REDIRECT_INDICATION (3006) result code)
UTD: accounts for requests that resulted with the DIAMETER_UNABLE_TO_DELIVER (3002) code
Code only applies to DIAMETER_UNABLE_TO_DELIVER received from a peer ADN.
- Other: accounts for sub-transactions that result in a reply that is not a 2xxx, DIAMETER_REDIRECT_INDICATION (3006), or DIAMETER_UNABLE_TO_DELIVER (3002).
For transaction round trip accounting, the following data measurement types are defined:
- Success: accounts for each transaction as a whole, beginning with the reception of the request from a peer, ending at the return of a successful (2xxx) reply to the peer.
- UTD: accounts for each transaction as a whole, beginning with the reception of the request from a peer, ending at the return of a DIAMETER_UNABLE_TO_DELIVER (3002) reply to the peer.
Other: accounts for a transaction as a whole, beginning with the reception of the request from a peer, ending at the return of a reply to the peer.
Includes all requests that resulted in an reply that is not a 2xxx, DIAMETER_REDIRECT_INDICATION, or DIAMETER_UNABLE_TO_DELIVER.
Sub-transactions: accounts for the number of sub-transactions used to complete the transaction.
An excessive or unexpected number of sub-transactions can indicate an issue in network configuration or destination server malfunction.
Round Trip Statistics Output Files
CSV (comma-separated) output files are generated for transaction and sub-transaction statistics with the following names:
- DSC_RTA_Subtr
- DSC_RTA_Trans
Both CSV output files are retrieved using the Statistics application or the file retrieval utility from the System menu in the Web UI. See Data Measurement Report.
For sub-transaction round trip accounting, the statistics CSV output file, DSC_RTA_Subtr, is defined for intervals of: 5 min, 30 min, and one day.
The columns contained in the CSV output file for sub-transactions are defined in the following table.
Sub-transaction Round Trip Statistics CSV Output File Definition
| CSV Column | Description |
|---|---|
| Date | Date and time of the statistics entry. |
| Instance | Instance Name of the statistics output. |
| Success Delay | The average round-trip delay measured on a sub-transaction where the response has a result code of 2xxx. |
| Success Messages | The number of messages included in the Success Delay measurement. |
| Success Delay O100 | The number of messages where the Success Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| Success Delay O500 | The number of messages where the Success Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| Success Delay O1000 | The number of messages where the Success Delay measurement is at least 1000 milliseconds. |
| Redirect Delay | The average round-trip delay measured on a leg of the transaction where the response is DIAMETER_REDIRECT_INDICATION (3006). |
| Redirect Messages | The number of messages included in the Redirect Delay measurement. |
| Redirect Delay O100 | The number of messages where the Redirect Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| Redirect Delay O500 | The number of messages where the Redirect Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| Redirect Delay O1000 | The number of messages where the Redirect Delay measurement is at least 1000 milliseconds. |
| UTD Delay | The average round-trip delay measured on a leg of the transaction where the response is DIAMETER_UNABLE_TO_DELIVER (3002) Measurement does not include locally generated DIAMETER_UNABLE_TO_DELIVER responses where an available outgoing ADNC is not found. |
| UTD Messages | The number of messages included in the UTD Delay measurement. |
| UTD Delay O100 | The number of messages where the UTD Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| UTD Delay O500 | The number of messages where the UTD Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| UTD Delay O1000 | The number of messages where the UTD Delay measurement is at least 1000 milliseconds. |
| Other Delay | The average round-trip delay measured on a leg of the transaction where the response is not a Success, Redirect, or UTD. Measurement does not include any request that has been filtered locally. |
| Other Messages | The number of messages included in the Other Delay measurement. |
| Other Delay O100 | The number of messages where the Other Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| Other Delay O500 | The number of messages where the Other Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| Other Delay O1000 | The number of messages where the Other Delay measurement is at least 1000 milliseconds. |
For transaction round trip accounting, the statistics CSV output file, DSC_RTA_Trans, is defined for intervals of: 5 min, 30 min, and one day.
The columns contained in the CSV output file for transactions are defined in the following table.
Transaction Round Trip Statistics CSV Output File Definition
| CSV Column | Description |
|---|---|
| Date | Date and time of the statistics entry. |
| Instance | Instance Name of the statistics output. |
| Sub Transactions | The number of sub-transactions used to complete the transaction. |
| Success Delay | The average delay measured between the reception of the request from a peer and transmission of a 2xxx reply. |
| Success Messages | The number of messages included in the Success Delay measurement. |
| Success Delay O100 | The number of messages where the Success Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| Success Delay O500 | The number of messages where the Success Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| Success Delay O1000 | The number of messages where the Success Delay measurement is at least 1000 milliseconds. |
| UTD Delay | The average delay measured between the reception of the request from a peer and transmission of the DIAMETER_UNABLE_TO_DELIVER reply |
| UTD Messages | The number of messages included in the UTD Delay measurement. |
| UTD Delay O100 | The number of messages where the UTD Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| UTD Delay O500 | The number of messages where the UTD Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| UTD Delay O1000 | The number of messages where the UTD Delay measurement is at least 1000 milliseconds. |
| Other Delay | The average delay measured between the reception of the request from a peer and transmission of a reply that is not a 2xxx, DIAMETER_REDIRECT_INDICATION, or DIAMETER_UNABLE_TO_DELIVER. |
| Other Messages | The number of messages included in the Other Delay measurement. |
| Other Delay O100 | The number of messages where the Other Delay measurement is at least 100 milliseconds but less than 500 milliseconds. |
| Other Delay O500 | The number of messages where the Other Delay measurement is at least 500 milliseconds but less than 1000 milliseconds. |
| Other Delay O1000 | The number of messages where the Other Delay measurement is at least 1000 milliseconds. |
Overview
Content Tools