This section examines the realization of softswitch-based solutions for local telephony. It will identify the various architectural options for the application of softswitch technology in local telephony and explain how softswitch solutions can lower the cost of local-exchange switching, present the means to create differentiated local telephony services, and ease the migration of networks to support packet voice end-to-end.

Network Architecture Requirements

A comprehensive local-exchange softswitch solution for local telephony requires support of the following kinds of network connections:

• Access network connections based on traditional telephony technologies, including analog lines, DLCs, and digital circuit-based facilities connecting to customer-owned PBXs
• Access network connections based on packet voice technologies, such as VoDSL
• Trunk network connections over digital circuit-based facilities to other end-office switches, into local and long-distance tandem interconnect switches, and into special facilities such as E911 and operator services tandem switches
• Trunk network connections to other MGs over packet-based facilities supporting VoIP and/or VoATM

Each possible combination of access and trunk network type requires a specific combination of MG capabilities to support local telephony access. The MG functions may be located on the customer premises, in the service provider’s network, or both.

Figure 3. Network Architectures for Local-Exchange Softswitch in Local Telephony

Figure 3 shows five examples of network architectures that use MGs to create softswitch-based solutions for local telephony. The diagram illustrates five network zones: customer premises, access network, originating end office, core network, and terminating end office. In each of these examples, the terminating end office is shown as a conventional circuit-based local-exchange switch; but an MG could equally well be shown in the originating end office. In each example, the MG that provides dial tone and other end-office switching functions is shown in gray. Note that, for clarity’s sake, the MGC that is associated with each MG is not shown.

Example (1) looks almost exactly like today’s phone network, with the exception that the originating end-office function is shown here being performed by an MG. In this case, the MG is simply a circuit switch. There is nothing in the definition of an MG that requires it to perform media conversion, and Megaco is fully capable of supporting the control of a pure circuit-switching MG from an MGC.

In example (2), the conventional circuit-based access network is replaced by a VoDSL network. An integrated access device (IAD) on the customer premises delivers packet voice access. Although the IAD does perform media conversion between analog ports and packet voice streams, it is not an MG in the softswitch sense because it is not controlled by an external MGC. The MG in the originating end office performs media conversion between the packet-voice access network and the circuit-based core network.

Example (3) shows a conventional telephony access network but replaces the circuit-based core network with packet voice. The MG in the originating end office performs media conversion between the circuit-based access network and the packet-based core. A second MG performs trunk conversion to enable the call to terminate in a conventional circuit-based local exchange. Note that the softswitch functionality associated with this second MG is far less complex than that associated with the MG in the originating end office: this is because the trunk conversion MG only has to deal with call setup and teardown, not with any of the special calling features that are handled by the MG in the originating end office.

Example (4) combines the packet-based access network of example (2) with the packet-based core of example (3), extending the reach of packet voice all the way from the originating customer premises to an MG that is located as close as possible to the terminating end office.

Example (5) moves the originating end-office MG functionality out to the customer premises. The customer premises MG is controlled by an MGC that resides in the public network. Although this architecture is superficially very similar to example (4), there are some major benefits to this approach—benefits that will be covered in more detail later.

In the examples that include multiple MGs, each MG may be controlled by a separate MGC, or a single MGC may control two or more of the MGs shown. A collection of MGs that is controlled by a single MGC behaves like a single distributed MG. Telephony signaling protocols are used to support the switching of calls between MGs that are controlled by different MGCs. Where the network that connects MGs is circuit-based, then conventional telephony protocols, such as SS7, may be used between MGCs. Where the network is packet-based, new signaling protocols, such as H.323 or session initiation protocol (SIP), are required.

Media Gateway Controller Requirements

The examples illustrated above identify two distinct categories of MGs: MGs that reside either in the end office or on the customer premises, and which deliver dial tone and support the full range of end-office switching functions; and MGs that provide trunk conversion capabilities, needing only to support basic call setup and teardown.

MGs deployed in today’s networks are all of the trunk conversion variety. They are primarily deployed to support interconnection of circuit switches over packet trunking facilities and to provide a tandem switch replacement function.

MGs that deliver end-office switching capabilities have yet to be demonstrated—perhaps because the MGC functionality that is required to support end office switching is, in orders of magnitude, more complex than that required for simple trunk conversion.

An end office or local-exchange MGC must implement three layers of functionality fully to meet the needs of a comprehensive softswitch-based local telephony solution: a call agent, a set of basic calling features, and a feature creation environment.

Call Agent

