Voice over IP (VoIP) for Enterprise Networks:
`Performance Implications & Traffic Models
`
`P.M. Fiorini
`BMC Software
`pierre_fiorini@bmc.com
`
`ABSTRACT
`
`Voice over Internet Protocol (VoIP) is a rapidly emerging technology. Currently, the Internet is being
`wired to support voice and fax traffic. The widespread interest in VoIP is not necessarily the ability of IP to
`carry voice traffic but the ability to carry voice and fax traffic over data networks. The implications of this
`are far-reaching. That is, the Internet, for the most part, will eventually replace the PSTN (Public Switched
`Telephone Network). Furthermore, VoIP will play a major role in e-commerce applications such as IP-
`based call centers. More importantly, by running intra-company inter-site voice/fax over its IP data
`network, a company can expect to reduce telephony1 costs by 70%-80%. In this paper, we discuss VoIP
`technology and its implications. In addition, we present traffic models to explore the performance
`implications of VoIP upon enterprise networks.
`
`Introduction
`
`Voice over Internet Protocol (VoIP) is the
`transmission of voice and fax traffic in
`packets over IP-based networks. There are
`many terms commonly used to describe this
`technology such as Internet Telephony, IP
`Telephony, etc. Interestingly, IP Telephony
`is viewed by some as a simply a means to
`place “free”
`telephone calls using
`the
`Internet; however, it is much more than that.
`In this paper, we discuss the importance of
`modeling VoIP for enterprise networks. We
`discuss how VoIP can be deployed and its
`increasing
`role
`in enterprise networks.
`Performance models that characterize VoIP
`traffic are presented and discussed.
`
`The Public Switched Telephone Network
`
`The Public Switched Telephone Network
`(PSTN) has become
`an
`“Intelligent
`Network” (IN). This means that the network
`has the capability to use real-time database
`information to route telephone calls. Using
`information retrieved from data stores, the
`
`the
`lists some of
`following
`services that can be performed:
`
`telephony
`
`(cid:34) Toll-free calling - Facilitates toll-free
`telephone services and proper billing.
`(cid:34) Wireless roaming - Enables wireless
`telephony via a series of networks.
`(cid:34) Calling Cards – Enables
`telephony
`services and proper billing.
`(cid:34) Local portability – Allows telephone
`users to change local carriers.
`(cid:34) Call Waiting – Notifies a calling party
`that another party is calling when the
`calling party’s line is utilized.
`(cid:34) Caller ID – Enables a caller to be
`identified.
`(cid:34) Pagers – Supports the abilities for
`callers
`to page subscribers of
`this
`service
`
`IN services are controlled by the Signaling
`Number Seven (SS7) protocol in the PSTN.
`SS7
`is a
`layered protocol and
`its
`functionality is encapsulated in its software
`layers. The ISDN user part (ISUP) layer is
`
`1 Telephony, be it IP-based or conventional, can be defined as the science of transmitting voice, data, video,
`or image signals over physical or wireless communication networks.
`
`GOOGLE 1025
`
`1
`
`

`

`Figure 1. An Intelligent Network Architecture
`
`Phone
`
`SSP
`
`SSP
`
`SSP
`
`Phone
`
`SCP
`
`STP
`
`STP
`
`SCP
`
`Phone
`
`SSP
`
`SSP
`
`SSP
`
`Phone
`
`used for setting up and tearing down phone
`calls while
`the
`transaction
`control
`application part (TCAP) layer is used for
`exchanging real-time database information.
`Consequently, the ability to support IN
`services in the PSTN necessitates both ISUP
`and TCAP support.
`
`Figure 1 illustrates the basic architecture of
`an IN. Signal switching points (SSPs) are
`telephone
`switches
`that
`initiate
`and
`terminate SS7 messages and signal transfer
`points (STPs) are devices that route SS7
`messages within
`the network. Service
`control points (SCPs) are database servers
`that provide real-time data information for
`IN services. The PSTN is known for its
`reliability and quality of service (QoS).
`Voice and data traffic is carried on dedicated
`connections (switched circuits) and
`the
`entire bandwidth is available during a call.
`As the utilization of the network increases, it
`is more likely that users will experience
`busy signals; however, performance will not
`degrade since bandwidth for a call is always
`guaranteed. This fundamental aspect of the
`PSTN is what distinguishes it from IP
`networks.
`
`The architecture in the PSTN is very reliable
`since
`the
`SS7
`protocol
`provides
`functionality in the event of link and node
`failures.
`In
`these cases, SS7 chooses
`alternate routes and/or facilitates message
`re-transmissions to make sure voice and data
`reach their destinations.
`
`Voice over IP
`
`A result of the tremendous growth of the
`World Wide Web (WWW) the Internet
`Protocol (IP) has become the de facto
`standard for data networking [BLAC00].
`Unlike the circuit-switched technology of
`the PSTN, IP networks are packet switched
`and network bandwidth is shared by all
`users. A consequence of this is that when the
`network gets more utilized, it is more likely
`to experience performance degradation.
`Although PSTN and
`IP networks are
`fundamentally different in terms of their
`architectures, it is possible for the networks
`to be integrated; that is, exchanging voice
`and data
`traffic. Figure 2 depicts one
`topology to achieve this integration.
`
`To see how this works suppose a subscriber
`connected to an SSP places a long-distance
`call though the PSTN. Voice traffic is routed
`though an intermediary toll SSP and there
`can be many hops involved when routing a
`call. The SS7 protocol is utilized to reserve
`voice trunks from one hop to the next and to
`set up the phone call. VoIP offers an
`alternative approach. A call is placed to an
`IP Telephony switch that digitizes and
`compresses
`the voice
`traffic
`into data
`packets and then sends this information
`across the IP network. SSPs on both ends of
`the call communicate with their respective
`IP Telephony switches (IPTS) using ISDN
`connections that include both voice and
`signaling information. Calls can be initiated
`or terminated on either the PSTN or the IP
`network. On IP networks, users send and
`receive voice using an IP Telephony
`
`2
`
`

`

`Figure 2. An Example of Integrating an IP network with the PSTN.
`
`Phone
`
`SSP
`
`SSP
`
`SSP
`
`Phone
`
`IPTT
`
`SCP
`
`STP
`
`STP
`
`SCP
`
`Internet
`
`IPTS
`
`IPTS
`
`SSP
`
`SSP
`
`Phone
`
`terminal (IPTT), which is a computer (i.e.
`usually a PC) that runs telephony software.
`
`devices
`network, VoIP
`IP
`an
`On
`using
`either
`proprietary
`communicate
`protocols or one of the emerging standards
`such as H.323 or MGCP (Media Gateway
`Control Protocol). Because of the lack of
`fully defined
`standards,
`initial VoIP
`products mandated gateways from the same
`vendor exist on both sides of the IP network.
`Recently, however, examples of multivendor
`interoperability (based on H.323) have
`appeared. Presently, VoIP products are
`limited in their functionality since, for the
`most part, basic call setup and call tear down
`is possible; however, IN services are only
`starting to appear (e.g. call waiting). In any
`event, it is only a matter of time until most
`or all IN services are available via VoIP
`products.
`
`4. Applications of VoIP Technology
`
`Currently, the primary application of VoIP
`has been to transport voice and fax calls
`over an IP network to save on long-distance
`charges. Other applications are beginning to
`emerge and incorporate IP voice and fax
`into telephony applications for enhanced
`network services (e.g.
`INs). These two
`objectives are the primary focus in main
`VoIP
`market
`applications.
`Some
`applications of VoIP are listed as follows
`[MICO99]:
`
`4.
`
`5.
`
`1. Toll-Free
`Telephony
`Corporate
`Services– Toll-free intra-company voice
`and fax between corporate locations.
`2. Fax over IP – Toll-free or reduced rate
`fax-machine
`fax between any
`two
`locations.
`3. PC-phone to PC-phone – Toll-free voice
`between any two PC’s on the Internet.
`IP-Based Public Phone Service – New
`public phone services, at reduced rates
`(especially international calls), where
`voice is sent over the Internet or over
`new public IP networks.
`These
`–
`IP-Based Call-Centers
`applications allow PC users at home
`with
`their browsers
`to click on a
`telephone icon in a catalog at a customer
`service Web page that enables he/she to
`an agent via the PC as a phone.
`IP Line Doubler – A PC user at home or
`in a hotel with just one connection to the
`Internet could subscribe to a new service
`that facilitates a single phone line to
`carry one or more phone calls
`in
`addition to data.
`
`6.
`
`Note that applications 1, 4, and 6 rely on an
`emerging
`communications
`technology
`known as a Voice/Fax IP gateway. A VoIP
`gateway converts analog voice and fax into
`IP packets. Application 3 does not use an IP
`gateway since PCs perform the gateway
`functionality. In other words, the PC has a
`sound card, speakers and microphones, or a
`phone card with a telephone. Thus, the PC
`performs voice packetizing. PC-fax is just
`
`3
`
`

`

