idnits 2.17.1 draft-ietf-sigtran-performance-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 126 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 826 has weird spacing: '...l Delay com...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-08) exists of draft-ietf-megaco-protocol-04 ** Downref: Normative reference to an Historic draft: draft-ietf-megaco-protocol (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force 2 INTERNET DRAFT Authors 3 Signaling Transport Working Group Huai-An P. Lin 4 October 22, 1999 Kun-Min Yang 5 Expires March 22, 2000 Taruni Seth 6 Christian Huitema 7 Telcordia Technologies 9 VoIP Signaling Performance Requirements and Expectations 10 12 Status of this document 14 This document is an Internet-Draft and is in full conformance with all 15 provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document serves as input into the IETF SIGTRAN requirements 34 process. It includes call setup delay requirements, derived from 35 relevant ISDN and SS7 standards published by ITU-T (International 36 Telecommunications Union--Telecommunications Standardization Sector) and 37 generic requirements published by Telcordia Technologies (formerly 38 Bellcore). To gain user acceptance of Voice-over-IP (VoIP) services and 39 to enable interoperability between Switched Circuit Networks (SCNs) and 40 VoIP systems, it is imperative that the VoIP signaling performance be 41 comparable to that of the current SCNs. The requirements given in this 42 Internet Draft are intended to be the worst-case requirements, for at 43 least in the United States SCN calls are typically set up at a faster 44 speed than the derived requirements. At the end of the draft, several 45 VoIP call connection scenarios based on the latest megaco protocol are 46 analyzed and compared with similar cases in the PSTN. It indicates the 47 PDD performance of VoIP systems is somewhat worst but not by much. An 48 improvement in some network element can bring VoIP systems to have 49 comparable PDD performance as the PSTN. 51 1. Introduction 53 This document serves as input into the IETF SIGTRAN requirements 54 process. It includes call setup delay requirements, derived from 55 relevant ISDN and SS7 standards published by ITU-T (International 56 Telecommunications Union--Telecommunications Standardization Sector) and 57 generic requirements published by Telcordia Technologies (formerly 58 Bellcore). To gain user acceptance of VoIP services and to enable 59 interoperability between SCNs and VoIP systems, it is imperative that 60 the VoIP signaling performance be comparable to that of the current SCNs. 61 The requirements given in this Internet Draft are intended to be the 62 worst-case requirements, since at least in the United States SCN calls 63 are typically set up within one to two seconds [1]--far faster than the 64 derived requirements. 66 The call setup delay, also known as the Post Dial Delay (PDD), in an ISDN- 67 SS7 environment is the period that starts when an ISDN user dials the 68 last digit of the called number and ends when the user receives the last 69 bit of the Alerting message. Call setup delays are not explicitly given 70 in the existing SCN performance requirements; rather, performances of 71 SCNs are typically expressed in terms of cross-switch (or cross-office) 72 transfer times. This Internet Draft uses ITU-T's SS7 Hypothetical 73 Signaling Reference Connection (HSRC) [2], cross-STP (Signaling Transfer 74 Point) time [3], Telcordia's switch response time generic requirements 75 [4], and a simple ISDN-SS7 call flow to derive the call setup delay 76 requirements. ITU-T's cross-switch time requirements [5] are listed as 77 references but not used, since the ISDN timings are missing. 79 At the end of the draft, we evaluate the PDD of VoIP systems based on 80 the proposed megaco protocol and compare its PDD performance with that 81 of the current PSTN. It gives a better understanding of where 82 the bottleneck is and hopefully suggest the area of improvement that can 83 be done in VoIP systems to achieve comparable performance. 85 2. Hypothetical Signaling Reference Connection (HSRC) 87 HSRC is specified in ITU-T Recommendation Q.709. A HSRC is made up by a 88 set of signaling points and STPs that are connected in series by 89 signaling data links to produce a signaling connection. Recommendation 90 Q.709 distinguishes the national components from the international 91 components. A HSRC for international working consists of an 92 international component and two national components. The size of each 93 country is considered; however, the definitions of large and average 94 countries was not precisely defined: 96 When the maximum distance between an international switching center and 97 a subscriber who can be reached from it does not exceed 1000 km or, 98 exceptionally, 1500 km, and when the country has less than n x 10E7 99 subscribers, the country is considered to be of average-size. A country 100 with a larger distance between an international switching center and a 101 subscriber, or with more than n x 10E7 subscribers, is considered to be 102 of large-size. (The value of n is for further study.) 104 Recommendation Q.709 uses a probabilistic approach to specify the number 105 of signaling points and STPs on a signaling connection. The maximum 106 number of signaling points and STPs allowed in a national component and 107 an international component are listed in Tables 1 and 2, respectively. 109 Table 1: Maximum Number of Signaling Points and STPs in a National 110 Component (Source: ITU-T Recommendation Q.709, Table 3) 112 Country size Percent of Number of Number of 113 connections STPs signaling points* 115 Large-size 50% 3 3 116 95% 4 4 118 Average-size 50% 2 2 119 95% 3 3 121 * The terms signaling points and switches are used interchangeably in 122 this Internet Draft. 124 Table 2: Maximum Number of Signaling Points and STPs in International 125 Component (Source: ITU-T Recommendation Q.709, Table 1) 127 Country size Percent of Number of Number of 128 connections STPs signaling points 130 Large-size 50% 3 3 131 to 132 Large-size 95% 4 3 134 Large-size 50% 4 4 135 to 136 Average-size 95% 5 4 138 Average-size 50% 5 5 139 to 140 Average-size 95% 7 5 142 3. Switch Response Time (aka Cross-switch Transfer Time) 144 Most of SCN performance requirements are specified in terms of switch 145 response times, which are also referred to as cross-switch transport 146 time or cross-switch delay. This section reviews the meanings of switch 147 response times, several other related terms, and the generally accepted 148 values of switch response times published by Telcordia Technologies. The 149 corresponding ITU-T's cross-switch timing requirements are also listed 150 as references. 152 This Internet Draft reviews the switch response time requirements 153 intended to apply under normal loading. Normal loading is usually 154 associated with the notion of the Average Busy Season Busy Hour (ABSBH) 155 load. Simply put, it is expected that the switch response times that a 156 particular switch experiences at this load will be virtually load- 157 independent. 159 Switch response time is the period that starts when a stimulus occurs at 160 the switch and ends when the switch completes its response to the 161 stimulus. The occurrence of a stimulus often means the switch receives 162 the last bit of a message from an incoming signaling link, and 163 completion of a response means the switch transmits the last bit of the 164 message on the outgoing signaling link. If the switch's response to a 165 stimulus involves the switch sending a message on the outgoing signaling 166 link, then switch processing time is the sum of the switch processing 167 time and the link output delay: 169 Switch Response Time = Switch Processing Time + Link Output Delay 170 Switch processing time is the period that starts when a stimulus occurs 171 at the switch and ends when the switch places the last bit of the 172 message in the output signaling link controller buffer. The period 173 between the switch placing the message in the output signaling link 174 controller buffer and the switch transmitting the last bit of the 175 message on the outgoing signaling link is defined as the link output 176 delay. Link output delay can be further divided into the queuing delay 177 and message emission time. There are separate delay requirements for 178 switch processing time and link output delay; however, for simplicity 179 only the combined delay requirements for switch response time, as given 180 in Table 3, will be listed in this Internet Draft. 182 Table 3: Switch Response Time Assuming Typical Traffic Mix and 183 Message Lengths (Source: Telcordia GR-1364-CORE, Table 5-1) 185 Type of Call Segment Switch Response Time (ms) 186 Mean 95% 187 ISUP Message 205-218 <=337-349 188 Alerting 400 <=532 189 ISDN Access Message 220-227 <=352-359 190 TCAP Message 210-222 <=342-354 191 Announcement/Tone 300 <=432 192 Connection 300 <=432 193 End MF Address - Seize 150 <=282 195 Telcordia GR-1364 specifies switch response time using switch call 196 segments as a convenient way to refer to the various phases of call 197 processing that switches are involved in. (An alternative would be 198 proposing switch processing requirements for every possible type of 199 switch processing. Obviously, this would become burdensome and would 200 necessitate adding to the requirements every time an additional type of 201 switch processing was required.) Listed in Table 3 are: 203 1. ISUP message call segments that involve the switch sending an ISUP 204 message as a result of a stimulus. 205 2. Alerting call segments that involve the switch alerting the 206 originating and/or terminating lines as a result of a stimulus. 207 3. ISDN access message call segments that involve the switch sending an 208 ISDN access message (other than an ISDN access ALERT message) as a 209 result of stimulus. ISDN access message call segment processing 210 occurs at originating or terminating switches where the originating 211 or terminating line, respectively, is an ISDN line. 212 4. TCAP message call segments that involve the switch sending a TCAP 213 message as a result of a stimulus. 214 5. Announcement/tone call segments that involve the switch playing an 215 announcement, placing a tone on, or removing a tone from the 216 originating or terminating line as a result of a stimulus. However, 217 the announcement/tone call segments do not include dial-tone delay, 218 of which the delay requirements can be found in Telcordia 219 TR-TSY-000511[6]. 220 6. Connection call segments involve the switch connecting one or more 221 users as a result of a stimulus. 223 The ITU-T's cross-switch timing requirements are listed below as 224 references. It is noted that the ITU-T's requirements are noticeably 225 stringent that those of Telcordia under the normal loading. However, 226 since the ITU-T's values are stated as provisional and they do not 227 provide the timing requirements for ISDN, Telcordia's values will be 228 used to derive the call setup delay requirements. 230 Table 4: ITU-T Cross-Switch Transfer Time 231 (Source: ITU-T Recommendation Q.725, Table 3) 232 Exchange call Cross-Switch Transfer 233 Time (ms)* 234 Message type attempt loading Mean 95% 236 Simple Normal 110 220 237 (e.g. answer) +15% 165 330 238 +30% 275 550 240 Processing Normal 180 360 241 intensive +15% 270 540 242 (e.g. IAM) +30% 450 900 244 * Provisional values. 246 4. Cross-STP Delay 248 Message delay through an STP is specified as the cross-STP delay. It is 249 the interval that begins when the STP receives the last bit of a message 250 from the incoming signaling link, and ends when the STP transmits the 251 last bit of the message on the outgoing signaling link. As with the 252 switch response time discussed in the previous section, the cross-STP 253 can be divided into processor handling time and link output delay. This 254 Internet Draft adopts the cross-STP delay requirements specified in ITU- 255 T Q.706 Recommendation. 257 Table 5: Message transfer time at an STP 258 (Source: ITU-T Recommendation Q.706, Table 5) 260 Message transfer Time (ms) 261 STP signaling traffic load Mean 95% 263 Normal 20 40 264 +15% 40 80 265 +30% 100 200 267 5. Maximum End-to-End Signaling Delays 269 Using the HSRC, switch response times, and cross-STP delays, one can 270 compute the maximum signaling transfer delays for ISUP messages under 271 normal load. As with Telcordia GR-1364, it is assumed that the 272 distribution of switch response time for each call segment is 273 approximately a normal distribution. It is further assumed that switch 274 response times of different switches are independent. Under these 275 assumptions, the end-to-end (from originating switch to terminating 276 switch) delays for each national component and for international calls 277 are listed in Tables 6 and 7, respectively. The 20 ms cross-STP delay is 278 assumed in all cases. It should be noted that all these values must be 279 increased by the transmission propagation delays, which are listed in 280 Table 8. 282 Table 6: Maximum ISUP Signal Transfer Delays for Each National Component 284 Country size Percent of Delay (ms) 285 connections Mean 95% 287 Large-size 50% 675-714 <=904-941 288 95% 900-952 <=1164-1214 290 Average-size 50% 450-476 <=637-661 291 95% 675-714 <=904-941 293 Table 7: Maximum ISUP Signal Transfer Delays for International Calls 295 Country size Percent of Delay (ms) 296 connections Mean 95% 298 Large-size to 50% 2025-2142 <=2421-2538 299 Large-size 95% 2495-2638 <=2933-3076 301 Large-size to 50% 2250-2380 <=2677-2797 302 Average-size 95% 2720-2876 <=3177-3333 304 Average-size to 50% 2475-2618 <=2913-3056 305 Average-size 95% 2965-3134 <=3441-3610 307 Table 8: Calculated Terrestrial Transmission Delays for Various Call 308 Distances (Source: ITU-T Recommendation Q.706, Table 1) 310 Arc length Delay terrestrial (ms) 311 (km) Wire Fiber Radio 312 500 2.4 2.5 1.7 313 1000 4.8 5.0 3.3 314 2000 9.6 10.0 6.6 315 5000 24.0 25.0 16.5 316 10000 48.0 50.0 33.0 317 15000 72.0 75.0 49.5 318 17737 85.1 88.7 58.5 319 20000 96.0 100.0 66.0 320 25000 120.0 125.0 82.5 322 6. Basic Call Flow and Call Setup Delays 324 The following figure illustrates the simplest call flow for call setup 325 in an ISDN-SS7 environment. The end user terminals are assumed to be 326 ISDN phones and use Q.931 messages (i.e., Setup and Alerting). The 327 switches use ISUP messages to establish inter-switch trunks for the 328 subsequent voice communication. 330 Caller Originating Terminating Called 331 Terminal Switch Switch Terminal 332 | | | | 333 | Setup | | | 334 |---------------->| | | 335 | | IAM IAM | | 336 | |------> . . . . ------>| | 337 | | | Setup | 338 | | |-------------->| 339 | | | | 340 | | | Alerting | 341 | | |<--------------| 342 | | ACM ACM | | 343 | |<------ . . . . <------| | 344 | Alerting | | | 345 |<----------------| | | 346 | | | | 347 | | | | 349 Figure 1: Simple Call Setup Signaling Flow 351 Using the above call flow, the end-to-end message transfer delays in 352 Tables 6 and 7, and the switch response times for Q.931 messages in 353 Table 3, one can derive the call setup times given in the following 354 tables. Again, all these values must be increased by the transmission 355 propagation delays listed in Table 8. 357 Table 9: Call Setup Delays for Each National Component 359 Country size Percent of Call Setup Delay (ms) 360 connections Mean 95% 362 Large-size 50% 2590-2682 <=3007-3099 363 95% 3040-3158 <=3497-3615 365 Average-size 50% 2140-2206 <=2513-2579 366 95% 2590-2682 <=3007-3099 368 Table 10: Call Setup Delays for International Calls 370 Country size Percent of Delay (ms) 371 connections Mean 95% 373 Large-size to 50% 5290-5538 <=5909-6157 374 Large-size 95% 6230-6530 <=6903-7203 376 Large-size to 50% 5740-6014 <=6387-6661 377 Average-size 95% 6680-7006 <=7378-7704 379 Average-size to 50% 6190-6490 <=6863-7163 380 Average-size 95% 7170-7522 <=7893-8245 382 7. User Expectations 384 The requirements derived in the previous section should be interpreted 385 as the worst-case requirements. At least in the United States, users of 386 SCN typically experience far less setup delays than the derived delay 387 requirements. With the maturing of Common Channel Signaling (CCS) 388 Network, call setup time has been reduced to a mere one to two seconds 389 [1]. The VoIP networks are expected to achieve the same level of delay 391 There is no known study on expected setup delays for international 392 calls. As discussed, a HSRC for international working consists of an 393 international component and two national components, and the maximum 394 number of signaling points and STPs in a national component is roughly 395 the same as the number in an international component (Tables 1 and 2). 396 As a consequence, the end-to-end ISUP delays in an international call 397 are roughly three times of those in a national call. On the other hand, 398 the Q.931 signals occur only at the two ends for both national and 399 international calls. Based on these observations, one may expect 2.5-5 400 second call setup delays to be reasonable for international calls. 402 8. Post Dial Delay in VoIP Systems 404 After deriving the PDD requirements in the PSTN, it's important to check 405 if VoIP systems can meet those requirements. 407 In the following sections, we will evaluate several VoIP systems, 408 illustrate the call flow that contributes to the PDD, and analyze the 409 PDD in terms of delay in network elements. We emphasize that the intend 410 for this analysis is not to set the requirement for VoIP systems, but 411 rather to gain further understanding of the PDD expectation in VoIP 412 services. 414 For definition of Media Gateway (MG), Media Gateway Controller (MGC), 415 Residential Gateway (RGW), Trunking Gateway (TGW), Access Gateway (AGW), 416 and Signaling Gateway (SG), please refer to [7]. 418 8.1. Methodology and Assumptions 420 The VoIP systems we intend to investigate are based on the architecture 421 and protocol defined in megaco WG [7]. The set of commands megaco 422 protocol specifies is "Add", "Modify", "Subtract", "Move", "AuditValue", 423 "AuditCapacity", "Notify", and "ServiceChange". The Post Dial Delay is a 424 function of the Response Time in each network element (e.g. RGW, MGC), 425 and the Transmission Delay between network elements. The Response Time 426 can be divided into the Processing Time and the Link Output time. The 427 Processing Time required by a network element depends on the command it 428 receives and the state of the call connection at that time. It is defined 429 as the period that starting when a stimulus occurs at the network element 430 (e.g., when the network element receives the last bit of a message from 431 the incoming signaling link) and ending when the network element places 432 the last bit of the message in the output signaling link controller 433 buffer. [3] 435 The PDD analysis is based on the call flow derived from the megaco 436 protocol and only the portion that contributes to the PDD needs to be 437 considered. In the following section, we will show only "Add", "Modify", 438 "Notify" and their Reply messages are used to calculate the PDD. 440 For the purpose of comparing the performance of the VoIP systems with 441 that of the PSTN, we assume network elements in each system have 442 comparable Processing Time for executing the same or similar function in 443 a call connection setup. The comparison then can be made based on the 444 system complexity (i.e. number of components) and the set of messages 445 (i.e. the number and types of commands) need to be exchanged and executed. 446 More specifically, we assume the response time to create a connection in 447 a VoIP system (i.e. Add Termination processing in both the MGC and a MG) 448 is comparable with that of a Connection call segment in a PSTN switch 449 (i.e. the Connection in Table 3, which has a mean value of 300 ms and 95% 450 of prob. not exceeding 432 ms). The split of this Connection Response Time 451 into delay components in MGC and MG depends on the implementation itself. 452 We use 80-90% of it for MGC processing assuming most of the intelligent 453 functionality of a switch now reside in the MGC. The processing for a 454 Modify Termination command is expected to be close to or less than that of 455 an Add Termination command. Also, the processing time for the TGW is 456 expected to be larger than that for RGW. 458 Therefore, we define: 459 * MGC Connection Response Time - The call segment for which MGC 460 processing involves the MGC sending an "Add" command as a result of 461 a stimulus. 462 * MG Add Termination Response Time - The call segment for which 463 MG processing involves the MG adding a termination to a context and 464 sending a reply message as a result of receiving an "Add" command. 465 * MG Modify Termination Response Time - The call segment for which 466 MG processing involves the MG modifying a termination in a context 467 and sending a reply message as a result of receiving a "Modify" 468 command. 470 The Signaling Gateway can reside close to the MGC if not in the same 471 host, the Transmission Delay between them is negligible in comparison 472 with the expected PDD values in Table 9. The Signaling Gateway relays 473 signaling message between the PSTN and the MGC, it is assumed to act 474 like an STP in the PSTN, and the cross-STP delay is used for the 475 Processing Time in the SGs. 477 Therefore, we define: 478 * SG Response Time - The call segment for which SG processing involves 479 a SG sending a message to the MGC or the PSTN as a result of a 480 stimulus. 482 In the VoIP scenario, the processing of the call setup messages in the 483 MGC and AGWs is taken to be comparable to the processing of the ISDN 484 Access message call segment, i.e. Setup message, that contributes to the 485 PDD in the PSTN scenario. Further, the terminating switch in the PSTN 486 usually needs to generate the ringback tone after receiving an Alerting 487 message from the called ISDN terminal. However, in the VoIP systems, the 488 terminating AGW do not have to generate the ringback tone. Instead, 489 the ringback tone can be generated by the originating AGW. Therefore, 490 the processing delay for Alerting message at the terminating AGW in 491 the VoIP scenario can be reduced. 493 The Transmission Delay in an IP network has different characteristics 494 from that in an SS7 network. We gathered some experiment data from the 495 Internet and applied them for the purpose of this analysis. More data 496 based on the methodology being defined in the IPPM WG can refine the 497 characteristics of the Transmission Delay in the future. 499 For ease of manipulation, we define: 500 * Tgc - MGC Connection Response Time. 501 * Tta - TGW Add Termination Response Time. 502 * Tra - RGW Add Termination Response Time. 503 * Taa - AGW Add Termination Response Time. 504 * Ttm - TGW Modify Termination Response Time. 505 * Trm - RGW Modify Termination Response Time. 506 * Tam - AGW Modify Termination Response Time. 507 * Tcc - Transmission delay between two MGCs. 508 * Tcr - Transmission delay between a MGC and a RGW. 509 * Tct - Transmission delay between a MGC and a TGW. 510 * Tca - Transmission delay between a MGC and a AGW. 511 * Tia - Transmission delay between a user's ISDN terminal and a AGW. 512 * Ts - SG Response Time. 513 * Tisup - ISUP message call segment Response Time. 515 We assume the delays in network elements are mutually independent of 516 each other and have Normal distributions. 518 In summary, the tentative statistics we use for this draft is as 519 follows: 521 Table 11: Network Element Processing Time in VoIP. 523 Processing Time (ms) 524 50% 95% 525 Tgc 255 380 526 Tra/Trm 30 60 527 Taa/Tam 30 60 528 Tta/Ttm 60 120 529 Tcc 100 200 530 Tcr 15 20 531 Tct 20 30 532 Tca 15 20 533 Ts 20 40 535 9. PDD Analysis for VoIP scenarios 537 In this section, we derived four call connection scenarios. For each 538 scenario, we first illustrate the portion of the call flow that 539 contribute to the PDD, then we calculate the PDD based on the assumed 540 characteristics mentioned in the last section. 542 9.1. Scenario 1: Two Residential Gateways under a MGC 544 We start with a simple scenario where two Residential Gateways (RGW1 & 545 RGW2) and a Media Gateway Controller (MGC) are involved in a call 546 connection as shown in Figure 2. Both of the RGWs are controlled under 547 the same MGC. 549 ______ _____ ______ 550 | | | | | | 551 | RGW1 |----| MGC |----| RGW2 | 552 |______| |_____| |______| 554 Figure 2. Call Connection Model, Scenario 1. 556 The call flows we use for the PDD analysis in this draft are derived 557 from those in [8], and we substitute the commands with the corresponding 558 ones specified in the latest draft of megaco protocol [7]. The portion 559 of the call flow that affects the PDD in scenario 1 is illustrated as 560 follows: 562 _________________________________________________ 563 | Usr | RGW1 | MGC | RGW2 | 564 |__________|___________|______________|___________| 565 | Off-hook | | | | 566 |(Dialtone)| | | | 567 | Digits | Notify | -> | | 568 | | <- | Reply | | 569 | | <- | Add | | 570 | | Reply | -> | | 571 | | | Add | -> | 572 | | | <- | Reply | 573 | | <- | Modify | | 574 | | Reply | -> | | 575 | | <- | Modify | | 576 | ringback | | (Signal) | | 577 |__________|___________|______________|___________| 579 The sequence of messages must be processed successfully before a 580 ringback tone can be posted to the caller is as follows: 582 * A Notify message is generated with collected digits by RGW1. 583 * The Notify message is transported to the MGC. 584 * The Notify message is processed by the MGC, call connection resource 585 is set in the MGC, an Add message is generated by the MGC. 586 * The Add message is transported to the RGW1. 587 * The Add message is processed by the RGW1, a connection is made in the 588 RGW1, a Reply message is generated by the RGW1. 589 * The Reply message is transported to the MGC. 590 * The Reply message is processed by the MGC, call connection resource 591 is modified in the MGC, another Add message is generated by the MGC. 592 * The Add message is transported to the RGW2. 593 * The Add message is processed by the RGW2, a connection is made in the 594 RGW2, a Reply message is generated by the RGW2. 595 * The Reply message is transported to the MGC. 597 * The Reply message is processed by the MGC, call connection resource 598 is modified in the MGC, a Modify message is generated by the MGC. 599 * The Modify message is transported to the RGW1. 600 * The Modify message is processed by the RGW1, the connection in RGW1 601 is modified, a Reply message is generated by the RGW1. 602 * The Reply message is transported to the MGC. 603 * The Reply message is processed by the MGC, a Modify message is 604 generated by the MGC for signaling a ringback tone request. 605 * The Modify message is transported to the RGW1. 607 After applying the statistics in Table 11 on delay components above, the 608 PDD for this scenario is calculated as: 610 PDD = 2*Tgc + 2*Tra + 8*Tcr + Trm , 612 and has the statistic of 614 * Mean value 720 ms 615 * 95% prob. not exceeding 909 ms 617 This scenario can be compared with the case in the PSTN that both the 618 calling and called parties are served by the same Local Exchange. The 619 switch response time can be found in Table 3 as: 621 * Mean value 150 ms 622 * 95% prob. not exceeding 282 ms 624 9.2. Scenario 2: Two RGWs under Two Different MGCs 626 The difference between this scenario and the previous one is that the 627 second Residential Gateway is controlled by a different MGC, i.e. MGC2. 628 Some extra messages need to be exchanged between the two MGCs to achieve 629 the call connection. 631 ______ ______ ______ ______ 632 | | | | | | | | 633 | RGW1 |----| MGC1 |----| MGC2 |---| RGW2 | 634 |______| |______| |______| |______| 636 Figure 3. Call Connection Model for Scenario 2. 638 The portion of the call flow that affects the PDD for this scenario is 639 illustrated as follows: 641 ______________________________________________________________ 642 | Usr | RGW1 | MGC1 | MGC2 | RGW2 | 643 |__________|___________|______________|____________|___________| 644 | Off-hook | | | | | 645 |(Dialtone)| | | | | 646 | Digits | Notify | -> | | | 647 | | <- | Reply | | | 648 | | <- | Add | | | 649 | | Reply | -> | | | 650 | | | IAM | -> | | 651 | | | | Add | -> | 652 | | | | <- | Reply | 653 | | | <- | ACM | | 654 | | <- | Modify | | | 655 | | Reply | -> | | | 656 | | <- | Modify | | | 657 | ringback | | (Signal) | | | 658 |__________|___________|______________|____________|___________| 660 The additional messages added on top of those in scenario 1 are 662 .... 663 * An IAM message is generated by MGC1 664 * The IAM message is transported to MGC2 665 .... 666 * An ACM message is generated by MGC2 667 * The ACM message is transported to MGC1 668 .... 670 Therefore, by adding the additional two independent random variables to 671 the PDD calculated in section 9.1, the resulting PDD for the current 672 scenario is: 674 PDD = 2*Tgc + 2*Tra + 8*Tcr + 2*Tcc + Trm , 676 and has the statistic of 678 * Mean value 920 ms 679 * 95% of prob. not exceeding 1,156 ms 681 This scenario can be compared with the case in the PSTN that the called 682 party is served by a different Local Exchange than the calling party. 683 Without additional STPs involved in the connection and without 684 counting the transmission delay between two switches, the PDD in the 685 PSTN case is: 687 * Mean value 904 ms 688 * 95% of prob. not exceeding 1,127 ms 689 9.3. Scenario 3: Two ISDN Terminals under Different MGCs 691 In this scenario, we replace the RGW in the previous section with an 692 Access Gateway, and an ISDN terminal is connected to the Access Gateway. 693 The call connection model is shown in Figure 4. 695 ______ ______ ______ ______ ______ ______ 696 | ISDN | | | | | | | | | | ISDN | 697 |term 1|----| AGW1 |----| MGC1 |----| MGC2 |---| AGW2 |---|term 2| 698 |______| |______| |______| |______| |______| |______| 700 Figure 4. Call Connection Model for Scenario 3. 702 The portion of call flow that affects the PDD is shown as follows: 704 ______________________________________________________________________ 705 | Caller | AGW1 | MGC1 | MGC2 | AGW2 | Callee | 706 |__________|___________|____________|___________|___________|__________| 707 | Setup | ->- | -> | | | | 708 | | <- | Add | | | | 709 | | Reply | -> | | | | 710 | | | IAM | -> | | | 711 | | | | Add | -> | | 712 | | | | <- | Reply | | 713 | | | | Setup | ->- | -> | 714 | | | | <- | -<- | Alerting | 715 | | | <- | ACM | | | 716 | | <- | Modify | | | | 717 | | Reply | -> | | | | 718 | <- | -<- | Alerting | | | | 719 |__________|___________|____________|___________|___________|__________| 721 The ISDN Setup and Alerting messages are exchanged between the ISDN 722 terminal and the MGC via a relay in the AGW using a signaling back-haul 723 protocol. The AGW does not process the message itself. 725 Note that, after sending out the Setup message to the Called party, the 726 MGC2 can send a provisional message back to the MGC1 to inform it the 727 RTP connection information of AGW2, etc. In this case, the Modify 728 message MGC1 sends to AGW1 can overlay with the Alerting and ACM 729 messages, and thus the PDD can be reduced. 731 The resulting PDD for this scenario can be calculated as: 733 PDD = 2*Tgc + 2*Taa + 8*Tca + 2*Tcc + 4*Tia , 735 and has the statistic of 736 * mean value 906 ms 737 * 95% of prob. not exceeding 1,140 ms 739 The processing of the ISDN Access message call segment, i.e. Setup 740 message, that contributes to the PDD in the PSTN scenario is replaced by 741 the Call Connection processing delay in the MGC and the Add Termination 742 processing delay in the Access Gateway. Therefore, there is no need to 743 add additional delay to the PDD. And since the PDD does not include the 744 seizure of a ringing circuit and initialization of the audible ring 745 signal to the caller [3], the PDD is over as soon as the caller's ISDN 746 terminal receives the Alerting message. As a result of the functional 747 differences of the network elements between the VoIP systems and the PSTN, 748 the PDD calculated for VoIP in this scenario is better than those in the 749 PSTN that is shown in Table 9. 751 9.4. Scenario 4: PSTN users connecting to TGWs 753 The last scenario we analyzed involves two PSTN users connected by two 754 Trunking Gateways under two different MGCs. The call connection model is 755 shown in Figure 5. 757 _____ _____ _____ ______ ______ _____ _____ _____ 758 | | | | | | | | | | | | | | | | 759 | OLE |--| SG1 |--|TGW1 |--| MGC1 |--| MGC2 |--|TGW2 |--| SG2 |--| TLE | 760 |_____| |_____| |_____| |______| |______| |_____| |_____| |_____| 762 Figure 5. Call Connection Model for Scenario 4. 764 The portion of call flow that affects the PDD is illustrated as follows: 766 ______________________________________________________________________ 767 | OLE | SG1 | TGW1 | MGC1 | MGC2 | TGW2 | SG2 | TLE | 768 |______|________|________|_________|_________|_________|________|______| 769 | IAM | -> | | | | | | | 770 | | IAM | --- | -> | | | | | 771 | | | <- | Add | | | | | 772 | | | Reply | -> | | | | | 773 | | | | IAM | -> | | | | 774 | | | | | Add | -> | | | 775 | | | | | <- | Reply | | | 776 | | | | | IAM | --- | -> | | 777 | | | | | | | IAM | -> | 778 | | | | | | | <- | ACM | 779 | | | | | <- | --- | ACM | | 780 | | | | <- | ACM | | | | 781 | | | <- | Modify | | | | | 782 | | | Reply | -> | | | | | 783 | | <- | --- | ACM | | | | | 784 | <- | ACM | | | | | | | 785 |______|________|________|_________|_________|_________|________|______| 787 After the dialed digits are received by the Originating switch in the 788 Local Exchange, they are processed and an IAM message is generated. The 789 timing requirement for this is shown in Table 3. The IAM message is 790 transported to the MGC1 via a relay by a Signaling Gateway (SG1). As 791 mentioned in section 9.1, we use the cross-STP delay of 20 ms to 792 benchmark the performance requirement of the SGs. The same criterion is 793 applied to the ACM message generated by the Terminating switch. 795 Therefore, the PDD for this scenario is calculated as: 797 PDD = 2*Tgc + 2*Tta + 4*Tct + 2*Tcc + 4*Ts + 3*Tisup , 799 and has a statistics of 801 * Mean value 1,626 ms 802 * 95% of prob. not exceeding 1,963 ms 804 This scenario can also be compared with the case in the PSTN that the 805 called party is served by a different Local Exchange than the calling 806 party. If we assume there are 3 switches and 3 STPs involved in the 807 connection, then the PDD (without counting transmission delay) can be 808 calculated as: 810 * Mean value 1,295 ms 811 * 95% prob. not exceeding 1,620 ms 812 10. Summary of PDD analysis for VoIP systems 814 As summarized in Table 11, the PDDs for various VoIP scenarios we 815 analyzed are mostly comparable with those in the PSTN. The only 816 exception is scenario 1 where the calling and called parties are in the 817 same Local Exchange. However, the PDD for this scenario is less than 1 818 second which can meet user's expectation easily. Since the most 819 expensive delay component is the MGC Connection Response Time based on 820 the analysis we have shown, an improvement in this element can bring 821 the PDD performance of VoIP systems closer to if not better than that of 822 the PSTN. 824 Table 11. Summary of PDD for Various Scenarios. 826 Scenario Post Dial Delay comparable case 827 in VoIP (ms) in PSTN (ms) 828 50% 95% 50% 95% 829 1. RGW1-MGC-RGW2 720 909 150 282 830 2. RGW1-MGC1-MGC2-RGW2 920 1,156 904 1,127 831 3. AGW1-MGC1-MGC2-AGW2 906 1,140 2,140 2,513 832 4. OLE-SG1-MGC1-MGC2-SG2-TLE 1,626 1,936 1,295 1,620 834 Acknowledgements 836 The authors would like to express their gratitude to Dr. Daniel Luan of 837 AT&T Labs for his insight into network operation and valuable 838 suggestions for calculating end-to-end signaling delays as well as call 839 setup delays in section 7. 841 References 843 [1] AT&T Webpage, 844 www.att.com/technology/technologists/fellows/lawser.html. 846 [2] ITU-T Recommendation Q.709, Specifications of Signaling System No. 847 7--Hypothetical Signaling Reference Connection, March 1993. 849 [3] Telcordia Technologies Generic Requirements GR-1364-CORE, Issue 1, 850 LSSGR: Switch Processing Time Generic Requirements Section 5.6, 851 June 1995. 853 [4] ITU-T Recommendation Q.706, Specifications of Signaling System No. 854 7--Message Transfer Part Signaling Performance, March 1993. 856 [5] ITU-T Recommendation Q.706, Specifications of Signaling System No. 857 7--Signaling performance in the Telephone Application, March 1993. 859 [6] Telcordia Technologies TR-TSY-000511, LSSGR: Service Standards, 860 Section 11, Issue 2, July 1987. 862 [7] Brian Rosen, et. al., "Megaco Protocol", 863 draft-ietf-megaco-protocol-04.txt, September 21, 1999. 865 [8] Christian Huitema, et.al., "Media Gateway Control Protocol (MGCP) 866 Call Flows", draft-huitema-megaco-mgcp-flows-01.txt, January 20, 867 1999. 869 Authors' addresses 871 Huai-An Lin 872 Telcordia Technologies 873 445 South Street, MCC-1A216R 874 Morristown, NJ 07960-6438 875 Phone: 973 829-2412 876 Email: hlin@research.telcordia.com 878 Kun-Min Yang 879 Telcordia Technologies 880 331 Newman Springs Road, NVC-3X311 881 Red Bank, NJ 07701 882 Phone: 732 758-4034 883 Email: dyang@research.telcordia.com 885 Taruni Seth 886 Telcordia Technologies 887 445 South Street, MCC-1G209R 888 Morristown, NJ 07960-6438 889 Phone: 973 829-4046 890 Email: taruni@research.telcordia.com 892 Christian Huitema 893 Telcordia Technologies 894 445 South Street, MCC-1J244B 895 Morristown, NJ 07960-6438 896 Phone: 973 829-4266 897 Email: huitema@research.telcordia.com