Voice and multiservice network design over ATM and IP networks

Bell Labs Technical Journal ◆ October–December 1998 255

IntroductionDuring the last few years, both the Internet and

the demand for data services have grown explosively.

The need for network capacity is rising with the intro-

duction of capacity-intensive applications, the increase

in the size of the user population, and time-of-use con-

siderations. At the same time, telephony has become

one of the most ubiquitous innovations around the

world—especially for business customers. Today, voice

services transmitted over the circuit-switched network

account for the largest portion of business telecommu-

nications costs. At present, the challenge to voice and

data communications service providers is to use

mature technologies to reduce the total cost of net-

works while ensuring the quality of service (QoS) and

performance that individual services require.

Most established and new telecommunications

carriers provide or plan to provide both data and voice

switching and transport, while data service providers

intend to carry packetized voice, video, and facsimile

over their data networks. An integrated multiservices

network infrastructure may provide cost savings from

both network and operations perspectives, greater

network use, and bandwidth flexibility. Therefore, ser-

vice providers are interested in exploring the conse-

quences of providing multiple services over a single

integrated switching and transport network based on

asynchronous transfer mode (ATM) or Internet proto-

col (IP) technology. The two alternatives differ in how

voice and data traffic is carried over them. In an ATM

network, we assumed that voice traffic was carried as

ATM adaptation layer (AAL)-1 or AAL-2 cells over

ATM and presupposed that data packets

(IP/LLC/SNAP)1 are carried as AAL-5 over ATM. In an

IP network, we assumed that voice was carried over

the real-time transfer protocol (RTP)/user datagram

protocol (UDP)/IP and that data IP packets were car-

ried over the point-to-point protocol (PPP).2

Concerning multiservices carried over an ATM or

IP network, a key issue is the voice-over-IP versus

voice-over-ATM question. Arguments are based on

♦ Voice and Multiservice Network Design over ATM and IP Networks Zheng Chen, Kamala P. Das, and Benjamin Y. C. Tang

Asynchronous transfer mode (ATM) and Internet protocol (IP)-based networks haveenabled the introduction of a multitude of computing and communications applica-tions and revolutionized the data services market. Rapid acceptance of Internetapplications by users has demonstrated the potential for explosive service growth indata networking. However, voice services still generate most of the revenues fortelecommunications service providers. The next challenge for these providers andtheir vendors, therefore, is to incorporate an integrated network that will imple-ment the traffic characteristics and demands associated with the different servicetypes to provide cost-effective and efficient voice and data services. We analyzedsuch multiservice network architectures and designed backbone wide area networks(WANs) based on ATM and Internet protocols to handle the varying demands ofboth voice-only and multiservice traffic. This paper describes our design methodology,our network architecture considerations, and our results obtained from several spe-cific network studies that drive equipment and facility capacity requirements.

256 Bell Labs Technical Journal ◆ October–December 1998

the current realities of the relative maturity of the two

technologies and reasonable expectations of their evo-

lution. It is clear that both ATM and IP will evolve to

support differentiated multimedia services. ATM is

well ahead of IP in addressing the QoS challenge and

has the proven ability to support complex service fea-

tures. Traffic isolation required in mixed voice and

data networks will require advanced QoS-enabled IP

router technology. Lucent Technologies has developed

carrier-class next-generation smart routers using

unique schemes designed by Bell Labs to make possi-

ble high-quality differentiated services.

The network planning and design community

within Bell Labs is involved in understanding the net-

working requirements of Lucent’s customers, facilitat-

ing the planning and design of cost-optimized network

topologies that satisfy the traffic demands generated by

the services. Additionally, such networks must satisfy

the requirements of robustness, reliability, scalability,

ease of evolution, and the assurance of performance

objectives and QoS.

This paper provides an analysis of the design trade-

offs for networks that satisfy the aforementioned cus-

tomer requirements based on time division

multiplexing (TDM), ATM, and IP technologies. The

“Packet Network Design Methodology” section intro-

duces our design methodology for ATM and IP net-

work designs. The “Packet Network Architecture”

section describes the integrated network architectures

for both voice and data services based on ATM and IP.

These design methodologies and network architectures

are then applied to the network design of several

examples of voice-only over ATM and multiservice

applications over ATM and IP networks. In the voice

and telephony over ATM (VTOA) study, results are

compared from network designs based on TDM, from

ATM permanent virtual circuits (PVCs) using AAL-2

with compressed voice, and from ATM switched virtual

circuits (SVCs) using the AAL-1 Circuit Emulation

Service (CES). The VTOA study presented in this paper

focuses on the green-field long-distance carrier sce-

nario. Depending on the market segments addressed,

different VTOA network architectures were developed

and the resulting economics assessed.3-5 In the multi-

service network design study, results are compared

Panel 1. Abbreviations, Acronyms, and Terms

AAL—ATM adaptation layerATM—asynchronous transfer modeB-ISUP—broadband ISDN user partCBR—constant bit rateCES—Circuit Emulation ServiceCLEC—competitive local exchange carrierCPE—customer premises equipmentDS—digital signalFR—frame relayILEC—incumbent local exchange carrierIP—Internet protocolISDN—integrated services digital networkITS SP—Internet telephony server for service

providers, a Lucent productITS—Internet telephony server/gatewayITU-T—International Telecommunication

Union – Telecommunication StandardizationSector

LAN—local area networkLDC—long-distance carrierLLC—logical link controlMUX—multiplexerNNI—network-to-network interfaceOC—optical carrierPDH—plesiochronous digital hierarchyPNNI—private network-to-network interfacePPP—point-to-point protocolPSTN—public switched telephone networkPVC—permanent virtual circuitQoS—quality of serviceRFC—request for commentRTP—real-time transfer protocolSAC—synchronous-to-asynchronous conversionSCP—station control programSDH—synchronous digital hierarchySNAP—subnetwork attachment pointSONET—synchronous optical networkSS7—Signaling System 7SVC—switched virtual circuitSW—switchTDM—time division multiplexed, time division

