October 2001

 
SS7 And IP Telephony

BY DAVID EVANS
 

What Is SS7?
Chances are, unless you are involved in public network telecommunications, you have never heard of SS7. However, you have probably used it. SS7 is what runs public wireless and wireline networks. It is the communications network for the communications network, both a suite of protocols as well as an architecture.

When you pick up the telephone in your home, or one connected to your company's private branch exchange (PBX), it connects to your local telephone exchange. The exchange then routes your call using SS7 protocols over SS7 links. In seconds, it can send your call around the world through all kinds of equipment. If the person you are calling has moved to a different state in the U.S., SS7 will find out where. If the recipient is out and has voice-mail, SS7 will route the call to the mailbox, wherever it may be.

On top of that, when you dial a mobile phone or send a text message, the SS7 network finds out where in the world that mobile phone is and routes the call there, making sure the appropriate charges are logged. It can also reroute your call when you roam into the domain of another switching center, or cut you off if you run out of money on your prepaid phone.

In short, the intelligence in the public network is SS7.

SS7 Versus ISDN
To be useful, IP telephony networks need to be connected to the public network. Today corporate telephony systems usually connect using ISDN PRI interfaces -- so why not just use that to connect to the public network? For small systems, ISDN is very cost effective. But once you start to scale up, SS7 becomes more economical. A single SS7 link can handle the messaging traffic for thousands of voice circuits. However, the most compelling reason for using SS7 is not cost, but the extra features and capabilities it brings.

Fundamentally, ISDN just makes calls. The network-side equivalent of ISDN is the SS7 protocol ISUP, which makes calls much faster and more efficiently than ISDN. ISUP also gives you more information about the call and routes it more efficiently.

And ISUP is only one part of the SS7 suite. SS7 also includes protocols for data traffic through the network, such as querying databases or more complicated interactions between different nodes. The underlying transport and management are also much more sophisticated, with redundancy, fault reporting, and correcting as more integral parts of the design.

The basic difference? With ISDN, you're just a user. With SS7, you're the network.

What's The Catch?
There is always a price to pay for sophisticated capabilities -- and this is true of SS7.

First, SS7 is very complex, with many different national variants. Operation is often covered by legislation -- which is, after all, part of the core infrastructure of most countries. But there are methods and tools you can use to overcome these problems (which we will discuss later).

The second problem is that once you are a part of a network, the network expects you to be properly functioning 24/7. Firing garbage into an ISDN application only affects you. That is the idea behind an access protocol like ISDN. Firing garbage into an SS7 network gets the attention of the operator, and you'll lose the connection. Therefore, when you start playing with SS7, you need to get it right.

I'm In IP Telephony; Why Do I Need SS7?
The installed base for SS7 is massive -- more than $1 trillion. IP telephony deployment and revenues are microscopic by comparison. IP-based services need to become parasites on the SS7 network, leveraging that access instead of competing on an installed base.

Consider an example. Today, you can get a British Internet service provider (ISP) service that tells you when a call is incoming while you are using your line for connecting to the Internet. You can then choose whether to send the call to voice-mail, hang up and take the call, or even take the call over IP through your modem. This is a good example of IP telephony services sneaking in by leveraging existing SS7 technology. It is good for the ISP, since people use its service without worrying about missing calls. It also gives the ISP's customers a taste of IP telephony. It also allows the ISP to terminate the incoming call, tapping into another source of revenue.

How about a service that lets you consolidate your different phones and voice mail? For someone to contact you, they need to know where you are and which number to use: Office phone, home phone, or cell phone. Callers can also end up leaving voice mail in three different places, all of which you need to check periodically. The answer to this problem could come from IP service logic without the calls actually leaving the SS7 network.

SIP developers have promised a unified environment that unhooks addresses from physical equipment, letting users process calls more intelligently. However, today's SIP service logic needs access to the SS7 network to reach the market. Without SS7 connectivity, a SIP service is a novelty. With SS7 connectivity, service platforms can intercept and reroute normal calls. They can monitor when your mobile phone is switched on and where it is, even controlling the response the network sends to the caller. Voice mailboxes can be amalgamated, with the presence of a message communicated over e-mail, mobile short messaging, or any medium that is most convenient.

