ARCHIVE | ID Number: EFRA-NA-DP-9907
| This research is provided for historical perspective; portions of this document may not reflect current conditions. |
Signaling the Way to PSTN-IP Convergence
16 August 1999 David A. Schwartz This Dataquest Perspective examines the signaling architectural differences between the Public Switched Telephone Network (PSTN) and packet networks. It also looks at the signaling requirements for PSTN-IP (Internet Protocol) convergence and examines the proposed solutions for bridging signaling between PSTN and packet networks.
* | Recipients who do not own this document will receive a summary only.
| Browse Topics
| Advanced Search
| Ask an Analyst
| Rate This Document
| Downloads:
|  | 80878.pdf (82.8KB) |

# Signaling the Way to PSTN-IP Convergence This Dataquest Perspective examines the signaling architectural differences between the Public Switched Telephone Network (PSTN) and packet networks. It also looks at the signaling requirements for PSTN-IP (Internet Protocol) convergence and examines the proposed solutions for bridging signaling between PSTN and packet networks.

Table of Contents
Overview Signaling Variations: The PSTN versus the Internet The Gateway from IP Networks to the PSTN Dataquest Perspective Dataquest Recommendations

List of Figures
Figure 1: | MeGaCo Architecture

Key Business Issue How are Intelligent Network markets, standards, and technology developing? Strategic Business Assumptions A new signaling architecture will emerge that allows PSTN signals to be transmitted over an IP network reliably enough for toll-quality voice services by 2002 (0.7 probability). Media Gateway Control Protocol (MGCP) will be the de facto standard around which the new signaling architecture is developed (0.8 probability). Overview [return to Table of Contents] Public network service providers are demanding solutions that which allow them to take advantage of the superior economics and openness of packet-based technologies, such as those used in the Internet, while allowing them to maintain the reliability, redundancy, availability, security and quality of service of the Public Switched Telephone Network (PSTN). Meanwhile, Internet service providers (ISPs) are clamoring for solutions that allow them to increase their revenue opportunities by offering reliable voice telephony services. Interworking between PSTN and Internet Protocol (IP) networks is being demanded by all types of service providers. Satisfying these demands will entail a bridging of the PSTN with packet networks. There are challenges to providing all calls access to both PSTN and IP networks. These result from differences in the technologies used and the evolutionary paths the technologies have followed. Network performance in a PSTN-IP-converged architecture must be comparable to that of current PSTN standards in order to avoid degradation of services so that user expectations can be met. Also, solutions must be developed that allow for the delivery of services across both networks as needed during any call, and allowing service providers to leverage the best attributes of both networks without losing or having to modify their existing service offerings on either network. To meet these needs the signaling provided in a PSTN-IP-converged network must interwork seamlessly. Within the traditional IP protocol infrastructure a signaling message protocol that can reliably exchange existing, tried and true, PSTN signaling information between PSTN and IP network elements does not exist. Various considerations regarding reliability and timing that are unique to the PSTN make standard IPs ineffective for exchanging all the necessary messages between elements without degrading service quality. To carry the necessary variants of PSTN signaling messages rapidly and reliably in IP networks, a new generation of IP-based signaling protocols and functions is required. Therefore, meeting the demands of the market requires a new signaling architecture that enables a user to access the positive attributes of both types of networks. Such an architecture, that relies on gateways between the PSTN and the IP worlds, is being developed. However, until signaling standards and quality-of-service issues are resolved, the products sold will be relegated to private networks using proprietary and semiproprietary technology where quality can be managed. Signaling Variations: The PSTN versus the Internet [return to Table of Contents] Despite some similarities, fundamental differences exist between signaling that takes place in the PSTN and signaling for packet networks such as the Internet. These similarities and differences are a result of the way in which the architectures of each network were designed and have evolved. Signaling in the PSTN The PSTN provides users with circuit-based, dedicated, end-to-end connections with constant bandwidth streams that deliver voice as well as other media content. Network elements in the PSTN are designed to meet high reliability, availability, and security requirements with elements usually deployed in mated pairs (as are signaling links) for redundancy. Circuits are reserved throughout the duration of each call placed over the PSTN. Circuit-switched networks are less efficient, compared to IP networks, in that network connections occupy bandwidth even when no information is being exchanged. The signaling used in the PSTN is carried physically over a different network than is voice or media content. This network is known as the common channel signaling network (CCSN), or as the Signaling System 7 (SS7) network. SS7 messages are carried in the form of packets on dedicated overlay networks used exclusively for signaling. Prior to the introduction of the SS7 network in the 1970s, signaling was carried out over the bearer channel ("talk path") through "in-band" signaling, which used the same network for signaling and voice or media content, much as is the case with the Internet today. The SS7 protocol exchanges information between PSTN elements using dedicated channels (called signaling links), which transport specialized signaling messages, such as transaction capabilities application part (TCAP), which is used to access databases that contain call handling information, or through ISDN user part (ISUP) to setup, manage, and release voice circuits between terminating line exchanges for called and calling parties. Both ISUP and TCAP signaling are widely used in the PSTN today. They are required for most calls in order to access informational databases and perform call routing and specialized call handling. SS7 links deliver only call-control-related messages, enabling switching elements to quickly communicate call-related control information necessary to establish, bill, and terminate connections. The signaling of the SS7 network is known as "out-of-band" signaling because it provides the PSTN with a signaling network separate from the transport of voice and media content. The out-of-band signaling that the SS7 network provides for the PSTN was a major advancement for telecommunications networks. Efficiency and call completion rates are improved by using a separate signaling network to ensure that lines are clear and trucks are free prior to setting up calls. The advantages of "out-of band" signaling are that it allows for the transport of more data at higher speeds (56 to 64 Kbps or higher) over a dedicated network. It allows signaling at any time during a call. It makes the entire network more efficient by freeing up network resources (trunk circuits) and thus increasing throughput, and it enables signaling to network elements to which there is no direct trunk. It provides the network with a higher degree of reliability and security. Out-of-band signaling also made it possible to support Intelligent Network (IN) functions. The out-of band signaling of the SS7 network is used to access the specialized databases used by the IN. These databases contain routing information and call-control logic such as the information required for applications, including local number portability (LNP), calling card data bases, call forwarding, caller identification, call routing, toll-free (800) services, and so forth. PSTN carriers will require that PSTN-IP integrated architectures maintain access and support for IN databases so that they can leverage their investments in these technologies while maintaining compliance with government mandates that require carriers to access these databases during the course of certain calls. Signaling for the Internet IP networks were designed with a distributed architecture for the efficient delivery of data using multiple independent cooperating devices. This distributed networking model provides the potential for more cost-effective, scalable systems. Packet-switched IP networks differ from the PSTN in that they provide shared, statistically multiplexed paths rather than dedicated connections between users. IP networks are designed to be self-learning and self-healing rather than centrally managed. In an IP network, bandwidth is allocated dynamically in order to allow for more efficient use of network capacity. However, the IP network is a "best effort" network in which it is not only accepted, but expected, that when network failures or congestion occurs, some of the packets will not arrive at their assigned destinations. Also, IP networks do not achieve the stringent security required by the PSTN. There is a lack of quality of service guarantees in using packet networks if dedicated resources are not used. When packet networks do not dedicate resources to the transmission of packets, latency can occur. This is the result of transmission speeds between any two destinations varying significantly based on traffic loads, as well as other bottlenecks that may exist within the common elements of the network. To begin to alleviate this problem, new IP signaling and routing protocols are being developed. Out-of-band signaling is not currently used in packet networks, which makes it difficult for packet networks in their current incarnation to access PSTN-based IN services. Within a packet network, signaling information and media streams are carried within the same network. The signaling information that is used in packet networks often uses H.323 or session initiation protocols (SIPs). The media stream is carried by the Real-Time Transport Protocol (RTP). All data in an IP network is broken up into data packets. Each data packet contains a header with the address of its sender and its destination. Packets from the same message group can be routed over separate network paths and thus can arrive in random sequence. They are then reassembled at their final destinations. This maximizes bandwidth efficiency. H.323 Has Its Limitation The H.323 family of standards specifies the components, protocols, and procedures required to provide multimedia communications over packet-based networks, including IP-based networks. The widespread deployment and relative maturity of the H.323 protocol will allow it to continue to play an important role in networking for some time. However, H.323 is a full-featured protocol with a high degree of complexity and relatively large code sizes. Due to some of these limitations it cannot support all the applications required of the next-generation networks. It will not, therefore, be the only signaling protocol used for PSTN-IP converged applications. H.323 has its place, but other technologies provide simpler solutions for connection setup and media mapping with a correspondingly smaller code size, making it more attractive for future terminal and device designs. Similarities and Differences between SS7 and IP Like SS7 networks IP networks are packet-oriented. However, many of the characteristics of IP networks differ significantly from the PSTN and SS7 networks, particularly in the area of signaling. Despite their differences, commonalities between the PSTN and IP networks can be found. In bridging the PSTN and the Internet, these similarities should be relied upon. While signaling between the PSTN and the Internet differs, the SS7 protocol and network have some similarities with routing protocols and router networks. The signaling used in the PSTN is communicated with data packets over the SS7 network, giving it inherent similarities with IP networks. Other commonalities include the use of distributed architecture for both IP networks and for IN applications in the PSTN. Also, similarities exist in the distributed nature of intelligence and the separation of the switching and service logic functionalities used in each network. The primary differences that must be overcome for convergence to succeed between the PSTN and IP networks are in reliability and latency requirements. The SS7 network was designed to support the PSTN, so while it is packet-technology-based, it employs redundant transport channels to meet the same reliability and quality attributes of the PSTN. To ensure that these PSTN requirements are met by the SS7 network, any unused bandwidth is populated with "filler" packets to generate constant streams of bandwidth. This allows for greater reliability through the immediate detection of interruptions in message delivery, so that information can be quickly rerouted. A New Signaling Architecture Is Needed Within the traditional IP protocol infrastructure, a signaling message protocol that can reliably exchange existing SS7 signaling information between elements in the PSTN and the IP network does not exist. Various considerations regarding reliability and timing that are unique to SS7 make standard IP protocols ineffective for exchanging all the necessary messages between SS7 and IP network elements. To allow interoperability between the PSTN and the IP network it is necessary for signaling performance to be comparable to that of current standards to avoid introducing degradation of services. PSTN network elements have a low tolerance for delays and losses, and users have expectations set by the current PSTN performance criteria. According to some of the standards groups working on PSTN-IP convergence the common user expectation for most simple TCAP query-response applications appears to be on the order of 500 milliseconds. However, the actual PSTN working data shows that these are in the range of 250ms to 350ms. There is approximately a 150ms budget for round-trip TCAP message transfer, or 75ms one way, to achieve a response time comparable to the PSTN. Loss and delay bounds from the existing telephony standards for PSTN-IP interworking must be derived for an effective bridging of these networks. Both loss and latency affect perceived user quality when establishing voice calls across an IP network. Excessive delay may cause call setup failure through end-switch time-outs, requiring the user to redial. TCAP loss may also cause call setup failures through time-outs that may leave resources in the network held in an active state after a call teardown message is lost. An ISUP equivalent functionality must also be achieved when transported over IP in order to maintain the required signaling reliability and redundancy. To carry the necessary variants of SS7 signaling messages rapidly and reliably in IP networks, a new generation of IP-based signaling protocols and functions is required. To meet this requirement standards and specifications for bridging PSTN and IP networks have already begun to emerge. The signaling standards that have been proposed as a part of PSTN-IP integration include H.323, SIP, IPS7, ASP, SGCP, RSGP, IPDC, MNDTP, and MGCP. Gateways and protocols that are being developed to provide interoperability between the PSTN and packet are addressed in the remainder of this Perspective. The Gateway from IP Networks to the PSTN [return to Table of Contents] Gateways have been designed to meet the challenges of integrating the PSTN with IP networks. Gateways reside between the SS7 signaling network and a packet network. According to a reference architecture that was submitted to the Internet Engineering Task Force (IETF) in mid-1998, IP interfacing with the PSTN requires three main basic functional elements: Media Gateways, Signaling Gateways, and Media Gateway Controllers. The Media Gateway and Signaling Gateway are interface elements, while the Media Gateway Control provides call control and coordination functionality. Together these functional elements provide a platform for multimedia services delivered through the convergence of IP and PSTN technologies. They provide interoperability between the different signaling protocols and media streams carried between packet networks and the PSTN. For interworking with SS7-controlled PSTN networks, the Signaling Gateway terminates the SS7 link and transfers the signaling information to the Media Gateway Controller using signaling transport. The Media Gateway terminates the interswitch trunk and controls the trunk based on the control signaling it receives from the Media Gateway Controller. These three basic elements can be supplemented by applications and database servers in order to offer additional value-added services. These additional elements can be added on an as-needed basis. The functionalities assigned to Media Gateways, Media Gateway Controllers, and Signaling Gateways can be provided either as physically separate or integrated products to any degree desired. However, not all the functions and interrelationships scale efficiently at the same ratio. It can make sense to physically and functionally separate these products. These network elements can then be configured in a variety of ways. Network architects are free to combine elements to best meet their needs. Figure 1 shows schematically how MGCP works.