multiplexer, or time division multiplexingUDP—user datagram protocolVBR-rt—VBR real timeVBR—variable bit rateVoIP—voice over Internet protocolVTOA—voice and telephony over ATMWAN—wide area network


among four different network scenarios:

• Voice carried over TDM and data carried over

ATM,

• Voice carried over TDM and data carried over

IP,

• Voice from circuit switches packetized and car-

ried with data over a single integrated ATM

network, and

• Voice from circuit switches packetized and car-

ried with data over a single integrated direct

IP network.

Packet Network Design MethodologyThis section discusses the design methodology for

packet networks for integrated traffic. The packet net-

works considered here are ATM or direct IP networks.

Figure 1 illustrates a generic packet network

design methodology. It identifies the high-level

requirements and constraints to be considered and

tasks to be performed. Since the ultimate goal of a

designed network is to support revenue-generating

services, packet network design begins with the con-

sideration of service requirements, which specify the

multiple services that the packet network must sup-

port and their associated QoS requirements. Network

constraints refer to the pre-existing network environ-

ment that must be accommodated during network

design. Most incumbent network operators have

legacy network infrastructures, such as plesiochronous

digital hierarchy (PDH) or SDH/SONET fiber optic

transmission networks or existing in-service network

equipment that must be used or reused as much as

possible. Another likely network constraint is the

requirement to design with equipment from multiple

vendors according to the preference of the network

provider. Interoperability becomes a critical issue in

the design of such networks.

Taken together, service requirements and network

constraints provide crucial input to the determination

of the network architecture. The network architecture

gives a qualitative description of the packet network

by specifying the network hierarchy, various network

components and their interconnections, and the nec-

essary functionality of each network component to

provide end-to-end support for the required services.

The network architecture provides a foundation on

which the basic network design is performed according

to a set of design inputs. Network design tools can assist

in basic network design and in other design tasks, such

as performance analysis, cost analysis and sensitivity analy-

sis (see Figure 1).

Service RequirementsThe following subsections discuss the service

requirements for both voice and data.

Optimizeddesign

Sensitivityanalysis

Performanceanalysis

Servicerequirements

Networkarchitecture

Networkconstraints

Designinputs

Networkdesign

Costanalysis

Tool assisted

Figure 1.Generic packet network design methodology.


Voice service requirements. The VTOA service

requirement identifies the voice service to be sup-

ported and specifies how the service should be deliv-

ered. The network operator may want to transport

only voice traffic over ATM in a circuit mode due to

consideration of the delivered voice quality. This can

be accomplished using the AAL-1 CES6-9 for mapping

DS1/E1 and DS3/E3 circuits over an ATM virtual cir-

cuit network using a constant bit rate (CBR) over a

PVC/SVC connection. Alternatively, voice traffic can

be transported using AAL-2 with voice compression

and silence suppression as variable bit rate (VBR) traf-

fic. AAL-210,11 allows for the multiplexing and trans-

port of small, variable sized voice packets with several

voice compression options—notably G.727,12 G.729,13

and G.723.114—at bit rates ranging from 32 kb/s to

5.3 kb/s per channel. Carrying voice over AAL-2 with

compression and silence suppression enables statistical

multiplexing and allows improved bandwidth use. The

ATM virtual circuits for voice traffic can be established

as PVCs based on expected service demands, or they

can be set up dynamically as SVCs on a per-call basis.

The PVC approach uses ATM as a way of providing

trunks15,16 among the circuit networks. On the other

hand, the SVC approach more effectively uses the

transmission and switching capabilities of the ATM

network and allows the network resources to be

shared by other traffic generated by data and multi-

media communications.

Standards have been developed to support voice

over IP (VoIP) applications.17 Among them, H.323,18

developed by the International Telecommunication

Union – Telecommunication Standardization Sector

(ITU-T), has been the industry’s de facto standard for

VoIP applications and equipment. H.323 generally

defines multimedia communications over a local area

network (LAN) without guaranteed QoS and is sup-

ported by other standards, such as H.22519 and

H.24520 for call signaling and control and H.23521 for

security. Based on the H.323 protocol suite, voice traf-

fic is compressed (with similar compression options in

the VTOA AAL-2 case) and carried over the IP net-

work by a protocol stack of IP, UDP, and RTP. The

Lucent Internet telephony server for service providers

(ITS SP) implements both industry-standard G.723.1

voice encoding and Lucent’s elemedia® technology

for improved voice quality.

In both the VTOA and VoIP cases, network opera-

tors expect that the same toll-quality voice received in

the public switched telephone network (PSTN) will be

retained by the packet network design. This condition

would require that the traditional PSTN QoS require-

ment, such as maximum round-trip delay, be trans-

lated to equivalent ATM or IP backbone QoS

requirements. Lucent’s ATM access concentrators, as

well as edge and core switches, support the various

QoS parameters required by the different ATM service

classes CBR and VBR real time (VBR-rt). PacketStarTM

core IP routers, new from Lucent, incorporate the

basic requirements for supporting differentiated ser-

vices over IP networks. The result is a full-featured IP

engine that supports differentiated services through

sophisticated buffering and queuing schemes, priority-

based bandwidth allocation, and the delay bounds

required for IP telephony, even when the network is

highly congested.

Data service requirements. Existing data traffic,

such as frame relay (FR) and LAN, can be carried over

ATM using the various ATM service classes or over an

IP network in the different priority flows. The data ser-

vice requirements expressed in performance objec-

tives, such as packet loss ratio, will be translated to

equivalent ATM or IP QoS requirements.

Design InputsThe following items are typically contained in

design inputs:

• Voice traffic demands. The voice-over-ATM or IP

traffic demand between a pair of service nodes

can be described in the traditional PSTN fash-

ion by the number of subscribers, the percent-

age of subscribers calling during the busy hour,

the average call duration, and the blocking

probability. The erlang B formula can then be

applied to calculate the number of trunks

(DS0s) required for provisioning between the

service nodes to satisfy the traffic demand. In

an ATM network, each derived voice trunk

demand must be converted to an equivalent

ATM traffic demand that will be used during