Call agent is the term used to describe the basic MGC functionality needed to set up and tear down calls, and to maintain details of the state of each call. The call agent interacts with the signaling protocols that exist on either side of MG for the purposes of coordinating call setup and teardown. For example, an MG that supports the conversion of SS7 intermachine trunks to VoIP connections requires an MGC with a call agent that can handle SS7 ISUP messages and the H.245 call control messages that support VoIP call establishment as part of the H.323 protocol suite.

MGs that support only trunk conversion need little more than basic call agent functionality in the MGC, and most of today’s softswitch solutions comprise just such a call agent and little else. In a softswitch-based solution for local telephony, the call agent is the lowest of three layers of functionality.

The call agent includes call routing functionality. In general, call routing is more complex in a local-exchange switch than it is in a tandem switch in the core of the network. This is because the local-exchange switch has to support special call routing capabilities, including operator services routing, E911 call routing, 800 number translation, local number portability (LNP), preferred interexchange carrier (PIC) code routing, and carrier access code (CAC) routing.

Basic Calling Features

An MGC that contained only call agent functionality could provide local telephony service to customers that use PBXs. This is because PBXs deliver the calling features required by the end user, and the connection from the PBX into the public network requires only basic transport services, which can be provided by a call agent.

Small-business and residential customers do not, generally, have their own PBXs. They expect a set of calling features, such as caller I.D., call waiting, call forwarding, voice mail, to be provided by the network. Service providers are making good margins on these services today, and subscribers have become dependent on them. Therefore, they must be provided as part of any softswitch solution for local telephony.

Some of the most common local telephony calling features include the following:

• Call Waiting
• Call Forward All
• Call Forward Busy Line
• Call Forward Don’t Answer (CFDA)
• CFDA Subscriber Ring Control
• Remote Activation of Call Forwarding
• Three-Way Calling
• Call Transfer
• Call Pickup
• Distinctive Ringing
• Do Not Disturb
• Calling Number Delivery
• Calling Number Delivery Blocking
• Caller ID with Call Waiting
• Calling Name Delivery
• Calling Name Delivery during AC/AR Ringing
• Automatic Callback
• Automatic Recall
• Unidentified Call Rejection
• Selective Call Forwarding
• Selective Call Rejection
• Customer Originated Trace
• Business Group Line
• Business Group Dialing Plan
• Semi-Restricted Line
• Fully-Restricted Line
• Intercom Dialing
• Special Intercept Announcement
• Critical Inter-Digit Timing for Dialing Plan
• Customer Access Treatment Code Restriction
• Direct Inward Dialing/Direct Outward Dialing DID/DOD
• Automatic Identified Outward Dialing
• Single-Digit Dialing
• Busy Line Verification
• Busy Line InterruptE
• E911 Operator Services
• Feature Creation Environment

An MGC that just implemented a call agent and a set of basic calling features might provide a local-exchange softswitch-based solution for local telephony that offers comparable functionality to a traditional local-exchange switch—perhaps at substantially lower cost—but it would not provide any means for a service provider to create differentiated services. This is a key requirement for attracting and retaining customers, so an MGC for local telephony services must have the ability for new services to be created and customized by the service provider.

Today’s local-exchange switches do not offer any facilities for service creation. All the switch’s features are implemented in embedded software, and no public interfaces exist in which features can be added to the switch or existing features modified.

Some special features can be implemented outside the switch using standard signaling interfaces, such as SS7, and this is the basis for the advanced intelligent network (AIN) concept. But AIN has promised more than it has been able to deliver—this is because many desirable new features require direct interaction with the call state machine, and AIN does not provide that capability.

Developing new features in a traditional local-exchange switch requires opening up the embedded software and writing code to the internal application programming interfaces (APIs) of the switch. In most current switches, the software code base has evolved for many years, and the sheer complexity of the code almost guarantees that complex interactions are involved in any new feature development. Consequently, exhaustive regression testing is required to verify that the addition of a new feature has not introduced errors into any of the rest of the features.

If service providers are to have the opportunity to create their own new features, an entirely new approach is required for creating the architecture of the feature processing software in the MGC:

• A high-level language is required to define the functionality of new features, and this language should be linked to graphical tools that enable new features to be designed visually, without complex coding rules.
• A fully object-oriented approach is required, in which basic feature primitives are implemented as objects, and new features can be built upon these feature primitives, thereby taking advantage of inheritance.
• The object model for call processing should take account of the possible interactions between basic feature primitives, making it unnecessary to carry out extensive regression testing of any new feature that has been created from the basic feature primitives.
• The data that describes each subscriber’s configured features and the parameters that control them should be accessible through an open, self-describing data exchange format that facilitates Web-based subscriber self-care. Extensible markup language (XML) is ideal for this purpose.

