.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .LP \fBMONTAGE: FIN DU \(sc 2.3.11 EN T\* | TE DE CETTE PAGE\fR .sp 1P .LP \v'34P' 2.4 \fIDelay probability\fR \fI\(em ISDN environment\fR .sp 9p .RT .PP The following notes apply to the delay parameters included in this section: .RT .LP 1) The term \*Qmean value\*U is understood as the expected value in the probabilistic sense. .LP 2) Where several messages are received at the exchange from a digital subscriber line signalling system (e.g.\ several alert messages are received from a multi\(hyuser configuration), the message that is accepted for call handling is the one considered in determining the start of a given delay interval. .LP 3) The terms \*Qreceived from\*U and \*Qpassed to\*U the signalling system are used. For CCITT Signalling System\ No.\ 7 this is designated as the instant the information is exchanged between the signalling data link (layer\ 1) and the signalling link functions (layer\ 2). For digital subscriber line signalling, this is designated as the instant the information is exchanged by means of primitives between the data link layer (layer\ 2) and the network layer (layer\ 3). Thus, the time intervals exclude the above layer\ 1 (CCITT Signalling System\ No.\ 7) and layer\ 2 (D\ channel) times. They do, however, include queuing delays that occur in the absence of disturbances but not any queuing delays caused be re\(hytransmission. .bp .sp 1P .LP 2.4.1 \fBuser signalling acknowledgement delay\fR .sp 9p .RT .PP User signalling acknowledgement delay is the interval from the instant a user signalling message has been received from the subscriber line signalling system until a message acknowledging the receipt of that message is passed back from the exchange to the user line signalling system. Examples of such messages are SETUP ACKNOWLEDGEMENT TO SETUP, CONNECT ACKNOWLEDGEMENT to CONNECT and RELEASE ACKNOWLEDGEMENT to RELEASE. .PP The values in Table 27/Q.543 are recommended. .RT .ce \fBH.T. [T28.543]\fR .ce TABLE\ 27/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B\fR _ .T& lw(90p) | cw(60p) | rw(60p) . Mean value \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | rw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms 1000 ms _ .TE .nr PS 9 .RT .ad r \fBTable 27/Q.543 [T28.543], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 1 2.4.2 \fBsignalling transfer delay\fR .sp 9p .RT .PP The exchange signalling transfer delay is the time taken for the exchange to transfer a message from one signalling system to another with minimal or no other exchange actions required. The interval is measured from the instant that a message is received from a signalling system until the moment the corresponding message is passed to another signalling system. Examples of messages are ALERT to ADDRESS COMPLETE, ADDRESS COMPLETE to ADDRESS COMPLETE, CONNECT to ANSWER, RELEASE to DISCONNECT,\ etc. .PP The values in Table 28/Q.543 are recommended for originating and terminating connections. .RT .ce \fBH.T. [T29.543]\fR .ce TABLE\ 28/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | cw(60p) . Mean value \(= | 00 ms \(= | 50 ms _ .T& lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms \(= | 00 ms _ .TE .nr PS 9 .RT .ad r \fBTable 28/Q.543 [T29.543], p.\fR .sp 1P .RT .ad b .RT .PP For transit connections, the requirements of the appropriate signalling system Recommendation should apply, e.g.\ CCITT Recommendations\ Q.725 and\ Q.766 for \fIT\fR\d\fIc\fR\\d\fIu\fR\uvalue (case of a simple message). .PP \fINote\fR \ \(em\ User\(hyto\(hyuser signalling may imply additional functions in the exchanges, e.g.\ charging, flow control,\ etc. The requirements for user\(hyto\(hyuser signalling transfer delay and the impact of user\(hyto\(hyuser signalling on exchange performance is for further study. .bp .RT .sp 1P .LP 2.4.3 \fBcall set up delay\fR .sp 9p .RT .PP Call set up delay is defined as the interval from the instant when the signalling information required for outgoing circuit selection is received from the incoming signalling system until the instant when the corresponding signalling information is passed to the outgoing signalling system. .RT .PP 2.4.3.1 For originating 64 kbit/s circuit switched connections (types\ I, II and III option a). .sp 9p .RT .LP i) If overlap sending is used, the interval starts when the information message received contains a \*Qsending complete\*U indication or the address information for call set up is complete. .LP ii) If en\(hybloc sending is used, the time interval starts when the SETUP message has been received from the user signalling system. .PP For call attempts using overlap sending, the values in Table\ 29/Q.543 are recommended. .ce \fBH.T. [T30.543]\fR .ce TABLE\ 29/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | rw(60p) . Mean value \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | rw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms 1000 ms _ .TE .nr PS 9 .RT .ad r \fBTable 29/Q.543 [T30.543], p.\fR .sp 1P .RT .ad b .RT .PP .sp 1 For call attempts using en\(hybloc sending, the values in Table\ 30/Q.543 are recommended. .ce \fBH.T. [T31.543]\fR .ce TABLE\ 30/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | rw(60p) . Mean value \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | rw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms 1200 ms _ .TE .nr PS 9 .RT .ad r \fBTable 30/Q.543 [T31.543], p.\fR .sp 1P .RT .ad b .RT .PP .sp 1 2.4.3.2 For originating supplementary service call attempts: .sp 9p .RT .PP for further study. .PP 2.4.3.3 For transit 64 kbit/s circuit switched connections between circuits that use CCITT Signalling System\ No.\ 7, the requirements of CCITT Recommendations\ Q.725 and\ Q.766 should apply for \fIT\fR\d\fIc\fR\\d\fIu\fR\uvalue (case of a processing intensive message). .bp .sp 9p .RT .sp 1P .LP 2.4.4 \fBthrough connection delay\fR \v'3p' .sp 9p .RT .PP 2.4.4.1 For originating outgoing and transit traffic 64 kbit/s switched circuit connections, through connection delay is defined as the interval from the instant that the signalling information required for setting up a connection through the exchange is received from the incoming signalling system to the instant that the transmission path is available for carrying traffic between the incoming and outgoing terminations on the exchange. .PP Usually, both directions of transmission will be switched through at the same time. However, at an originating exchange, on certain calls, there may be a requirement to effect switch through in two stages, one direction at a time. In this case, different signalling messages will initiate the two stages of switch through and the recommended delay applies to each stage of switch through. .PP The values in Table 31/Q.543 are recommended. .RT .ce \fBH.T. [T32.543]\fR .ce TABLE\ 31/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(72p) | cw(66p) . Reference load A Reference load B _ .T& lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) . Without ancillary function With ancillary function Without ancillary function With ancillary function _ .T& lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) . Mean value \(= | 50 ms \(= | 50 ms \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) . { 0.95 probability of not exceeding } \(= | 00 ms \(= | 00 ms \(= | 00 ms \(= | 00 ms _ .TE .nr PS 9 .RT .ad r \fBTable 31/Q.543 [T32.543], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 .PP 2.4.4.2 For internal and terminating traffic 64 kbit/s switched circuit connections the through connection delay is defined as the interval from the instant that the CONNECT message is received from the called line signalling system until the through connection is established and available for carrying traffic and the ANSWER and CONNECT ACKNOWLEDGEMENT messages have been passed to the appropriate signalling systems. .PP The values in Table 32/Q.543 are recommended. .ce .ce \fR .ce \fBH.T. [T33.543]\fR .ce TABLE\ 32/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | cw(60p) . Mean value \(= | 50 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms \(= | 00 ms _ .TE .nr PS 9 .RT .ad r \fBTable 32/Q.543 [T33.543], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP .sp 1 2.4.5 \fBincoming call indication sending delay \(em (for terminating and internal traffic connections)\fR .sp 9p .RT .PP The incoming call indication sending delay is defined as the interval from the instant at which the necessary signalling information is received from the signalling system to the instant at which the SETUP message is passed to the signalling system of the called subscriber line. .bp .PP In the case of overlap sending in the incoming signalling system, the values in Table\ 33/Q.543 are recommended. .RT .ce \fBH.T. [T34.543]\fR .ce TABLE\ 33/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | rw(60p) . Mean value \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | rw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms 1000 ms _ .TE .nr PS 9 .RT .ad r \fBTable 33/Q.543 [T34.543], p.\fR .sp 1P .RT .ad b .RT .PP In the case of en\(hybloc sending in the incoming signalling system, the values in Table\ 34/Q.543 are recommended. .ce \fBH.T. [T35.543]\fR .ce TABLE\ 34/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | rw(60p) . Mean value \(= | 00 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | rw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms 1200 ms _ .TE .nr PS 9 .RT .ad r \fBTable 34/Q.543 [T35.543], p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 2.4.6 \fBconnection release delay\fR .sp 9p .RT .PP Connection release delay is defined as the interval from the instant when DISCONNECT or RELEASE message is received from a signalling system until the instant when the connection is no longer available for use on the call (and is available for use on another call) and a corresponding RELEASE or DISCONNECT message is passed to the other signalling system involved in the connection. .PP The values in Table 35/Q.543 are recommended. .RT .ce \fBH.T. [T36.543]\fR .ce TABLE\ 35/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | cw(60p) . Mean value \(= | 50 ms \(= | 00 ms _ .T& lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms \(= | 00 ms _ .TE .nr PS 9 .RT .ad r \fBTable 35/Q.543 [T36.543], p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 2.4.7 \fICall clearing delay\fR .sp 9p .RT .PP Disconnect and call clearing will usually be performed at the same time. However, on certain calls it may be necessary for an exchange to retain call references after disconnect has occurred, until a clearing message is received. The exchange may then discard the call reference information. The corresponding RELEASE message must be passed on to other involved signalling systems in the interval allowed for signalling transfer delay (see\ \(sc\ 2.4.2). .RT .sp 1P .LP 2.4.8 \fITiming for start of charging\fR (circuit switched calls) .sp 9p .RT .PP When required, timing for charging at the exchange where this function is performed, shall begin after receipt of an ANSWER indication from a connecting exchange or the called user. The start of timing for charging should occur within the intervals recommended in Table\ 36/Q.543. .RT .LP .ce \fBH.T. [T37.543]\fR .ce TABLE\ 36/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ .T& lw(90p) | cw(60p) | cw(60p) . Mean value \(= | 00 ms \(= | 175 ms _ .T& lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } \(= | 00 ms \(= | 50 ms _ .TE .nr PS 9 .RT .ad r \fBTable 36/Q.543 [T37.543], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 2.5 \fICall processing performance objectives\fR .sp 1P .RT .sp 2P .LP 2.5.1 \fI64 kbit/s switched connections\fR .sp 1P .RT .sp 1P .LP 2.5.1.1 \fIPremature release\fR .sp 9p .RT .PP The probability that an exchange malfunction will result in the premature release of an established connection in any one minute interval should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 2\ \(mu\ 10\uD\dlF261\u5\d .ce 0 .sp 1P .LP .sp 1 2.5.1.2 \fIRelease failure\fR .sp 9p .RT .PP The probability that an exchange malfunction will prevent the required release of a connection should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 2\ \(mu\ 10\uD\dlF261\u5\d .ce 0 .sp 1P .LP .sp 1 2.5.1.3 \fIIncorrect charging or accounting\fR .sp 9p .RT .PP The probability of a call attempt receiving incorrect charging or accounting treatment due to an exchange malfunction should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 10\uD\dlF261\u4\d .ce 0 .sp 1P .LP .bp .sp 1P .LP 2.5.1.4 \fIMisrouting\fR .sp 9p .RT .PP The probability of a call attempt misrouted following receipt by the exchange of a valid address should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 10\uD\dlF261\u4\d .ce 0 .sp 1P .LP .sp 1 2.5.1.5 \fINo tone\fR .sp 9p .RT .PP The probability of a call attempt encountering no tone following receipt of a valid address by the exchange should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 10\uD\dlF261\u4\d .ce 0 .sp 1P .LP .sp 1 2.5.1.6 \fIOther failures\fR .sp 9p .RT .PP The probability of the exchange causing a call failure for any other reason not identified specifically above should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR \ \(=\ 10\uD\dlF261\u4\d .ce 0 .sp 1P .LP .sp 1 .sp 1P .LP 2.5.2 \fI64 kbit/s semi\(hypermanent connections\fR .sp 9p .RT .PP This requires further study taking into consideration: .RT .LP \(em need to recognize an interruption; .LP \(em probability of an interruption; .LP \(em requirements for re\(hyestablishment of interrupted connection; .LP \(em any other unique requirements. .sp 1P .LP 2.5.3 \fIn \(mu 64 kbit/s switched connections\fR .sp 9p .RT .PP To be recommended if/when specific services are defined. .RT .sp 1P .LP 2.5.4 \fIn \(mu 64 kbit/s semi\(hypermanent connections\fR .sp 9p .RT .PP To be recommended if/when specific services are defined. .RT .sp 2P .LP 2.6 \fITransmission performance\fR .sp 1P .RT .sp 1P .LP 2.6.1 \fI64 kbit/s switched connections\fR .sp 9p .RT .PP The probability of a connection being established with an unacceptable transmission quality across the exchange should be: \v'6p' .RT .sp 1P .ce 1000 \fIP\fR (Unacceptable transmission)\ \(=\ 10\uD\dlF261\u5\d .ce 0 .sp 1P .LP .sp 1 .PP The transmission quality across the exchange is said to be unacceptable when the bit error ratio is above the alarm condition. .PP \fINote\fR \ \(em\ The alarm condition has yet to be defined. .RT .sp 1P .LP 2.6.2 \fI64 kbit/s semi\(hypermanent connections\fR .sp 9p .RT .PP To be recommended. .RT .sp 1P .LP 2.6.3 \fIn \(mu 64 kbit/s switched connections\fR .sp 9p .RT .PP To be recommended, if/when specific services are defined. .RT .sp 1P .LP 2.6.4 \fIn \(mu 64 kbit/s semi\(hypermanent connections\fR .sp 9p .RT .PP To be recommended if/when specific services are defined. .bp .RT .sp 2P .LP 2.7 \fISlip rate\fR .sp 1P .RT .sp 1P .LP 2.7.1 \fINormal conditions\fR .sp 9p .RT .PP The slip rate under normal conditions is covered in Recommendation\ Q.541. .RT .sp 1P .LP 2.7.2 \fITemporary loss of timing control\fR .sp 9p .RT .PP The case of temporary loss of timing control corresponds to the \*Qholdover operation\*U defined and recommended in Recommendation\ G.812. The allowable slip rate will correspond to the maximum relative TIE also recommended therein. .RT .sp 1P .LP 2.7.3 \fIAbnormal conditions at the exchange input\fR .sp 9p .RT .PP The slip rate in case of abnormal conditions (wide phase diviations,\ etc.) at the exchange input is the subject of further study taking into account the requirements of Recommendation\ G.823. .RT .sp 2P .LP \fB3\fR \fBExchange performance during overload conditions\fR .sp 1P .RT .PP This section applies to digital exchanges operating during periods when the number of call attempts presented to the exchange exceeds its call processing capacity for a significant period of time, excluding momentary peaks. Under these conditions the exchange is said to be operating in an overload condition. .PP This Recommendation identifies requirements for exchange performance during overload and for overload mechanisms in the exchange. Network management functions to be supported by an exchange are defined in Recommendation\ Q.542, \(sc\ 5. .RT .sp 1P .LP 3.1 \fIExplanation of terms used in definition of overload\fR \fIparameters\fR \v'3p' .sp 9p .RT .LP \(em \fBload\fR : the total number of call attempts presented to an exchange during a given interval of time (i.e.\ offered load) .LP \(em \fBoverload\fR : that part of the total load offered to an exchange, in excess of the engineered traffic processing capacity of the exchange. Overload is usually expressed as a percentage of engineered capacity. .LP \(em \fBthroughput\fR : the number of call attempts processed successfully by an exchange per unit time. .LP \(em \fBengineered capacity\fR : the mean offered load at which the exchange just meets all grade of service requirements used by the Administration to engineer the exchange. .sp 1P .LP 3.2 \fICall processing performance during overload\fR .sp 9p .RT .PP An exchange must continue to process a specified load even when the offered call attempts exceed its available call processing capacity. The number of call attempts handled during an overload condition should not be significantly lower than the engineered capacity of the exchange for a specified Grade Of Service (GOS), as noted in \(sc\ 3.7. .PP Two basic requirements for exchange performance during overload are: .RT .LP \(em to maintain adequate exchange throughput in sustained overload .LP \(em to react sufficiently quickly to load peaks and the sudden onset of overload. .PP As the offered load increases beyond the engineered attempt capacity of the exchange, the throughput or the carried attempt load may exhibit a behaviour shown by curve\ A in Figure\ 1/Q.543, i.e.\ processor throughput may be reduced drastically if the offered load increases well beyond the engineered load. Curve\ B in Figure\ 1/Q.543 represents the maximum throughput, where the throughput remains at the nominal design level under overload. Appropriate overload protection mechanisms should be included in the overall exchange design so that the throughput performance of the processor under overload resembles the curve\ C in Figure\ 1/Q.543. .bp .LP .rs .sp 20P .ad r \fBFigure 1/Q.543, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.3 \fIEngineered exchange capacity\fR .sp 9p .RT .PP Exchange engineered capacity is the maximum load that the exchange can handle while operating in a \*Qnormal\*U mode (i.e.\ performing all required operating and administrative functions) while meeting performance requirements specified in \(sc\ 2 or those specified by the Administration. It is not necessarily the point of maximum throughput (see Figure\ 1/Q.543). .PP Overload controls, when applied, may have a significant effect on exchange capacity. Overload throughput performance should be specified relative to the engineered capacity of the exchange when overload controls are operating. .RT .sp 1P .LP 3.4 \fIOverload control strategy\fR .sp 9p .RT .PP An effective overload control strategy will prevent the rapid decrease in processed call attempts with increasing overload (see Curve\ A in Figure\ 1/Q.543); the relatively gradual decrease with overload controls enabled (Curve\ C in Figure\ 1/Q.543) is due to the increasing processing overhead in exercising the overload controls. .PP Overload is defined as the level of call attempts offered to the exchange in excess of the exchange engineered capacity. For example, when the exchange is offered call attempts at a rate of 10% greater than the engineered capacity, the exchange is said to have 10% overload. .PP The exchange throughput at an overload of Y% above the engineered capacity load should be at least X% of the throughput at engineered capacity. This concept is shown in Figure\ 2/Q.543 which shows the region of unacceptable throughput performance. Any throughput curve which remains above the X% level until reaching the point of Y% overload is acceptable. The recommended values are Y\ =\ 50% and X\ =\ 90%. Beyond Y% overload the exchange should continue to process calls in an acceptable manner. .RT .PP As long as the level of overload does not exceed Y% above the exchange engineered capacity, then the exchange throughput should be no less than X% of engineered capacity, as depicted in Figure\ 2/X.543. .PP Measurements that can provide data as the basis for calculation of X and Y, are identified in \(sc\ 3.8. .bp .RT .LP .rs .sp 18P .ad r \fBFigure 2/Q.543, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.5 \fIDetection of overload\fR .sp 9p .RT .PP The exchange should incorporate suitable means for detecting overload conditions. .PP The onset of an overload state should be recognized by the exchange processing logic which in turn will invoke strategies to avoid a severe degradation in throughput load. During overload, both severe delays and processing delays will increase and will normally exceed the performance objectives given for Reference load\ B. .PP Overload indications may, for example, be provided by: a continuous measurement of the occupancy of the resources used for call handling over short periods (e.g.\ a few seconds); monitoring the queue lengths for the various call handling processes,\ etc. Overload control activation indications should be given to the administration staff. .RT .sp 1P .LP 3.6 \fIOverload protection\fR .sp 9p .RT .PP The internal overload control methods used in an exchange are dependant on the particular technical arrangement of the switching system, and are not subject to CCITT Recommendations. Overload controls used in conjunction with adjacent exchanges are discussed under \*QNetwork management design objectives\*U in Recommendation\ Q.542, \(sc\ 5. .PP In order to reduce the load on the exchange caused by calls that cannot be processed during overload, it may be necessary to discourage further attempts by customers during this situation. Methods used to achieve this reduction should not significantly increase the load on exchange processors, as for example, routing calls to recorded announcements. .PP Overload controls, once applied, should be removed as quickly as possible when the degree of overload reduces, consistent with the need to avoid oscillatory behaviour which might prolong the period of degraded service. .PP As a guideline to providing service during overload conditions, the following general principles are applicable: .RT .LP \(em give preference to the processing of terminating calls, .LP \(em give preference to priority class lines, calls to priority destinations based on digit analysis and incoming calls with priority indications in, for example, the Initial Address Message of a call using CCITT Signalling System\ No.\ 7, if an essential service protection capability has been invoked, .bp .LP \(em defer some or all activities non\(hyessential to handling offered traffic; examples are some administration and maintenance processes in the exchange. (Nevertheless the man\(hymachine communications essential for priority operational tasks should always be preserved. In particular, network management terminals and functions associated with interfaces to network management support systems should be afforded high priority, since network management actions can play an important role in reducing exchange overloads), .LP \(em maintain normal charging and supervisory functions, and established connections until the receipt of the appropriate release signal, .LP \(em assign priorities to specific exchange measurements, such that low priority measurements cease at a predetermined level of congestion. Higher priority measurements may be ceased at a higher level of congestion, or may be run continuously, depending on their importance to the call handling functions, .LP \(em give preference to calls already being processed, before accepting new calls. .sp 1P .LP 3.7 \fIGrade of service during overload\fR .sp 9p .RT .PP In general the overall grade of service seen by the subscribers will deteriorate when the exchange experiences severe overload conditions and the overload protection mechanisms have been invoked. This may be due to the fact that the overload protection procedures may require that the exchange not accept all the call attempts offered. .PP Accepted calls may or may not receive a grade of service equal to that received by calls at Reference load\ B of \(sc\ 2. In terms of the exchange overload performance, it is sufficient that calls be accepted in such a way that throughput is maximized. .RT .sp 1P .LP 3.8 \fIPerformance monitoring during overload control activation\fR .sp 9p .RT .PP The operational measurements in the exchange should be sufficient to determine the number of call attempts accepted by the exchange, and the number that are successfully being completed, from the exchange point\(hyof\(hyview. Separate measurements should be available to count the number of attempts rejected by the exchange during overload, so that the total load can be estimated. .PP An accepted call attempt is defined to be a call attempt which is accepted for processing by the exchange. This does not necessarily mean that an accepted call attempt will complete or receive an acceptable grade of service. .PP The call completion rate can vary statistically with time, according to the specific call attempt acceptance process invoked by the overload controls. Therefore the call completion rate estimated from the operational measurements needs to be taken over a sufficiently long period of time to verify conformance to the X% throughput requirement. .RT .ce 1000 ANNEX\ A .ce 0 .ce 1000 (to Recommendation Q.543) .sp 9p .RT .ce 0 .ce 1000 \fBAn example of methodology for computing the call\fR .sp 1P .RT .ce 0 .ce 1000 \fBprocessing capacity of a Digital Exchange\fR , .ce 0 .ce 1000 \fBtaking into account ISDN services,\fR .ce 0 .ce 1000 \fBincluding packet data handling\fR .ce 0 .LP A.1 \fIGeneral\fR .sp 1P .RT .PP Exchanges will generally be required to handle many types of calls as they provide basic telephony service, supplementary telephony service, ISDN bearer service and ISDN supplementary services. A variety of signalling types will be used on subscriber lines and for handling calls over interexchange circuits. Performance objectives have been recommended and are applicable over the full range of exchange sizes and loads up to the limit of exchange \*Qengineered\*U capabity at its maximum size for the mix of call types handled and .PP signalling types used in the exchange. Different mixes of call types and signalling types require different amounts of processing capacity. Thus the maximum number of subscriber lines that can be served and the number of calls that can be handled will be different for each mix on the same switching system. This ANNEX serves as an example of a methodology that makes it possible to compute the processing capacity of an exchange for any particular mix of call types and signalling expected to be encountered in its implementation. Of course, other possible limiting factors such as allowable hardware configuration, memory capacity,\ etc., must also be taken into account when determining the capacity of the exchange. .bp .PP The method of calculating call processing capacity illustrated herein is for a particular multi\(hyprocessor exchange design shown in Figure\ A\(hy1/Q.543. However, the principles used can be applied to any processor controlled exchange design for any mix of services, traffic and signalling handled by the exchange. This method requires that manufacturers provide information and data about their exchange designs in terms that Administrations can use in the formulae derived below and that Administrations make measurements and/or estimates to forecast the expected traffic volumes and mix of services, call types and signalling. .PP It is important to examine the exchange architecture and to understand how calls are processed in order to recognize potential limiting elements. For example, ISDN calls involving packet switching will have two separate elements to be considered, call set up and packet handling. Packet call set up can be dealt with in the same manner as circuit switched call setup by considering these types of call attempts in and with the circuit switched call attempt originations and dispositions. However, subsequent packet handling requires continuing processing capacity, occasionally for long periods of time, may be handled by processors other than those involved in call setup and thus, must be dealt with separately. .PP Figure A\(hy1/Q.543 of this ANNEX shows a block diagram of an exchange design with several processors, which is used as an example in this ANNEX. .RT .LP a) The Interface Unit 1 through n provide interfaces to user lines, interexchange circuits, signalling terminals and any other interfaces to entities outside the exchange. A certain amount of call processing (e.g.\ handling signalling to or from lines or interexchange circuits, digit analysis,\ etc.) can be performed by processors in these interface units. In this example, each Interface Unit also contains its own packet handler (shown as PH). The Interface Units communicate with a Central Processing Unit over high capacity inter\(hyprocessor lines. .LP b) The Central Processing Unit directs call processing by the exchange. It receives information about call attempts from the Interface Units, determines how they should be handled and routed and directs their disposition by the appropriate Interface Units. In connection with packet switching calls, it is assumed that the Central Processing Unit is involved only in call set up and call release and that ongoing packet handling requires no significant amount of CPU processing capacity. The CPU also performs other call related and administrative tasks, such as maintaining charging information, and performs other administrative and operations functions for the exchange. .PP To determine the capacity of this design it is necessary to know how many Interface Units can be connected to an exchange. Then it is necessary to compute the call processing capacity of the Central Processing Unit and the capacity of the Interface Units to determine which is the limiting factor. In some designs, other elements, such as a utility processor or the switching network, can limit the size of the exchange. Thus, it is necessary to understand the exchange design and then to make appropriate computations involving the limiting elements to determine the processing capacity of the exchange for the traffic mix envisioned. .sp 2P .LP A.2 \fIDefinitions\fR .sp 1P .RT .sp 1P .LP A.2.1 \fBcapacity unit\fR .sp 9p .RT .PP The processing capacity required in an exchange (or processing unit) to process a call attempt consisting of the originating portion plus the terminating (or disposition) portion. .RT .sp 1P .LP A.2.2 \fBhalf unit\fR .sp 9p .RT .PP The processing capacity required to process either the originating or terminating (disposition) portion of a call attempt handled by an exchange or a processing unit, e.g.\ an Interface Unit in the exchange design shown. .RT .sp 1P .LP A.2.3 \fBoriginating type\fR .sp 9p .RT .PP A type of call attempt entering the exchange (e.g. a telephone call from a line class\(hymarked for basic telephone service, or one from a line marked for supplementary services, or basic ISDN services, \fIor\fR ISDN supplementary services, or a call entering the exchange on an incoming interexchange circuit,\ etc.). .bp .RT .sp 1P .LP A.2.4 \fBterminating (disposition) type\fR .sp 9p .RT .PP A type of call attempt leaving or disposed of by the exchange (e.g. a call attempt terminating to a line class marked for basic telephone service, or one to a line with supplementary or ISDN services assigned, or to an outgoing interexchange circuit,\ etc.). .RT .sp 1P .LP A.2.5 \fBreference capacity unit\fR .sp 9p .RT .PP The processing capacity required for processing an arbitrarily selected pair of half units, one an originating type attempt and one a terminating (disposition) type attempt, usually a pair that is expected to be involved in a significant portion of the traffic load in the exchange. The reference capacity unit uses a standard against which capacity units for other types of attempts are compared. (It is suggested that an originating outgoing \*Qlocal\*U telephone call attempt from a basic telephone line and disposed of by routing it to an interexchange circuit using CCITT Signalling System\ No.\ 7 as the reference capacity unit.) .RT .sp 1P .LP A.2.6 \fBreference capacity half\(hyunit\fR .sp 9p .RT .PP The processing capacity required in an interface unit to process an arbitrarily selected half\(hyunit, either an originating or a terminating (disposition) type (usually one that is involved in a significant portion of traffic that interface units handle, e.g.\ an originating telephone call attempt from a basic telephone line). The reference capacity half\(hyunit is used as the standard against which half\(hyunits of other types of attempts are compared. When separate calculations for different interface units are necessary, which occurs when different mixes of line classes and traffic are served by the different interface units, the same reference capacity half\(hyunit should be used for all calculations. .RT .sp 1P .LP A.2.7 \fBcentral processor unit (CPU) reference capacity unit\fR .sp 9p .RT .PP The processing capacity required in the CPU to process the portions of attempts associated with one reference capacity unit. The reference capacity unit is assigned unit value. Thus, if \fIF\fR is the fraction of one reference capacity unit for processing the originating portion and \fIF\fR ` is the fraction of one reference capacity unit required for processing the terminating (disposition) portion, the sum is unity ( \fIF\fR \ +\ \fIF\fR `\ =\ 1). .RT .sp 1P .LP A.2.8 \fBinterface unit (IU) reference capacity unit\fR .sp 9p .RT .PP The amount of processing capacity required in the IU in the exchange design shown, to properly handle one reference capacity half\(hyunit. .RT .sp 1P .LP A.2.9 \fBweighting factor\fR .sp 9p .RT .PP The ratio of the relative amount of processing capacity required to handle either portion, originating or terminating (disposition), of any \fIattempt\fR type, to the capacity required in that processor to perform the same functions for reference capacity unit, (originating and terminating (disposition) portions). For example, if a complete reference capacity unit requires 1000\ processor cycles in the CPU and the originating portion of a call attempt entering the exchange requires 430\ cycles in the CPU, the weighting factor (CPU) for that originating attempt type would be 0.43. .PP Similarly, in the interface unit, a weighting factor is the ratio of the amount of IU processing capacity required to handle a particular half\(hyunit to the amount of IU processing capacity required to handle a reference capacity half\(hyunit. Thus if an IU requires 600\ cycles to handle a reference capacity half\(hyunit and another type of call entering the exchange via the IU requires 725\ IU processor cycles, the weighting factor (IU) for that half\(hyunit attempt type would be 1.21. .PP Weighting factors for all originating and terminating (disposition) types of capacity units and half\(hyunits, are required for each processing unit in the exchange in order to make capacity computations. These weighting factors must be furnished by the manufacturer. .RT .sp 1P .LP A.2.10 \fBreference unit (and half\(hyunit) processing capacity (RUPC)\fR .sp 9p .RT .PP Is capacity information that should be furnished by the manufacturer. RUPC is the total number of reference capacity units (and half\(hyunits) that can be performed by a processor (or processing unit) in one hour in an exchange while meeting performance criteria specified by the Administration and at the same time performing all the operations and administrative tasks required for normal operation of the exchange. Thus, RUPC is the processing capacity available .bp .PP for call handling. It is the total .PP installed capacity diminished by an amount required for overhead, administrative tasks,\ etc. In addition to accounting for the overhead of administrative tasks, it may also be desirable to \*Qreserve\*U a certain percentage of capacity for program growth additions that would be needed in a maximum size exchange for adding new features in the future. To be able to make a realistic comparison of different systems, it is necessary that the Administration learn from the manufacturers, the non\(hycall handling functions that are accounted for and the percent of capacity that is being reserved for growth. .RT .sp 1P .LP A.3 \fIProcessing capacity computation (for a central processing unit)\fR .sp 9p .RT .PP Capacity information and weighting factors are furnished by the manufacturer. .RT .LP Let \fIF\fR\d\fIi\fR\u = weighting factor for originating type \fIi\fR .LP \fIF\fR ` \fI\fI\d\fIj\fR\u = weighting factor for terminating (disposition) type \fIj\fR . .PP Traffic mix on the CPU is specified by the Administration. .LP Let \fIP\fR\d\fIi\fR\u = fraction of call attempts expected to be originating type\ \fIi\fR .LP \fIP\fR ` \fI\fI\d\fIj\fR\u = fraction of call attempts expected to be terminating (disposition) type\ \fIj\fR . \v'6p' .ad r .ad b .RT .PP If, R = the call attempt rate expressed in terms of busy hour call attempts, then the amount of processing capacity required for originating type work units associated with the i\(hyth call attempt type traffic is: \v'6p' .sp 1P .ce 1000 \fIP\fR\d\fIi\fR\u .EF '% \fI'' .OF '''\fI %' .EF '% \fI'' .OF '''\fI %' .ce 0 .sp 1P .PP .sp 1 Similarly, the processing capacity required for disposition work associated with the j\(hyth call type traffic is: \v'6p' .sp 1P .ce 1000 \fIP\fR ` \fI\fI\d\fIj\fR\u\fIF\fR ` \fI\fI\d\fIj\fR\u\fIR\fR .ce 0 .sp 1P .LP \fR .sp 1 .PP In order to satisfy the performance design objectives in Recommendation\ Q.543, the reference unit processing capacity (RUPC) must be equal to or greater than the total originating type work plus the total terminating (disposition) type work: \v'6p' .ad r .ad b .RT .ad r .ad b .RT .sp 1P .LP A.4 \fIProcessing capacity computation (for an interface unit)\fR .sp 9p .RT .PP Capacity information and weighting factors are furnished by the manufacturer. .RT .LP Let \fIH\fR\d\fIi\fR\u\ = weighting factor for half\(hyunit type i. .PP Traffic mix on the interface unit is specified by the Administration. .bp .LP Let \fIP\fR\d\fIi\fR\u\ = fraction of attempts to be half\(hyunit type i. \v'6p' .ad r .ad b .RT .PP If, R = the attempt rate in terms of busy hour half\(hyunits, the processing capacity required for i\(hyth type half\(hyunits is: \v'6p' .sp 1P .ce 1000 \fIP\fR .EF '% \fI'' .OF '''\fI %' .EF '% \fIiR'' .OF '''\fIiR %' .ce 0 .sp 1P .LP .sp 1 .PP In order to satisfy performance criteria, the reference unit call processing capacity (RUPC) must be equal to or greater than the total processing load: \v'6p' .ad r .ad b .RT .ad r .ad b .RT .sp 2P .LP A.5 \fIExamples of processing capacity computations\fR .sp 1P .RT .sp 1P .LP A.5.1 \fIFor a central processing unit\fR \v'3p' .sp 9p .RT .LP \fIInputs\fR .PP Information furnished by manufacturer: .LP \(em RUPC = 100,000 central processor reference capacity units per hour .LP \(em Weighting factors (see Table A\(hy1/Q.543). .LP .sp 1 .ce \fBH.T. [T38.543]\fR .ce TABLE\ A\(hy1/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(120p) | cw(54p) | cw(54p) . Termination type Originating portion (F) { Termination (disposition) portion (F`) } _ .T& lw(120p) | cw(54p) | cw(54p) . Basic analogue access line 0.60 0.40 .T& lw(120p) | cw(54p) | cw(54p) . { Analogue access line with supplementary services } 0.72 0.48 .T& lw(120p) | cw(54p) | cw(54p) . ISDN access line 0.72 0.56 .T& lw(120p) | cw(54p) | cw(54p) . Interexchange circuit (IXC) 0.50 0.40 _ .TE .nr PS 9 .RT .ad r \fBTable A\(hy1/Q.543 [T38.543], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP Information furnished by the Administration. .PP Expected traffic mix (see Table A\(hy2/Q.543). .RT .ce \fBH.T. [T39.543]\fR .ce TABLE\ A\(hy2/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(90p) | cw(90p) | cw(48p) . Originating call type From\ \(em\ termination type { Traffic mix (fraction of total) } _ .T& lw(90p) | lw(90p) | cw(48p) . Telephone Basic analogue access line 0.28 .T& lw(90p) | lw(90p) | cw(48p) . Telephone { Analogue acess line with supplementary services } 0.32 .T& lw(90p) | lw(90p) | cw(48p) . 64\ kbit/s switched ISND access line 0.05 .T& lw(90p) | lw(90p) | cw(48p) . Packet switched (setup) ISDN access line 0.02 .T& lw(90p) | lw(90p) | cw(48p) . Incoming\(hycircuit switched Interexchange circuit (IXC) 0.33 _ .T& lw(90p) | rw(90p) | cw(48p) . Total 1.00 _ .T& cw(90p) | cw(90p) | cw(48p) . Terminating call type To\ \(em\ termination type { Traffic mix (fraction of total) } _ .T& lw(90p) | lw(90p) | cw(48p) . Telephone Basic analogue access line 0.26 .T& lw(90p) | lw(90p) | cw(48p) . Telephone { Analogue access line with supplementary services } 0.30 .T& lw(90p) | lw(90p) | cw(48p) . 64\ kbit/s switched ISDN access line 0.05 .T& lw(90p) | lw(90p) | cw(48p) . Packet switched (setup) ISDN access line 0.02 .T& lw(90p) | lw(90p) | cw(48p) . Outgoing\(hycircuit switched Interexchange circuit (IXC) 0.37 _ .T& lw(90p) | rw(90p) | cw(48p) . Total 1.00 _ .TE .nr PS 9 .RT .ad r \fBTable A\(hy2/Q.543 [T39.543], p.\fR .sp 1P .RT .ad b .RT .PP .sp 2 Computation (see Table A\(hy3/Q.543). .ce \fBH.T. [T40.543]\fR .ce TABLE\ A\(hy3/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(60p) | cw(60p) . Termination type Originating portion Terminating portion _ .T& lw(108p) | rw(60p) | rw(60p) . Basic analogue access line { 0.28 \(mu 0.60 = 0.168\fR \fR } 0.26 \(mu 0.40 = 0.104 .T& lw(108p) | rw(60p) | rw(60p) . { Analogue access line with supplementary services } 0.32 \(mu 0.72 = 0.230 0.30 \(mu 0.48 = 0.144 .T& lw(108p) | rw(60p) | rw(60p) . { ISDN access line\ \(em\ circuit switched } 0.05 \(mu 0.72 = 0.036 0.05 \(mu 0.56 = 0.028 .T& lw(108p) | rw(60p) | rw(60p) . { ISDN access line\ \(em\ packet switched } 0.02 \(mu 0.72 = 0.014 0.02 \(mu 0.56 = 0.011 .T& lw(108p) | rw(60p) | rw(60p) . Interexchange circuit (IXC) 0.33 \(mu 0.50 = 0.165 0.37 \(mu 0.40 = 0.148 _ .T& lw(108p) | rw(60p) | rw(60p) . Total 0.613 0.435 _ .TE .nr PS 9 .RT .ad r \fBTable A\(hy3/Q.543 [T40.543], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP Maximum call attempt rate for the central processor for the specified mix of traffic: \v'6p' .sp 1P .ce 1000 \fIR\fR maximum = @ { 00,000 } over { .613\~+\~0.435 } @ = 95,420 call attempts per hour .ce 0 .sp 1P .PP .sp 1 At this point in the computation, it would be wise to examine the exchange design to verify that hardware configuration, memory capacity, or any other possible limitations do not prevent reaching this computed capacity. .sp 1P .LP A.5.2 \fIExample of a processing capacity computation for an interface\fR \fIunit\fR | see Table\ A\(hy4/Q.543) .sp 9p .RT .PP Weighting factors are furnished by the manufacturer. .PP Traffic mix is estimated by the Administration. .RT .LP .ce \fBH.T. [T41.543]\fR .ce TABLE\ A\(hy4/Q.543 .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(60p) | cw(78p) | cw(30p) | cw(48p) . Call type Weighting factor { Traffic mix (fraction of total) } _ .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . \fIFrom:\fR .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . Basic analogue access line { Telephone (reference call) False start/abandon } 1.00 1.16 \(mu \(mu 0.14\ 0.005 = 0.140 = 0.006 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . Analogue access line { Telephone False start/abandon Supplementary service No. 1 Supplementary service No. 2 Supplementary service No. n } { 1.15\fR 1.20 1.52 1.31 1. ++ } \(mu \(mu \(mu \(mu \(mu 0.10\ 0.005 0.05\ 0.01\ . { = 0.115 = 0.006 = 0.076 = 0.013 . } .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . ISDN access line { 64\ kbit/switched Packet call setup Supplementary service No. 1 Supplementary service No. 2 Supplementary service No. n } 1.20 1.15 1.44 1.20 1. ++ \(mu \(mu \(mu \(mu \(mu { 0.025 0.01\ 0\ \ \ \ 0.01\ . } = 0.030 = 0.012 . = 0.012 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . IXC \(em CCITT No. 5 Incoming 1.30 \(mu 0.07\ = 0.091 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . IXC \(em CCITT No. 7 Incoming 0.90 \(mu 0.08 = 0.072 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . \fITo:\fR .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . Basic analogue line Telephone 0.65 \(mu 0.13 = 0.085 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . Analogue line { Telephone Supplementary service No. 4 } 0.75 0.80\fR \fR \(mu \(mu 0.12\ \fR 0.035 = 0.090 = 0.028 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . ISDN { 64\ kbit/switched Packet call setup Supplementary service No. 5 } 0.75 0.75 0.80 \(mu \(mu \(mu 0.02 0.01 0.01 = 0.015 = 0.008 = 0.008 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . IXC\ \(em\ CCITT No. 5 Outgoing 1.62 \(mu 0.08 = 0.130 .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . IXC \(em CCITT No. 7 Outgoing 0.83 \(mu 0.10\ = 0.083 _ .T& lw(60p) | lw(78p) | lw(30p) | lw(12p) | lw(18p) | lw(18p) . Total \fB=\fR 1.020 _ .TE .nr PS 9 .RT .ad r \fBTable A\(hy4/Q.543 [T41.543], p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP Information from the manufacturer. .PP Reference capacity for an interface unit = 15,000 reference capacity half\(hyunits per hour. .PP Computation: \v'6p' .RT .sp 1P .ce 1000 \fIR\fR maximum = @ { 5,000 } over { .020 } @ = 14,705 half\(hyunits per hour or 7,352 call attempts per hour .ce 0 .sp 1P .LP .sp 1 .PP If the traffic load is distributed in the above proportions across all interface unit the number of interface units required to fully load the central processing unit would be 13 [95,420 divided by 7,352]. In this case it would probably be wise to plan on a maximum of 14\ interface units in order to reserve some processing capacity for future program growth. At this point in the computation, it would be wise to examine the exchange design to verify that hardware configuration, memory or any other possible limitations do not prevent reaching this computed capacity. .PP The above capacity computation methodology can also be used to study the effects of different traffic mixes on interface units. .RT .LP A.6 \fIPacket handling\fR .sp 1P .RT .sp 2P .LP A.6.1 \fIDefinitions\fR .sp 1P .RT .sp 1P .LP A.6.1.1 \fBpacket\fR .sp 9p .RT .PP The unit of information exchanged between processors at layer\ 3. .RT .sp 1P .LP A.6.1.2 \fBuser packet\fR .sp 9p .RT .PP A packet of information exchanged between the originating and terminating users in a packet switched connection. The length of packets may vary, depending on the protocol used. The number of user packets transferred between the originating and terminating users measures the amount of information transferred. The fundamental measure of packet switching capacity is expressed as the number of some agreed standard length user packets per second. .RT .sp 1P .LP A.6.1.3 \fBacknowledgement packet\fR .sp 9p .RT .PP Packet switching protocols have various strategies to ensure the reliable transmission of packets between users. These strategies involve sending packets not containing user data to verify the successful transmission of users packets. Such packets are called acknowledgement packets. The acknowledgement strategy depends on the packet switching protocol being used. .RT .sp 1P .LP A.6.1.4 \fBreference packet type\fR .sp 9p .RT .PP An arbitrarily selected user packet type, usually one of a protocol that is expected to be involved in a significant portion of the packet traffic an exchange might handle. .RT .sp 1P .LP A.6.1.5 \fBreference packet work unit\fR .sp 9p .RT .PP The amount of processor capacity required to handle one packet of the reference packet type together with its \*Qshare\*U of capacity required to handle associated acknowledgement packets. The reference packet work unit is assigned unit value. .RT .sp 1P .LP A.6.1.6 \fBweighting factor\fR .sp 9p .RT .PP The ratio of the amount of processing capacity required to handle any type of packet [including its \*Qshare\*U of associated acknowledgement packets] to the amount of processing required to handle one reference packet [including its \*Qshare\*U of associated acknowledgement packets]. For example, if a complete reference packet requires 1000\ processor cycles and a complete X.25 message packet requires 1200\ cycles, the weighting factor for that packet type would be 1.2. The weighting factors must be furnished by the manufacturer for each packet type handled by the exchange. .bp .RT .sp 1P .LP A.6.1.7 \fBreference packet processing capacity (RPPC)\fR .sp 9p .RT .PP The total number of reference type user packets that can be handled by the processor in one second while meeting the specified performance criteria. This number should be furnished by the manufacturer. It is important .PP to note that RPPC derives from that processing capacity reserved for packet handling and generally is the installed capacity diminished by an amount required for overhead, administrative tasks,\ etc. .RT .sp 1P .LP A.6.2 \fIPacket calls\fR .sp 9p .RT .PP Packet calls consist of two parts: packet call set\(hyup [and disconnect] and ongoing packet exchanging [packet handling stage]. .RT .LP A.6.2.1\ \ Packet call set\(hyup can be dealt with in the same manner as that described previously for circuit switched call set\(hyup. Appropriate weighting factors for the various types of packet call set\(hyup and estimates of packet type calls in the traffic mix are used for computing the capacity of the processor involved. [See \(sc\ A.5. Packet call set\(hyup was included in the example of call attempt processing capacity computations]. Just as with circuit switched services, there may be packet calls with different processing requirements and therefore it will be necessary to treat the different type packet calls individually in the computation. .LP A.6.2.2\ \ After packet call set\(hyup, each packet exchanged between users during the call requires processing at the originating and terminating exchanges. The total amount of processing work required during a packet switched call is a function of the number of packets exchanged throughout the call. If a processor is dedicated to handling packets, the processing capacity is usually expressed in terms of number of user packets of a standard length handled per second. To account for the packet processing capacity that will be needed in an exchange during a busy hour, data on the average number [and type] of packets per call must be forecast. Note that for very long duration calls, e.g.\ permanent virtual circuits, only packets offered during the busy hour need to be considered. Also, packets from long duration calls originated prior to but extending into the busy hour, must be included. .PP In the exchange architecture shown in Figure A\(hy1/Q.543, it is assumed that each interface unit has a separate packet handling processor (shown as PH) within the unit. This processor interacts with digital line or digital circuit units to handle the protocols involved in packet switching. Once a packet call has been set\(hyup, there is no further demand for processing work on the interface unit processor nor the central processing unit processor .LP until call disconnect. Thus, the only potential capacity limitation due to packet handling in the exchange will be that imposed by the processing capacity of the packet handling processor in the interface unit. [For systems that use the same processor for call set\(hyup \fIand\fR packet handling, see \(sc\ A.7.] .sp 1P .LP A.6.2.3 \fIProcessing capacity computation for a packet handling\fR \fIprocessor\fR .sp 9p .RT .PP Weighting factors are furnished by the manufacturer. Let \fIG\fR\d\fIk\fR\ube the weighting factor for handling a user packet of type\ \fIk\fR [including the handling of an appropriate \*Qshare\*U of associated acknowledgement packets]. .PP The data traffic mix (fractions of total) and volumes is forecast by the Administration. .PP Let \fIQ\fR\d\fIk\fR\ube the fraction of user packets of type \fIk\fR . Note that: \v'6p' .RT .ad r .ad b .RT .PP If \fIR\fR\d\fIp\fR\u= user packet arrival rate, then the amount of processing capacity required for work associated with user packet traffic of the k\(hyth type is: \v'6p' .sp 1P .ce 1000 \fIQ\fR\d\fIk\fR\u\fIG\fR\d\fIk\fR\u\fIR\fR\d\fIp\fR\u .ce 0 .sp 1P .LP .sp 1 .PP In order to satisfy performance criteria the reference packet processing capacity (RPPC) must be equal to or greater than the total packet handling work. Thus: \v'6p' .ad r .ad b .RT .LP .bp .PP From which the maximum packet processing capacity \fIR\fR\d\fIp\fR\umax is: \v'6p' .ad r .ad b .RT .sp 1P .LP A.6.2.4 \fIExample of a packet processing computation for an interface\fR \fIunit packet processor\fR .sp 9p .RT .PP Information furnished by the manufacturer: .RT .LP a) RPPC = 10000 reference packet work units per second .LP b) Weighting factors (\fIG\fR ): .LP \(em X.25 type data = 1.00 (reference type) .LP \(em X.75 type data = 0.70 .LP Estimated data traffic mix (furnished by the Administration): .ce \fBH.T. [T42.543]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(30p) | cw(60p) . Type Traffic portion (Q) _ .T& cw(30p) | cw(60p) . X.25 0.52 .T& cw(30p) | cw(60p) . X.75 0.48 _ .TE .nr PS 9 .RT .ad r \fBTable [T42.543], p.\fR .sp 1P .RT .ad b .RT .PP Computation .ce \fBH.T. [T43.543]\fR .ce .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(48p) | cw(60p) . Packet type Processing factor _ .T& cw(48p) | rw(60p) . X.25 data 1.00 \(mu 0.52 = 0.520 .T& cw(48p) | rw(60p) . X.75 data 0.70 \(mu 0.48 = 0.336 .T& cw(48p) | rw(60p) . Total\ \ \ 0.856 _ .TE .nr PS 9 .RT .ad r \fBTable [T43.543], p.\fR .sp 1P .RT .ad b .RT .PP Maximum processing capacity for the above data traffic mix: \v'6p' .sp 1P .ce 1000 \fIR\fR\d\fIp\fR\umax = @ { 000 } over { .856 } @ = 1168 packets per second .ce 0 .sp 1P .PP .sp 1 If the estimated data packet arrival rate (\fIR\fR\d\fIp\fR\u) does not exceed the above number, then packet handling capacity in the interface unit will not limit the number of digital lines or circuits that generate data packets terminated on the unit. If it does exceed the above number, the digital lines and circuits generating the packet traffic will have to be spread over more interface units. .bp .sp 1P .LP A.7 \fICapacity computation for exchange architectures other than that\fR \fIassumed in Figure\ A\(hy1/Q.543\fR .sp 9p .RT .PP If the same processor is used for both call set\(hyup (circuit switched calls and packet calls) and for handling data packet traffic, the capacity of the processor must be allocated between the two functions. This can be done by computing the capacity of the processor for each function separately [with zero capacity used for the other function] and then allotting capacity between the two functions as required. Thus, if a processor has a maximum call processing capacity of 100,000\ calls per hour \fIor\fR 1,000\ packets per second, for every 100\ packets per second of packet handling capacity required, the call processing capacity will be reduced by 10,000\ calls. .RT .sp 1P .LP A.8 \fIConclusion\fR .sp 9p .RT .PP The methodology shown here illustrates a possible approach for determining the limiting factors in an exchange design and for computing its processing capacity. It is most important that the exchange architecture be understood, that capacity limiting elements be identified and that the proper computations be made to determine the true capacity of the exchange. These procedures can be used in engineering and loading the exchange most effectively. Trade\(hyoffs can be made between the use of capacity for various purposes. For example, in Figure\ A\(hy1/Q.543, a signalling terminal is shown connected to an interface unit. In that IU, the available processing capacity will be reduced by the amount of work required by the interface unit to support that terminal. The remainder of the processing capacity can be allocated effectively by using information generated in the call processing computation methodology. .PP It is also very important that the capacity of an exchange should not be calculated using the entire capacity for call processing. It should be made using the processing capacity available under \*Qnormal\*U operating conditions with the exchange performing all the operations and administrative functions expected of it during the busy hour. .RT .LP .rs .sp 28P .ad r \fBFigure A\(hy1/Q.543, p.\fR .sp 1P .RT .ad b .RT .LP .bp .ce 1000 ANNEX\ B .ce 0 .ce 1000 (to Recommendation Q.543) .sp 9p .RT .ce 0 .ce 1000 \fBAn example of a methodology for measuring\fR \fBexchange capacity\fR .sp 1P .RT .ce 0 .LP B.1 \fIGeneral\fR .sp 1P .RT .PP The capacity of an exchange used for call processing can be measured in a laboratory or in the field and projections can be made to predict the maximum processing capacity of the exchange design for the configuration and load characteristics involved in the measurements. This Annex serves as an example of a methodology that makes it possible to measure the processing capacity of an exchange for the configuration and load characteristics involved in the measurement. .RT .sp 1P .LP B.2 \fITheory behind the measurement method\fR .sp 9p .RT .PP The call handling capacity of \fIa processor\fR | an be expressed in terms of the maximum number of calls (or call attempts) which can be processed in a fixed interval of time while meeting all service criteria. In normal conditions, the work functions performed by a switching system processor can be divided into three categories (one fixed level and two variable) as shown in Figure\ B\(hy1/Q.543. .RT .LP .rs .sp 19P .ad r \fBFigure B\(hy1/Q.543, p.\fR .sp 1P .RT .ad b .RT .PP At normal loads, a linear relationship is usually observed between offered load and processor utilization. However, at heavy loads, some system components may become overloaded and this can be reflected in non\(hylinearity in the processor utilization versus load characteristic. .PP In the case of a single processor controlled system, Figure B\(hy1/Q.543 represents the processing capacity of the exchange. In a multi\(hyprocessor system, the capacity is distributed among processors and the exchange capacity is related to the system configuration and the exchange processing capacity is a function of the processors involved in call handling functions. .PP As shown in Figure B\(hy1/Q.543, the processing capacity of a processor is divided between three elements: .RT .LP 1) fixed overhead related to mandatory tasks (e.g. task scheduling and scanning); .LP 2) call processing work (including traffic\(hyrelated overhead tasks); .LP 3) deferrable (base\(hylevel) tasks (e.g. routine maintenance). .bp .PP The tasks which a processor executes are assigned to three levels of priorities, base, medium and high\(hylevel tasks (see Figure\ B\(hy2/Q.543 | ) and Figure\ B\(hy2/Q.543 | )). .LP .rs .sp 17P .ad r \fBFigure B\(hy2/Q.543, p.\fR .sp 1P .RT .ad b .RT .PP As the traffic load (call attempts) increases call processing work expands and the processing of deferrable tasks decreases. .PP Measurement of the percentage of time spent by the processor performing base\(hylevel tasks gives an indication of the percent or processing capacity required for a particular load on the processor. .PP As shown in Figure B\(hy2/Q.543 | ), at low traffic load, the percentage of time used to perform base\(hylevel tasks is relatively high. In Figure\ B\(hy2/Q.543 | ), at high traffic load, the percentage of time at base\(hylevel is relatively low. Thus the measurement of percentage of time used to perform base\(hylevel tasks can be used to determine call processing capacity. .RT .sp 1P .LP B.3 \fICapacity measurement methodology for exchanges\fR .sp 9p .RT .PP Measurements can be performed on exchanges in laboratories or in the field to measure capacity usage for various load levels and then to project the data to estimate the call processing capacity of a processor. .PP The collection of data will depend on facilities available to perform the required measurements. The exchange may be designed to provide indications of time spent performing base\(hylevel tasks or it may be necessary to access the bus system of a processor in order to measure this time. Equipment will be needed to create loads, or loads in a working exchange must be measured in order to establish load points. Various level loads for the various types of calls (or services) should be observed in order to establish a basis for projecting the load line to determine the maximum processing capacity for the mix of traffic services assumed or measured. In projecting call capacity care must be taken not to extrapolate beyond the linear region of the processor utilization versus offered call attempts relationship. .RT .PP Where multi\(hyprocessors are involved, the exchange configuration, the distribution of traffic types and processing capacity of each processor must be examined to determine the limiting factors that controls the exchange capacity (as discussed in Annex\ A. An example of methodology for computing the call processing capacity of a digital exchange, taking into account ISDN services, including packet data handling). .bp .LP .rs .sp 22P .ad r \fBFigure B\(hy3/Q.543, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fBRecommendation\ Q.544\fR .RT .sp 2P .sp 1P .ce 1000 \fBDIGITAL\ EXCHANGE\ MEASUREMENTS\fR .EF '% Fascicle\ VI.5\ \(em\ Rec.\ Q.544'' .OF '''Fascicle\ VI.5\ \(em\ Rec.\ Q.544 %' .ce 0 .sp 1P .LP \fB1\fR \fBGeneral\fR .sp 1P .RT .PP This Recommendation applies to digital local, combined, transit and international exchanges for telephony in Integrated Digital Networks\ (IDN) and mixed (analogue/digital) networks, and also to local, combined, transit and international exchanges in an Integrated Digital Networks\ (ISDN). The field of application of this Recommendation is more fully defined in Recommendation\ Q.500. Some measurements only apply to a certain type (or types) of exchange. Where this occurs, the application is defined in the text. Where no such qualification is made, the measurement applies to all exchange applications. .PP This Recommendation includes traffic and performance measurements that are necessary for provisioning and operating exchanges so as to satisfy grade of service objectives covered in the E.500 series of Recommendations. These measurements are typically performed during specified periods and intervals after which the results are sent to designated local and/or remote exchange terminals or operation and maintenance centres\ (OMC) or any other appropriate data handling centre. In some cases, data may be utilized in its original form whereas in other cases data may need to be processed to determine when pre\(hyset thresholds are exceeded and/or to recognize an abnormal condition when it occurs. In this Recommendation, no particular system design requirement is implied. Different designs may have more or less data accumulated and processed within the exchange or by an external system. .PP Different types and sizes of exchanges may require different sets of measurements. Also, different Administrations may have different requirements for measurements depending on policies, procedures or national network considerations. An Administration may thus find it desirable in some applications to measure items that are not covered by this Recommendation whereas in other applications some measurements may not be desired. .bp .PP Exchange measurements are required for both national and international service. Requirements for international service take into consideration the following CCITT\ Recommendations: .RT .LP \(em Recommendations E.401 to E.427: International telephone network management and checking of service quality; .LP \fR \(em Recommendations E.230 to E.277: Operational provisions relating to charging and accounting in the international telephone service. .PP The aspects of traffic engineering are given in Recommendations\ E.500 to E.543. Recommendations on traffic meaurements for SPC exchanges are provided by Recommendations\ E.502, E.503 and\ E.504. .PP Additional measurements in an exchange, not specified in this Recommendation, are required, e.g.\ for: .RT .LP \(em Transmission performance (Recommendations Q.551, Q.552, Q.553 and\ Q.554). .LP \(em Digital access signalling (Recommendations Q.920 to Q.931). This is for further study. .LP \(em Packet mode (Recommendations X.25 and X.75). This is for further study. .LP \(em Signalling System No. 7 (e.g. those measurements specified in Recommendation\ Q.791 for the message transfer part require further study to determine their applicability to this Recommendation). .PP \fINote\fR \ \(em\ For the terms and definitions of teletraffic used in this Recommendation, see Recommendation\ E.600. .sp 2P .LP \fB2\fR \fBMeasurement processes\fR .sp 1P .RT .sp 1P .LP 2.1 \fIGeneral\fR .sp 9p .RT .PP The activities involved in exchange measurements can be split in four processes as represented by Figure\ 1/Q.544. .RT .LP .rs .sp 17P .ad r \fBFigure 1/Q.544, p.\fR .sp 1P .RT .ad b .RT .LP .bp .PP On choice of each individual national Administration, the above four processes can be fully or partially integrated into the exchanges. .PP It is nevertheless recommended that: .RT .LP a) \fIdata collection\fR | be fully integrated into the exchange for all types of data; .LP b) \fIdata presentation\fR | be integrated into the exchange and/or at the O&M centre at least for the measurements required by O&M personnel. .PP Presentation of data required for planning and administration activities could be performed at the O&M personnel premises or in other locations which could be more centralized and generally takes place at a deferred time. .sp 1P .LP 2.2 \fIData collection\fR .sp 9p .RT .PP Three different activities of data collection can be identified: .RT .LP \(em event registration; .LP \(em traffic registration (traffic intensity and/or volume of traffic); .LP \(em call records registration. .PP The data generated by event registration and traffic registration are suitable for direct utilization (immediate presentation). .PP Call records can only be utilized after off\(hyline analysis. Processing of call records can generate any type of data, including the event registration and traffic registration. .RT .sp 1P .LP 2.3 \fIBulk data storage, analysis and processing\fR .sp 9p .RT .PP Data storage for collected data can be required for accumulation of a massive data base suitable for subsequent analysis and processing. .PP These data can be held in the exchange for processing at the exchange location or transferred to administrative and engineering centres. .RT .sp 1P .LP 2.4 \fIData presentation\fR .sp 9p .RT .PP It is the function through which the collected data are becoming readable. Features related to the data presentation are: .RT .LP a) location of presentation; .LP b) time frame of presentation. It is dependent on the nature of the data and their utilization. The activities of maintenance and network management require immediate presentation; .LP c) physical support of the displayed data and relevant format. These aspects are mainly related to the type of data and are to be left to individual implementations. .sp 2P .LP \fB3\fR \fBTypes of measurement data\fR .sp 1P .RT .PP Measurement data primarily consists of counts of various events and the traffic intensity on various resources. For certain measurement data, sampling, or time averaging techniques may provide an acceptably accurate result. In some cases, externally generated test calls may provide the most practical method of obtaining the data. In other cases, call records, such as detailed charging records, may be used. .RT .sp 1P .LP 3.1 \fIEvent counts\fR .sp 9p .RT .PP Events, for example incoming seizures, call attempts encountering busy, and call attempts to specified destination codes should be countable. Some event counts may be accumulated over the whole exchange whereas others may be accumulated only over a subset such as an inter\(hyexchange circuit group. In some cases, event counts may be accumulated several ways. .bp .RT .sp 1P .LP 3.2 \fITraffic intensity\fR .sp 9p .RT .PP Traffic intensity on a pool of resources is the traffic volume divided by the duration of observation. It is thus equal to the average number of busy resources. As in the case of event counts, traffic intensity data may be for the whole exchange or for various subsets. .RT .sp 1P .LP 3.3 \fICall records\fR .sp 9p .RT .PP Call records contain data used by the exchange for the setting up of calls. The data may include the identity and classification of the originating line or incoming circuit, the dialled number, the call routing and disposition, and possibly the time of occurrence of certain events during the entire call period. .PP Call records can be generated and outputted by the exchange to allow the establishment of a data base suitable for off\(hyline processing to determine traffic values and characteristics. Output of the call records associated with a statistical sample of total calls may be sufficient for this purpose. .RT .sp 2P .LP \fB4\fR \fBMeasurement administration\fR .sp 1P .RT .PP Exchanges should provide capabilities for operating personnel to establish measurement schedules and direct the output routing of measurement results. The methods of establishing measurement schedules should be designed to minimize the introduction of errors when defining relevant parameters. It should be possible to have a number of measurements simultaneously active with different schedules and output routings. A single measurement should be capable of having more than one measurement schedule and/or output routing simultaneously. The number of measurement types running concurrently may be limited to conserve exchange storage and processing resources. Criteria for measurement and recording of traffic may be found in Recommendation\ E.500 and other related E\(hySeries Recommendations. .RT .sp 2P .LP 4.1 \fIScheduling\fR .sp 1P .RT .sp 1P .LP 4.1.1 \fIRecording periods\fR .sp 9p .RT .PP A recording period is the time interval during which a measurement is performed. Measurements can be activated either on\(hydemand or according to a time schedule. .PP Different measurement periods may be schedulable for different days of the week. For example, a measurement may be scheduled for\ 0900 to\ 1800 on Monday through Friday and\ 0900 to\ 1200 on Saturday. The measurements for an entire week may be programmed and the weekly cycle may be repeated until a new command will stop it. .RT .sp 1P .LP 4.1.2 \fIResult accumulation periods\fR .sp 9p .RT .PP A recording period contains one or more result accumulation periods. The beginning and ending of the recording period must correspond to the beginning and ending of result accumulation periods. .PP The measurement result outputs are to be made available at the end of each result accumulation period and shall refer to that period. .PP More than one result accumulation period may be required for an individual measurement. .RT .sp 2P .LP 4.2 \fIData output criteria\fR .sp 1P .RT .sp 1P .LP 4.2.1 \fIOn schedule\fR .sp 9p .RT .PP Measurement data output typically occurs shortly after the end of each result accumulation period specified by the measurement schedule. Alternatively, the exchange may store the data in its memory for limited periods, e.g.\ in the event of contention for output resources. .RT .sp 1P .LP 4.2.2 \fIOn demand\fR .sp 9p .RT .PP (For further study.) .bp .RT .sp 1P .LP 4.2.3 \fIOn exception\fR .sp 9p .RT .PP The exchange should be able to provide measurement data when specified criteria are met, for example, when the rate of incoming call attempts exceeds a particular value. .RT .sp 2P .LP 4.3 \fIData output routing\fR .sp 1P .RT .sp 1P .LP 4.3.1 \fITo a local or remote terminal\fR .sp 9p .RT .PP Measurement data should be able to be routed for printing or display on designated terminals which are either directly connected to the exchange or remotely connected via dedicated or switched circuits. .RT .sp 1P .LP 4.3.2 \fITo an external processing centre\fR .sp 9p .RT .PP Measurement data should be routable to external locations such as OMC that provide data collection and analysis functions for multiple exchanges. .RT .sp 1P .LP 4.3.3 \fITo local storage media\fR .sp 9p .RT .PP An Administration may require exchanges to store measurement data in bulk memories such as magnetic tapes for later processing and analysis. This could be an alternative to sending the data to an OMC. .RT .sp 1P .LP 4.4 \fIPriorities\fR .sp 9p .RT .PP High priority should be assigned to certain measurements that are essential, e.g.\ those associated with collection and output of data used for overload detection, network management and accounting. These should not be discontinued during periods of exchange processing congestion (see Recommendation\ Q.543, \(sc\ 3.8). Measurements that have been suspended should be resumed in an order that is reverse to the order in which they were suspended. .PP When recovery procedures are invoked, records associated with call accounting and billing should be retained. .RT .sp 2P .LP \fB5\fR \fBApplication of measurements\fR .sp 1P .RT .sp 1P .LP 5.1 \fIPlanning and engineering\fR .sp 9p .RT .PP Measurement data is essential for planning efficient telecommunication networks that meet specified grade\(hyof\(hyservice standards. Analysis of data accumulated over a period of time provides information needed to forecast future demand and to plan and engineer extensions to the network. .RT .sp 1P .LP 5.2 \fIOperation and maintenance\fR .sp 9p .RT .PP Operation and maintenance functions are supported by the following types of measurement data: .RT .LP i) performance data pertaining to call handling irregularities and delays; .LP ii) availability data for the exchange, its subsystems, and its connecting subscriber lines and inter exchange circuits; .LP iii) load on various components of the exchange. .PP The above data may be used to evaluate exchange and network performance and to plan rearrangements to improve the service provided by the existing network equipment. .sp 1P .LP 5.3 \fINetwork management\fR .sp 9p .RT .PP Data for network management includes certain traffic and performance measurements and status indications. These are used to detect abnormalities in the network and to automatically enable, or allow manual operation of, network management controls. In some cases, the data must be analyzed to determine whether specified thresholds are being exceeded. Since the effectiveness of network management actions depends upon their responsiveness to changing conditions in the network as a whole, it may be appropriate to perform this analysis by a data processing system serving one or more exchanges and display the results at a network management centre. Network management functions are covered in Recommendations\ E.410 through E.414 and\ Q.542. .bp .RT .sp 1P .LP 5.4 \fIAccounting in international service\fR .sp 9p .RT .PP Accounting in international service needs to be mutually agreed between Administrations; Recommendations\ E.230 to\ E.277 apply. .RT .sp 1P .LP 5.5 \fISubdivision of revenue\fR .sp 9p .RT .PP Subdivision of revenue is a matter of agreement between RPOAs of the same country. Requirements in this area are a national matter. .RT .sp 1P .LP 5.6 \fITariff and marketing studies\fR .sp 9p .RT .PP The studies are intended to identify subscriber needs and trends. Requirements in this area are a national matter. .RT .sp 2P .LP \fB6\fR \fBCall events definition\fR .sp 1P .RT .PP This section is applicable to 64 kbit/s circuit switched call attempts. Application to other types of calls or Supplementary Services is for further study. .RT .sp 1P .LP 6.1 \fIGeneral\fR .sp 9p .RT .PP Every call attempt coming from a subscriber line or interexchange circuit moves across a branch of the possible status of call events reference diagram shown in Figure\ 2/Q.544. .RT .sp 2P .LP 6.2 \fICall events detailed description\fR .sp 1P .RT .sp 1P .LP 6.2.1 \fISeizure from a subscriber line or incoming circuit\fR .sp 9p .RT .PP This is the starting point for an incoming/outgoing call attempt. .RT .sp 1P .LP 6.2.2 \fIValid address\fR .sp 9p .RT .PP The incoming/originating seizure is successfully accepted by the exchange. .RT .sp 1P .LP 6.2.3 \fINot routed call attempt\fR .sp 9p .RT .PP A call attempt that is not routed through the exchange, perhaps due to an exchange condition or to receipt of an address that is incomplete or invalid. .RT .sp 1P .LP 6.2.3.1 \fIFalse start\fR .sp 9p .RT .PP An incoming seizure signal that has been recognized without being followed by digit reception. .RT .sp 1P .LP 6.2.3.2 \fIIncomplete dialling (time out, abandon)\fR .sp 9p .RT .PP An incoming seizure that has been received but the number of received digits is not sufficient to perform call routing. .RT .sp 1P .LP 6.2.3.3 \fIInvalid address\fR .sp 9p .RT .PP An attempt where the received digits do not correspond to an existing or allowed destination. The call is then given interception treatment (tone or announcements or operators). .RT .sp 1P .LP 6.2.3.4 \fICall not routed due to the exchange\fR .sp 9p .RT .PP A call attempt where the system cannot perform call routing due to internal reasons (congestion): \v'3p' .RT .LP 1) Blocking through the switching network .LP Although there is an outgoing circuit/subscriber line available for the required destination, the connection cannot be realized through the switching network, and no further routing choices are available. .LP 2) Unavailability of common resources .LP Unavailability of service circuits or other common resources (e.g. memory areas) .LP 3) System faults .LP Presence of some internal fault in the exchange. .bp .LP .rs .sp 47P .ad r \fBFigure 2/Q.544, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 6.2.4 \fICalls routed to interexchange circuits\fR .sp 9p .RT .PP These calls are successfully routed to an outgoing circuit available for the required destination or routed to another circuit group for overflow reasons. When making overall exchange measurements, these calls can be counted all together. .RT .sp 1P .LP 6.2.4.1 \fISeizure of outgoing circuit\fR .sp 9p .RT .PP These are calls that are routed to a specific circuit. They have to be separately counted when making measurements on the outgoing circuit group. .RT .sp 1P .LP 6.2.4.2 \fIOverflow to next circuit group\fR .sp 9p .RT .PP These are calls that cannot be routed on a specific circuit group but are routed to a subsequent routing\(hychoice circuit group. They have to be counted separately when making measurements on the outgoing circuit group. Measurement of the subsequent events associated with these calls are only associated with circuit group on which the calls are routed. .RT .sp 2P .LP 6.2.5 \fICalls not routed due to network conditions\fR .sp 1P .RT .sp 1P .LP 6.2.5.1 \fICalls in overflow from the last routing choice\fR \fI(all circuits busy)\fR .sp 9p .RT .PP These are calls on which the system cannot perform routing due to the unavailability of outgoing circuits towards the required destination. .RT .sp 1P .LP 6.2.5.2 \fICalls blocked by network management controls\fR .sp 9p .RT .PP These are call attempts that are suppressed by the exchange as a consequence of the application of network controls. .RT .sp 1P .LP 6.2.6 \fISuccessful backward call set\(hyup signal\fR .sp 9p .RT .PP These are calls for which a backward signal is received, indicating the conclusion of call routing at a remote exchange, but not answered. The set of signals typically includes: .RT .LP \(em end of selection .LP \(em address complete .LP \(em subscriber line free .sp 2P .LP 6.2.7 \fIUnsuccessful call attempts\fR .sp 1P .RT .sp 1P .LP 6.2.7.1 \fIReceiving an unsuccessful backward call set\(hyup signal\fR .sp 9p .RT .PP This occurs when a backward signal is received indicating the impossibility of setting up the call. .PP These backward signals typically are: .RT .LP \(em congestion signals .LP \(em subscriber line busy signals .LP \(em signals defined as part of the UBM (Unsuccessful Backward set\(hyup information Message) group of messages in CCITT Signalling System\ No.7 (see Recommendation\ Q.723). .sp 1P .LP 6.2.7.2 \fINot receiving a backward call set\(hyup signal\fR .sp 9p .RT .PP These are calls that are abandoned or forced\(hyout before reception of any backward call set\(hyup signal. They include: .RT .LP \(em calls abandoned by the calling party .LP \(em calls forced out by the expiration of timers. .bp .PP Note that within these categories of calls there are several types of call disposition that cannot be distinguished by the exchange since they may be characterized by tones, announcements or the lack thereof, for instance: .LP \(em ring\(hyback tone .LP \(em busy tone .LP \(em congestion tone .LP \(em announcements .LP \(em no tones or announcements .LP \(em incompletely dialled calls .sp 1P .LP 6.2.8 \fICalls routed to subscriber line\fR .sp 9p .RT .PP These are call attempts that are successfully routed to a subscriber line. .RT .sp 1P .LP 6.2.9 \fICalls not routed due to called line conditions\fR .sp 9p .RT .PP These are unsuccessful call attempts which do not reach answer status due to the particular condition of the called subscriber line: .RT .LP \(em busy .LP \(em out\(hyof\(hyservice .LP \(em rerouted call .LP \(em no free outlet .LP \(em etc. .sp 1P .LP 6.2.10 \fIAnswered calls\fR .sp 9p .RT .PP These are calls that reach the \*Qanswered\*U status. Depending on the signalling protocol answered status can be reached in one of the following ways: .RT .LP \(em reception of an answer signal .LP \(em reception of a metering pulse .LP \(em immediate answer status on seizure (of the subscriber line/outgoing interexchange circuit). .PP The following events are \fInot\fR included in this class of calls: .LP \(em reception of Re\(hyanswer signal .LP \(em answer from an intercepting device (automatic or manual) due to call diversion at the transit exchange. .sp 1P .LP 6.2.11 \fINot answered call attempts\fR .sp 9p .RT .PP These are calls on which an answer signal is not received after a successful backward signal has been received, or after the seizure of the called subscriber line. These include: .RT .LP \(em calls forced\(hyout by the expiration of timers .LP \(em calls abandoned by the calling party after listening to ring\(hyback tone. .sp 2P .LP \fB7\fR \fBTraffic measurements\fR .sp 1P .RT .PP This section is applicable to 64 kbit/s circuit switched traffic. \*QApplication to other types of traffic or supplementary services is for further study.\*U .RT .sp 1P .LP 7.1 \fIGeneral\fR .sp 9p .RT .PP Traffic in an exchange can be categorized as shown in Figure\ 3/Q.544. All measurements listed in this section can be obtained by recording and analyzing events that can be experienced by calls. .bp .RT .LP .rs .sp 15P .ad r \fBFigure 3/Q.544, p.\fR .sp 1P .RT .ad b .RT .PP It is not intended that every exchange should be required to make all the different measurements in this Recommendation. Due to the application of various signalling methods and differing switching system designs, some variation of the measurements might be appropriate in a specific exchange. For example, an Administration may require more detailed counts of events to permit a meaningful call failure analysis on a specific exchange. Furthermore, the traffic categories to which any measurement relates may vary depending on system design, on system application and measurement utilization. .PP Measurements may be combined into sets appropriate to a specific type of exchange, for example, local or transit. In particular, Administrations may consider that, by the use of a few measurement sets, it is possible to satisfy the majority of their requirements. .RT .sp 1P .LP 7.2 \fIOverall measurements\fR .sp 9p .RT .PP The following measurements are applicable to the total traffic of an exchange. Due to possible variations in sytem design, the traffic categories to which any measurement relates may vary from that shown in the following text. Figure\ 3/Q.544 illustrates the exchange traffic categories. .RT .sp 1P .LP 7.2.1 \fIOriginating traffic\fR \v'3p' .sp 9p .RT .LP a) Originating call attempts. .LP b) Invalid call attempts for example: .LP \(em no dialling, .LP \(em incomplete dialling, .LP \(em invalid number dialled. .LP c) Call attempts not routed due to the exchange, for example, due to: .LP \(em blocking through the switching network, .LP \(em unavailability of common resources, .LP \(em system faults. .LP d) Internal call attempts. .sp 1P .LP 7.2.2 \fIIncoming traffic\fR \v'3p' .sp 9p .RT .LP a) Incoming seizures. .LP b) Invalid call attempts for example: .LP \(em incomplete dialling, .LP \(em invalid number dialled. .bp .LP c) Call attempts not routed due to the exchange, for example, due to: .LP \(em blocking through the switching network, .LP \(em unavailability of common resources, .LP \(em system faults. .LP d) Transit call attempts. .sp 1P .LP 7.2.3 \fITerminating traffic\fR \v'3p' .sp 9p .RT .LP a) Call attempts routed to subscriber lines. .LP b) Call attempts not routed due to line condition. .sp 1P .LP 7.2.4 \fIOutgoing traffic\fR \v'3p' .sp 9p .RT .LP a) Outgoing call attempts routed to an interexchange circuit. .LP b) Call attempts not routed due to network condition. .LP c) Unsuccessful call attempts. .sp 1P .LP 7.2.5 \fIService utilization\fR .sp 9p .RT .PP The exchange should be able to measure the utilization of each type of basic and supplementary service it provides. The mix of services and the corresponding exchange measurements depends upon switching system capabilities and Administration policies. .RT .sp 1P .LP 7.3 \fIInterexchange circuit groups\fR .sp 9p .RT .PP The measurements apply to individual circuit groups. All circuit groups should be measurable. For traffic intensity, it may be desirable to measure all circuit groups simultaneously. Information for estimating the average number of circuits in service during the result accumulation period should be provided in addition to the traffic data for each circuit group. .RT .sp 1P .LP 7.3.1 \fIIncoming traffic\fR .sp 9p .RT .PP Incoming traffic is understood to be: .RT .LP \(em the traffic on incoming circuit group, .LP \(em the incoming traffic on both\(hyway circuit groups. .PP The following parameters should be measured: .LP a) traffic intensity, .LP b) number of seizures. .sp 1P .LP 7.3.2 \fIOutgoing traffic\fR .sp 9p .RT .PP Outgoing traffic is understood to be: .RT .LP \(em the traffic on outgoing circuit groups, .LP \(em the outgoing traffic on both\(hyway circuit groups. .PP The following parameters should be measured: .LP a) traffic intensity, .LP b) number of seizures, .LP c) number of call attempts overflowing from the group, .LP d) answered call attempts. .sp 1P .LP 7.4 \fISubscriber line groups\fR .sp 9p .RT .PP These measurements are applicable to groups of subscriber lines that share switching network access paths. The lines served by a particular line concentration unit of a local exchange would be an example of such a group. In systems where traffic levels on such line groups could result in failure to meet grade of service objectives, appropriate measurements for load balancing purposes should be provided. \v'3p' .bp .RT .LP a) Originating calls .LP i) Number of call attempts .LP ii) Number of call attempts resulting in an outgoing seizure .LP iii) Number of answered calls .LP iv) Traffic intensity .LP b) Terminating calls .LP i) Number of call attempts .LP ii) Number of answered calls .LP iii) Traffic intensity .LP c) Internal (e.g. intra\(hyconcentrator calls) .LP i) Number of call attempts .LP ii) Number of answered calls .LP iii) Traffic intensity .sp 1P .LP 7.5 \fIAuxiliary units\fR .sp 9p .RT .PP Auxiliary units provide functions such as multifrequency signalling, tones, announcements, and access to operators. Grouping of auxiliary units may vary with system implementation characteristics. Groups in this section refer to system independent functional groups. Some systems may allow calls to wait for an auxiliary circuit of one is not immediately available. .PP The measurements indicated below are intended to provide information for the dimensioning of auxiliary units. They should be provided for each group which may require dimensioning. Measurements may be activated for any specified list of auxiliary units. Information for estimating the average number of units in service during the result accumulation period should be provided in addition to the traffic data for each circuit group: .RT .LP a) traffic intensity, .LP b) number of seizures, .LP c) number of bids not served. .sp 1P .LP 7.6 \fIControl unit(s)\fR .sp 9p .RT .PP These measurements are highly system dependent and therefore no specific recommendations can be made. However, it is essential that systems will have provisions for determining the utilization of control equipment, such as processors, for dimensioning, planning, and grade of service monitoring of the exchange. .RT .sp 1P .LP 7.7 \fICall attempt destinations (see also \(sc 9.3)\fR .sp 9p .RT .PP These measurements are used to assess the probability of success on calls to various destinations and may be used in deciding on any network management actions considered necessary. The number of destination codes specified for measurement at any one time may be limited. For any specified destination code, the following parameters should be measured: .RT .LP a) number of call attempts, .LP b) number of call attempts resulting in an outgoing seizure, .LP c) number of answered calls. .PP Intensity measurements for specified destination codes may be required by some Administrations for traffic engineering purposes. .sp 2P .LP \fB8\fR \fBExchange performance and availability measurements\fR .sp 1P .RT .sp 1P .LP 8.1 \fIPerformance measurements\fR .sp 9p .RT .PP For monitoring the exchange grade of service, a certain number of parameters should be observed. They may include the measurements given in Recommendation\ E.543 for delay grade of service monitoring. However, other processing delays (see relevant paragraphs of Recommendation\ Q.543) may be observed for complete monitoring of the exchange grade of service. .bp .PP Measuring processing delays on a per call or statistical basis could be burdensome to the exchange. Moreover, some processing delays may not be measurable with an acceptable time accuracy and others may not be easily measured by the exchange itself. .PP Operating procedures of Administrations will impose constraints on the accuracy of the measurements for grade of service monitoring purposes. When such accuracy requirements allow, it may be possible to measure processing delays on a sample or test call basis. Requirements in this area are therefore a national matter. .RT .sp 1P .LP 8.2 \fIAvailability measurements\fR .sp 9p .RT .PP The exchange should record the beginning and ending time of all detected instances during which service is unavailable to one or more exchange terminations. The recorded information should permit the determination of the number and identity of terminations affected if possible. .RT .sp 2P .LP \fB9\fR \fBData for network management\fR .sp 1P .RT .sp 1P .LP 9.1 \fIGeneral\fR .sp 9p .RT .PP Procedures for network management are specified in Recommendations\ E.410 through\ E.414. Those procedures make use of data from exchanges to determine overall network performance and, when required, appropriate control actions. Much of the data required for network management is also needed for other operation and maintenance functions. However, effective network management requires control actions to be executed quickly in response to changing network and traffic conditions. Therefore, exchanges that Administrations have designated to provide network management functions must be able to provide traffic and status data to other exchanges and network management centres on a pre\(hyarranged basis or when triggered by a specific event, such as an overload condition. The network management functions provided by any specific exchange will depend upon factors such as its size, position in the network, and Administration policies. .PP Details of traffic measurement requirements for network management are found in Recommendation\ E.502. Most of the information required for network management operations can only be generated by the exchanges and consist of two general categories of data: \v'3p' .RT .LP a) Network status information, for example: .LP \(em busy/idle status of circuit groups .LP \(em individual equipment's availability .LP \(em alarms .LP \(em network management action (controls) in effect .LP Status information generally does not require measurements. .LP b) Network traffic load and performance information, for example: .LP \(em number of bids per route per hour .LP \(em answer/seizure ratio per route per destination. .PP This type of information requires \*Qreal\(hytime\*U monitoring of network performances via exchange measurements, and it is specifically the subject of this part of the Recommendation. The objects and entities of measurement are given in full details by \(sc\(sc\ 9.2, 9.3 and\ 9.4. .PP The exchange generated information can be: .RT .LP \(em utilized at the source exchange, if network management actions are taken locally, .LP \(em transmitted to other exchanges or elements of the TMN (typically to network management centres) for possible network management actions. .PP It should be noted that exchange internal overload controls are complementary to network management functions, and the information generated by the internal overload monitoring system can also be used for network management functions. Exchange performance under overload conditions is dealt with in Recommendation\ Q.543,\ \(sc\ 3. .bp .sp 2P .LP 9.2 \fIManagement on interworking circuit groups\fR .sp 1P .RT .sp 1P .LP 9.2.1 \fIGeneral\fR .sp 9p .RT .PP Performance monitoring of interexchange circuit groups for network management purposes should be performed on outgoing traffic. This is where the offered and routed traffic can be seen. .PP Circuit group monitoring should be organized on the basis of individual interexchange circuit groups. It should be possible to monitor the performance of all circuit groups. However, the number of circuit groups to be monitored simultaneously at an exchange and the length of data accumulation periods will depend on many aspects of the network management implementation and the function of the exchange in the network. For example, a large transit exchange may require performance monitoring on a large percentage of its outgoing circuit groups while a local exchange may only require monitoring on a few groups. .PP It should be possible to readily activate/deactivate measurements on circuit groups. .RT .sp 1P .LP 9.2.2 \fIEntities to be measured on interexchange circuit groups\fR .sp 9p .RT .PP The following measurements should be made on outgoing interexchange circuit groups for network management purposes: .RT .LP a) outgoing bids (see Note) .LP b) outgoing seizures (see Note) .LP c) overflow bids (see Note) .LP d) answers received .LP e) count of calls affected by network management circuit group controls. .PP \fINote\fR \ \(em\ Any two of these measurements are necessary. The third can be derived from the other two. .sp 1P .LP 9.2.2.1 \fIAdditional measurements required on international circuit\fR \fIgroups at international transit exchanges\fR \v'3p' .sp 9p .RT .LP \(em transit bids (international traffic only) .LP \(em incoming seizures (international transit traffic only). .sp 1P .LP 9.2.3 \fICalculated network performance parameters\fR .sp 9p .RT .PP The entities of measurement in \(sc 9.2.2 can be used to calculate all the network management performance parameters required for network management on the basis of (Draft) Recommendation\ E.411 as follows: .RT .LP a) bids per circuit per hour .LP b) seizures per circuit per hour .LP c) percentage overflow .LP d) answer/seizure ratio .LP e) answer/bid ratio .LP f) mean holding time per seizure. .PP Depending on the type of network management implementation the network performance parameters can be calculated at the source exchange, or in other elements of the TMN, consistent with the distribution of the network management functions in the TMN. .sp 2P .LP 9.3 \fIMeasurements on call destinations\fR .sp 1P .RT .sp 1P .LP 9.3.1 \fIGeneral\fR .sp 9p .RT .PP Depending on the network management implementation and the function of the exchange in the network, the exchange should be able to make traffic measurements to different numbers of destinations indicated on a preliminary basis to be critical destinations. Call destinations can be represented by country codes, area codes, exchange codes or any combination of them. .PP Measurement by destination is essential for the implementation of the hard\(hyto\(hyreach network management feature. Typically, traffic measurements by destination will be limited to a predetermined set of destination codes (e.g.\ country or area code). It should be possible to readily expand the scope of the measurements within a focused area when certain thresholds are exceeded. .bp .RT .sp 1P .LP 9.3.2 \fIEntities to be measured on call destinations\fR .sp 9p .RT .PP The following are the entities that should be measurable per destination for network management purposes: .RT .LP a) outgoing bids; .LP b) outgoing circuit seizures; .LP c) answers; .LP d) counts of calls affected by network management controls by type of control. .sp 2P .LP 9.4 \fIMeasurements on exchange resources\fR .sp 1P .RT .sp 1P .LP 9.4.1 \fIGeneral\fR .sp 9p .RT .PP The exchange should be able to monitor the level of utilization of its own common resources, like processing capacity, call registers, hardware units such as digit senders and receivers,\ etc., in order to provide the information on exchange congestion level to the network management function (see Recommendation\ E.411). .PP Since the common resource monitoring function is also required for overload protection purposes, the same mechanisms of measurement can be used for both functions, namely, exchange overload protection and network management. .RT .sp 1P .LP 9.4.2 \fIObjects and entities to be measured on exchange resources\fR .sp 9p .RT .PP The objects and entities of exchange resources to be measured depend on the system architecture. The decision concerning which kind of specific objects and entities should be measured is therefore left to individual Administrations or Operating Agencies. .RT .LP .rs .sp 30P .ad r Blanc .ad b .RT .LP .bp