network design to determine the ATM virtual


connections, the required network topology,

and the link facility. This conversion to ATM

traffic will take into account the additional

overhead contributed by ATM and the specific

AAL used as designated by the voice service

requirement, as well as the use of voice com-

pression and silence suppression, if applicable.

Voice traffic using AAL-1 CES will be modeled

as CBR traffic, while compressed voice packets

carried over AAL-2 will be modeled as VBR-rt

traffic with an average cell rate, a peak cell

rate, and a burst period. In an IP network, each

derived voice trunk demand will be converted

to an equivalent IP traffic demand that consid-

ers the overhead introduced by the H.323, the

IP protocol stacks, and the use of voice com-

pression. VoIP packet headers consume about

50% of the overall packet size when voice is

encoded as G.711 5-ms packets.

• Data traffic demands. These are described based

on the average packet rate, burst information,

and the QoS characteristics specified by the

data service requirement for various data ser-

vices. Each data traffic demand will be con-

verted to an equivalent ATM or IP traffic

demand that considers the original data appli-

cation (such as FR or IP-based applications)

and the overhead introduced in the ATM or IP

network. Most data applications in our study

examples are IP based. IP data traffic will be

carried over ATM with an overhead of about

20% and carried through the PPP with an

overhead of about 4%.22 A Lucent internal

study on the efficiency of carrying IP packets in

frames versus cells over SONET was based on

the traffic data obtained from the National

Laboratory of Advanced Network Research on

one of the MCI backbone OC3 links. The

results showed a 24.5% overhead for classical

IP over ATM (RFCs 14831 and 157723) and an

18.1% overhead for ATM with null encapsula-

tion (without the overhead associated with

RFC 1483).

• Geographic locations. The basic topological

information of the network is provided by

the geographic locations of candidate nodes

where network equipment will be placed.

The locations of candidate nodes allow for

the calculation of distances, which are

needed for a number of purposes—for

example, to calculate tariff costs and to pro-

vide metrics for the routing protocols during

the design of the network. Such information

is generally stored as latitude/longitude or

vertical/horizontal coordinates.

• Design parameters. These parameters control the

behavior of the network design procedure.

They may specify the following: the routing

protocols employed by the packet network; the

network-level performance requirements, such

as network reliability and survivability; net-

work facility ownership (leased or constructed)

and type (for example, T1, T3 or OCn); equip-

ment model considered in the packet network;

reserved bandwidth used to reroute traffic in

the event of network failures; and the maxi-

mum allowable hop counts for each routed

traffic demand.

• Cost information. This information provides the

cost structures of leased and constructed net-

work facilities, as well as the cost model of the

employed ATM or IP equipment. Cost infor-

mation is used to produce a network design

having a minimal total network cost.

Network DesignBased on a selected network architecture and all

the aforementioned network design inputs, the

objective of network design is to lay out a network

topology specifying the locations and sizes of the

nodes. Network design also lays out the link facilities

interconnecting the candidate nodes such that the

traffic demands from different services among the

nodes can be satisfied. The design is optimized by

minimizing a certain objective function, usually the

total network cost of the derived network design. A

large network often is segmented into access and

backbone due either to architectural requirements or

to an attempt to reduce the design’s complexity. This

segmentation produces a near-optimal but flexible

network design.


Access network design. Based on a given service

demand, the goal of access network design is to deter-

mine the optimal homing configuration for edge

switches, concentrators, or edge routers and to deter-

mine the access link capacity requirements. The design

identifies the backbone nodes from given candidates

and calculates the most cost-effective way to connect

the edge nodes to the backbone nodes, achieving con-

centration of traffic through homing. The result will

specify where and how many edge nodes should be

established in the network, as well as the number of

gateways, routers, data MUXs/switches, and firewall

servers that will be needed at each edge node. The

access network design contributes to the data and

voice edge node equipment and edge-to-backbone

facility costs of the entire packet network.

The trunks required between edge and backbone

nodes are determined by the aggregated traffic

demands in each edge node, the edge node locations,

and whether or not the voice and data traffic are

aggregated at the edge node or backbone nodes.

The result of an access network design provides a

matrix of backbone node-to-node ATM or IP traffic

demands that are used as input to the backbone net-

work design.

Backbone network design. The goal of backbone

network design is to derive a minimum-cost backbone

network that can support the transport of interedge

node traffic derived from the access network’s design.

The backbone network design performs optimal design

on both new and existing backbone nodes. It deter-

mines the connectivity and link capacities among the

backbone nodes and includes such considerations as

routing constraints, the number of hops, and other

QoS requirements to allow sufficient switch-to-switch

bandwidth to support network demands. Backbone

network design contributes to the transport cost of the

ATM or IP network.

The design task faced here is a classical network

optimization problem. It requires finding a network

topology having certain link capacities such that all the

interedge traffic demands are satisfied and the total

network cost is minimized. Because of nonsimultaneous

use of services by subscribers, the total bandwidth

requirement is reduced. Consequently, an overbook-

ing factor is used in backbone trunk engineering to

account for this reduction.

Finally, the design tool output is analyzed for per-

formance verification, parameter sensitivity, and cost

analysis. Reports also are created. It should be noted

that costs for equipment, facilities, and operations, for

example, vary considerably from vendor to vendor

depending on vendor/customer negotiations.

Performance AnalysisThe performance parameters used for evaluation

purposes are the delay jitters for voice traffic and the

packet loss ratio for data traffic. After the initial net-

work design is completed, the network’s performance

is analyzed. If the performance of the designed network

does not meet the performance objective for different

services, design parameters (such as maximum link use

or number of hops) are adjusted and a new design is

created. This process is repeated until the designed net-

work meets the service performance objectives.

Sensitivity AnalysisThe objective of sensitivity analysis is to determine

whether a designed network can withstand a desired

amount of traffic demand fluctuation. Since the pro-

jected traffic is usually estimated with some variance

even though the designed network is sufficient to han-

dle the forecasted demand, any variation in traffic

demand, service mix, or cost model may change both

the topology and cost of the designed network. The

