SS7 Signaling Convergence White Paper
Convergent SS7 Signaling for Seamless Service Deployment
Introduction
This paper discusses convergent Signaling System 7 (SS7) signaling for a seamless service deployment. Topics to be covered include transport, platforms, Application Programming Interfaces (APIs), and Gateways (GW) and how they affect seamless service deployment. This evolutionary area of transport and GWs will be examined as the key to providing practical, seamless services in the near term. Service infrastructure of SS7 and SS7 over Internet Protocol (IP) and the emergent Session Initiation Protocol (SIP) infrastructure will be covered, as will the convergence of SIP and SS7 leading to some possible outcomes.
I. SS7 "Classic"
The term SS7 classic differentiates between SS7 over IP and narrowband 64-kilobit SS7. SS7 classic is signaling for call delivery that follows a separate physical path from the bearer channel to set up calls. A Service Switching Point (SSP) communicates to another SSP, with media traffic fl owing through on a separate channel from the signaling. Service Control Points (SCP) provide services that can be delivered via signaling alone (e.g., 800 service). Service Nodes (SN) and Intelligent Peripherals can be used for delivering services that require both signaling interaction and interaction with the bearer. Voice mail, follow-me services, and prepaid service are typical SN applications. Figure 1 represents the classical Intelligent Network (IN) environment, with the ability to deploy service on SCPs and SNs/ Intelligent Peripherals.
Figure 1: SS7 “Classic”
II. Evolution to SS7 over IP
The Internet Engineering Task Force (IETF) is driving much of the activity to develop protocols for the evolution of SS7 to SS7 over IP. The Signaling Transport (SIGTRAN) working group is focusing on how the existing SS7 protocol will run over IP.
One approach is to attempt to enable the SS7 service levels to run over IP. The fi rst step is creating components - such as Simple Control Transport Protocol (SCTP) - to run directly over IP, thus replacing Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) to provide a reliable transport for signaling in the telephony networks.
In addition, adaptation layers adapt the generic SCTP transport capability to meet the needs of various SS7 protocols. In the case of Message Transport Protocol 2 (MTP2) peer-to-peer adaptation (M2PA), the adaptation layer adapts the SCTP generic transport to enable Message Transfer Part 3 (MTP3) to run over it. As a result, an existing SS7 link can run directly over IP with all the existing services remaining the same.
Message Transfer Protocol 3-User Adaptation layer (M3UA) is an adaptation layer that adapts the SCTP to the MTP3 boundary. Consequently, Integrated Services Digital Network User Part (ISUP) and Signaling Connection Control Part (SCCP) can run directly over IP without having to adopt an SS7 link-based topology. While M2PA requires the maintenance of the topology of SS7 and SS7 links, M3UA requires only SS7 endpoints, thus participating at only the services level rather than needing the SS7 topology.
Another evolving adaptation layer is SCCP User Adaptation Layer (SUA). Although not as mature as some of the other adaptation layers, SUA is a protocol evolving to allow Transactional Capabilities Application Part (TCAP) to run on top of SCTP. TCAP can run on top of M3UA as well, but SUA is slightly lighter weight than M3UA and SCCP as an endpoint (see Figure 2).
Figure 2: Evolution to SS7 over IP
The Role of M2PA
M2PA allows the classical SS7 link to be replaced by SS7 over IP while maintaining the SS7 link topology. Link-based architecture between the endpoints — various SSPs, Signaling Points (SP), or STPs — can be maintained using links but replaced with IP by using M2PA. Only the transport is changed. Existing service can thus be leveraged for seamless service interoperation simply by replacing the transport and leveraging IP infrastructure in the existing backbone. This, obviously, offers bandwidth savings as well (see Figure 3).
Figure 3: Role of M2PA
The Role of M3UA
M3UA allows the Network Elements (NE), interconnected via the M3UA, to participate at the service level in the SS7 network. The classical network evolves to transiting through a Signaling GW (SGW) that provides, on one side, the interface at the classical SS7 signaling level and provides a transition to M3UA signaling over IP. As a result, SCPs and SSPs can interconnect and be full participants in the network, exactly like all the other elements in the network, except that they are interconnected over IP and adherence to the SS7 link topology is not necessary. The SGW bridges the SS7 service level between the SS7 classic and SS7 over M3UA domains. An IP-centric SCP or an IP-centric SSP, otherwise known as a softswitch, can plug in and be a full participant in the network. The resultant full participation in the network at the service level allows the exercise of all the ISUP protocols and TCAP protocols (see Figure 4).
Figure 4: Role of M3UA
The Impact of SS7 over IP
SS7 over IP primarily addresses the transport aspect of SS7. Call-control services and other types of services, therefore, can continue to be offered and deployed without concern for the method of interconnection. The method of service implementation, however, remains dependent on the particular NE chosen to support the service rather than the transport chosen. To deploy a service on a SN, SCP, an Intelligent Peripheral, or an SSP, the key decision on how to build that service is based on the NE and is not dependent on the transport that happens to be chosen. (see Figure 5).
Figure 5: Impact of SS7 over IP
The Role of SS7 over IP Gateways
SS7 over IP GWs is the key to providing seamless services and call delivery between SS7 over IP and SS7 domains. The ISUP call delivery-call setup, Initial Address Message (lAM), Address Complete Message (ACM), Answer Message (ANM), and so on-transits from the SSP through STPs to SGWs and then to an SSP on the IP domain side that resembles any other SSP, except that it is interconnected via the IP. ISUP call delivery flows between the SS7 and SS7 over IP SSPs without translation, ensuring complete interoperation.
By supporting M2PA and SS7 links simultaneously and translating to the M3UA domain, SS7 over IP also enables migration to IP-based SS7 signaling links. SS7 over IP GWs permit the use of M2PA to connect and slowly migrate out existing SS7 links. Thus, an existing SS7 topology can use the GW as a transitional element to migrate away from the classic SS7 network to an IP-based network using SS7 protocols (see Figure 6).
Figure 6: SS7 over IP GWs
III. Common Service APIs
Playing a critical role in providing service capabilities, common service APIs enable applications written for the classic SS7 domain to run seamlessly over SS7 in the IP domain. This, in turn, permits significant feature and function compatibility between domains to meet user expectations. Running over IP will not alter expectations of the levels of function and capability. Users with phones connected via an IP network will demand the same service as before and will want it to work the same way with the same reliability. Thus, it is key to provide the same functional capability and to provide compatibility between what exists now and what will exist in the future.
Providing the same kind of APIs from one platform to another also ensures full retention of application development investment. Applications written to run the classic SS7 domain, for instance, can run directly in SS7 over IP without being rewritten. This is a key point for getting services deployed rapidly and for being able to provide function and feature compatibility between different converged networks (see Figure 7).
Figure 7: Common Service APIs
IV. Emergent Signaling
A Consideration for SIP
SIP has the potential to be very important in the future and to replace many of SS7’s current uses. Several years will be required, however, before even the standards become solidified. Of course, there will be some deployments of SIP by early entrants, but full feature and function compatibility such as exists now on SS7 is a distant possibility.
SIP is growing in popularity because of the inherent flexibility and extensibility that can address Next Generation Network (NGN) needs. Some people view it as the answer to all problems related to call delivery, services, and device control, but it must be recognized that there are technical hurdles to overcome before it can be deployed seamlessly.
Because of SIP extensibility, some proprietary encodings emerged for early services. TCAP, for instance, provides an envelope for sending back and forth messages and dialogues. Unless what goes in some of those messages is defined, what proprietary encoding is used remains open. To some degree, SIP application interfaces are similar. Currently there is exploitation of SIP to build proprietary messages based on the application need. IETF standards work, however, will eventually promote standardization (see Figure 8).
Figure 8: Emergent Signaling
SIP for Softswitch Services
The International Softswitch Consortium (ISC) has proposed deployment of services in application servers interconnected to the softswitch using SIP. Currently, efforts are being made to encode these proprietary messages and to provide standardization (see Figure 9).
Figure 9: SIP for Softswitch Services
SIP Proxies
The proxy server approach for deployment of services in SIP is widely used. The SIP proxy provides a critical place in the network for routing and other service decisions related to a message. Because SIP messages for the supported entities transit the proxy, opportunities exist to perform services on behalf of each endpoint entity (see Figure 10).
Figure 10: SIP Proxies
Service Programming
IETF Call Processing Language (CPL) may be used to program services. CPL is tied to the SIP interaction and is interesting not only from the standpoint of end users being able to deploy their own services, but also from inside the network. Abstractions have been proposed to enable more generic and seamless service programming. A Capability Set 1 (CS-1) call model running on
top of SIP has been proposed to allow, for instance, the existing IN-based SCPs to provide services in a SIP environment.
A Parlay call model also has been proposed to provide an abstracted API. The Parlay call model wraps around a SIP proxy server to provide services. These proposals suggest the interest in, and the thinking about, how to deploy services seamlessly across these different environments (see Figure 11).
Figure 11: Service Programming
SIP and Interworking
The majority of people still are connected to the existing Switched Circuit Network (SCN). This will not change overnight. ”Forklifting out” existing networks and replacing them with SIP-based networks is not realistic. Calls must be delivered into and from the SCN. Service will need to interwork across domains. Individual “islands” — with services and features existing only within one particular domain— cannot survive (see Figure 12).
Figure 12: SIP and Interworking across Domains
SIP to SS7 GWs
SS7-to-SIP GWs will be required for seamless call and service delivery. If a SIP-to-SS7 GW exists, it is in actuality sitting at the edge of the SIP network. The GW translates SIP to ISUP signaling based on IETF recommendations. Calls originating in the SCN, transiting the NGN, and terminating in the SCN will encapsulate the ISUP according to SIP for Telephony (SIP- T). The interworking of this SIP to SS7 is done at the GW, so the call can be passed through the network and the ISUP message then carried along for regeneration when it is dropped off in the SCN at the opposite end of the network (see Figure 13).
Figure 13: SIP to SS7 GWs
The ability also exists for proxy servers that may run a call model and have seamless service interworking with SIP to CS-1- type mapping. Thus, SCPs could work with the SIP proxy servers. Interworking of services may be accomplished through the evolution of work started in the IETF Service in the PSTN/IN Requesting Internet Service (SPIRITS) working group. While in the early stages, this work is exciting and has tremendous potential for the future.
V. Common Service Platforms
Cross-domain service platforms with a common API and multiple “domain interfaces” (e.g., SIP or SS7) could aid in providing seamless services. For example, a Java APIs for Integrated Networks (JAIN) platform could have SS7 interfaces and a SIP interface; applications could be provided that run on top of this platform and seamlessly across domains.
The emergence of an open API for the generation of services also could seed seamless services. Parlay API, for instance, could allow this to happen. Common APIs, however, often trade flexibility for compatibility, rendering the API less than useful. An abstracted API - an attempt to make it fit everything - is not as useful as one made specifically for an environment.
VI. Cross-Domain Service Deployment
There is some speculation that SIP, and SIP-based, service deployment will become dominant, with SCN viewed as a peripheral interfaced through GWs. In this scenario all services would be built in the SIP environment, and the SCN would be treated as a peripheral to interwork services (see Figure 14).
Figure 14: Cross-Domain Service Deployment with Peripheral SCN
Service platforms may emerge that present a common API and aggregate multiple domains as resources. A common application server could offer interfaces to different domains through something similar to a Parlay API. For instance, a service could be designed that interworks an SCP service together with a proxy server as one seamless service, with transparency to the user application (see Figure 15).
Figure 15: Cross-Domain Service Deployment with Common A
VII. Potential Outcomes
Services will continue to be deployed in different platforms in various ways. A singular solution is unlikely to emerge. The telco environment provided an early indication of this with IN services. Decisions on switch-based, SCP-based, or SN-based services are driven by time to market and revenue.
At opposite ends of the spectrum, point solutions will emerge and ambitious open platform initiatives will be deployed, with classes of applications gravitating toward each. In the telephony environment, for example, there are core network services, such as 800 services or emergency 911 (E911) service that cannot be put into the enterprise. These services gravitate to the core of the network. A follow-me service, however, arguably could belong in an enterprise. Service will tend to gravitate to the solution that makes sense in terms of time to market, where the data has to go, and revenue generation. One solution will not cover all needs and cases.
