PDF of this tutorialVoDSL Today
Today’s solutions for VoDSL leverage the broadband access network to provide transport for multiple lines of telephony over a single broadband connection. These VoDSL solutions invariably consist of two elements: an IAD located in the customer premises that packetizes voice and voiceband data transmissions and an access gateway located in the service provider’s network that converts packetized voice back into a circuit-based format suitable for delivery to a local-exchange switch.
In this approach, there is no switching of voice traffic within the broadband network. The first switching operation that voice traffic experiences within the service provider’s network takes place at the local-exchange switch that is upstream of the access gateway. Although an individual IAD may have packet connections to multiple gateways, each port of an IAD must logically be tied to a specific local-exchange switch. This fixed relationship between IAD ports and local-exchange switch ports is essential to the proper delivery of local telephone service; it has given rise to the term “loop emulation” to describe this class of solution.
Transformation of the Access Gateway
If the VoDSL access gateway has been designed with sufficient architectural flexibility, then it should be possible to add support to it for MG control via Megaco. In this case, the access gateway becomes a true MG. If it is paired up with a suitable MGC that supports local telephony features, then it should be able to deliver local telephone service over the VoDSL connection without the need for a conventional local-exchange switch.
Media Gateway Supporting Circuit Trunks
This transformation of an access gateway into a MG can be accomplished without any change to the packet voice protocol that is used between the IADs and the gateway. The new capabilities offered by the MG are transparent to the IADs, which are unaware that dial tone is now originating from the MG to which they are connected, instead of a local-exchange switch that lies upstream of the gateway. To function as an MG that supports existing VoDSL IADs, the gateway requires some additional signal processing hardware resources to perform the following:
- Generation of call progress tones, such as dial tone, ringback, busy, fast busy, stutter dial tone, etc.
- Generation of voiceband data transmission tones, such as those needed for sending Caller I.D. information to the user
- Detection and collection of DTMF dial digits
The access gateway is connected into the PSTN via circuit-based connections that support an access network protocol, such as GR–303 or V5.2. The transformed MG can make use of the same physical interfaces, but these are now connected to tandem switches and are controlled by trunking protocols, such as SS7 and PRI. Ideally, the MG will have the ability to terminate the physical, data link, and network layers of these signaling protocols, passing the signaling application layer messages to the MGC over an IP connection using a standard transport encapsulation such as SIGTRAN.
Media Gateway Supporting Packet Trunks
The MG described in the previous section supports packet voice access (such as VoDSL) with conversion to circuit-based trunks. This type of functionality is an absolute requirement for a local telephony softswitch solution, since much of the traffic that originates at an IAD will terminate in the same local calling area on a regular POTS connection served by a conventional circuit-based local-exchange switch. Therefore, most of the packet traffic arriving at the MGs on the access side will have to be handed off to a local access tandem switch via a circuit-switched trunk, typically an SS7 intermachine trunk (IMT).
It will not be long, however, before packet-based voice trunking is required in this scenario. The packet trunks may be used to network together multiple MGs in the same local calling area to provide a kind of distributed local switch solution, or they may be used to hand off voice traffic to long-distance packet voice service providers.
Figure 5. Use Cases for Packet-to-Circuit Access from IADs
- Case 1: Phone C makes a local call with handoff to another service provider
- Case 2: Phone K makes a call via a remote tandem gateway with handoff to another service provider
- Case 3: Phone A makes a station-to-station call to Phone B
- Case 4: Phone D makes a call to Phone M, which is on another IAD
In either case, the MG will need to be able to switch packet-voice traffic arriving from the access side onto outgoing packet-voice trunks. If the access network and the trunks are using the same packet voice technology (for example, ATM AAL–2), then the MG acts simply as a packet switch to move voice packets between the access and trunk networks. If different packet voice technologies are used on either side of the MG, then the MG will have to perform packet-voice protocol conversion. This can be done without having to convert the voice back to TDM form and repacketize. An AAL–2 voice packet can be converted to a VoIP voice packet by mapping the AAL–2 packet header to an IP/UDP/RTP packet header.
For a VoDSL access gateway to migrate successfully to this role of packet voice switching, it must have a high performance and fault-tolerant packet-switching bus. If the access gateway is designed to convert incoming packet voice traffic to a TDM bus, then it will not be able to handle the passing through of packet voice traffic without introducing an additional cycle of depacketization and repacketization. This is undesirable because it adds substantially to transmission delay and potentially squeezes end-to-end delay budgets that are already tight.
Migrating the Media Gateway to the Network Edge
The transformation of an access gateway into an MG like the one described above will bring most of the advantages of a local-exchange softswitch approach; it does so without making any changes whatsoever to the IADs that provide the customer connections into the packet access network. The combination of MG and MGC will allow service providers to deliver local telephony services that leverage the economic benefits of packet voice access, at a small fraction of the cost of a typical local-exchange switch.
The economics associated with this kind of solution are such that competitive local-exchange carriers (CLECs) can profitably serve local markets where they may only expect to win a few thousand lines. They will be able to attract customers by combining bundled voice and data services with innovative and narrowly targeted new voice features, instead of relying on deep discounts on voice services as they did in the past.
But there is one further optimization that may be useful for certain types of customers. The solution described so far relies on an MG located in the service provider’s network to provide dial tone, and this MG acts effectively as an end office switch. As a result, each IAD voice port must be permanently tied to a specific MG in the service provider’s network, since the MG represents a single point of ownership for the line in handling features like call waiting and call forwarding.
A consequence of this is that all traffic from a given IAD port has to physically pass through the MG that owns it. This is not necessarily a bad thing. The MG provides essential media conversion functions on most calls to provide the handoff to local and long-distance circuit-switched connections and to perform packet voice protocol conversion where necessary between packet access and trunk networks.
Occasionally, it becomes undesirable for all IAD–originated traffic to pass through the same MG in the service provider’s network; three such circumstances are discussed below. Before this, a solution that decouples the IAD from a fixed connection with a given service provider’s MG is also covered. The IAD as Media Gateway
The functional model we have developed here assumes no switching takes place in the network between the IAD and the service provider’s MG. Each IAD port is logically hard-wired to an MG in the service provider’s network. This is necessary if dial tone is being originated in the service provider’s MG because the MG has to have exclusive control of the IAD's ports in order to handle successfully complex features, such as call waiting and call forwarding.
It follows that, to move away from this model, a dial tone in the IAD itself must be provided. This is done by moving MG functionality into the IAD and by establishing a Megaco connection with the MGC. The MGC must still reside in the service provider’s network because it must connect into the SS7 network to support calls over the PSTN and because it is not feasible for small-business or residential users to have their own MGCs with SS7 connections.
As previously explained, the additional functionality necessary to transform an access gateway into an MG comprises mainly signal processing hardware to perform tone generation and recognition, as well as support for the Megaco protocol itself. By adding these capabilities to the IAD, it can be transformed into an MG that brings end-office switching functionality to the customer premises.
The IAD/MG will support analog telephony user ports and a packet-voice access port, typically over a DSL connection. Unlike the IAD previously described, the IAD/MG does not have a fixed association with a service provider’s MG. It is free to establish packet voice connections with any device on the packet network that can support the same protocols. This freedom is, of course, strictly under the control of the MGC that is in the service provider’s network. The MGC sees all call setup activity and is able to track all calls by calling number, called number, time of day, and duration. With this information, the MGC can produce the call detail records that are necessary for billing purposes.
The service provider’s MGC is responsible for analyzing the dial digits collected by the IAD/MG and determining how to route the call. If, for instance, a call is destined to terminate on another service provider’s local-exchange switch in the same calling area, the MGC will direct the IAD/MG to establish a packet connection with the appropriate MG in the service provider’s network where the packet-to-circuit conversion can be performed and the call can be directed to the appropriate local access tandem.
For this model to operate successfully, it must be possible for the IAD/MG to establish packet voice connections to arbitrary MGs on request. If the packet voice access is based on VoIP, the MGC will supply the IAD/MG with the IP address of the target MG and instruct it to set up a VoIP session. If the packet voice access is based on VoATM, then the MGC will instruct the IAD/MG to establish a switched virtual circuit to the target MG and provide the relevant ATM address.
It will now be valuable to explore the circumstances in which this solution delivers real value.
Direct Packet-Voice Connections between IADs
A business customer may have multiple locations that are served by packet voice access, where the IADs are all connected to a common packet network. If there were a substantial amount of intraenterprise voice traffic between and among these IADs, it would be more efficient for this traffic to travel on direct packet connections between IADs rather than via service provider MGs.
A service provider may choose to support this kind of scenario with a virtual private voice network solution. In this case, the service provider’s MGC could be configured to handle calls among this community of IAD/MGs using, say, a four-digit dial plan. The community of IADs would then behave like a distributed PBX. While a virtual private network (VPN) is not a new idea, this use of packet voice to implement a VPN solution under the control of a service provider’s MGC brings the concept into new light.
Direct Packet-Voice Connections to Remote Trunking Gateways
As packet voice networking becomes ubiquitous, it should be possible for an IAD/MG to make direct packet-voice connections with remote gateways that perhaps lie on the far side of a long-distance or international packet-voice network. If the packet-voice access network and the long-distance packet-voice network are operated by different service providers, packet-voice peering agreements may be needed. The IAD/MG and the remote gateway must use the same packet voice transport protocol in order to interoperate in this way. For this reason, support for multiple packet voice protocols (VoIP and VoATM) is desirable in the IAD/MG.
Station-to-Station Calls at the IAD
Many businesses require support for local station-to-station calling, and today they have a choice of using local switching based on a PBX or key system or network switching using Centrex-type services.
PBXs and key systems can be used with packet-voice access networks, but the access network connections have to be configured in specific ways to deal with the presence of local switching. Typically, a hunt group is configured for outgoing calls and for calls to the main switchboard or auto-attendant number, while an additional direct inward dialing (DID) group must be configured to handle direct dialed incoming calls. With this setup, all the required local calling features, such as call waiting, must be implemented in the PBX.
Not all businesses are prepared to deal with the cost and complexity of PBXs. The alternative solution has been to use Centrex, where the local-exchange switch provides support for the four- or five-digit dial plan that is used for station-to-station calling while offering access to outside lines and direct inward dialing.
One of the problems with Centrex is that all station-to-station calls physically pass through the local-exchange switch and, therefore, consume resources in the local access network. A Centrex customer with 100 stations requires 100 voice connections to the local-exchange.
Using an IAD/MG with local switching support, a service provider could offer a kind of next-generation Centrex service where all the call handling and feature processing intelligence belongs in the MGC that is part of the service provider’s network, but local switching is performed directly in the IAD/MG. The customer would gain all of the utility benefits of Centrex while the service provider would only have to provide sufficient access network resources to support external calls. For example, a typical installation with 100 stations might need only 16 outside line connections, and these could be delivered via packet voice over a single DSL connection.
Figure 6. Use Cases for Packet-to-Circuit Access from IAD/MGs
- Case 1: Phone C makes a local call with handoff to another service provider.
- Case 2: Phone K makes a call via a remote tandem gateway with handoff to another service provider.
- Case 3: Phone A makes a station-to-station call to Phone B.
- Case 4: Phone D makes a call to Phone M, which is on another IAD.