The technologies now available can provide amazing integration and new services, but they need to be deployed as an integral part of the SS7 network -- not simply as customers.

Getting Into SS7
The advantages of understanding and using SS7 are becoming clear. And you can enter the world of SS7 at several levels, using protocol interworking, service interfaces, protocol interfaces, or abstraction layers, or by implementing an SS7 stack. Each level provides a different trade-off of flexibility and control versus simplicity and speed.

The simplest method is with an SS7 protocol interworking device. This lets you use an SS7 connection just by configuring the unit. It is ideal for taking advantage of the economics of SS7 for large systems. However, the amount of control and number of extra features you get are limited by the lowest common denominator of SS7 and the other protocol it is interworking to (for example, SIP, H.323, or ISDN).

Some of these interworking devices also provide an application programming interface (API) or other interface for simple services. This gives you more control and flexibility without forcing you to become an SS7 expert. Similar to interworking devices are service interfaces like those provided by the JAIN and PARLAY groups. These give you a service-oriented API so that, again, you have a high-level abstraction between you and the complications of the SS7 network.

Getting a good level of flexibility and control requires visibility down to the SS7 message level. Until recently, this would be done using a proprietary API from a specific vendor. Now the JAIN group provides protocol interfaces, as well as their service interfaces, to the three key SS7 protocols: ISUP, MAP, and INAP. ISUP is the SS7 call control protocol; MAP is the wireless protocol for database lookups, roaming and, short messaging; and INAP is the intelligent networking protocol used for advanced services in the SS7 network. There is also a JAIN API for TCAP, the SS7 protocol used by MAP and INAP, which can give a higher degree of flexibility.

This combination of protocol interfaces gives you the ability to create most kinds of SS7/IP service. The underlying protocols all have main variants and national sub-variants, but the JAIN APIs shield you from that extra complexity. This allows you to deploy a system almost anywhere without extra development.

The JAIN protocols are for use in a Java environment, and they don't end at SS7. JAIN also includes an interface for SIP, allowing you to develop in a single environment, with the same type of interface, for all protocols. It also solves the problem of vendor dependence, since the JAIN API is an open standard. The only problem with JAIN is that not all the work is complete. You may be forced to use a vendor-specific API to implement it today.

The final option is to implement an SS7 stack. This is usually done by buying-in a hardware design and protocol source code. This option gives you the ultimate flexibility, but the advantages over an API are minimal. The investment for this approach is massive, so it is unlikely to give you the best relative return on your investment.

Choosing SS7 Hardware and Software
SS7 links are usually presented on a timeslot/circuit in an E-1, T-1, or J-1 connection or on a serial interface. Most SS7 hardware supports these interfaces. They are likely to have more of a certain type, depending on which regional market the designer had in mind.

The number of major and minor protocol variants supported by the SS7 stack in use is important, since it limits where you can deploy. The main variants are U.S. (ANSI), International Telecommunications Union (ITU -- which is the basis for European ETSI ISUP), and Japanese. Most other variants are based on one of these.

Protocol interworkers are a chassis-based system, usually with a TCP/IP interface used for management and the service API (if there is one). These systems may already have approvals from network operators for SS7 interconnects, so this route is often the quickest to market.

If you can use a standard API like JAIN, you will enjoy a measure of vendor independence, since you can instantly use any stack or hardware certified as JAIN-compliant. The choice, then, is whether to integrate a board into your system or to connect using an independent chassis.

For smaller systems, the board is the obvious choice. However, chassis systems often provide a convenient IP-based API. SS7 systems like this can allow you to consolidate your expensive SS7 links in one place, sending and receiving the messages from many other chassis in a large IP network.

Another alternative is to use a system based on the new SIGTRAN standard. SIGTRAN is an Internet Engineering Task Force (IETF) working group that has produced a number of protocols for sending SS7 messages over IP. The higher-layer SS7 protocols then run on your system, along with an adaptation layer. This adaptation layer communicates over the new IP protocol SCTP (a part of the SIGTRAN suite) with a signaling gateway, allowing messages to be sent on the SS7 network.

The best choice for your system depends on several factors and may also vary with time. You can quickly get connected using a protocol interworker, then integrate SS7 to gain better access as your expertise grows.

