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 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