results from sensitivity analysis are used as one of the

criteria for final recommendations.

Cost AnalysisNetwork design is based on the optimization of a

certain condition—generally, the cost of network facili-

ties and equipment. The total cost of the designed cost-

optimized network is calculated based on the network’s

topology and link capacities, tariff cost structure (if

leased lines are used), and the cost model of ATM/IP

equipment. The calculation of the network’s facility

cost is relatively straightforward using either the tariff

cost formula or any of several different methods to

determine this cost according to network operators’

preferences. To calculate network equipment cost,

however, the derived network topology and link capac-

ities must be mapped to requirements on the service


interface, and the switching capacity of the ATM/IP

equipment must be placed at each of the candidate

nodes. The cost model of ATM/IP equipment is then

applied to derive the total network equipment cost.

Packet Network ArchitectureIn this section, we discuss the current TDM net-

work architecture, the ATM network architecture, and

the IP network architecture.

Current TDM Network ArchitectureA typical TDM network architecture is illustrated

in Figure 2. Voice traffic is carried through end-office

switches, tandem switches, and finally to the TDM

core network.

ATM Network ArchitectureSome public service providers are considering inte-

grating their voice traffic onto the ATM backbone net-

work. In this new integrated architecture, such voice

traffic will be routed through an end-office switch to a

tandem switch, then carried through the CBR (AAL-1)

circuit emulation virtual circuits or VBR-rt (AAL-2)

virtual circuits through ATM backbone networks.

Figure 3 illustrates a typical end-to-end integrated

ATM backbone network architecture, which carries

the voice and data traffic.

The upper half of the network architecture given

in Figure 3 is suitable for a VTOA application. Each tan-

dem switch is connected to an ATM switch that sits in

the same office or in a nearby office. The synchronous-

to-asynchronous conversion (SAC) function performs

conversion between TDM and ATM voice traffic, with

possible employment of voice compression and silence

suppression. Note that this SAC function can be an

integral part of either the tandem/toll switch or ATM

switch, or it can be implemented by a separate net-

work element in the ATM network. A signaling gate-

way performs the translation between Signaling

System 7 (SS7) and ATM NNI signaling protocols

(PNNI or B-ISUP) for the dynamic setup of SVCs for

carrying voice traffic. In addition, the signaling gate-

way will be able to control the dynamic allocation of

Signaling trafficApplication traffic

SCP

End-officecircuit switch

Tandemswitch(es)

SS7network

Toll switch(es)

TDM core network

Tandemswitch(es)


SCP – Station control programSS7 – Signaling System 7TDM – Time division multiplexer

Figure 2.Current voice TDM network architecture.


resource in the SAC functional component. The tan-

dem switch, SAC gateway, and signaling gateway con-

tribute to the voice edge node function.

The lower half of Figure 3 shows the ATM net-

work architecture supporting data services. The cus-

tomer premises equipment (router, ATM, or FR

switch) is connected to an ATM data edge

MUX/switch, then connected to an ATM core switch.

It is possible that the tandem switch can be collocated

with an ATM data edge MUX/switch. Then, the voice

traffic may be aggregated with the data traffic in the

same ATM data edge MUX/switch before being trans-

ported to the backbone network.

IP Network ArchitectureSome Internet service providers are considering

providing voice service over their IP backbone net-

work. In this new integrated architecture, such voice

traffic first will be routed through the end-office switch

ATM edgeMUX/SW

Tokenring

CPE ATMSW

CPE FRSW

Signaling trafficApplication trafficPossible traffic

SCP


Tandem/tollswitch

SS7network

Tandem/tollswitch(es) End-office

circuit switch

ATM backbone

SignalinggatewaySAC SAC

ATMSW

ATMSW

ATMSW

ATMSW

SAC

ATM edgeMUX/SW

Tokenring

CPE ATMSW

CPE FRSW

ATM – Asynchronous transfer modeCPE – Customer premises equipmentFR – Frame relayMUX – MultiplexerSAC – Synchronous-to-asynchronous conversionSCP – Station control programSS7 – Signaling System 7SW – Switch

Customer router

Figure 3.Integrated ATM backbone architecture.


to an Internet telephony server/gateway (ITS), then

carried through the IP backbone networks. Figure 4

illustrates a typical end-to-end integrated IP backbone

network architecture that carries voice and data traffic.

The upper half of the network architecture in

Figure 4 is suitable for the voice-over-IP application.

Voice traffic is routed through the end office, encapsu-

lated in RTP/UDP/IP in the ITS gateway, and carried

through an IP session in the IP core network. The

gatekeeper performs the translation between SS7 and

the IP session management protocol to set up sessions

dynamically for carrying the voice traffic. The ITS gate-

way, gatekeeper, and edge router contribute to the

voice edge function.

The lower half of Figure 4 is the same as the IP

network architecture supporting data services. Data

IP edgerouter

IP edgerouter

Tokenring

CPE ATMSW

CPE FRSW

Signaling trafficApplication trafficPossible traffic

SCP


SS7network


IP backbone

IP edgerouter

IP corerouter

IP corerouter

IP corerouter

IP edgerouter

Tokenring

CPE ATMSW

CPE FRSW

ITSgateway

Gatekeeper

ITSgateway

Customer router

ATM – Asynchronous transfer modeCPE – Customer premises equipmentFR – Frame relayIP – Internet protocolITS – Internet telephony server/gatewaySCP – Station control programSS7 – Signaling System 7SW – Switch

Gatekeeper

IP corerouter

Figure 4.Integrated IP backbone architecture.


traffic is carried through the customer premises equip-

ment (CPE) to the IP edge router, then transferred

through the IP core network.

Analysis of Voice and Multiservice Network DesignsIn this section, we discuss and detail some spe-

cific examples of the transmission of voice over

ATM networks, as well as multiservice over ATM

and IP networks.

Voice over ATM Network Design ExamplesThe following two subsections explain our VTOA

studies and give an example of a VTOA network

design for a new long-distance carrier.

VTOA studies. Our VTOA studies explore the eco-

nomic benefits of providing voice and telephony ser-

