In this section:

Overview

It is important for STP operators to be aware of the traffic levels and patterns transiting their systems. The relevant measurements, data and operational, allow the operator to evaluate system performance as it relates to the network. The data measurements are recorded in real-time and are written to files that can be obtained at any time.

The measurements are used for the following:

  • network design
  • link utilization optimization
  • growth management
  • accounting for inter-carrier traffic
  • verification of services and features
  • verification of inter-carrier agreements
  • optimization of inter-carrier traffic
  • troubleshooting

The following three methods are used to compile these measurements:

  • industry-standard operational measurements collection
  • Gateway Accounting
  • Integrated Monitoring Feed (IMF)

For information about configuring operational measurements, refer to Data Measurement Reference.

Operational Measurements Collection

Note

Operational measurements are referred to as data measurements or statistics in the DSC Documentation Library.

As a full featured STP, the DSC provides industry standard operational measurements (OMs). Through this function, the operator can obtain information required to understand network activity levels, past events, and trends. This data is required by Network Engineering and current operations. These measurements allow the evaluation of system performance as it relates to a network.

The OMs are recorded in real-time and are written to ASCII comma separated value (CSV) files that can be obtained at any time. These files can then be loaded into spreadsheets, databases, third-party applications, or reviewed directly.

The intervals are gathered in files and accumulated in the following three time slots:

  • 5 - every 5 minutes
  • 30 - every 30 minutes
  • d - every 24 hours (daily, with accumulation intervals ending at midnight)

Operational Measurements

The following operational measurement categories are supported:

  • system, including Global Title Translation (GTT), as defined in GR-82-CORE, section 6.4.2 System Total Measurements, and section 6.4.3 Translation Type Measurements

    Note
    System refers to the DSC that includes the hardware, software, operating system (OS), and the purchased applications.

  • linksets and links as defined in GR-82-CORE, section 6.4.6 Link Set Measurements and section 6.4.4 Link Measurements

  • destination (routesets) as defined in GR-82-CORE, section 6.4.7 Destination Measurements

  • Signaling Gateway (SG)

    Note
    The measurements for SG have not yet been defined in the Internet Engineering Task Force (IETF) specifications.

  • Gateway Accounting (GWA) 

    Note
    The measurements for GWA are based on ITU-T Q.752, Section 7 for MTP3 and SCCP traffic. Items and sections in Q.752 which are defined for further study are excluded. For more information about GWA, refer to Gateway Screening and MSU Tracing.

  • INAPGW

  • VM Usage
  • DSC
  • IWF

Gateway Accounting

In addition to regular STP OMs and IMF, the DSC offers a method to further analyze traffic information by groupings of parameters similar to those found in Gateway Screening. The operator defines the set of parameters and provides an instance name with which to reference the counts in the ASCII files produced with the results.

The gateway accounting functionality (GWA) is a licensed feature to allow network operators to support cascade remuneration of the SS7 messages coming into or through a signaling network from an SS7 linkset or from a user. The accounting method used is based on the ITU Recommendation Q.752, 1997/06 and is applied to both ANSI and ITU networks.

There are up to 10,000 possible GWA related counters active per file on a DSC at any one time.

The inspection criteria for the purposes of Gateway Accounting can be a combination of the following fields:

  • MTP3 Parameters
    • NA
    • Linkset APC or Application ID (incoming or outgoing based on traffic direction)
    • Traffic Direction (RX/TX)
    • OPC Range
    • DPC Range
    • SI Range
  • SCCP Parameters:
    • NA
    • Linkset APC or Application ID (incoming or outgoing based on traffic direction)
    • Traffic Direction (RX/TX)
    • OPC Range
    • DPC Range
    • CLD SSN Range
    • CLD Digits Prefix (6 max)
    • CLG Digits Prefix (6 max)
    • SCCP Class Range
    • TCAP Op Code Range

For information about configuring Gateway Accounting, refer to Gateway Accounting Data Measurement.

Integrated Monitoring Feed

Monitoring traffic across a traditional STP requires an investment by the operator in probe equipment for each link used. However, the DSC allows the operator to send a copy of all MSUs transiting the system to any application connecting on TCP/IP using the Integrated Monitoring Feed (IMF). A dedicated port on the switches is used for this purpose.

Every MSU that enters or leaves the DSC can be copied and sent over IP for off-board monitoring. This functionality eliminates the need for probes to monitor SS7 and SIGTRAN traffic.

When configuring IMF, the operator may choose only a subset of messages to be sent to the receiver application. Up to five separate receiver applications may be connected at one time.

For those looking for a simple troubleshooting tool, and who do not want to create a receiver application, this feed can be sent directly to a file ready for Wireshark.

A VLAN on port 23 of the switches is dedicated to this purpose. This is a TCP/IP connection. The MSU is sent including its MTP3 information along with header information. The header information contains a sequence number, a connection heartbeat indication, and information concerning the Network Appearance (NA).

For information about configuring IMF, refer to Configuring the Integrated Monitoring Feed.

IMF to Wireshark

For simple troubleshooting and monitoring of both SIGTRAN and TDM links, DSC allows placing information into a format ready for the Wireshark utility which is the predominant tool for troubleshooting protocols and connections. Wireshark is a PC-based Open Source utility for protocol analysis.

The use of Wireshark is already well established for SIGTRAN links, however, most signaling systems cannot feed TDM link information into Wireshark. By using the IMF, the DSC is able to provide both SIGTRAN and TDM traffic to Wireshark.

The following figure shows the basic architectural information flow. The IMF processes on each Routing CPU (Management and Routing VM and Routing VM) send a copy of the MSU along with header information to a file on the Management CPUs (Management and Routing VMs). The operator can download that file to his or her workstation. It is required that Wireshark runs on this workstation.

To allow Wireshark to understand the IMF header information, Ribbon supplies the source code for the Wireshark plug-ins to decode this information. For information about the prerequisite to using Wireshark and configuring this application, refer to Using Wireshark (prerequisite) and Configuring Wireshark Lua Plugins for Linux, respectively.

Architecture of IMF to Wireshark Flow



  • No labels