Systems may vary in size for different deployments, or expand as demand for a service grows. Therefore, the scalability a vendor provides is also important. The vendor needs to demonstrate a roadmap that meets your ongoing needs, including support for new standards and methods as they become available.

The Future Of SS7
The days of SS7 are numbered, but not over. SS7 technology is becoming higher density, more powerful, and less expensive. It is also becoming significantly easier to integrate and use. This, combined with the huge installed base, gives SS7 a profitable -- and not insignificant -- future.

It is also worth keeping in mind that SS7 is an architecture as well as a technology. New technologies are allowing the architecture to exist in software. For example, the SIGTRAN suite allows an entire SS7 network to be run over IP, with SS7 providing many features not currently available on any other technology.

The pivotal moment will not be when the last SS7 link is taken down, but when SS7 is no longer dominant, which could happen suddenly. Currently, European and Asian mobile operators are committed to deploying packet-based systems. Fixed-line operators are rolling out large data networks capable of handling the voice traffic.

The last mile will eventually bring high-bandwidth to most users and make the IP phone something the man in the street has heard of. At this point, SS7 could suddenly find itself playing second fiddle to IP telephony protocols like SIP. When that happens, being in IP telephony won't mean you need to understand SS7 to be successful. But remember, as long as SS7 has more users than IP telephony, you need it more than it needs you.

David Evans is product manager, Telecommunications and Embedded Group, Intel Corporation. The Intel Telecommunication and Embedded Group develops advanced communications technologies and products that merge data and voice technologies into a single network. Products from the Telecommunications and Embedded Group are available to customers at multiple levels of integration: silicon, software, boards, platforms, systems, and appliances.

[ Return To The October 2001 Table Of Contents ]

BY GUY REDMILL

Implementing value-added services used to be a costly and time consuming business, requiring upgrades to all of the central office switches within a network. The advent of the Advanced Intelligent Network (AIN or IN) was supposed to change this, as it outlined a means by which services could be deployed at a network level, thereby eliminating the need to modify each central office switch. The AIN / IN provides a mechanism to deploy basic services rapidly and to innovate new service products that allow competing service providers to differentiate themselves. It also achieves the goal of vendor and platform independence. This was achieved by designing a separate service architecture as an overlay to the existing circuit switched network.

The physical overlay consists of three principal components -- the service switching point (an enhanced central office switch); the service control point (the remote control node); and the Intelligent Peripheral (a node dedicated to supporting services). A set of signaling protocols, extensions to the SS7 signaling standards, was created to provide the framework for the interaction of these components. The protocols, such as the Intelligent Networking Application Part, or INAP, also define a number of services in terms of the individual steps needed to complete a particular service function. These steps are usually referred to as operations. The protocols also show how new services can be created simply by assembling operations into different sequences. All services can be broken down into a series of logical steps, all of which are co-ordinated by the Service Control Point, or SCP.

The service switching point, or SSP is responsible for determining if a particular call requires a service to be activated. It performs this task by checking received call set-up information against entries in a local database. When a call requiring a service is recognized, the SSP uses INAP signaling to notify the SCP, which holds the details of all subscribers in the network, the services that can be offered and to whom. The SCP may either be adjacent to the SSP, or more distantly located, serving a number of different SSPs.

The SCP has an associated database, sometimes referred to as the service data point, or SDP. This contains all of the information relating to the service and is interrogated before the SCP can implement the pre-defined service logic. The service logic may involve requesting the SSP to connect the call to the intelligent peripheral, or IP, so that the caller can be played some specific announcements, or simply providing an alternative number to which the original call should be routed by the SSP, or a combination of both with additional user interactio -- the collection of DTMF tones, for example. IPs may either be locally associated with each SSP as an adjunct, or may also be accessed via remote network connections.

The SCP may be controlled by a service creation center, or Service Creation Environment (SCE). The SCE can be used by the network operator to build new services rapidly, and to deploy them without further modifications to the SSPs. The AIN / IN therefore offers an elegant means of delivering innovative services to subscribers, relying as it does on a centralized architecture, and provides a means of constant upgrade independent of the underlying circuit switched network.

Although the AIN / IN architecture and signaling standards are highly defined, it is important to recognize that they also provide a conceptual framework for service delivery and are therefore readily extensible to other environments. This may prove to be their real value in the long term, and we need to consider the implications of this.