vices over ATM. These studies cover four types of

service providers: incumbent local exchange carriers

(ILECs), competitive local exchange carriers (CLECs),

existing long-distance carriers (LDCs), and new LDCs.

For each type of service provider, the VTOA network

design was performed in two cases: one in which voice

traffic is carried through PVC connections using AAL-2

with voice compression and silence suppression, and

another in which voice traffic is carried through SVC

connections using AAL-1 CES. In addition, a baseline

TDM network design was included for each service

provider type for the purpose of comparison with the

ATM designs.

It should be noted that the VTOA network designs

performed in the study employed different sets of traf-

fic data, network constraints, and architectural

assumptions specific to the particular service provider’s

environment. As a result, the consequent economic

benefits of VTOA drawn from these studies vary from

one service provider type to another. The results of

VTOA network designs for the new LDC case are pre-

sented in the following subsection. A detailed discus-

sion on VTOA, along with results for some other

service provider cases, is also available.3-5

A VTOA network design example for a new

long-distance carrier. The objective in this example

is to design an ATM network for a new LDC—that is,

to build a cost-optimized ATM backbone network

capable of interconnecting voice toll switches and

having sufficient capacity to allow the switches to

carry voice traffic. The design of the network is based

on the following assumptions:

• Voice traffic carried in the PVC AAL-2 case is

compressed using G.72712 at 32 kb/s per

channel.

• The ATM backbone is built using a leased

facility with ATM switches being intercon-

nected via T3s, while ATM and toll switches

are interconnected via T1s.

• Lucent’s MX 1000TM multiservice ATM switch

is selected as the ATM backbone switch, and its

equipment and cost models are used for net-

work design.

• One signaling gateway can support three MX

1000 switches.

• To enhance network survivability, 20% of net-

work bandwidth is reserved.

The new LDC and the network designers agreed

on a set of traffic forecasts for the years 1999 to

2002 in terms of the numbers of voice trunks

(DS0s) that are required between each pair of toll

switches. Table I gives a partial list of such traffic

demands for the year 1999. These traffic demands

are converted to the equivalent ATM bandwidth

requirements as previously described in the “Packet

Network Design Methodology” section. The

required ATM bandwidth is specified as VBR-rt for

voice traffic carried by PVC/AAL-2 and as CBR for

voice traffic carried by SVC/AAL-1.

Implementing the methodology described in the

“Packet Network Design Methodology” section, a

VTOA network design is created through preprocess-

From node To node Demand (DS0)

A E 672

A H 672

A K 552

B D 480

C F 432

C I 672

C J 648

D F 648

D G 672

Table I. VTOA traffic demands among toll switches for theyear 1999 (partial list).


ing of input with shell scripts, spreadsheets, and awk

programs, followed by processing using a network

design tool. Figure 5 illustrates the baseline TDM net-

work topology generated for comparison. Figures 6

and 7 depict the topologies of the two VTOA net-

works. The number of T3s in the ATM designs are dif-

ferent (44 for PVC and 108 for SVC) from the TDM

network (57), affecting facility costs.

Figure 8 provides a cost analysis of the VTOA net-

work design outputs. These costs are displayed in the

bar charts as a relative percentage of the total cost of

the TDM network design. Note that the AAL-1 SVC

facility cost is highest and the AAL-2 PVC cost is low-

est. The primary reason for this cost difference is that

AAL-1 adds extra overhead for the TDM circuit, and

according to our assumption, AAL-2 uses 32-kb/s

voice compression. The economic benefit of ATM is

clear for PVC AAL-2 since the leased facility cost repre-

sents most of the total network cost in the new LDC

case. This ATM benefit is enhanced even more by the

year 2000 due to increased traffic and to the purchase

of additional leased lines.

Figure 9 plots facility utilization by the separate

TDM and ATM networks as a percentage of facilities

employed by TDM. Notice that facility utilization repre-

sents the network capacity allocated exclusively to

voice traffic and that it differs from the actual band-

width consumed by the voice traffic that varies during

the day. The varying facility utilization curve shows the

benefit of ATM SVC in that network capacity, which is

allocated dynamically to the voice traffic, can be made

available during nonbusy hours for data traffic.

Multiservice over ATM and IP Network Design ExamplesThe VTOA analysis provides the motivation for

performing multiservice design. It is expected that if

data service traffic is interleaved in the same

packet/cell network with packetized voice, the links

will be used much more efficiently due to statistical

multiplexing gain. We design such networks with real-

life examples and provide the results in this section to

elaborate on how the backbone network design can be

Figure 5.Baseline TDM network design for the year 1999.

Figure 6.PVC/AAL-2 network design for the year 1999.

0.900.750.500.250.00

Link use

0.900.750.500.250.00

Link use

Figure 7.SVC/AAL-1 network design for the year 1999.


improved by means of multiple service applications.

We discuss two network design cases: ATM net-

work and IP network designs for handling a forecasted

mix of both voice and data traffic. The network com-

prises 31 data edge nodes and 53 voice edge nodes.

Based on the voice and data traffic demands between

each pair of nodes, five backbone nodes are selected

using a design tool. Figure 10 illustrates the network’s

topology, and Table II lists the aggregated backbone

voice and data traffic. The five backbone nodes are

labeled A, B, C, D, and E. The voice traffic unit is in

DS0 and the data traffic unit is in average Mb/s. All

voice and data traffic in Table II is represented as

bidirectional traffic demands. For brevity, we discuss

only the 1999 backbone network in the next two sub-

sections, although we include the results of both the

1999 and 2003 networks. In addition, we show the

sensitivity analysis for both years in the “Design

Comparisons and Sensitivity Analysis” subsection.

In this study, we compare the facility cost and the

backbone equipment port requests between the ATM

and IP networks. Both voice and data traffic studied

here use the traffic projections for 1999 and 2003. In

the end, we implement the sensitivity analysis for the

varying voice traffic projections for both years.

In developing the design, we assumed the following:

• All trunks are OC3 links and the access

trunks between edge and backbone nodes

are DS3 links.

140

120

100

