16.4 VoDSL Architectures

   


There are three basic architectures for DSL, each of which makes use of a different layer of the communications stack for carrying the voice-over DSL connection. Figure 16.7 illustrates these three basic architectures:

  1. Voice-over IP (VoIP) in which voice is encapsulated within IP data packets. In this case voice is transmitted at Layers 3 and 4 of the communications stack.

  2. Voice-over ATM in which the voice is encapsulated within ATM cells . In this case the voice traffic is transmitted at layer 2 of the communication stack.

  3. Channelized voice over DSL (CVoDSL), where the digitized voice is carried directly on the PHY of the DSL link.

Figure 16.7. VoDSL architecture on the communications stack.

graphics/16fig07.gif

16.4.1 VoIP and DSL

The Internet and its suite of protocols were not originally developed to support voice but rather data. However, the pervasiveness of the Internet and the flexibility and extendibility of its suite of protocols invites the use of IP to carry voice traffic. This, and the fact that digitized voice is just a form of data (albeit data with some very stringent delivery requirements) when seen by IP routers, has lead to the development of a large number of Voice-over IP (VoIP) architectures and protocols. Several of these are seeing rapid deployment in a number of telephony environments. Any telephony protocol must cover three basic areas: The specific methods of carrying the voice traffic (i.e., the "bearer" protocols); the methods used for setting up the communications between the two end points (i.e., the "signaling protocols"); and the quality of the service must be managed, the services configured, and user problems resolved. This requires the definition of management protocols.

Three Approaches to VoIP
H.323

One approach to providing VoIP is based on an existing ITU Recommendation H.323 [6]. This approach is currently widely deployed in ad hoc "voice from the PC implementations " which uses the public Internet for transmitting voice between PCs or between PCs and gateways to the PSTN. Because of its complex call processing, it is losing favor to other VoIP solutions. This architecture has four main components .

  1. Terminals . A terminal is a computer or other device that supports the H.323 protocol and allows the termination of H.323 voice or multimedia sessions for use by the user. The H.323 protocols allow voice (or other multi-media sessions) to be supported between terminals.

  2. Gateways . A gateway connects a network supporting H.323 to another network. In an H.323 network a gateway is required to connect that network to the PSTN or to a corporations internal legacy voice network. Gateways are not required to support communications between two H.323 terminals.

  3. Gatekeepers . Gatekeepers provide information to terminals required for the setting up and management of H.323 voice sessions. This information includes address translation, admission control (that is, guaranteeing the network resources exist to set up a call before an attempt is made to allocate these resources), bandwidth management, and routing services. A gatekeeper is not required in an H.323 network but is highly desirable as it allows detailed network information to be hidden from terminals and instead be stewarded by the gatekeepers.

  4. Multi-point control units (MCUs) . MCUs allow the set up and management of calls such as conference calls between multiple terminals.

H.323 has the advantage of being widely deployed today, for example, in many PC-based "Net-to-Phone" services and PC-to-PC voice applications such as Microsoft's NetMeeting multimedia service. Because it makes few assumptions about the existing network and is quite tolerant of the fact that most IP networks do not guarantee quality of service (QoS), H.323 service is quite easy to set up on the existing public Internet or private intranets . It has several disadvantages: The call set-up model is very cumbersome and complex; it does not deal well with issues of stability and consistency that are vital in networks that claim to compete in quality with the PSTN; accounting and billing for services is difficult; it does not interact smoothly with those elements in a network that could guarantee quality of service.

In many cases, the use of H.323 is transparent to a DSL implementation. DSL is often used to provide a high bandwidth and always connected access to the Internet. This allows existing H.323 applications on the users' hosts (which are running software that makes then H.323 terminals) to make use of the improved service to enhance the H.323 VoIP performance. In a sense this enhancement comes for free; neither the access network nor the DSL CPE has been specifically enhanced to support H.323. Figure 16.8 illustrates a telephony system architecture based on H.323.

Figure 16.8. H.323 architecture for VoIP.

graphics/16fig08.jpg

H.248/MEGACO (Media Gateway Control Protocol)