There are several stages in the evolution of any network. First, there is a struggle to achieve ubiquity to ensure that as many subscribers as possible can access a network. Second, there is a struggle to retain subscribers in the face of competition from alternative network operators. It is at this stage that the implementation of services and the value of these services becomes crucial to the operator: Once access is ubiquitous, subscribers inevitably become less easily satisfied and begin to demand more than simply access rights from their network operator, particularly when more innovative service packages are made available by competitors and transfer between operators becomes a realistic proposition. However, a common problem of service creation is compatibility -- either services are tied to a particular platform or cannot be accessed across network boundaries. The AIN / IN addresses these issues by providing a framework designed using public rather than proprietary standards.

Mobile networks provide a classic illustration of the problem of subscriber retention. After the initial novelty of mobile access has evaporated, subscribers are faced with the choice of whether to remain with their original network operator or switch to another provider. The application of AIN / IN to the mobile environment can simplify the process of creating competitive services. Paradoxically, this creates an environment in which, at the same time as competitive operators can become more likely to offer an attractive product, the original operator is equally more likely to innovate their offering still further to ward off competition and retain their subscriber base.

The Custom Applications for Mobile Enhanced Logic (CAMEL), and the Wireless Intelligent Network (WIN), are two different but related approaches to achieving the same goal -- the application of the AIN / IN principles and architecture to mobile networks. In CAMEL, the CAMEL Service Environment (CSE), serves as the equivalent of the SCP, and provides the instructions necessary to deliver a service to a GSM subscriber.

The convergence of circuit-switched and packet-switched networks has led to the emergence of a new generation of switches based around the so-called softswitch architecture. Essentially, this means an application that "provides the intelligence that controls connection services" (International Softswitch Consortium). Softswitches are often located at the interface between circuit switched networks and packet switched networks, routing traffic between the two.

"Classical" Softswitches comprise three principal components: The call agent or softswitch application itself, often referred to as the media gateway controller or MGC; the media gateway, which has responsibility for converting media streams from one format to another and for making the appropriate connections under the direction of the MGC; and the signaling gateway, or SG, which connects to PSTN out-of-band signaling and converts it to an IP format for presentation to the MGC. Most MGC's typically utilize the services of a large database and one or more application servers that can be used to deliver services to subscribers.

In many ways, softswitch architecture resembles the conceptual model of the AIN / IN, and therein lies the rub. Most current deployments feature individual softswitches or softswitches from a single vendor, each with their own discrete set of service applications and service creation environments. This would seem, somewhat ironically, to mirror the development of the PSTN prior to the advent of the AIN / IN, in which networks grew using proprietary switching and service creation equipment from a number of different vendors. Perhaps inadvertently, the nascent IP telephony world may replicate some of the errors of the growth of the PSTN. It is vital, therefore, that consideration of a service architecture that is usable by all softswitches, and by legacy switching equipment within heterogeneous networks, takes place.

In the context of a multi-layered network with many forms of signaling, it makes sense for Softswitches to connect to something like a service overlay network in order to ensure timely and, most important of all, vendor-independent service creation and delivery. This suggests that an architecture not dissimilar to the AIN / IN would be appropriate in this environment.

Leveraging the conceptual framework and architecture provided by the AIN / IN model would seem to provide at least a framework for service delivery across such heterogeneous networks. Indeed, it would be foolish to move forward without considering the value of this approach. Perhaps the next challenge for the IP world is the creation of an AIN / IN-like service layer, independent of the routing and control architecture it would serve.

Guy Redmill is senior product manager for the SS7 product line at Brooktrout Technology. Brooktrout Technology delivers innovative hardware and software platforms that enable the development of New Network applications, systems and services in high growth market segments including voice over packet gateways, enhanced services platforms, wireless infrastructure, messaging, and contact centers.

[ Return To The October 2001 Table Of Contents ]

Last Night I Dreamed Of A Carrier-Grade SS7 Signaling Gateway

BY ALEX LEUNG