80

60

40

20

0

Perc

ent

TDM PVCAAL-2

SVCAAL-1

Year 1999

TDM PVCAAL-2

SVCAAL-1

Year 2000

120

100

80

60

40

20

0

Perc

ent

Leased facility

Equipment

Total

Percent normalized facility cost:AAL – ATM adaptation layerATM – Asynchronous transfer modePVC – Permanent virtual circuitSVC – Switched virtual circuitTDM – Time division multiplexer

Figure 8.Cost analysis of VTOA network designs for the years 1999 and 2000.

120

100

80

60

40

20

0

Uti

lizat

ion

(%

)

TDM

ATM PVC AAL-2

115.6

26

ATM SVC AAL-1

0 3 6 9 12 15 18 21 24

Hour of the day

AAL – ATM adaptation layerATM – Asynchronous transfer modePVC – Permanent virtual circuitSVC – Switched virtual circuitTDM – Time division multiplexer

Figure 9.Facility utilization by TDM and ATM networks.


• Voice traffic is aggregated at the tandem switch

using the SAC function before entering the

ATM/IP backbone nodes.

• Average data traffic is two times higher than

voice traffic entering the ATM/IP network in

1999 and 11 times higher in 2003.

• Data traffic is aggregated at the edge data

MUX nodes.

ATM network design. We made the following

additional assumptions for the ATM backbone design:

Backbone node

Edge voice/data node

OC3 backbone trunk

DS3 edge link between edge and backbone nodes

A

C

D

E

B

Figure 10.Example network topology.

Source Destination 1999 voice (DS0) 2003 voice (DS0) 1999 data (Mb/s) 2003 data (Mb/s)

A A 8,006 27,119 364.3181 6,695.504

A B 439 1,216 0 280.3448

A C 1,835 5,868 640.5716 10,592.45

A D 488 1,300 0 337.0437

A E 1,052 3,002 297.69 4,073.321

B B 2,688 8,833 27.34743 459.0523

B C 1,254 3,727 458.5664 6,988.412

B D 907 2,607 130.2304 2,340.194

B E 755 2,380 338.4423 6,382.014

C C 5,827 19,488 389.3958 6,362.266

C D 1,194 3,808 904.8173 13,150.9

C E 1,575 4,914 991.3918 13,797.29

D D 2,371 7,318 69.87741 1,070.39

D E 571 1,557 628.1674 9,208.641

E E 9,205 32,421 419.8459 8,203.446

Table II. Voice and data traffic matrix in ATM or IP backbone networks.


• Voice traffic is handled through the AAL-1 cir-

cuit emulation PVC service without any com-

pression, while data traffic is carried through

the AAL-5 PVC service.

• Trunk capacity of 10% is reserved for ATM

network management and signaling channels.

• Associated transport overhead for voice traffic

over AAL-1 is about 12.7%, while for data

traffic using LLC/SNAP and AAL-5, it is about

25% using typical packet size distributions in

the Internet.24

In this subsection, two network design scenarios

are covered. The first scenario develops ATM network

designs to handle voice and data traffic separately (the

upper and lower network halves in Figure 3). The sec-

ond scenario uses an integrated ATM network to han-

dle both voice and data (the entire network in Figure

3). Table III compares the number of trunks required

in both scenarios. An integrated ATM network

requires about 20% fewer trunks and trunk ports than

the segregated data and voice ATM networks require.

Figure 11 compares the normalized facility costs

for the two different networks. We present the costs

with respect to a base total cost in the segregated case.

The backbone trunk facility cost saving of the inte-

grated ATM network over the segregated voice and

data ATM network is about 20%. The total facility cost

saving is about 5%.

IP network design. For the IP network design, we

make the following additional assumptions:

• Voice traffic is handled with no compression

through the RTP/UDP/IP packet. Data traffic

is carried over the PPP to the IP backbone

network.

• Trunk capacity of 10% is reserved for IP ses-

sion control/network management traffic.

• Overhead to encapsulate voice over

RTP/UDP/IP is 50%, while the PPP overhead

for IP data traffic is 4%.

• IP router supports real-time services (for

instance, Lucent’s PacketStar core router sup-

ports priority differentiation of services).

In this subsection, two network design scenarios

are covered. The first scenario designs an IP backbone

Source DestinationNumber of OC3 trunks Number of OC3 trunks

node noderequested for voice (ATM) requested for integrated

and data (ATM) ATM backbone

A C 7 5

A B 0 1

A E 3 2

D B 2 1

D E 5 4

C D 8 7

C B 5 4

C E 9 7

B E 4 3

Totals 43 34

Table III. ATM trunk request comparisons between scenarios.

1.0

0.8

0.6

0.4

0.2

0ATM

voice + dataATM

integrated

No

rmal

ized

fac

ility

co

st

Access Trunk Total

ATM – Asynchronous transfer mode

Figure 11.Normalized facility costs for segregated ATM and inte-grated ATM networks.


network to handle voice and data traffic separately

(the upper and lower half networks in Figure 4). The

second scenario designs an integrated IP backbone net-

work to handle both voice and data (the entire net-

work in Figure 4). Table IV compares the number of

trunks required between the two scenarios. The num-

ber of trunks required in the integrated IP network is

reduced by about 20% compared to those required in

the segregated data and voice IP network.

Figure 12 compares the normalized facility costs

for the two different networks. Again, we present the

costs with respect to a base total cost in the segregated

case. As in the previous design scenarios, the backbone

trunk cost saving of the integrated IP network over the

sum of the segregated data and voice IP network is

about 20%. Total facility cost saving is about 5%.

Design comparisons and sensitivity analysis.Many service providers currently have separate voice

(TDM) and data (ATM or IP) backbone networks. In

this subsection, we compare the trunk facility costs for

the current segregated networks (TDM plus separate

data ATM or data IP networks) and integrated net-

works over either ATM or IP. Figures 13 and 14 com-

pare the trunk facility costs for the four different

network scenarios derived from our designs with 1999

and 2003 data, respectively. We observe that because

the ratio of data to voice traffic in 2003 is much higher