MEGACO is defined in ITU Recommendation H.248 [5]. This recommendation is derived from work done in the IETF on the MEGACO (Media Gateway Control) specification. MEGACO is a rather centralized approach to the control of VoIP services. This approach uses a media gateway controller to set up and control connections between the users. The media gateway controller both mediates control and bearer setup with other networks, either the PSTN or other VoIP networks (such as H.323) and controls media gateways within the H.248 network. Media gateways are coordinated and controlled by the media gateway controllers which instruct the media gateways in setting up communications paths between themselves through the packet network. MEGACO resembles the centralized structure of signaling and control used in the PSTN. In the PSTN, SS7 is a specialized signaling protocol that instructs telephone switches to set up calls between each other. The media gateway controller serves a similar function for the media gateways in a H.248-based network. However, in the SS7-controlled PSTN, the SS7 network is a physically distinct network, whereas in the MEGACO environment the media gateway controller and the media gateways are typically supported over the same packet-based network.

MEGACO has a number of advantages: Its signaling protocols are easily extendable to deal with new environments. Its similarity in architectural philosophy to the existing SS7 controlled PSTN simplifies interworking between MEGACO-based environments and the legacy telephone network. It is specifically designed to support distributed control of complex telephony services in a packet environment, thus aiding in the development and deployment of softswitches, which are distributed and packet-based replacements for existing telephone switches. As H.248 was developed largely by engineers with a more telephony mindset than H.323, it deals with issues of accounting (billing) and network stability as an inherent aspect of the architecture.

The ATM forum is in the processes of defining H.248 interfaces for support of VoDSL loop extension services. These interfaces define MEGACO messages between a softswitch or gateway and a device supporting the traditional telephony interfaces found at a customer's premises. The use of MEGACO is shown in Figure 16.9.

Figure 16.9. Overview of the MEGACO architecture.

graphics/16fig09.jpg

SIP (Session Interconnect Protocol)

SIP, based on IETF specifications RFC 2543, is a signaling protocol used for establishing sessions in an IP network [8]. A session could be a two-way telephone call or it could be a collaborative multimedia conference. SIP is a request-response protocol that closely resembles HTTP (hypertext transfer protocol, the communication protocol that underlies the World Wide Web) and SMTP (simple mail transport protocol, which is the basis of Internet email). The philosophy upon which SIP is designed is like that of many of the Internet applications in which a distributed family of servers provides addressing and location information while devices on the periphery of the network have the intelligence to actually support the applications. If MEGACO is the packet-voice environment that most resembles the PSTN, the SIP architecture is most Web-like. SIP provides the following services to control a session: Name translation and user location, which ensures that the call reaches the called party; feature negotiation, which allows the elements involved in a call to agree on the features that are supported; call participant management, which allows a user to establish a call or to add or delete additional users to a call; and call feature changes, which allow a user to modify the features of a call during the call.

There are two basic components to the SIP architecture: the User Agent and the SIP Network Server. The User Agent resides in the end systems that terminate the calls; the SIP Server resides in the network and coordinates calls. The main function of the SIP Server is to provide name resolution and user location, as the caller is unlikely to know the IP address or host name of the called party. The philosophy here is identical to that of Domain Name Servers that hide the need for a user to know an Internet address to connect to a service.

The advantage of SIP is that it is most converged of the various VoIP architectures with the structure of the Internet applications. Its developers thus expect that the great flexibility of this decentralized philosophy of application architecture will result in very low cost and very extendable voice applications that will be easily integrated with other IP-based applications. A SIP-based telephony architecture is shown in Figure 16.10.

Figure 16.10. Overview of the SIP architecture.

graphics/16fig10.jpg

All the VoIP architectures leverage the universal connectivity and growing efficiencies of the packet-switched Internet. It is expected by many that once the VoIP CPE elements are cost-reduced and the distributed call control feature matures, VoIP will enable voice transport at a cost less than the circuit-switched PSTN. Even more important it is hoped that VoIP will lower the development cost and speed the deployment of new voice services. VoIP maximizes the abilities to perform multimedia conferencing involving interactive combinations of voice, text, data, and video; this is what H.323 is all about. Both MEGACO and SIP add enhanced call control, session stability, and the ability to efficiently bill for VoIP-based services. When used to support VoDSL, VoIP has the advantage of using the existing DSLAMs without hardware or firmware modifications. The IP packets flow through the DSLAM and ATM traffic aggregator the same way as data packets.