Figure 1
MeGaCo Architecture
[return to List of Figures]
Source: Dataquest (August 1999)

Media Gateways The Media Gateway interfaces media flows between the PSTN and IP networks. The Media Gateway performs media mapping and functions as a bidirectional interface between circuit- or cell-based PSTN content and packet-based Internet content. Media Gateways digitize and compress voice calls from the PSTN into IP packets for routing across a packet network to another gateway for forwarding back to the PSTN, or for delivery to an H.323 device such as a personal computer. Media streams are converted to packets in an IP network and digital or analog streams in the circuit-based PSTN. This is done using various coding, sequencing, compression, echo cancellation, and decoding techniques. This information is then passed on either to another gateway, which reverses the process, or passed directly on to an H.323 device, depending upon the specified destination. Media Gateways do not provide call processing and do not use call models. The functions of a Media Gateway include media conversion, resource allocation and management, and event notification. The Media Gateway must be capable of supporting detection of events and application of signals associated with basic analog line, as well as Channel-Associated Signaling (CAS). Handling termination-associated signaling is done either by using event notifications or by signaling backhauls to other IP elements. Media Gateways must also support some level system-related functions, such as establishing and maintaining some kind of Media Gateway-Media Gateway Controller association. Media Gateway Controller A Media Gateway Controller can either be combined with a Media Gateway as a part of a Gatekeeper or it can be separated into a distinct physical element. The primary function of a Media Gateway Controller is to coordinate one or more Media Gateways. The Media Gateway Controller is the counterpart of a central office switch in the PSTN and is responsible for much of the call control and call-state functionality normally associated with switching elements or IN systems in the PSTN. Call processing, service logic and call routing are all functions of the Media Gateway Controller. Media Gateway Controllers contain the Call Controller, which provides signaling functionality for call setup. TCAP signaling over an IP network may be envisioned between the Media Gateway Controller and/or a Signaling Gateway and an IP-based SCP (IP-SCP). The Media Gateway Controller may also use IP-based TCAP signaling for cross-access between entities in the SS7 domain and the IP domain. Media Gateway Controllers provide call handling instructions to Media Gateways including instructions on how to set up, handle, and terminate various media flows. The Media Gateway Controller has responsibility for making decision based on the flow of information. The Media Gateway Controller can also cooperate with peer network elements (such as other Media Gateway controllers) through call control protocols, such as the Gateway Control Protocols (described later). Media Gateway Controllers provide instructions that are necessary to connect two or more IP devices, allowing them to exchange information. Media Gateway Controllers maintain current status information for media flows. They also provide parameters for bandwidth management and quality-of-service characteristics, and they generate administrative records, which can be used for billing. Signaling Gateway The Signaling Gateway resides between the SS7 signaling network and the packet network and provides a bidirectional interface between the SS7 network and the various call-control-related elements in packet networks. Because the Signaling Gateway must be attached to the SS7 network, it needs to meet the stringent reliability, availability, redundancy, and security requirements of the PSTN. In some cases, the function of the Signaling Gateway may be divided into multiple physical entities to support scaling, signaling network management, and addressing of concerns. Signaling support usually includes as a minimum H.323 and/or SIP protocols, as well as the SS7 protocol. Gateways transmit call-signaling information to the PSTN using multifrequency (MF) tones, ISDN D-channel signaling, or other forms of signaling. To enable IP elements to understand SS7 messaging protocols they are repackaged into formats that can be understood. A Signaling Gateway may also provide access to enhanced call-processing, such as services similar to those that are IN-based. Signaling Gateways also provide firewall functionality, shielding the PSTN from inappropriate traffic that can be transmitted from the IP network. The Signaling Gateway must also always maintain a complete and accurate view of the status of IP elements that need to have access to the SS7 network in order to coordinate the SS7 networks view of associated IP device availability. The associated IP elements typically include Media Gateway Controllers as well as elements associated with database storage and query functionality. The primary function of the Signaling Gateway is to translate the SS7 signaling, such as TCAP and ISUP messages, into formats that can be understood by elements in the packet network and vice versa. To interwork with the PSTN, an IP network must process these ISUP and TCAP messages. Both protocols have specific performance requirements associated with the PSTN, which must also be met by the IP network to achieve seamless interoperability. Through the translation provided by the Signaling Gateway, information about call setup can be relayed from one network to another and information about call handling can also be accessed and shared. By supporting the translation of both ISUP and TCAP traffic, Signaling Gateways allow IP network elements to access the existing portfolio of IN services available in the PSTN, some of which, such as local number portability (LNP), are required for routing almost all calls in the network. The IP side of the network must recognize when a database lookup is required, and the Signaling Gateway must launch TCAP queries into the PSTN to access IN databases to obtain information about how to route calls that require specialized handling. For calls that originate in the IP network, such as Internet telephony calls, the ability to recognize the service-activation triggers, which traditionally have been located on PSTN-based service switching points (SSP), must now reside on the IP side of the network so that IN services can be initiated. The Signaling Gateway communicates with other IP elements such as Media Gateways via simple proprietary or a standards-based protocol known as a gateway control protocol (GCP). GCPs are described in more detail in the sections that follow. Gateway Control Protocols The Signaling Gateway communicates with other IP elements such as Media Gateways via simple proprietary or standards-based protocols known as a Gateway Control Protocol. GCP standards are being defined so that Signaling Gateways can transport PSTN protocols to and communicate and interact with Media Gateway Controllers and other IP elements that need to receive and communicate with different types of signaling-related information. GCPs may also be used for transport of message-based signaling between Media Gateways and Media Gateway Controllers, between dispersed Media Gateway Controllers, and between two Signaling Gateways connecting signaling endpoints or signal transfer points (STPs) in the PSTN. In fact, anywhere that physical separation exists between functional entities, signaling transport can be applied to ensure that signaling information is transported between entities. Protocols are being defined for communications among each element and each other element, and protocols, as well as functional and reliability requirements need to be defined for the transmission of a variety of different types of SS7 signaling information for each IP element. A variety of protocols have already been proposed to resolve interoperability issues, and in fact, today Dataquest believes that there are currently more GCPs than will be supported in a few years' time. Several vendors are currently supporting more than one GCP with the idea that they will let the market decide which will become the de facto standard. GCPs began to come to market with announcements by Bay Networks (now owned by Nortel) of its Access Signaling Protocol (ASP). This was followed by Ascend's Signaling Gateway Control Protocol, Bellcore's Simple Gateway Control Protocol (SGCP), Bay and Ascend's Reliable Signaling Gateway Protocol (RSGP), and the Level3 Technical Advisory Committee's Internet Protocol for Device Control (IPDC). Recently, SGCP and IPDC have merged to become the Media Gateway Control Protocol (MGCP). Meanwhile, Nortel is also supporting a new related signaling architecture, known as Internet Protocol with Signaling System 7 (IPS7), which works in conjunction with MGCP and is comprised of more than 15 signaling IP-SS7 interworking protocols. Industry standards groups including the International Engineering Task Force (IETF ), ITU-T SG16 (H.323), the European Telecommunications Standards Institute (ETSI ), Telecommunications and Internet Protocol Harmonization Over Networks (Tiphon) group, the IN Forum, TIA TR41.3.4, and the Multiservice switching forum, as well as others, are currently working on standardizing signaling protocols. Some vendors are already offering products using proprietary and semiproprietary protocols. While a high degree of standardization is needed, some degree of proprietary closed system is expected to prevail as vendors attempt to differentiate their systems and protect their market positions. MGCP Emerging as the GCP of Choice Of the GCPs that have been proposed, the MGCP is the front runner. It is being developed in the IETF. The IETF has two working groups with a mandate of developing standards for PSTN-IP signaling associated GCPs. MGCP is a draft proposal that has been submitted to IETF Media Gateway Control (Megaco) working group. The IETF has also developed the Signaling Transport (Sigtran) workgroup to define how PSTN signaling is transported over IP. Other related IETF groups include the SIP (Session Initiation Protocol) working group, the IPTEL (IP telephony) workgroup and the PINT (PSTN and Internet Internetworking) work group. All of the IETF workgroups have many of the same participants and are working in association. Companies working on defining MGCP include Telcordia (Bellcore), Cisco/Selsius, Ericsson, Level 3, Lucent/Ascend, NetSpeak, and Nortel Networks, as well as others. Megaco As of this writing MGCP is a draft proposal that has been submitted to the IETF's Megaco workgroup. Megaco was formally accepted as a work group by the IETF in January 1999. With meetings scheduled for March, July, and November 1999, the final Megaco protocol specifications were due out in July 1999. Work is also focusing on Version 2 MGCP, which should be complete by the end of 1999. MGCP is being designed to create a standard to control media gateways and similar devices at the IP network edge. The group is creating the architecture and requirements for controlling Media Gateways from external control elements such as a Media Gateway Controller. MGCP is a simple protocol that operates between intelligent call agents, such as Signaling Gateways, and dumb Media Gateways. MGCP has been designed to both allow the call agent to control the Media Gateway, and to use a relatively small set of messages and procedures. MGCP messages are transmitted in ASCII text and the MGCP uses the IP Security (IPSEC) protocol to ensure security. The MGCP separates the signaling and media transport functions of the gateway. Sigtran The purpose of Sigtran is to define an architectural framework and functional requirements for transport of signaling information over IP networks. The framework of Sigtran's work describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply to gateway signaling from existing PSTN signaling protocols. Signaling backhaul protocols are also being defined. The backhaul takes place between a Media Gateway or Signaling Gateway as they interface with the PSTN and a Media Gateway Controller. Sigtran will not work on Media-Gateway-Controller-to-Media-Gateway-Controller protocols, nor on Media-Gateway-to-Media-Gateway protocols. These areas will have to be addressed by other groups. Dataquest Perspective [return to Table of Contents] A new signaling architecture is emerging, which will provide a bridge between PSTN and packet networks, allowing service providers and ISPs to take advantage of the superior economics and efficiency of packet-based technologies for voice calls. Due to differences in PSTN and IP networks, this will require that changes be made in the way in which signaling occurs. Any new signaling architecture must allow for reliability, redundancy, availability, security, and quality of service comparable to that currently found on the PSTN. Signaling delays in a PSTN-IP converged network must be made similar to those observed in classic telephony networks. The transition to a new signaling architecture must guarantee that there will be no degradation in service. Therefore, improvements must be made on the IP side of the network for convergence to progress. Telephony applications that rely on PSTN-grade signaling are relatively intolerant to the packet losses and network delays associated with today's IP network. Also, the delivery of services across both PSTN and IP networks, as well as access to critical PSTN databases must be made possible in any new architecture through seamless reliable signaling. To satisfy these demands an architecture relying on gateways between the PSTN and the IP world is emerging. A variety of protocols have already been proposed using gateways that mitigate interoperability and signaling issues. These protocols rely on a new architecture that utilizes Media Gateways, Media Gateway Controllers, and Signaling Gateways. However, standards must still be approved, implemented into products and deployed in the market. Quality must be improved to protect against packet loss and allowing for the transmission of toll-quality voice services. Expect Internet telephony traffic to be generally transported over dedicated IP networks until these issues can be resolved through reliable signaling. Dataquest Recommendations [return to Table of Contents] In order to achieve seamless interoperability for all carriers, the signaling and protocols that are adopted must not be biased to any single architecture. To achieve PSTN-grade reliability the protocol or signaling must be able to issue the same request to two different implementations and achieve the same result. Therefore, a high degree of standardization will be necessary. Gateway Control Protocols have been proposed toward this end. However, some degree of closed semiproprietary and proprietary systems are expected as vendors attempt to differentiate their systems and protect their market positions. Market participants must prepare for this. Choosing Partners IP-PSTN interworking products are in the early stages of an emerging market. Thus far, the gateways that have already been deployed in the market are targeted primarily toward private networks and the enterprise market, where bandwidth can be managed and quality of service can be controlled. Most were designed to be relatively small-scale solutions. Many are based on some form of interconnection in which all the signaling, call control, and media flow are carried in the same interface, such as through ISDN. As such, they have not offered a practical solution for large-scale, carrier-grade solutions. Vendors are looking for ways to improve today's gateway solutions. The products currently on the market are likely to evolve considerably as standards develop and as PSTN-grade reliability is built into them. In order to be prepared for the changes that will occur with product evolution, service providers should select vendors that are highly involved in the standardization process and that have the resources to support the evolution of their products in a rapid and seamless manner. Service providers that choose to be early adopters of this technology can gain competitive advantages by gaining early mind share and market share and by being able to deliver new services more rapidly and at less cost. They may also have an opportunity to influence the standards that will affect the integration of these networks. Prepare for Semiproprietary Systems Based on MCGP Dataquest believes that there are currently more GCPs than will be supported in a few years. Of the GCPs that have been proposed, the MGCP, along with the other related IETF work, is the front runner. However, some vendors are currently supporting more than one GCP, allowing the market to decide which will become the de facto standard. Vendors are also supporting their own proprietary and semiproprietary implementations for various key interfaces and for communications between their own network elements. Support for multiple standards allows vendors to gain an advantage by gaining experience in the protocol that is eventually adopted by the industry. Vendors can create deliberate barriers to entry and maintain competitive advantage by keeping some degree of their protocols semiproprietary. The result of this will create a situation similar to what exists in other areas of the PSTN today, such as switching and IN. Vendors and service providers should prepare for such a situation by working with market leaders to gain access to their technology and customers. These vendors are likely to license their proprietary and semiproprietary solutions as the market progresses in order to gain a stake in the sale of solutions by other industry participants.

| Browse Topics: Signaling Operations Support Systems |
| This document is published in the following Dataquest Clusters: Public Network Infrastructure Worldwide Telecom Equipment Europe Telecom and Internet Markets Asia/Pacific Telecom Strategies and Directions Worldwide |
| © 2005 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. |

Resource Id: 305019