than in 1999, the integrated IP trunk facility cost in

2003 is lower than that for the ATM network, while

the IP trunk facility cost is higher than that for the

ATM network in 1999. The reason for these cost dif-

ferences is that ATM adds less overhead for voice traf-

fic than the IP network, but it adds more overhead for

IP data traffic than the IP network.

In addition, we analyzed how the ratio of data to

voice traffic affects the two types of backbone facility

costs. Figures 15 and 16 chart the normalized total

facility costs (access plus backbone). From the figures,

we can observe that when voice traffic increases, the

ATM backbone is more cost effective than the IP back-

bone as far as facility costs are concerned. Note that

these results pertain only to facility costs and do not

include operations and equipment costs.

Source DestinationNumber of OC3 trunks Number of OC3 trunks

node noderequested for voice (IP) requested for integrated

and data (IP) IP backbone

A C 7 5

A D 1 1

A E 3 3

B E 3 2

C B 4 4

C D 7 6

C E 8 7

D B 3 2

D E 5 4

Totals 41 34

Table IV. IP trunk request comparisons between scenarios.

1.0

0.8

0.6

0.4

0.2

0IP

voice + dataIP

integrated

No

rmal

ized

fac

ility

co

st

Access Trunk Total

IP – Internet protocol

Figure 12.Normalized facility costs for segregated IP and integratedIP networks.


1.0

0.8

0.6

0.4

0.2

0N

orm

aliz

ed f

acili

ty c

ost

Voice (TDM)+ data (ATM)

Voice (TDM)+ data (IP)

IntegratedATM

IntegratedIP

ATM – Asynchronous transfer modeIP – Internet protocolTDM – Time division multiplexed

Figure 13.Normalized 1999 backbone trunk facility cost comparisons.

Figure 14.Backbone trunk facility cost comparisons for 2003.

ATM – Asynchronous transfer modeIP – Internet protocolTDM – Time division multiplexed

1.0

0.8

0.6

0.4

0.2

0

No

rmal

ized

fac

ility

co

st

Voice (TDM)+ data (ATM)

Voice (TDM)+ data (IP)

IntegratedATM

IntegratedIP

Figure 15.Trunk facility cost sensitivity for 1999.

1.0

0.5

0No

rmal

ized

fac

ility

co

st

1.0 1.5 2.0 4.0

Asynchronous transfer mode (ATM)Internet protocol (IP)

Voice traffic increasing ratio

Figure 16.Trunk facility cost sensitivity for 2003.

1.0

0.5

0No

rmal

ized

fac

ility

co

st

1.0

Voice traffic increasing ratio

1.5 2.0 4.0 8.0 16.0

Asynchronous transfer mode (ATM)Internet protocol (IP)


SummaryWith the growth in Internet and data services, it

is generally accepted among telecommunication ser-

vice providers that the underlying network must be

packet based. What is not yet clear is the relative mer-

its of the different packet technologies in providing

multiple services with varying traffic demands and

distinct levels of desired network performance to sat-

isfy customers. All voice telephony service providers

are interested in understanding the business aspects of

transporting their revenue-generating services to a

network based on ATM or IP technology. As we

pointed out, some important aspects must be consid-

ered in making these decisions.

The VTOA analysis presented here identified sav-

ings opportunities in the backbone network. The mod-

eled network takes into account a real network plan

and traffic forecasts for a long-distance backbone net-

work. The results indicate that even after considering

the expense of additional equipment, costs can be

moderated through better use and by fewer facility

trunks using AAL-2 PVC with compression. In the case

of an ATM SVC network, the access part of the net-

work consisting of links with lower use may offer bet-

ter savings opportunities in the backbone.25

Our analysis was extended to networks supporting

multiple services to investigate if data and voice service

mixes offer further opportunities for savings. In this

case, we modeled an end-to-end network having

access equipment, backbone equipment, and facilities.

The results indicate that the packet networks (both

ATM and IP) offer network savings opportunities, pri-

marily due to the inherent statistical multiplexing and

processing of payload in the packet networks. Cost of

the designed packet network in favor of IP or ATM is

greatly dependent on the ratio of data-to-voice traffic

carried over the network.

Our analysis did not include all network condi-

tions. Technologies and protocols will be improved

constantly over time providing further incentives for

transitioning to a multiservice packet network. Still,

this analysis shows the potential values and differentia-

tors of packet networks. It provided methods for assess-

ing the merits of ATM and IP networks and establishes

guidelines for technology choice and transition.

AcknowledgmentsThe authors thank Bell Labs researchers Bill

Byrne, Enrique Hernandez-Valencia, Brian Murphy,

Les Spindel, Vish Subramanian, Charles Vincelette,

and Dale Wisler for their valuable comments and con-

tributions in related projects.

References1. J. Heinanen and T. Finland, “Multiprotocol

Encapsulation over ATM Adaptation Layer 5,”RFC 1483, IETF, July 1993.

2. W. Simpson, “The Point-to-Point Protocol(PPP),” RFC 1577, IETF, Dec. 1993.

3. M. S. Chambers, H. Kaur, T. G. Lyons, andB. P. Murphy, “Voice over ATM,” Bell Labs Tech. J.,Vol. 3, No. 4, Oct.–Dec. 1998, pp. 176–191.

4. V. Fineberg and B. Y. C. Tang, “VoiceTelephony over ATM in a CLEC Network:Economic Study,” ATM Year 98 Europe,London, U.K., Sept. 15, 1998.

5. B. Y. C. Tang and R. Arias, “Voice andTelephony over ATM,” ATM Year 98 Europe,London, U.K., Sept. 15, 1998.

6. “B-ISDN ATM Adaptation Layer Specification:Type 1 AAL Overall Network Aspects andFunctions – Protocol Layer Requirements –Series I: Integrated Services Digital Network,”Study Group 13, ITU-T RecommendationI.363.1, Sept. 1996.

7. “Voice and Telephony over ATM – ATMTrunking Using AAL-1 for Narrowband ServicesVersion 1.0,” ATM Forum, af-vtoa-0089.00,July 1997.

