Internet Engineering Task Force
INTERNET DRAFT Authors
Signaling Transport Working Group Huai-An P. Lin
October 22, 1999 Kun-Min Yang
Expires March 22, 2000 Taruni Seth
Christian Huitema
Telcordia Technologies
VoIP Signaling Performance Requirements and Expectations
<draft-ietf-sigtran-performance-req-01.txt>
Status of this document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document serves as input into the IETF SIGTRAN requirements
process. It includes call setup delay requirements, derived from
relevant ISDN and SS7 standards published by ITU-T (International
Telecommunications Union--Telecommunications Standardization Sector) and
generic requirements published by Telcordia Technologies (formerly
Bellcore). To gain user acceptance of Voice-over-IP (VoIP) services and
to enable interoperability between Switched Circuit Networks (SCNs) and
VoIP systems, it is imperative that the VoIP signaling performance be
comparable to that of the current SCNs. The requirements given in this
Internet Draft are intended to be the worst-case requirements, for at
least in the United States SCN calls are typically set up at a faster
speed than the derived requirements. At the end of the draft, several
VoIP call connection scenarios based on the latest megaco protocol are
analyzed and compared with similar cases in the PSTN. It indicates the
PDD performance of VoIP systems is somewhat worst but not by much. An
improvement in some network element can bring VoIP systems to have
comparable PDD performance as the PSTN.
Lin, Yang, Seth, Huitema [page 1]
Internet-Draft VoIP Signaling Performance October, 1999
1. Introduction
This document serves as input into the IETF SIGTRAN requirements
process. It includes call setup delay requirements, derived from
relevant ISDN and SS7 standards published by ITU-T (International
Telecommunications Union--Telecommunications Standardization Sector) and
generic requirements published by Telcordia Technologies (formerly
Bellcore). To gain user acceptance of VoIP services and to enable
interoperability between SCNs and VoIP systems, it is imperative that
the VoIP signaling performance be comparable to that of the current SCNs.
The requirements given in this Internet Draft are intended to be the
worst-case requirements, since at least in the United States SCN calls
are typically set up within one to two seconds [1]--far faster than the
derived requirements.
The call setup delay, also known as the Post Dial Delay (PDD), in an ISDN-
SS7 environment is the period that starts when an ISDN user dials the
last digit of the called number and ends when the user receives the last
bit of the Alerting message. Call setup delays are not explicitly given
in the existing SCN performance requirements; rather, performances of
SCNs are typically expressed in terms of cross-switch (or cross-office)
transfer times. This Internet Draft uses ITU-T's SS7 Hypothetical
Signaling Reference Connection (HSRC) [2], cross-STP (Signaling Transfer
Point) time [3], Telcordia's switch response time generic requirements
[4], and a simple ISDN-SS7 call flow to derive the call setup delay
requirements. ITU-T's cross-switch time requirements [5] are listed as
references but not used, since the ISDN timings are missing.
At the end of the draft, we evaluate the PDD of VoIP systems based on
the proposed megaco protocol and compare its PDD performance with that
of the current PSTN. It gives a better understanding of where
the bottleneck is and hopefully suggest the area of improvement that can
be done in VoIP systems to achieve comparable performance.
2. Hypothetical Signaling Reference Connection (HSRC)
HSRC is specified in ITU-T Recommendation Q.709. A HSRC is made up by a
set of signaling points and STPs that are connected in series by
signaling data links to produce a signaling connection. Recommendation
Q.709 distinguishes the national components from the international
components. A HSRC for international working consists of an
international component and two national components. The size of each
country is considered; however, the definitions of large and average
countries was not precisely defined:
When the maximum distance between an international switching center and
a subscriber who can be reached from it does not exceed 1000 km or,
exceptionally, 1500 km, and when the country has less than n x 10E7
subscribers, the country is considered to be of average-size. A country
Lin, Yang, Seth, Huitema [page 2]
Internet-Draft VoIP Signaling Performance October, 1999
with a larger distance between an international switching center and a
subscriber, or with more than n x 10E7 subscribers, is considered to be
of large-size. (The value of n is for further study.)
Recommendation Q.709 uses a probabilistic approach to specify the number
of signaling points and STPs on a signaling connection. The maximum
number of signaling points and STPs allowed in a national component and
an international component are listed in Tables 1 and 2, respectively.
Table 1: Maximum Number of Signaling Points and STPs in a National
Component (Source: ITU-T Recommendation Q.709, Table 3)
Country size Percent of Number of Number of
connections STPs signaling points*
Large-size 50% 3 3
95% 4 4
Average-size 50% 2 2
95% 3 3
* The terms signaling points and switches are used interchangeably in
this Internet Draft.
Table 2: Maximum Number of Signaling Points and STPs in International
Component (Source: ITU-T Recommendation Q.709, Table 1)
Country size Percent of Number of Number of
connections STPs signaling points
Large-size 50% 3 3
to
Large-size 95% 4 3
Large-size 50% 4 4
to
Average-size 95% 5 4
Average-size 50% 5 5
to
Average-size 95% 7 5
3. Switch Response Time (aka Cross-switch Transfer Time)
Most of SCN performance requirements are specified in terms of switch
Lin, Yang, Seth, Huitema [page 3]
Internet-Draft VoIP Signaling Performance October, 1999
response times, which are also referred to as cross-switch transport
time or cross-switch delay. This section reviews the meanings of switch
response times, several other related terms, and the generally accepted
values of switch response times published by Telcordia Technologies. The
corresponding ITU-T's cross-switch timing requirements are also listed
as references.
This Internet Draft reviews the switch response time requirements
intended to apply under normal loading. Normal loading is usually
associated with the notion of the Average Busy Season Busy Hour (ABSBH)
load. Simply put, it is expected that the switch response times that a
particular switch experiences at this load will be virtually load-
independent.
Switch response time is the period that starts when a stimulus occurs at
the switch and ends when the switch completes its response to the
stimulus. The occurrence of a stimulus often means the switch receives
the last bit of a message from an incoming signaling link, and
completion of a response means the switch transmits the last bit of the
message on the outgoing signaling link. If the switch's response to a
stimulus involves the switch sending a message on the outgoing signaling
link, then switch processing time is the sum of the switch processing
time and the link output delay:
Switch Response Time = Switch Processing Time + Link Output Delay
Switch processing time is the period that starts when a stimulus occurs
at the switch and ends when the switch places the last bit of the
message in the output signaling link controller buffer. The period
between the switch placing the message in the output signaling link
controller buffer and the switch transmitting the last bit of the
message on the outgoing signaling link is defined as the link output
delay. Link output delay can be further divided into the queuing delay
and message emission time. There are separate delay requirements for
switch processing time and link output delay; however, for simplicity
only the combined delay requirements for switch response time, as given
in Table 3, will be listed in this Internet Draft.
Lin, Yang, Seth, Huitema [page 4]
Internet-Draft VoIP Signaling Performance October, 1999
Table 3: Switch Response Time Assuming Typical Traffic Mix and
Message Lengths (Source: Telcordia GR-1364-CORE, Table 5-1)
Type of Call Segment Switch Response Time (ms)
Mean 95%
ISUP Message 205-218 <=337-349
Alerting 400 <=532
ISDN Access Message 220-227 <=352-359
TCAP Message 210-222 <=342-354
Announcement/Tone 300 <=432
Connection 300 <=432
End MF Address - Seize 150 <=282
Telcordia GR-1364 specifies switch response time using switch call
segments as a convenient way to refer to the various phases of call
processing that switches are involved in. (An alternative would be
proposing switch processing requirements for every possible type of
switch processing. Obviously, this would become burdensome and would
necessitate adding to the requirements every time an additional type of
switch processing was required.) Listed in Table 3 are:
1. ISUP message call segments that involve the switch sending an ISUP
message as a result of a stimulus.
2. Alerting call segments that involve the switch alerting the
originating and/or terminating lines as a result of a stimulus.
3. ISDN access message call segments that involve the switch sending an
ISDN access message (other than an ISDN access ALERT message) as a
result of stimulus. ISDN access message call segment processing
occurs at originating or terminating switches where the originating
or terminating line, respectively, is an ISDN line.
4. TCAP message call segments that involve the switch sending a TCAP
message as a result of a stimulus.
5. Announcement/tone call segments that involve the switch playing an
announcement, placing a tone on, or removing a tone from the
originating or terminating line as a result of a stimulus. However,
the announcement/tone call segments do not include dial-tone delay,
of which the delay requirements can be found in Telcordia
TR-TSY-000511[6].
6. Connection call segments involve the switch connecting one or more
users as a result of a stimulus.
The ITU-T's cross-switch timing requirements are listed below as
references. It is noted that the ITU-T's requirements are noticeably
stringent that those of Telcordia under the normal loading. However,
since the ITU-T's values are stated as provisional and they do not
provide the timing requirements for ISDN, Telcordia's values will be
used to derive the call setup delay requirements.
Lin, Yang, Seth, Huitema [page 5]
Internet-Draft VoIP Signaling Performance October, 1999
Table 4: ITU-T Cross-Switch Transfer Time
(Source: ITU-T Recommendation Q.725, Table 3)
Exchange call Cross-Switch Transfer
Time (ms)*
Message type attempt loading Mean 95%
Simple Normal 110 220
(e.g. answer) +15% 165 330
+30% 275 550
Processing Normal 180 360
intensive +15% 270 540
(e.g. IAM) +30% 450 900
* Provisional values.
4. Cross-STP Delay
Message delay through an STP is specified as the cross-STP delay. It is
the interval that begins when the STP receives the last bit of a message
from the incoming signaling link, and ends when the STP transmits the
last bit of the message on the outgoing signaling link. As with the
switch response time discussed in the previous section, the cross-STP
can be divided into processor handling time and link output delay. This
Internet Draft adopts the cross-STP delay requirements specified in ITU-
T Q.706 Recommendation.
Table 5: Message transfer time at an STP
(Source: ITU-T Recommendation Q.706, Table 5)
Message transfer Time (ms)
STP signaling traffic load Mean 95%
Normal 20 40
+15% 40 80
+30% 100 200
5. Maximum End-to-End Signaling Delays
Using the HSRC, switch response times, and cross-STP delays, one can
compute the maximum signaling transfer delays for ISUP messages under
normal load. As with Telcordia GR-1364, it is assumed that the
distribution of switch response time for each call segment is
approximately a normal distribution. It is further assumed that switch
response times of different switches are independent. Under these
assumptions, the end-to-end (from originating switch to terminating
Lin, Yang, Seth, Huitema [page 6]
Internet-Draft VoIP Signaling Performance October, 1999
switch) delays for each national component and for international calls
are listed in Tables 6 and 7, respectively. The 20 ms cross-STP delay is
assumed in all cases. It should be noted that all these values must be
increased by the transmission propagation delays, which are listed in
Table 8.
Table 6: Maximum ISUP Signal Transfer Delays for Each National Component
Country size Percent of Delay (ms)
connections Mean 95%
Large-size 50% 675-714 <=904-941
95% 900-952 <=1164-1214
Average-size 50% 450-476 <=637-661
95% 675-714 <=904-941
Table 7: Maximum ISUP Signal Transfer Delays for International Calls
Country size Percent of Delay (ms)
connections Mean 95%
Large-size to 50% 2025-2142 <=2421-2538
Large-size 95% 2495-2638 <=2933-3076
Large-size to 50% 2250-2380 <=2677-2797
Average-size 95% 2720-2876 <=3177-3333
Average-size to 50% 2475-2618 <=2913-3056
Average-size 95% 2965-3134 <=3441-3610
Table 8: Calculated Terrestrial Transmission Delays for Various Call
Distances (Source: ITU-T Recommendation Q.706, Table 1)
Arc length Delay terrestrial (ms)
(km) Wire Fiber Radio
500 2.4 2.5 1.7
1000 4.8 5.0 3.3
2000 9.6 10.0 6.6
5000 24.0 25.0 16.5
10000 48.0 50.0 33.0
15000 72.0 75.0 49.5
17737 85.1 88.7 58.5
20000 96.0 100.0 66.0
25000 120.0 125.0 82.5
Lin, Yang, Seth, Huitema [page 7]
Internet-Draft VoIP Signaling Performance October, 1999
6. Basic Call Flow and Call Setup Delays
The following figure illustrates the simplest call flow for call setup
in an ISDN-SS7 environment. The end user terminals are assumed to be
ISDN phones and use Q.931 messages (i.e., Setup and Alerting). The
switches use ISUP messages to establish inter-switch trunks for the
subsequent voice communication.
Caller Originating Terminating Called
Terminal Switch Switch Terminal
| | | |
| Setup | | |
|---------------->| | |
| | IAM IAM | |
| |------> . . . . ------>| |
| | | Setup |
| | |-------------->|
| | | |
| | | Alerting |
| | |<--------------|
| | ACM ACM | |
| |<------ . . . . <------| |
| Alerting | | |
|<----------------| | |
| | | |
| | | |
Figure 1: Simple Call Setup Signaling Flow
Using the above call flow, the end-to-end message transfer delays in
Tables 6 and 7, and the switch response times for Q.931 messages in
Table 3, one can derive the call setup times given in the following
tables. Again, all these values must be increased by the transmission
propagation delays listed in Table 8.
Lin, Yang, Seth, Huitema [page 8]
Internet-Draft VoIP Signaling Performance October, 1999
Table 9: Call Setup Delays for Each National Component
Country size Percent of Call Setup Delay (ms)
connections Mean 95%
Large-size 50% 2590-2682 <=3007-3099
95% 3040-3158 <=3497-3615
Average-size 50% 2140-2206 <=2513-2579
95% 2590-2682 <=3007-3099
Table 10: Call Setup Delays for International Calls
Country size Percent of Delay (ms)
connections Mean 95%
Large-size to 50% 5290-5538 <=5909-6157
Large-size 95% 6230-6530 <=6903-7203
Large-size to 50% 5740-6014 <=6387-6661
Average-size 95% 6680-7006 <=7378-7704
Average-size to 50% 6190-6490 <=6863-7163
Average-size 95% 7170-7522 <=7893-8245
7. User Expectations
The requirements derived in the previous section should be interpreted
as the worst-case requirements. At least in the United States, users of
SCN typically experience far less setup delays than the derived delay
requirements. With the maturing of Common Channel Signaling (CCS)
Network, call setup time has been reduced to a mere one to two seconds
[1]. The VoIP networks are expected to achieve the same level of delay
There is no known study on expected setup delays for international
calls. As discussed, a HSRC for international working consists of an
international component and two national components, and the maximum
number of signaling points and STPs in a national component is roughly
the same as the number in an international component (Tables 1 and 2).
As a consequence, the end-to-end ISUP delays in an international call
are roughly three times of those in a national call. On the other hand,
the Q.931 signals occur only at the two ends for both national and
international calls. Based on these observations, one may expect 2.5-5
second call setup delays to be reasonable for international calls.
Lin, Yang, Seth, Huitema [page 9]
Internet-Draft VoIP Signaling Performance October, 1999
8. Post Dial Delay in VoIP Systems
After deriving the PDD requirements in the PSTN, it's important to check
if VoIP systems can meet those requirements.
In the following sections, we will evaluate several VoIP systems,
illustrate the call flow that contributes to the PDD, and analyze the
PDD in terms of delay in network elements. We emphasize that the intend
for this analysis is not to set the requirement for VoIP systems, but
rather to gain further understanding of the PDD expectation in VoIP
services.
For definition of Media Gateway (MG), Media Gateway Controller (MGC),
Residential Gateway (RGW), Trunking Gateway (TGW), Access Gateway (AGW),
and Signaling Gateway (SG), please refer to [7].
8.1. Methodology and Assumptions
The VoIP systems we intend to investigate are based on the architecture
and protocol defined in megaco WG [7]. The set of commands megaco
protocol specifies is "Add", "Modify", "Subtract", "Move", "AuditValue",
"AuditCapacity", "Notify", and "ServiceChange". The Post Dial Delay is a
function of the Response Time in each network element (e.g. RGW, MGC),
and the Transmission Delay between network elements. The Response Time
can be divided into the Processing Time and the Link Output time. The
Processing Time required by a network element depends on the command it
receives and the state of the call connection at that time. It is defined
as the period that starting when a stimulus occurs at the network element
(e.g., when the network element receives the last bit of a message from
the incoming signaling link) and ending when the network element places
the last bit of the message in the output signaling link controller
buffer. [3]
The PDD analysis is based on the call flow derived from the megaco
protocol and only the portion that contributes to the PDD needs to be
considered. In the following section, we will show only "Add", "Modify",
"Notify" and their Reply messages are used to calculate the PDD.
For the purpose of comparing the performance of the VoIP systems with
that of the PSTN, we assume network elements in each system have
comparable Processing Time for executing the same or similar function in
a call connection setup. The comparison then can be made based on the
system complexity (i.e. number of components) and the set of messages
(i.e. the number and types of commands) need to be exchanged and executed.
More specifically, we assume the response time to create a connection in
a VoIP system (i.e. Add Termination processing in both the MGC and a MG)
is comparable with that of a Connection call segment in a PSTN switch
(i.e. the Connection in Table 3, which has a mean value of 300 ms and 95%
Lin, Yang, Seth, Huitema [page 10]
Internet-Draft VoIP Signaling Performance October, 1999
of prob. not exceeding 432 ms). The split of this Connection Response Time
into delay components in MGC and MG depends on the implementation itself.
We use 80-90% of it for MGC processing assuming most of the intelligent
functionality of a switch now reside in the MGC. The processing for a
Modify Termination command is expected to be close to or less than that of
an Add Termination command. Also, the processing time for the TGW is
expected to be larger than that for RGW.
Therefore, we define:
* MGC Connection Response Time - The call segment for which MGC
processing involves the MGC sending an "Add" command as a result of
a stimulus.
* MG Add Termination Response Time - The call segment for which
MG processing involves the MG adding a termination to a context and
sending a reply message as a result of receiving an "Add" command.
* MG Modify Termination Response Time - The call segment for which
MG processing involves the MG modifying a termination in a context
and sending a reply message as a result of receiving a "Modify"
command.
The Signaling Gateway can reside close to the MGC if not in the same
host, the Transmission Delay between them is negligible in comparison
with the expected PDD values in Table 9. The Signaling Gateway relays
signaling message between the PSTN and the MGC, it is assumed to act
like an STP in the PSTN, and the cross-STP delay is used for the
Processing Time in the SGs.
Therefore, we define:
* SG Response Time - The call segment for which SG processing involves
a SG sending a message to the MGC or the PSTN as a result of a
stimulus.
In the VoIP scenario, the processing of the call setup messages in the
MGC and AGWs is taken to be comparable to the processing of the ISDN
Access message call segment, i.e. Setup message, that contributes to the
PDD in the PSTN scenario. Further, the terminating switch in the PSTN
usually needs to generate the ringback tone after receiving an Alerting
message from the called ISDN terminal. However, in the VoIP systems, the
terminating AGW do not have to generate the ringback tone. Instead,
the ringback tone can be generated by the originating AGW. Therefore,
the processing delay for Alerting message at the terminating AGW in
the VoIP scenario can be reduced.
The Transmission Delay in an IP network has different characteristics
from that in an SS7 network. We gathered some experiment data from the
Internet and applied them for the purpose of this analysis. More data
based on the methodology being defined in the IPPM WG can refine the
characteristics of the Transmission Delay in the future.
Lin, Yang, Seth, Huitema [page 11]
Internet-Draft VoIP Signaling Performance October, 1999
For ease of manipulation, we define:
* Tgc - MGC Connection Response Time.
* Tta - TGW Add Termination Response Time.
* Tra - RGW Add Termination Response Time.
* Taa - AGW Add Termination Response Time.
* Ttm - TGW Modify Termination Response Time.
* Trm - RGW Modify Termination Response Time.
* Tam - AGW Modify Termination Response Time.
* Tcc - Transmission delay between two MGCs.
* Tcr - Transmission delay between a MGC and a RGW.
* Tct - Transmission delay between a MGC and a TGW.
* Tca - Transmission delay between a MGC and a AGW.
* Tia - Transmission delay between a user's ISDN terminal and a AGW.
* Ts - SG Response Time.
* Tisup - ISUP message call segment Response Time.
We assume the delays in network elements are mutually independent of
each other and have Normal distributions.
In summary, the tentative statistics we use for this draft is as
follows:
Table 11: Network Element Processing Time in VoIP.
Processing Time (ms)
50% 95%
Tgc 255 380
Tra/Trm 30 60
Taa/Tam 30 60
Tta/Ttm 60 120
Tcc 100 200
Tcr 15 20
Tct 20 30
Tca 15 20
Ts 20 40
9. PDD Analysis for VoIP scenarios
In this section, we derived four call connection scenarios. For each
scenario, we first illustrate the portion of the call flow that
contribute to the PDD, then we calculate the PDD based on the assumed
characteristics mentioned in the last section.
9.1. Scenario 1: Two Residential Gateways under a MGC
We start with a simple scenario where two Residential Gateways (RGW1 &
RGW2) and a Media Gateway Controller (MGC) are involved in a call
connection as shown in Figure 2. Both of the RGWs are controlled under
Lin, Yang, Seth, Huitema [page 12]
Internet-Draft VoIP Signaling Performance October, 1999
the same MGC.
______ _____ ______
| | | | | |
| RGW1 |----| MGC |----| RGW2 |
|______| |_____| |______|
Figure 2. Call Connection Model, Scenario 1.
The call flows we use for the PDD analysis in this draft are derived
from those in [8], and we substitute the commands with the corresponding
ones specified in the latest draft of megaco protocol [7]. The portion
of the call flow that affects the PDD in scenario 1 is illustrated as
follows:
_________________________________________________
| Usr | RGW1 | MGC | RGW2 |
|__________|___________|______________|___________|
| Off-hook | | | |
|(Dialtone)| | | |
| Digits | Notify | -> | |
| | <- | Reply | |
| | <- | Add | |
| | Reply | -> | |
| | | Add | -> |
| | | <- | Reply |
| | <- | Modify | |
| | Reply | -> | |
| | <- | Modify | |
| ringback | | (Signal) | |
|__________|___________|______________|___________|
The sequence of messages must be processed successfully before a
ringback tone can be posted to the caller is as follows:
* A Notify message is generated with collected digits by RGW1.
* The Notify message is transported to the MGC.
* The Notify message is processed by the MGC, call connection resource
is set in the MGC, an Add message is generated by the MGC.
* The Add message is transported to the RGW1.
* The Add message is processed by the RGW1, a connection is made in the
RGW1, a Reply message is generated by the RGW1.
* The Reply message is transported to the MGC.
* The Reply message is processed by the MGC, call connection resource
is modified in the MGC, another Add message is generated by the MGC.
* The Add message is transported to the RGW2.
* The Add message is processed by the RGW2, a connection is made in the
RGW2, a Reply message is generated by the RGW2.
* The Reply message is transported to the MGC.
Lin, Yang, Seth, Huitema [page 13]
Internet-Draft VoIP Signaling Performance October, 1999
* The Reply message is processed by the MGC, call connection resource
is modified in the MGC, a Modify message is generated by the MGC.
* The Modify message is transported to the RGW1.
* The Modify message is processed by the RGW1, the connection in RGW1
is modified, a Reply message is generated by the RGW1.
* The Reply message is transported to the MGC.
* The Reply message is processed by the MGC, a Modify message is
generated by the MGC for signaling a ringback tone request.
* The Modify message is transported to the RGW1.
After applying the statistics in Table 11 on delay components above, the
PDD for this scenario is calculated as:
PDD = 2*Tgc + 2*Tra + 8*Tcr + Trm ,
and has the statistic of
* Mean value 720 ms
* 95% prob. not exceeding 909 ms
This scenario can be compared with the case in the PSTN that both the
calling and called parties are served by the same Local Exchange. The
switch response time can be found in Table 3 as:
* Mean value 150 ms
* 95% prob. not exceeding 282 ms
9.2. Scenario 2: Two RGWs under Two Different MGCs
The difference between this scenario and the previous one is that the
second Residential Gateway is controlled by a different MGC, i.e. MGC2.
Some extra messages need to be exchanged between the two MGCs to achieve
the call connection.
______ ______ ______ ______
| | | | | | | |
| RGW1 |----| MGC1 |----| MGC2 |---| RGW2 |
|______| |______| |______| |______|
Figure 3. Call Connection Model for Scenario 2.
The portion of the call flow that affects the PDD for this scenario is
illustrated as follows:
Lin, Yang, Seth, Huitema [page 14]
Internet-Draft VoIP Signaling Performance October, 1999
______________________________________________________________
| Usr | RGW1 | MGC1 | MGC2 | RGW2 |
|__________|___________|______________|____________|___________|
| Off-hook | | | | |
|(Dialtone)| | | | |
| Digits | Notify | -> | | |
| | <- | Reply | | |
| | <- | Add | | |
| | Reply | -> | | |
| | | IAM | -> | |
| | | | Add | -> |
| | | | <- | Reply |
| | | <- | ACM | |
| | <- | Modify | | |
| | Reply | -> | | |
| | <- | Modify | | |
| ringback | | (Signal) | | |
|__________|___________|______________|____________|___________|
The additional messages added on top of those in scenario 1 are
....
* An IAM message is generated by MGC1
* The IAM message is transported to MGC2
....
* An ACM message is generated by MGC2
* The ACM message is transported to MGC1
....
Therefore, by adding the additional two independent random variables to
the PDD calculated in section 9.1, the resulting PDD for the current
scenario is:
PDD = 2*Tgc + 2*Tra + 8*Tcr + 2*Tcc + Trm ,
and has the statistic of
* Mean value 920 ms
* 95% of prob. not exceeding 1,156 ms
This scenario can be compared with the case in the PSTN that the called
party is served by a different Local Exchange than the calling party.
Without additional STPs involved in the connection and without
counting the transmission delay between two switches, the PDD in the
PSTN case is:
* Mean value 904 ms
* 95% of prob. not exceeding 1,127 ms
Lin, Yang, Seth, Huitema [page 15]
Internet-Draft VoIP Signaling Performance October, 1999
9.3. Scenario 3: Two ISDN Terminals under Different MGCs
In this scenario, we replace the RGW in the previous section with an
Access Gateway, and an ISDN terminal is connected to the Access Gateway.
The call connection model is shown in Figure 4.
______ ______ ______ ______ ______ ______
| ISDN | | | | | | | | | | ISDN |
|term 1|----| AGW1 |----| MGC1 |----| MGC2 |---| AGW2 |---|term 2|
|______| |______| |______| |______| |______| |______|
Figure 4. Call Connection Model for Scenario 3.
The portion of call flow that affects the PDD is shown as follows:
______________________________________________________________________
| Caller | AGW1 | MGC1 | MGC2 | AGW2 | Callee |
|__________|___________|____________|___________|___________|__________|
| Setup | ->- | -> | | | |
| | <- | Add | | | |
| | Reply | -> | | | |
| | | IAM | -> | | |
| | | | Add | -> | |
| | | | <- | Reply | |
| | | | Setup | ->- | -> |
| | | | <- | -<- | Alerting |
| | | <- | ACM | | |
| | <- | Modify | | | |
| | Reply | -> | | | |
| <- | -<- | Alerting | | | |
|__________|___________|____________|___________|___________|__________|
The ISDN Setup and Alerting messages are exchanged between the ISDN
terminal and the MGC via a relay in the AGW using a signaling back-haul
protocol. The AGW does not process the message itself.
Note that, after sending out the Setup message to the Called party, the
MGC2 can send a provisional message back to the MGC1 to inform it the
RTP connection information of AGW2, etc. In this case, the Modify
message MGC1 sends to AGW1 can overlay with the Alerting and ACM
messages, and thus the PDD can be reduced.
The resulting PDD for this scenario can be calculated as:
PDD = 2*Tgc + 2*Taa + 8*Tca + 2*Tcc + 4*Tia ,
and has the statistic of
Lin, Yang, Seth, Huitema [page 16]
Internet-Draft VoIP Signaling Performance October, 1999
* mean value 906 ms
* 95% of prob. not exceeding 1,140 ms
The processing of the ISDN Access message call segment, i.e. Setup
message, that contributes to the PDD in the PSTN scenario is replaced by
the Call Connection processing delay in the MGC and the Add Termination
processing delay in the Access Gateway. Therefore, there is no need to
add additional delay to the PDD. And since the PDD does not include the
seizure of a ringing circuit and initialization of the audible ring
signal to the caller [3], the PDD is over as soon as the caller's ISDN
terminal receives the Alerting message. As a result of the functional
differences of the network elements between the VoIP systems and the PSTN,
the PDD calculated for VoIP in this scenario is better than those in the
PSTN that is shown in Table 9.
9.4. Scenario 4: PSTN users connecting to TGWs
The last scenario we analyzed involves two PSTN users connected by two
Trunking Gateways under two different MGCs. The call connection model is
shown in Figure 5.
_____ _____ _____ ______ ______ _____ _____ _____
| | | | | | | | | | | | | | | |
| OLE |--| SG1 |--|TGW1 |--| MGC1 |--| MGC2 |--|TGW2 |--| SG2 |--| TLE |
|_____| |_____| |_____| |______| |______| |_____| |_____| |_____|
Figure 5. Call Connection Model for Scenario 4.
The portion of call flow that affects the PDD is illustrated as follows:
Lin, Yang, Seth, Huitema [page 17]
Internet-Draft VoIP Signaling Performance October, 1999
______________________________________________________________________
| OLE | SG1 | TGW1 | MGC1 | MGC2 | TGW2 | SG2 | TLE |
|______|________|________|_________|_________|_________|________|______|
| IAM | -> | | | | | | |
| | IAM | --- | -> | | | | |
| | | <- | Add | | | | |
| | | Reply | -> | | | | |
| | | | IAM | -> | | | |
| | | | | Add | -> | | |
| | | | | <- | Reply | | |
| | | | | IAM | --- | -> | |
| | | | | | | IAM | -> |
| | | | | | | <- | ACM |
| | | | | <- | --- | ACM | |
| | | | <- | ACM | | | |
| | | <- | Modify | | | | |
| | | Reply | -> | | | | |
| | <- | --- | ACM | | | | |
| <- | ACM | | | | | | |
|______|________|________|_________|_________|_________|________|______|
After the dialed digits are received by the Originating switch in the
Local Exchange, they are processed and an IAM message is generated. The
timing requirement for this is shown in Table 3. The IAM message is
transported to the MGC1 via a relay by a Signaling Gateway (SG1). As
mentioned in section 9.1, we use the cross-STP delay of 20 ms to
benchmark the performance requirement of the SGs. The same criterion is
applied to the ACM message generated by the Terminating switch.
Therefore, the PDD for this scenario is calculated as:
PDD = 2*Tgc + 2*Tta + 4*Tct + 2*Tcc + 4*Ts + 3*Tisup ,
and has a statistics of
* Mean value 1,626 ms
* 95% of prob. not exceeding 1,963 ms
This scenario can also be compared with the case in the PSTN that the
called party is served by a different Local Exchange than the calling
party. If we assume there are 3 switches and 3 STPs involved in the
connection, then the PDD (without counting transmission delay) can be
calculated as:
* Mean value 1,295 ms
* 95% prob. not exceeding 1,620 ms
Lin, Yang, Seth, Huitema [page 18]
Internet-Draft VoIP Signaling Performance October, 1999
10. Summary of PDD analysis for VoIP systems
As summarized in Table 11, the PDDs for various VoIP scenarios we
analyzed are mostly comparable with those in the PSTN. The only
exception is scenario 1 where the calling and called parties are in the
same Local Exchange. However, the PDD for this scenario is less than 1
second which can meet user's expectation easily. Since the most
expensive delay component is the MGC Connection Response Time based on
the analysis we have shown, an improvement in this element can bring
the PDD performance of VoIP systems closer to if not better than that of
the PSTN.
Table 11. Summary of PDD for Various Scenarios.
Scenario Post Dial Delay comparable case
in VoIP (ms) in PSTN (ms)
50% 95% 50% 95%
1. RGW1-MGC-RGW2 720 909 150 282
2. RGW1-MGC1-MGC2-RGW2 920 1,156 904 1,127
3. AGW1-MGC1-MGC2-AGW2 906 1,140 2,140 2,513
4. OLE-SG1-MGC1-MGC2-SG2-TLE 1,626 1,936 1,295 1,620
Acknowledgements
The authors would like to express their gratitude to Dr. Daniel Luan of
AT&T Labs for his insight into network operation and valuable
suggestions for calculating end-to-end signaling delays as well as call
setup delays in section 7.
References
[1] AT&T Webpage,
www.att.com/technology/technologists/fellows/lawser.html.
[2] ITU-T Recommendation Q.709, Specifications of Signaling System No.
7--Hypothetical Signaling Reference Connection, March 1993.
[3] Telcordia Technologies Generic Requirements GR-1364-CORE, Issue 1,
LSSGR: Switch Processing Time Generic Requirements Section 5.6,
June 1995.
[4] ITU-T Recommendation Q.706, Specifications of Signaling System No.
7--Message Transfer Part Signaling Performance, March 1993.
[5] ITU-T Recommendation Q.706, Specifications of Signaling System No.
7--Signaling performance in the Telephone Application, March 1993.
Lin, Yang, Seth, Huitema [page 19]
Internet-Draft VoIP Signaling Performance October, 1999
[6] Telcordia Technologies TR-TSY-000511, LSSGR: Service Standards,
Section 11, Issue 2, July 1987.
[7] Brian Rosen, et. al., "Megaco Protocol",
draft-ietf-megaco-protocol-04.txt, September 21, 1999.
[8] Christian Huitema, et.al., "Media Gateway Control Protocol (MGCP)
Call Flows", draft-huitema-megaco-mgcp-flows-01.txt, January 20,
1999.
Authors' addresses
Huai-An Lin
Telcordia Technologies
445 South Street, MCC-1A216R
Morristown, NJ 07960-6438
Phone: 973 829-2412
Email: hlin@research.telcordia.com
Kun-Min Yang
Telcordia Technologies
331 Newman Springs Road, NVC-3X311
Red Bank, NJ 07701
Phone: 732 758-4034
Email: dyang@research.telcordia.com
Taruni Seth
Telcordia Technologies
445 South Street, MCC-1G209R
Morristown, NJ 07960-6438
Phone: 973 829-4046
Email: taruni@research.telcordia.com
Christian Huitema
Telcordia Technologies
445 South Street, MCC-1J244B
Morristown, NJ 07960-6438
Phone: 973 829-4266
Email: huitema@research.telcordia.com
Lin, Yang, Seth, Huitema [page 20]
Internet-Draft VoIP Signaling Performance October, 1999