SS7 and IP

Much of the growth in SS7 networks requires that the carriers add dedicated 56 KB or 64 KB circuits between and among the nodes. As already discussed for reliability, most carriers add these circuits in redundant pairs. The voluminous growth of database dips and SS7 queries due to network expansion, AIN and LNP, means that more dedicated circuits must be installed. Network operators can no longer accurately predict the volume or growth rates of their SS7 circuits and networks. When we view the amount of traffic required in the wireless networks (that is, GSM networks with GPRS and SMS service growths approaching explosive proportions), the carriers cannot even begin to predict the volumes they will see on their networks. Usage has been increasing at over 400 to 500 percent annually, causing the carriers and operators to fail in their predictions. To circumvent the problem, carriers have actually been over-provisioning to ensure that network blockage will not occur.

As more SS7 links are being installed in the SS7 network, devices like STPs, SCPs, and HLRs are increasing in size and complexity. Moreover, they require faster processing speeds to handle the loads being generated. These high-speed database engines and processing units are expensive. Because the systems are installed in redundant architectures, they become less efficient because operators must connect myriad devices in the network. Each time a new STP or HLR/ VLR is added to the network, a reconfiguration of the entire network occurs, which also results in additional network management costs.

Network planners are anxious to find alternatives that can reduce their STP or HLR port consumption and delay major unit replacements. Today's SS7 network planners face the following obstacles:

• Their SS7 networks are growing exponentially.

• Dedicated 56—64 Kbps SS7 link solutions are expensive when we contrast that to the shared resources of other networks.

• Ports on the nodes (that is, STP, HLR/VLR) are being rapidly consumed.

• New technology may be required; replacing existing STPs is expensive.

The carriers began to look for other solutions. One of the initial questions that they considered are as follows:

• With all the emphasis on moving to shared packet networks, would it be possible to reliably transport SS7 messages on an IP networks?

• Can the cost advantages be maximized through a shared IP network?

• Is there a way to ensure the reliability of an IP datagram if it is carrying SS7 traffic?

• Can other solutions be used to minimize the load on the existing nodes in the SS7 network?

The availability of cost-effective hardware and the growing global knowledge of IP networking has led many of the carriers to reconsider the way they deploy the SS7 networks. Advancements in reliable IP communication (using various tools such as MPLS, quality of service [QoS], RSVP, and others) and the market successes of Voice over IP (VoIP) enable the carriers to consider the next logical step — the convergence of SS7 and IP networks. For the network planners, any means or device for off-loading SS7 traffic must be

• Capable of handling carrier-grade traffic loads

• PSTN/SS7 network transparent — there must be no additional point codes and no network reconfiguration requirements

• As reliable for message transfers as the current Public Switch Telephone Network (PSTN)

• Remotely manageable with support for existing operations standards, like Simple Network Management Protocol (SNMP)

The industry response to their dilemma is the development of a new standard protocol for routing SS7 messages over IP — the Stream Control Transmission Protocol (SCTP). This Internet Engineering Task Force (IETF) standard ensures the reliable transmission of SS7 messages routed over IP networks.


SCTP is an IP transport protocol developed by the Signal Transport (SIGTRAN) working group of the IETF. The basic structure of the SCTP stack is shown in Figure 8-12 with its sublayers defined. It is used to replace the User Datagram Protocol (UDP) and Transmission Control Protocol (TCP)

transports for performance and security critical applications, such as voice signaling where protocols like SS7 or ISDN are carried over IP. To place it on an equivalent level of the SS7 protocol, it is more related to the MTP-2 layer as shown in Figure 8-13.


Sequencing Sublayer

Restructure Sublayer

Reliability Sublayer

-igure 8-12: The SCTP sublayers









Figure 8-13: The SCTP relates to MTP-2

In SCTP, data transfer is packet-based, and delivery is guaranteed. This makes SCTP more suitable for handling transaction-based applications (specifically, signaling protocols) than TCP, where an application is forced to deal with the complexity of an undelineated data stream, or UDP, where an application needs to implement its own retransmission algorithms.

SCTP is designed to handle congestion and packet loss better than existing standards. Each SCTP association (an SCTP association is similar to a TCP connection, except that it can support multiple IP addresses at either or both ends) is divided into a number of logical streams. Data is delivered in order for each stream. Much like TCP, SCTP uses a message acknowledgement and retransmission scheme that ensures message delivery to the remote end. However, SCTP provides multiple message streams in order to minimize the head-of-the-line blocking effect that can be a disadvantage with TCP. A key advantage of SCTP is its ability to support multiple network interface controllers that enable applications to dynamically determine the fastest and most reliable IP network for message transmission.

Was this article helpful?

0 0
Mobile Apps Made Easy

Mobile Apps Made Easy

Quick start guide to skyrocket your offline and online business success with mobile apps. If you know anything about mobile devices, you’ve probably heard that famous phrase coined by one of the mobile device’s most prolific creators proclaiming that there’s an app for pretty much everything.

Get My Free Training Guide

Post a comment