8. “Specifications of (DBCES) Dynamic BandwidthUtilization – In 64KBPS Time Slot Trunkingover ATM – Using CES,” ATM Forum, af-vtoa-0085.000, July 1997.

9. “Circuit Emulation Service InteroperabilitySpecification, Version 2.0,” ATM Forum, af-vtoa-0078.000, Jan. 1997.

10. “B-ISDN ATM Adaptation Layer Type 2Specification,” ITU-T Recommendation I.363.2,Sept. 1997.

11. J. H. Baldwin, B. H. Bharucha, B. T. Doshi,S. Dravida, and S. Nanda, “AAL-2—A NewATM Adaptation Layer for Small PacketEncapsulation and Multiplexing,” Bell LabsTech. J., Vol. 2, No. 2, Spring 1997, pp. 111–131.

12. “5-, 4-, 3- and 2-bits Sample EmbeddedAdaptive Differential Pule Code Modulation(ADPCM),” Study Group 15, ITU-TRecommendation G.727, Dec. 1990.

13. “Coding of Speech at 8 kb/s Using Conjugate-Structure Algebraic-Code-Excited Linear-


Prediction (CS-ACELP) – General Aspects ofDigital Transmission Systems,” Study Group 15,ITU-T Recommendation G.729, Mar. 1996.

14. “Dual Rate Speech Coder for MultimediaCommunications Transmission at 5.3 and 6.3kbit/s, Annex A: Silence Compression Scheme –Series G: Transmission Systems and MediaDigital Transmission Systems – TerminalEquipments – Coding of Analogue Signals byMethods Other Than PCM,” Study Group 15,ITU-T Recommendation G.723.1, Dec. 1996.

15. “ATM Trunking Using AAL-1 for NarrowbandServices,” ATM Forum, af-vtoa-0089.000, July 1997.

16. “ATM Trunking Using AAL-2 for NarrowbandServices,” ATM Forum, btd-vtoa-lltaat2, (work in progress).

17. B. Y. C. Tang, K. P. Das, B. P. Murphy, “AnAnalysis on the Design of Voice over IP Networks,”Eighth International Telecommunication Net-work Planning Symp., Sorento, Italy, Sept. 1998.

18. “Visual Telephone Systems and Equipment forLocal Area Networks which Provide a Non-Guar-anteed Quality of Service – Series H: Audiovisualand Multimedia Systems Infrastructure of Audio-visual Services – Systems and Terminal Equip-ment for Audiovisual Services,” Study Group15, ITU-T Recommendation H.323, Dec. 1996.

19. “Media Stream Packetization andSynchronization on Non-Guaranteed Quality ofService LANs – Series H: Transmission of Non-Telephone Signals – Infrastructure of Audio-visual Services – Transmission Multiplexing andSynchronization,” Study Group 15, ITU-TRecommendation H.225.0, Dec. 1996.

20. “Control Protocol for MultimediaCommunication – Series H: Audiovisual andMultimedia Systems Infrastructure of Audio-visual Services – Communication Procedures,”Study Group 15, ITU-T RecommendationH.245, Apr. 1996.

21. “Security and Encryption for H-Series (H.323-and other H.245-based) Multimedia Terminals,”ITU-T Draft Recommendation H.235, Sept. 1997.

22. P. Busschbach, “The Future of Transport Net-works,” Lucent Technologies Data ArchitectureWhite Paper, Murray Hill, NJ, Jan. 1998.

23. M. Laubach, “Classical IP and ARP over ATM,”RFC 1577, IETF, Jan. 1994.

24. Z. Chen and E. Hernandez-Valencia, “ATMNetwork Designs and Performance Analysis forIntegrated Voice and Data Traffics,” Proc. SixthIFIP Workshop on Performance Modeling andEvaluation of ATM Networks, (IFIP ATM ‘98), West Yorkshire, U.K., July 1998.

25. Z. Chen, “PVC/SVC ATM Network Designs forVoice Traffic,” Proc. Sixth IFIP Workshop onPerformance Modeling and Evaluation of ATMNetworks, (IFIP ATM ‘98), West Yorkshire, U.K.,July 1998.

(Manuscript approved December 1998)

ZHENG CHEN is IP product manager in the IP NetworkingProduct Management Department at LucentTechnologies in Holmdel, New Jersey. Shehas B.S. and M.S. degrees from the NanjingUniversity of OSTS and Telecommunicationsin the P.R.C., as well as a Ph.D. from Cornell

University in Ithaca, New York, all in electrical engineer-ing. Currently, Dr. Chen is responsible for IP product lineplanning and consulting for AP/China customers.Previously, she designed data networks based on ATMand IP technologies as a member of technical staff in theNetwork Planning and Design Center at Bell Labs. Beforejoining Lucent, Dr. Chen worked on interspan ATM ser-vice and IP service planning.

KAMALA P. DAS, formerly a distinguished member oftechnical staff, currently is a technical man-ager in the Next-Generation NetworkSystems Engineering Department at BellLabs in Holmdel, New Jersey. He has anM.S. degree in physics from the University

of Delhi in India, as well as an M.S. in computer andinformation science and a Ph.D. in physics, both fromthe University of Oregon in Eugene. Dr. Das is inter-ested in data network planning and design for ATMand IP-based networks. His area of research providesanalysis of architecture alternatives, network evolutionplanning, and network design services to national andinternational service providers. In addition, he focuseson the systems engineering of new data service offers,such as virtual private networks.

BENJAMIN Y. C. TANG is a member of technical staff inthe Next-Generation Network SystemsEngineering Department at Bell Labs inHolmdel, New Jersey. He has a B.S. degreefrom the National Taiwan University inTaipei, P.R.C, an M.S. from the University of

Florida in Gainesville, and a Ph.D. from PurdueUniversity in West Lafayette, Indiana. Dr. Tang’s areaof research centers on data network planning anddesign, as well as on next-generation systems engi-neering, performance, reliability, operations, data ser-vices, and offers. ◆

Documents

Voice and multiservice network design over ATM and IP networks