`data so only a fax-machine needs a gateway.
`For the most part, apart from gateways, most
`telephony technology is software driven
`[MICO99].
`
`Since toll-free corporate telephone services
`has been the fastest to mature and be
`adapated, we will discuss this area further.
`The popularity of
`the IP protocol
`in
`corporate data networks has
`increased
`tremendously
`recently.
`Networking
`managers have adapted IP as the protocol
`foundation for their networks since most any
`type of corporate network can be built upon
`IP. The reason is that it scales to millions of
`nodes and users. More importantly, by
`running intra-company, inter-site voice/fax
`over its IP data network, a company can
`expect to reduce telephony costs by 70%-
`80% [MICO99].
`
`5. VoIP Voice Quality
`
`There are several technologies to ensure
`good voice quality. They will be described
`in turn by the following:
`
`(cid:34) Echo Cancellation – When a telephone
`cable connects to, say, a Private Branch
`Exchange
`(PBX)
`interface
`or
`a
`telecommunications company central
`office (CO), a special electrical circuit
`called a hybrid is used for the signal
`conversion. Although hybrid circuits are
`efficient in their conversion ability, a
`small percentage of telephony energy is
`not converted but instead reflected back
`to the caller. This is referred to as echo.
`If the caller is near the PBX or CO
`switch, the echo it is not discernible.
`However, this may not always be the
`case. To
`prevent
`this
`gateway
`manufacturers include special code in
`Digital Signal Processors (DSPs) that try
`to cancel the echo.
`(cid:34) Network Delay & Jitter – IP packet
`delay and network jitter is responsible
`for reduced voice quality on VoIP
`networks. Network delay is the average
`length of time for a packet to travel in a
`network. Network jitter describes the
`
`variability in arrival time of a packet.
`When a voice packet is delayed and
`does not arrive at the destination time to
`fit into the voice stream going out of the
`destination gateway, it is discarded, and
`the previous packet is replayed. If this
`happens too often, the listener will
`perceive reduced voice quality.
`(cid:34) VoIP Packet Prioritization – VoIP
`works well over a corporate IP network
`because the network can be optimized
`for low VoIP packet jitter and low
`delay. This
`results
`from corporate
`routers prioritizing voice packets. The
`router is instructed to look for voice IP
`packets and put them ahead of any data
`packets waiting in the router’s transmit
`queue. This way, a stream of outgoing
`packets will not add to the variability of
`the arrival time of voice packets. The
`router
`is
`instructed
`to prioritize
`voice/fax IP packets either by
`the
`network
`administrator
`explicitly
`programming the router to look for the
`gateway’s UDP port number, or by
`using a prioritization protocol called
`RSVP. When the gateway determines it
`needs to receive a voice/fax call, it
`establishes an RSVP session with the
`router using
`the LAN
`to pass
`information. The gateway instructs the
`router to prioritize such packets for the
`duration of the call.
`(cid:34) IP Packet Segmentation – This method
`is used to ensure that large data packets
`do not delay voice packets from exiting
`the router in a timely manner. This is
`achieved by programming the router to
`segment all outbound data packets
`according the speed of the WAN access
`link.
`
`6. VoIP Standards
`
`H.323 is a set of standards defining real-time
`multimedia
`communications
`and
`conferencing over packet-based networks. It
`is a standard choice for VoIP. Version 1 of
`the H.323 protocol was first accepted by the
`ITU-T in 1996; however, the IETF is still
`debating a few alternative standards. For the
`
`4
`
`

`