There are three network components that are essential for an IP telephony network to leverage SS7/AIN network and capabilities -- the media gateway, the softswitch, and the SS7 signaling gateway. Much has been said about the media gateway and the softswitch, and the requirements needed to make them carrier-grade. Yet there are few articles focused on the unsung hero -- the SS7 signaling gateway. In addition to facilitating the interconnection between IP telephony and SS7/AIN network, the signaling gateway enables network operators to offer traditional SS7/AIN services such as toll-free and calling card services to IP telephony network subscribers -- without duplicating the associated infrastructure.

What Is A SS7 Signaling Gateway And Why Do We Need It?
The Public Switched Telephone Network today uses Signaling System 7 (SS7) to perform two main functions: Providing call signaling/setup functions between telephony switches, and enabling a wide range of SS7 services (toll-free calling, number portability, calling ID, and many more) to which we are accustomed. In fact, SS7 is the foundation for Intelligent Network (IN) services.

The SS7 architecture consists of a protocol-layered suite that can be fragmented into network protocols and application protocols. The SS7 network protocol Message Transfer Part (MTP) carries the SS7 message to the right destination. The MTP has built-in mechanisms to guarantee delivery in a timely manner -- even during SS7 network failure situations. All the other SS7 protocols use the MTP services for message transportation. Signaling Connection Control Part (SCCP) provides additional functions to MTP to support both connectionless and connection-oriented services. The two main SS7 application protocols are ISDN User Part (ISUP) and Transaction Capabilities Application Part (TCAP). ISUP is used for call setup and disconnect between switches while TCAP is used to enable IN services such as toll-free service. Both TCAP and ISUP messages are encapsulated in MTP messages to be carried to the proper SS7 destinations -- which is similar to how IP application messages are carried in IP packets in the IP environment.

While IP telephony provides the opportunity to enable additional new services, SS7 network accessibility is required whenever one wants to leverage existing SS7 services/features. Even in the scenario where a network provider determines to duplicate existing SS7 services, SS7 accessibility is still needed when one of the parties belongs to the PSTN. While SS7 accessibility is the current main driver for deploying IP/SS7 interoperability, IP telephony network accessibility is equally needed from the SS7 network to access the IP telephony subscribers. In the future, the PSTN may also need to access IP feature servers for advanced services that are not provided in the PSTN SS7 network today.

There are two distinct areas where SS7 signaling interworking is applicable. The first area is to provide the physical interconnection between the IP telephony and the SS7 network. While MTP is used to carry SS7 messages in the SS7 network, Stream Control Transmission Protocol (SCTP) RFC 2960 has been developed by IETF to be the SS7 transport protocol for IP networks. The reason that a different protocol is needed is because MTP is based on a circuit-oriented technology -- not an IP-packet-based technology. As other SS7 protocol stacks use MTP as the transport protocol, adaptation modules are needed in the IP network in order to maintain transport transparency. The IETP Sigtran working group and the North America cable industry have introduced different adaptation modules. The most prominent adaptation module is MTP3-User Adaptation Layer (M3UA), which is supported by several commercial products.

The second area where SS7 signaling interworking is applicable is to provide SS7 ISUP functionality. SS7 ISUP is not designed with IP devices in mind. Furthermore, call setup and bearer control are tightly coupled, which is not optimized for softswitch implementation. As a result, the IP network has developed its own signaling protocols for inter-softswitch communication, the most prominent one being the Session Initiation Protocol (SIP). Thus, there is a need to provide SIP-ISUP interworking.

As the mapping between SIP and ISUP is application-related, SIP-ISUP interworking is performed at the softswitch. Moreover, since no direct physical interconnection to the SS7 network is required, SIP-ISUP interworking is generally not considered a signaling gateway function -- thus outside the scope of this article. Nevertheless, the interworking between ISUP and SIP is critical to achieve seamless signaling interoperability.

The signaling gateway addresses the first area of SS7 signaling interworking, providing physical interconnection between the IP telephony and the SS7 network. In particular, it provides transport transparency between the softswitch and SS7 signaling points using adaptation modules to translate MTP messages into SCTP messages.

Carrier Grade Signaling Gateway
What makes a true carrier-grade signaling gateway? There are three areas that make a signaling gateway carrier-grade: reliability, performance, and scalability. This section examines the SS7 reliability, performance, and scalability requirements and their implications on Signaling Gateway.