However, development and deployment of VoIP will require much effort to supplant the PSTN and its environment. The IP protocol stack was developed to provide a best effort data service. The basic IP protocol stack does not allow control of QoS, especially with regard to delay, guarantee of bandwidth to carry the messages, and control of jitter factor that are all vital to quality transmission of voice. In addition to the basic architectures that are mentioned above, successful deployment of VoIP requires enhancements to IP networks, especially the addition of QoS functionality provided by protocols such as RSVP, MPLS, and Diffserv. The deployment of these protocols is still in its earliest stages.

It is not clear whether H.248-MEGACO or SIP will ultimately be the favored approach for VoIP. The latency inherent in VoIP is a serious concern, especially for VoDSL. The variable packet delay in the routed IP network results in yet more delay in the voice IP conversion points where the packets must be buffered to avoid bit-stream underrun. Furthermore, lost packets can be a problem because there is not sufficient time to retransmit lost packets in a voice environment. Voiceband echo cancellation can reduce the perceived effects for a total one-way latency less than 200 ms. However, echo cancelers add some cost, and the voice quality is noticeable reduced when the total delay is above 200 ms.

16.4.2 VoATM on DSL ”Loop Extension

Voice-over ATM conveys voice in an ATM virtual circuit (VC) and data in separate ATM VC. Unlike VoIP, VoATM uses the connections provided in the ATM network to ensure the proper quality to support voice adequately. However, unlike the TDM (time division multiplex )-based PSTN, VoATM uses the 53-byte cells of ATM to make very efficient use of the bandwidth for transporting voice. VoATM architectures have been defined specifically for the DSL environment ”DSL Forum TR 39 Annex A [10] and ATM Forum af-vmoa-0145.0000 [1].

As most of the DSL implementations are based upon ATM networking, VoATM is a natural architecture for VoDSL. The greater efficiency of VoATM when compared with VoIP is very desirable for the DSL environment where line rates are relatively slow (often as little as 128 kbps) upstream when compared with the 10 Mbps or greater line rates found on Ethernet in corporate environments. Because voice is carried over its own ATM VC, QoS can be guaranteed for the voice traffic independently of that provided for the data traffic for a particular customer.

The loop extension architectures (BLES or LES) defined by the ATM Forum and DSL Forum, illustrated in Figure 16.11, allow telephony functions from existing telephony equipment at a customer's site to be connected to a telephone network over ATM connections. The loop extension service replaces the copper telephone loop with derived lines carried over an ATM VC. The basic elements in the architecture are:

  1. The devices at the customer's premises that can support either POTS (plain old telephone service) or ISDN BRI.

  2. A customer premises interworking function (CP-IWF) which converts the telephony interfaces into voice-over ATM and inserts the voice traffic on the ATM AAL2 VC.

  3. The DSL link provides the interface to the carrier's ATM network.

  4. The CO interworking function (CO-IWF or CO gateway) converts the voice-over ATM back into an interface that is supported by the telephone network. These interfaces include Telcordia GR-303 and TR-08 for North American implementations and ITU-T V5.2 for implementation elsewhere in the world.

  5. The data traffic to and from the customer is carried on its own ATM VC, over the DSL link and through the carrier's ATM network to its own termination at the far end of the carrier's network.

Figure 16.11. Overview of a VoATM architecture for DSL.

graphics/16fig11.jpg

The loop extension interface uses AAL2, defined in ITU I 366.2 [7] to carry the voice traffic. AAL2 allows multiple voice channels identified by a channel ID (CID) to be carried over a single ATM VC. Digitized voice from multiple conversations can thus be carried in a single ATM cell , resulting in a very efficient transport of voice traffic with little overhead. This is true even if the digitized voice is not compressed. By allowing efficient transport of uncompressed voice (pulse code modulated ”PCM voice ”as defined in ITU-T G.711 [2]), loop extension allows for a very simple conversion between analog and digital voice, which reduces transmission latency and simplifies the design of the CPE. Voice compression can also be supported.

Each ATM cell contains one or more AAL2 data structures. Each AAL2 data structure is composed of a 3-byte header and the data. The header contains:

  1. An 8-bit channel identifier.

  2. A 6-bit length indicator that indicates the length of the payload, which can be between 1 and 45 bytes.

  3. A 5-bit UUI field. This is used to indicate the "profile" that indicates how the voice data is encoded and compressed.

  4. A 5-bit error-detecting HEC code.