`most part, the market place has already
`adapted the H.323 standard. Version 2 of
`H.323 was adapted in 1998 and basically
`comprises
`four
`components
`and
`are
`discussed below:
`
`(cid:34) Terminals – Terminals provide real-time
`communications. They must support
`voice
`communications. The most
`common H.323 terminals are telephony
`applications
`(e.g.
`Microsoft’s
`NetMeeting that runs on a PC).
`(cid:34) Gateways – H.323 gateways provide
`services to H.323 clients so that they can
`communicate with non-H.323 terminals
`and telephones on the circuit-switched
`network. The gateway must provide
`translation
`between
`different
`transmission formats, communication
`procedures, and audio codecs.
`(cid:34) Gatekeepers – Gatekeepers provide call
`control services for H.323 end-points
`such
`as
`address
`translation
`and
`bandwidth management. Gatekeepers
`are optional. If they are present in a
`network, however, endpoints must use
`their services. The H.323 standards
`define mandatory
`services
`that a
`gatekeeper must provide.
`(cid:34) Multipoint Control Units (MCUs) –
`They provide support for conferences of
`three or more endpoints. An MCU
`manages conference
`resources and
`negotiations between endpoints for the
`purposes of determining the audio or
`video codec to use. Sometimes, it also
`handles the media stream.
`
`Unfortunately, at the present time, most
`VoIP products are not Version 2 compliant
`and most
`implementations are missing
`important aspects of the H.323 standard
`[WILL99]. For
`instance,
`security
`is
`available; that is, authentication, encryption,
`and integrity. However, products do not
`need to offer security to be H.323 compliant.
`Without security, it is easy via packet
`analyzers to eavesdrop on conversations
`wherever packets pass. Some protocol
`analyzers can be configured to detect VoIP
`streams and play them back as audio files.
`
`As mentioned previously, the gatekeeper
`function
`is optional. Essentially,
`the
`gatekeeper provides mechanisms to prevent
`the system being overloaded with voice (and
`video)
`calls.
`It
`also
`provides
`call
`management, signaling, and overall system
`control. The VoIP gatekeeper is significant
`for real system management. Without the
`gateway, instead of receiving a busy signal,
`endpoints submit packets to the network
`without guarantees of anything. As a result,
`audio and video packets can overflow
`network devices. In addition to the H.323 set
`of standards, the Internet Engineering Task
`Force (IETF) is developing specifications
`that will facilitate IP networks to handle
`voice calls as reliably as the PSTN in the
`future. The IETF is considering whether to
`preserve
`the PSTN’s native
`signaling
`protocols, including SS7, or create new IP
`control protocols. One issue is how to send
`SS7 signals over IP networks. The IETF’s
`Media Gateway Control Working Group is
`operating under the assumption that SS7
`networks will eventually evolve into IP
`networks. MGCP defines how media
`devices controls packets and determines
`how calls are manipulated and forwarded
`and gives the network device the ability to
`determine if a call should be sent over a
`company’s intranet, over the Internet, or
`over the the PSTN. Service providers are not
`only depending on the IETF for VoIP
`standards; they are looking to the ITU and
`vendor driven forums to address tariffing
`and voice traffic exchange specifications
`that promise interoperability.
`
`7. Advantages of VoIP
`
`The advantages of VoIP technology can be
`divided
`into
`the
`following categories
`[TECH99]:
`
`(cid:34) Cost Reduction – Fixed rate pricing is
`available with the Internet and can result
`in savings for both voice and fax
`transactions. Lower prices are based on
`avoiding telephony charges rather than
`being a reduction in resource costs.
`Also, sharing equipment and operations
`
`5
`
`

`

`costs across both data and voice users
`can improve network efficiency. This
`occurs since bandwidth is shared among
`all users.
`(cid:34) Simplification – An infrastructure that
`supports many types of communication
`allows more standardization and reduces
`equipment costs. Furthermore, it can
`support
`dynamic
`bandwidth
`optimization and a fault tolerant design.
`(cid:34) Consolidation – Individuals are among
`the most significant cost elements in a
`network. Any opportunity to combine
`operations, to eliminate points of failure,
`etc., would be helpful. For enterprise
`networks, SNMP-based management
`can be provided for both voice and data
`service using VoIP. Universal use of the
`IP protocols for most or all applications
`is promising in the sense of reduced
`complexity and flexibility.
`– Basic
`(cid:34) Multimedia Applications
`telephony such as voice and fax are
`initial applications for VoIP; however,
`the long-term benefits are expected to be
`derived from multimedia applications.
`For
`instance,
`Internet
`e-commerce
`solutions can combine WWW access to
`information with a voice call button that
`allows immediate access to IP-based call
`centers. Furthermore, voice
`is an
`integral part of conferencing systems
`that may also include shared screens,
`whiteboarding, etc. Combining voice
`and data features into new applications
`will provide the greatest returns over the
`long term.
`
`8. VoIP Performance Models
`
`The purpose of this section is to identify
`some of the performance issues and present
`some analytic
`traffic models for VoIP
`applications.
`Section
`8.1
`discusses
`performance
`issues while Section 8.2
`discusses models for traffic generated by
`single and multiple users. Section 8.3
`discusses how voice and fax traffic can be
`characterized. Finally, Section 8.4 discusses
`how to compute performance measurements
`using these models.
`
`8.1. VoIP Performance Issues
`
`Essentially, VoIP is packetized voice over
`IP, consequently, architects for any VoIP
`application must pay close attention to
`packet size, buffer size, packet loss, and
`packet latency [BLAC00]. For instance, the
`larger the packet loss, the more audio quality
`degrades. In addition, large packet sizes
`increase delay as well as do large buffers.
`Empirical studies have shown that losing
`traffic that is greater than 32 ms in duration
`is problematic for listeners since speech
`phonemes are lost [BLAC00]. However,
`traffic losses between 4-16 ms are not
`noticeable to the listener [BLAC00]. Many
`studies have consistently shown that the
`larger the packet size, the more likely that
`packet
`loss will
`occur
`[BLAC00]
`[MINO98]. Regarding buffers, large ones
`will likely increase delay and decrease the
`loss rate. The reason is that the larger buffer
`allows
`fewer
`discards
`of
`packets.
`Alternatively, decreasing the buffer size,
`while decreasing delay, implies that more
`packets will be discarded during bursty or
`periods of heavy traffic. The important thing
`for
`any VoIP
`application,
`from
`a
`performance perspective, is to minimize
`end-to-end delay. Studies have shown, the
`overall delay of packet transmissions should
`not exceed 200 ms; however, delays of less
`than 150 ms are desirable [MINO98].
`Typically, when delay reaches 800 ms,
`normal conversation is impeded [MINO98].
`
`8.2 Analytic Traffic Models for VoIP
`
`When modeling voice traffic, it is important
`to understand the speech process between
`two parties. Much research has gone into
`this area and, in general, it has been found
`that the following events are relevant to
`speech patterns: talk-spurt, pause, double-
`talk, mutual silence, alternative silence,
`pause
`in
`isolation,
`solitary
`talk-spurt,
`interruption, speech after interruption, and
`speech before interruption. In fact, these
`events or “states” can be placed in a discrete
`Markov Chain and probabilities transition
`probabilities assigned. For instance, a six-
`state Markov Chain, called the Brady Model
`
`6
`
`

`

`Figure 3. The Brady Markov Model with two speakers A and B.
`
`Double-talk A
`is interrupted
`2
`
`B talks
`B goes silent
`B goes silent
`
`A goes
`silent
`
`3
`
`Double-talk B
`is interrupted
`
`A goes
`silent
`
`A talks
`
`B talks
`5
`
`B talks
`B goes silent
`
`6
`
`B talks
`A silent
`
`Generated
`Voice
`Packets
`
`[SCHW96]. More specific studies indicate
`that the talk-spurt lasts approximately 352
`ms; and, the average silence period lasts
`around 650 ms [SRIR86].
`
`Using Linear Algebraic Queueing Theory
`(LAQT)
`(see
`[LIPS92]) a generating
`function, Q,
`representing
`the process
`depicted in Figure 4 can be written as
`
`?BQ
`
`
`
`,
`
`(1)
`
`where the matrix B is the “modulator” of the
`process and is represented by
`
`(2)
`
`.
`
`
`
`
`
`/1
`S
`
`/1
`T
`
`/1
`S
`/1
`T
`
`
`
`
`
`
`B
`
`
`
`T and S are respectively the mean times for
`talk-spurt and silence periods. The matrix,
`? , (which places
`the packets on
`the
`communications line) is represented by
`
`A talks
`B silent
`1
`
`A talks
`
`A talks
`
`Ag
`
`oes
`silent
`
`Mutual Silence
` A spoke last
`
`4
`
`Mutual Silence
` B spoke last
`
`Figure 4. A simple two-state traffic model.
`
`User A
`
`Talk-
`spurt
`
`Silence
`Period
`
`is one approach [MINO98]. The sequence of
`events in Figure 3 shows how the Brady
`model depicts the interaction between two
`speakers A and B. Interest in this model has
`been high because of its excellent predictive
`abilities [MINO98].
`
`As can be seen by Figure 3, the analysis of
`the Brady Model can be rather complex;
`however, there are simplier methods that can
`yield
`reasonable
`performance
`measurements.
`
`Intuitively, we can think of voice traffic
`generated by a using a “two-state” process.
`In other words, some user A alternates
`between periods of “talk-spurts” and
`“silence periods”. Figure 4 illustrates this
`type of model. This model has immediate
`applications since studies of telephone users
`have consistently demonstrated
`that
`the
`average
`talk-spurt
`is
`exponentially
`distributed and lasts between 0.4-1.2 sec
`followed by an exponentially distributed
`silence period of 0.6-1.8 sec in length
`
`7
`
`

`

`Figure 5. A concurrent or multiple source traffic model.
`1 / T
`1 / T
`1 / T
`1 / T
`1 / T
`
`1 / T
`
`1 / T
`
`1 / T
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`1 / S
`
`1 / 2S
`
`1 / 3S
`
`1 / 4S
`
`1 / 5S
`
`1 / 6S
`
`1 / 7S
`
`1 / 8S
`
`?
`
`?
`
`?
`
`?
`
`sec, where again, ? is the rate that packets
`are placed on the communications line
`during a talk-spurt. It should be noted that
`variants of multiple state processes, such as
`the one depicted in Figure 5, have been used
`extensively in telecommunications modeling
`(see
`[SCHW96]).
`In any event,
`the
`generating function for this process, Qc (the
`subscript c means concurrent), looks like
`
`?BQ
`
`
`c
`c
`
`,
`
`c
`
`(4)
`
`where, (similarlily to Eq. (2)) the matrix Bc
`is the “modulator” of the process. Using
`Figure 5, Bc comes out to be
`
`,
`
`
`
`
`
`
`
`(5)
`
`(cid:31)(cid:31)(cid:31)
`
`(cid:31)
`
`
`
`(
`
`S
`TS
`
`2T
`
`
`)
`
`0
`S
`
`
`
`
`(
`
`S
`
`
`
`)2T
`
`(cid:31)
`
`(cid:31)
`
`S
`
`T
`0
`
`(cid:31)
`
`
`
`
`
`
`
`
`
`
`Bc
`
`recalling that T and S are mean times for
`talk-spurt and silence periods respectively.
`The matrix ? that puts the packets on the
`communications line is represented by
`
`.(6)
`
`
`
`
`
`
`
`(cid:31)(cid:31)(cid:31)(cid:31)(cid:31)
`
`(cid:31)
`
`0
`0
`0
`0
`0
`
`0
`?
`0
`0
`0
`
`0
`0
`?
`2
`0
`0
`
`0
`0
`0
`?
`3
`0
`
`0
`0
`0
`0
`?
`4
`
`(cid:31)
`
`(cid:31)
`
`(cid:31)
`
`(cid:31)
`
`(cid:31)
`
`
`
`
`
`
`
`?
`
`
`
`8.3 Traffic models for Voice/Fax
`
`?
`
`(3)
`
`
`
`?
`
`,
`
`00
`
`?0
`
`
`
`
`
`
`
`?
`
`
`
`where ? is the rate of packets that are placed
`on the line during a talk-spurt. The quantity
`? is a function of the delay (depending upon
`the VoIP deployment) due to analog-digital
`conversion, the packetization period, and the
`mean packet size. Also, ? will be highly
`dependent upon the network interface of the
`VoIP application. For instance, if the VoIP
`application is configured to accommodate
`two ISDN and T1/E1 interfaces via a
`Telecommunications provider, then a VoIP
`gateway will be needed and voice signals
`will be digitized into a format useful to the
`interface (i.e. usually 64 kbps). If the VoIP
`application is, say, PC-to-PC over a LAN,
`then we have a different story. In other
`words, ? would be more a function of the
`PC’s networking interface hardware.
`
`The problem with the model depicted in
`Figure 4 is that it only represents packets
`generated by one user. A more realistic
`VoIP model would incorporate more users
`sending
`voice
`packets
`down
`the
`communications line (e.g. enterprise VoIP
`networking applications). For
`instance,
`consider
`the
`following
`transition state
`diagram in Figure 5.
`
`the
`Each state (labled 0-7) represents
`number of users
`that are concurrently
`generating voice traffic. At each state, the
`rate of packets generated is a function of the
`state the system is in. For instance, when
`there are six users concurrently generating
`voice traffic, the amount of traffic placed on
`the communication line is 6? packets per
`
`8
`
`

`

`Once the R matrix is calculated the steady-
`state probabilities can be computed by
`RRI
`
`
`
`, (10)
`
`
`where  I is the stationary probability vector
`and is calculated by
`
` 
`nr
`
`
`
`?
`
`I
`
`n
`
` (11)
`
` I
`
`
`
`V
`
`,
`?
`V
`
`where  is the left eigenvector of the matrix
`Y which represents the state of the system
`after a voice packet is generated and departs
`the system. This quantity is given by
`
` Y = V? .
`
`(12)
`
`To compute  , we must solve the following
`
` =  Y.
`
`(13)
`
`D
`
`
`
`?
`
`I
`
`2?
`
`. (14)
`
`1
`
`Now performance measurements such as
`delay can be obtained by
`x
`
`
`
`RRI
`
`
`the above equation,
`The first part of
`
`?
`
`
`, is the mean number of
`2
`RRI
`
`
`I
`packets waiting in the buffer at the receiving
`end (mean number in the queue). The
`second part of Eq. (14), x1 , is the average
`delay of the link(s). The buffer overflow
`probabilities at the receiving end can be
`computed by calculating the probability that
`an arriving voice packet will find N slots in
`the buffer filled. This turns out to be
`
`? 
`
`?R
`N
`?
`?
`
`I
`
`
`. (15)
`
` 
`NPr
`
` 
`
`Nn
`
`
` 
`na
`
`
`
`
`
`I
`
`
`In this section we generalize the approach
`used for the VoIP models discussed in the
`previous
`section
`to
`include
`packet
`generation for both voice and fax. If we
`think of an “average” voice and fax traffic
`load during the “talk-spurt” or better yet
`during the “spurt” period, then, in essence,
`all this does is add more traffic onto the
`communications
`line.
`Consider
`the
`generating matrix, QVoice/Fax, representing the
`traffic generated on a network by VoIP
`applications concurrently running
`
`Q
`
`Voice/Fax
`
`
`
`B
`
`Modulator
`
`
`
`?
`
`Voice
`
`
`
`?
`
`Fax
`
`. (7)
`
`Here, the generating matrix QVoice/Fax is
`represented by the tensor product of the state
`spaces
`involved
`in
`representing
`the
`modulator, voice traffic, and fax traffic.
`From a computational point of view, these
`matrices can get very large, however, there
`are analytic means to reduce their state
`spaces. In addition, simplifying assumptions
`can be made. For instance, assuming all the
`distributions are exponential (except the
`modulator) can make this very tractable
`analytically. In this case, the generating
`function would look like
`
`Q
`
`Voice/Fax
`
`
`
`B
`
`Modulator
`
`
`
`?
`
`Voice
`
`
`
`?
`
`Fax
`
`. (8)
`
`8.4 Computing Performance
`Measurements
`
`To compute performance measurements we
`need to use an SM/G/12 queue. For now, we
`will use an exponential distribution for the G
`distribution and this represents the speed of
`the link(s) between the two parties. To
`compute the steady-state probabilities, the
`quadratic matrix R
`(that characterizes
`transition rates of the system at hand) needs
`to be solved (see [NEUT82]), that is,
`
`??????????? – R(Q + ?I) + R2?I = O.
`
` (9)
`
`9. VoIP Performance Analysis
`
`2 The symbol “SM” stands for semi-Markov and
`is a correlated arrival process to the queue in this
`case.
`
`The purpose of this section it to gain some
`intuition regarding the performance of VoIP
`applications using the traffic models
`
`9
`
`

`

`Figure 6. An architecture for a VoIP deployment.
`
`N calling parties
`
`Site A
`
`Phones
`Connected
`To PC’s
`
`Local
`Ethernet
`
`Conventional
`Phone(s)
`
`VoIP
`Gateway
`G.729
`
`Conventional
`Phone(s)
`
`VoIP
`Gateway
`G.729
`
`Leased
`Line
`
`N called parties
`
`Phones
`Connected
`To PC’s
`
`Site B
`
`Local
`Ethernet
`
`Figure 7. The probability of having n concurrent talk-spurts.
`
`system. If we assume the number of calling
`parties or states is very large at site A, then
`results from the M/M/ queue can be
`applied to compute the expected number of
`concurrent
`talkbursts, E(nt),
`and
`the
`probability of nt concurrent talkbursts, p(nt).
`This quantity E(nt) can be calculated by
`
`, (16)
`
`TS
`
` 
`ntE
`
`
`
`and p(nt), can be computed by
`
`
`
` 
`np
`
`t
`
`
`
`
`n
`
`t
`
`
`
`
`
`
`
`exp
`
`developed in Section 8. We illustrate a
`typical architecture for a VoIP application
`and formulate an approximation using an
`M/M/1-type queue.
`
`Figure 6 shows an architecture of a VoIP
`deployment. Users can place phone calls
`conventionally or via their PC. When a user
`places a call through his/her PC at Site A,
`voice packets travel though the LAN, the
`VoIP gateway, and the leased line to the
`VoIP gateway at Site B where voice packets
`travel through the LAN at Site B once the
`calling party has been located.
`
`By examining the diagram in Figure 5 and
`the modulator in Eq. (5), insights into the
`behavior of this process can be gained.
`Transitions to talkburst states occur at rate 1
`/ T and transitions from silent states occur at
`rate 1 / nS where n is the current state of the
`
`
`
`
`
` 
`nE
`
`t
`
`
`
` .
`
`
`
`
`
`
`
`2/1
`)
`log
`n
`t
` (17)
`
`
`
`n
`t
`
`t
`
`t
`
`t
`
`t
`
`n
`
` 
`
`nE
`
`t
`
`exp
`!
`n
`
` 
`
`
` 
`log
`nE
`nE
`
`
` 
`
`?
`log
`2
`
`
`n
`t
`
`10
`
`

`

`Figure 7. VoIP delays: Comparing SM/G/1 results with the M/M/1 approximation.
`
`Given Eq. (16), E(nt) comes out to be
`approximately 1.85 concurrent
`talkbursts
`given S = 650 ms and T = 352 ms. By
`applying Eq. (17), it can be seen the
`probability of having a large number (e.g.
`20) of concurrent talkbursts is very small.
`This behavior is indicated by Figure 6.
`
`9.2 Approximating Performance using an
`M/M/1 Queue
`
`The VoIP model in Section 8 can be used
`characterize VoIP applications, however, it’s
`computation can get somewhat involved. In
`this section we present an approximation
`using an M/M/1 queue and it’s performance
`will be compared to the original SM/G/1
`formulation discussed in Section 8. For the
`M/M/1 queue, the offered load to the
`network will be approximated by
`
`?
`*
`offered 
`
`?
`N
`
`, (19)
`
`where N is the number of users generating
`traffic and ??is the packet rate during a talk-
`spurt. Eq. (19) assumes the following: 1)
`The callers are always generating traffic;
`and, 2) The amount of traffic generated is a
`function of the number of callers, N. The
`delay can be computed using the known
`M/M/1 response time formula
`
`.
`
` (20)
`
`R
`
`
`
`x
`?
`1
`Here x is the mean service time utilization
`of network device(s) the voice packets are
`carried on (e.g. the leased line – see Figure
`offered?? *
`is the utilization of the
`5); and,
`x
`system. Note that for an M/M/1 queue, the
`probability of losing an arriving packet is
`
`  
`1
`na
`
`
`
`
`
`???
`N
`n
`
`
`. (21)
`
`Pr
`
` 
`N
`
` 
`
`Nn
`
`
`Example
`
`Suppose we are interested in modeling
`delays for the VoIP application depicted by
`Figure 5. This system enables PC users at
`site A to call PC users at site B (for now,
`ignore the conventional phone users at sites
`A and B). Assume that there are 20 PC users
`at site A making telephone calls and that a
`leased line connects the two sites. From a
`modeling
`standpoint,
`performance
`measurements of interest are estimates of
`voice packet delays assuming, for expository
`purposes, both sites have negligible Ethernet
`delays.
`
`To compute the rate of packets carried on
`the leased line, results of the VoIP gateway
`
`11
`
`

`

`using the G.729 CODEC3 will be used.
`Since this coder has a frame size4 of 10 ms,
`then on average 35.2 packets are generated
`during a talk-spurt (a talk-spurt lasts 352
`ms). Assuming the voice cards on the PC’s
`perform comparably, then 0.03 packets per
`ms will travel down the leased line from one
`VoIP gateway to the other (given no traffic
`is generated by the conventional telephones)
`- this quantity is ? (see Eqs. (3) and (6)).
`The latency caused by the leased line can be
`computed by dividing the mean packet size
`generated by the VoIP application by the
`leased line speed.
`
`shows packet delays after
`Figure 8
`computing performance measurements using
`the SM/G/1 and M/M/1 models. The mean
`packet size was fixed to 800 bits and is a
`reasonable assumption (see [MINO98]).
`Both models indicate that as the number of
`users approaches 19 or 20, then mean pa