Reliability
To understand the reliability requirements needed of a signaling gateway, it is necessary to reflect on the SS7 reliability requirements. Remember, if the SS7 network is unavailable, inter-switch calls (including 911 calls in many cases) will not be possible. Even intra-switch calls will be impacted as enhanced SS7 services will not be accessible.

The SS7 downtime objective from American National Standards Institute (ANSI) between any two SS7 signaling end points (which includes the SS7 switches and SS7 service control points which provide the enhanced service functions) is 10 minutes per year -- with three minutes allocated to the user interface segment, two minutes allocated to the network access segment, and negligible amount of time allocate to the backbone network segment.

Part of the backbone network segment is the signaling transfer point (STP) which transfers SS7 messages to the appropriate SS7 signaling end points. They serve as the SS7 access points for SS7 switches and service control points. To achieve a backbone network segment with negligible downtime, not only must the STP (which is responsible for transport) have no single point of failure, but very often it is deployed in diverse geographical locations as a mated configuration -- to avoid a single disaster (such as fire, flood, or even earthquake) that would render the STP unavailable.

In an integrated IP-circuit PSTN architecture, the SS7 user interface segment includes the softswitch signaling interface, the managed IP network, and the signaling gateway. In other words, the sum of the failure of the softswitch signaling interface, the managed IP network, and the signaling gateway must be less than three minutes to conform to existing SS7 network reliability requirements.

A general reliability principle when designing a network is to provide the highest reliability at the equipment where the highest concentration will be impacted. In the SS7 user interface segment case, the signaling gateway and the managed IP network supports multiple softswitches. It is thus important to have high reliability at these two components. A true carrier-class signaling gateway thus should have the same reliability requirement as the SS7 backbone network segment, which has a negligible downtime. The signaling gateway, therefore, must have an even higher SS7 availability than the softswitches in the IP network.

To meet these carrier-grade requirements, there must be no single point of failure within a signaling gateway. Furthermore, it is extremely desirable to have a "virtual" signaling gateway that can be deployed in geographically diverse locations -- at least two. To have a negligible downtime, each of the links between components of the "virtual" signaling gateway needs also to have no single point of failure.

Performance
A true carrier-grade signaling gateway needs also to have carrier-grade performance characteristics. SS7 network has stringent performance requirements in terms of SS7 message delay, sequencing, and loss. While SCTP has gone a long way to address these issues, additional SS7 delay is nevertheless introduced due to the involvement of additional network components (which introduce additional intra-component and inter-component delay).

Previous comparative studies between IP telephony and PSTN telephony have shown that IP telephony theoretically has similar post-dial delay as PSTN telephony. It would be a dream if vendors can integrate the softswitch and signaling gateway into one physical component. With such integration, the additional signaling delay will be drastically reduced, not to mention that message mis-sequencing, and loss between the softswitch and the signaling gateway will be completely eliminated.

Scalability/Capacity
A true carrier-grade signaling gateway also needs to be scalable and have high capacity. The scalability and capacity are required as some IP telephony network providers may determine to use single or few signaling gateways to support their IP telephony network. With a scalable signaling gateway, the network provider can add capacity as it grows.

SS7 imposes a constraint on the number of SS7 links (32 links) between any two signaling points. While this may be sufficient for typical PSTN switch, it can be insufficient for a signaling gateway that may serve the entire IP telephony network. One way to address this issue is to support multiple SS7 point codes at the signaling gateway, thus bypassing the SS7 constraint. An alternate method is to configure the signaling gateway as SS7 STP, which requires additional SS7 network management functions at the signaling gateway. Given the desire to reduce deployment and development risks, the STP configuration approach may not desirable in initial deployment.

Enable The Signalling Gateway Vision
To be a true carrier-grade signaling gateway, the signaling gateway needs to meet the PSTN/SS7 reliability, performance, and scalability/capacity requirements. This article shows some methods -- "virtual" signaling gateway, integrating softswitch and signaling gateway, and supporting multiple SS7 point codes -- enabling a signaling gateway to be truly carrier-grade.

Alex Leung is senior marketing manager for ADC. ADC is The Broadband Company. ADC's fiber optics, network equipment, software, and integration services make broadband communications a reality worldwide by enabling communications service providers to deliver high-speed Internet, data, video, and voice services to consumers and businesses.

[ Return To The October 2001 Table Of Contents ]