The digitized voice for a particular voice connection is placed in the payload. Thus, each call over the DSL interface is associated with a particular CID. The layout of the AAL2 cell is shown in Figure 16.12.

Figure 16.12. AAL2 cell structure.

graphics/16fig12.gif

The signaling information for a particular call is carried in AAL2 messages. Loop extension supports channel associated signaling (CAS), used in North America, and common channel signaling (CCS), used in Europe:

  • In CAS the signaling (such as the telephone is off-hook or on-hook or the ringing of a telephone) is encoded in a 4-bit code word. Each CAS message is carried in an AAL2 packet with the same CID as the voice traffic for the call.

  • In CCS signaling specific messages are used for the signaling. In this case all messages for a particular interface are carried in CID 8.

Loop extension supports a management channel between the CO-IWF and the CP-IWF carried in CID 9.

16.4.3 VoSTM

Voice-over synchronous transfer mode (VoSTM, also known as channelized voice-over DSL [CVoDSL]) conveys voice calls over a separate bearer channel within the PHY. Voice in VoSTM is converted from an analog voice signal to digital: 64 kb/s G.711, 32 kb/s G.726, or 16 kb/s G.723. Several voice calls are placed in a DSL PHY bearer channel separate from data. At the DSLAM, the voice calls are combined with those from other lines and multiplexed into a TDM digital interface to the class 5 voice switch using an interface such as GR-303 or TR-008. Figure 16.13 illustrates this architecture.

Figure 16.13. CVoDSL architecture.

graphics/16fig13.jpg

The advantages claimed for VoSTM include low signal latency and reduced equipment complexity. The separate bearer channel would operate without data interleaving to achieve low signal latency, and thus would improve end-to-end voice quality by avoiding noticeable voice echo. The low latency would further eliminate the need for voice- band echo cancellation in the CPE, and the CPE would be further simplified by eliminating the complex AAL2 functionality. Furthermore, the voice is conveyed directly as TDM traffic, without ATM or IP channel overhead. The VoSTM method also avoids the need to administer the separate ATM virtual circuits needed for VoATM.

It has been claimed that VoSTM eliminates the cost and complexities of the voice gateway in the CO. Actually, the voice gateway would still be in the CO, but it is integrated within the DSLAM. This integration could provide some advantages. However, placing the gateway within the DSLAM precludes the efficiencies of pooling the traffic from several DSLAMs into one shared voice gateway.

VoSTM raises some complex issues. Would a system supporting up to several simultaneous voice calls (e.g., four calls) permanently reserve the full bandwidth needed for the maximum number of calls, and thereby waste this bandwidth the majority of the time when a smaller number of calls are active? Alternatively, would a system implement a complex dynamic PHY channel rate- repartitioning scheme to change the voice bearer channel rate in real time as calls begin and end. If the dynamic bearer bit rate approach is taken, then the bit rate of the data bearer channel will change dynamically, resulting in the need for the data multiplexers, switches, and routers to adapt to the changing bit rate.

The disadvantages of VoSTM include the difficulty of incorporating it into the embedded base of DSLAM and NGDLC equipment that now amounts to many millions of lines of network capacity. Whereas VoATM and VoIP would flow through the existing DSLAM and NGDLC equipment without replacement or upgrade, VoSTM would require at least a major in-service field upgrade to the hardware and software of every DSLAM or NGDLC that would need to support VoSTM. Because most ADSL systems in use operate in a low-latency mode already, the further latency reduction provided by VoSTM is of marginal value. It is doubtful that VoATM causes a need for voice-band echo cancellation in the IWD, because the VoATM latency for the DSL portion of the network can be about 2 ms. Furthermore, voice-band echo cancellation is usually performed at the network gateway, and is not needed elsewhere. The ATM cell overhead is more than recovered in the transport efficiency of silence suppression, where ATM cells are not sent during the silence between utterances. Silence suppression provides no benefit for data and fax type calls, but does provide an average traffic savings of over 50 percent for voice calls. Regarding the cost savings due to eliminating AAL2 processing, this would be true for implementations optimized to support only VoSTM. However, DSL chips often attempt to support all major options in an all-purpose chip; thus, AAL2 functions would likely not be eliminated.


   
Top


DSL Advances
DSL Advances
ISBN: 0130938106
EAN: 2147483647
Year: 2002
Pages: 154

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net