An MGC that takes this approach and offers an easy-to-use and robust feature creation environment places a great deal of power in the hands of telephony service providers. The low cost and rapid development time for new features means that, for the first time, service providers can afford to cater to the specialized needs of specific market segments rather than falling back on the generic features that are found in every switch today. Just a single, unique new feature that meets the needs of a particular group or community could attract and retain large numbers of new customers, without having to offer large discounts as an inducement.

Integration of Softswitch Functionality

The MGC functions described above can be thought of as layers, in the sense that the call agent, the basic calling features, and the feature creation environment add progressively more sophisticated capabilities to the MGC. But these functions should not be treated as layers in the sense of a protocol stack, where each layer communicates with the one above and below by means of well-defined APIs. This approach imposes undesirable restrictions on the capability of the MGC.

The restrictions imposed by a strictly layered approach have become apparent over a number of years of experience with programmable switches, which implement an embedded call agent and support well-defined APIs to an external server that, itself, implements advanced features. This type of switch is widely used for special telephony applications, such as calling card processing. The limitation of the layered approach is that the call-state model and its interactions with the external feature server are fixed. A new feature that requires new kinds of call state or a new kind of interaction with the call-state model cannot be implemented in this environment.

The concept of separating basic call control from advanced features has found its way into the softswitch world. Many of the softswitch solutions that are being proposed today consist of three elements: an MG, an MGC that just handles basic call control, and a feature server in which the advanced features and feature creation environment are supported. This model suffers from the same inflexibility as the programmable switch, since the fixed nature of the APIs between the MGC and the feature server make it impossible to exploit new kinds of interaction between features and the call-state machine.

A vertically integrated approach to MGC functionality provides a much more future-proof solution. In this model, the call agent, the basic features, and the feature creation environment are all running in the same system. This makes the call-state machine fully accessible to the feature creation environment, allowing one to retain the complete flexibility needed to create innovative new features that may require unforeseen call-state interactions in the future.

Operating Environment for the MGC

One must also be familiar with the kind of platform an MGC will be running on. The objectives of separating the physical switching function from the call processing function are to permit call processing to run on industry-standard platforms, to leverage low-cost processing power and storage, and to open operating system and development environments.

In practice, this means that the MGC should run on a high-availability Unix server platform in a dual-redundant configuration. For ultimate protection, the two servers that make up the dual-redundant configuration could be placed in separate physical locations, as long as there is sufficient network bandwidth available between them to support the call-state replication required for complete fault tolerance.

An individual MGC may control a single MG or a collection of MGs, depending on its call processing capacity. Configurations that include multiple MGs controlled by a single MGC behave like a single distributed MG when viewed from the outside.

Signaling Connections for the MGC

MGCs that control MGs connected to circuit-based or packet-based voice networks must support the termination and processing of the telephony signaling protocols associated with those networks.

For packet-based voice networks, the signaling protocols most likely to be used include H.245 (the signaling protocol that belongs to the H.323 protocol suite) and SIP. These protocols ride on top of an IP transport, and because the MGC is likely to have an IP network connection for the transport of Megaco, this connection can be shared for the transport of the packet voice signaling.

For circuit-based networks, the applicable signaling protocols include signaling system 7 (SS7), ISDN primary rate interface (PRI) signaling, and channel associated signaling (CAS). These protocols are usually transported on circuit-based facilities. In the case of message-based protocols, such as SS7 and PRI, the messages are carried on a connection-oriented data link layer, such as link access protocol for D-channels (LAPD) or SS7 message transfer part 2 (MTP2), which in turn occupies one or more DS–0 time slots on a T-1 facility. CAS is a bit-oriented protocol that is carried in the framing information on T-1 facilities.

The MGC function does not typically contain the physical interfaces needed to connect to and terminate these circuit-based signaling protocols. Since the MGC’s native mode of communication with the outside world is IP–based, the obvious solution is to map each of the circuit-based signaling protocols onto an IP–based transport.

This is the purpose of SIGTRAN, a proposal being developed in the IETF for a method of carrying circuit-based signaling protocols over IP networks. The key component of this solution is the simple control transmission protocol (SCTP), a protocol that can carry multiple sessions of various signaling protocols over a single IP connection efficiently.

Since circuit-based signaling protocols are typically associated with and physically carried on the circuit-based transmission facilities that terminate on MGs, the obvious solution for these protocols is to implement a SIGTRAN–signaling gateway as an additional function within the MG. This signaling gateway will terminate the lower layers of the SS7 and PRI protocols, and encapsulate the application layer messages for forwarding over the IP connection to the MGC.

Figure 4. Media Gateway for Packet-to-Circuit Access with Integrated Signaling Gateway