C:\WINWORD\CCITTREC.DOT_______________ ANNEX A (to Recommendation Q.543) An example of methodology for computing the call processing capacity of a Digital Exchange, taking into account ISDN services, including packet data handling A.1 General 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 signal- ling types will be used on subscriber lines and for handling calls over inter- exchange circuits. Performance objectives have been recommended and are applicable over the full range of exchange sizes and loads up to the limit of exchange “engineered” capabity at its maximum size for the mix of call types handled and 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 meth- odology 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. The method of calculating call processing capacity illustrated herein is for a particular multi—processor exchange design shown in Figure A—1/ Q.543. However, the principles used can be applied to any processor con- trolled exchange design for any mix of services, traffic and signalling han- dled by the exchange. This method requires that manufacturers provide information and data about their exchange designs in terms that Administra- tions 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. 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 con- sidering 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. Figure A—1/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. a) The Interface Unit 1 through n provide interfaces to user lines, interexchange circuits, signalling terminals and any other inter- faces to entities outside the exchange. A certain amount of call processing (e.g. handling signalling to or from lines or interex- change circuits, digit analysis, etc.) can be performed by proces- sors 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—processor lines. 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 Cen- tral 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 informa- tion, and performs other administrative and operations functions for the exchange. 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 under- stand 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. A.2 Definitions A.2.1 capacity unit The processing capacity required in an exchange (or processing unit) to process a call attempt consisting of the originating portion plus the termi- nating (or disposition) portion. A.2.2 half unit 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. A.2.3 originating type A type of call attempt entering the exchange (e.g. a telephone call from a line class—marked for basic telephone service, or one from a line marked for supplementary services, or basic ISDN services, or ISDN sup- plementary services, or a call entering the exchange on an incoming interex- change circuit, etc.). A.2.4 terminating (disposition) type 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 out- going interexchange circuit, etc.). A.2.5 reference capacity unit The processing capacity required for processing an arbitrarily selected pair of half units, one an originating type attempt and one a terminating (dis- position) type attempt, usually a pair that is expected to be involved in a sig- nificant 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 “local” 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.) A.2.6 reference capacity half—unit The processing capacity required in an interface unit to process an arbitrarily selected half—unit, either an originating or a terminating (dispo- sition) 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—unit is used as the stan- dard against which half—units 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 dif- ferent interface units, the same reference capacity half—unit should be used for all calculations. A.2.7 central processor unit (CPU) reference capacity unit 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 F is the fraction of one refer- ence capacity unit for processing the originating portion and F` is the frac- tion of one reference capacity unit required for processing the terminating (disposition) portion, the sum is unity (F + F` = 1). A.2.8 interface unit (IU) reference capacity unit The amount of processing capacity required in the IU in the exchange design shown, to properly handle one reference capacity half—unit. A.2.9 weighting factor The ratio of the relative amount of processing capacity required to handle either portion, originating or terminating (disposition), of any attempt type, to the capacity required in that processor to perform the same functions for reference capacity unit, (originating and terminating (disposi- tion) 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. Similarly, in the interface unit, a weighting factor is the ratio of the amount of IU processing capacity required to handle a particular half—unit to the amount of IU processing capacity required to handle a reference capacity half—unit. Thus if an IU requires 600 cycles to handle a reference capacity half—unit and another type of call entering the exchange via the IU requires 725 IU processor cycles, the weighting factor (IU) for that half— unit attempt type would be 1.21. Weighting factors for all originating and terminating (disposition) types of capacity units and half—units, are required for each processing unit in the exchange in order to make capacity computations. These weighting factors must be furnished by the manufacturer. A.2.10 reference unit (and half—unit) processing capacity (RUPC) Is capacity information that should be furnished by the manufacturer. RUPC is the total number of reference capacity units (and half—units) that can be performed by a processor (or processing unit) in one hour in an exchange while meeting performance criteria specified by the Administra- tion and at the same time performing all the operations and administrative tasks required for normal operation of the exchange. Thus, RUPC is the pro- cessing capacity available for call handling. It is the total 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 “reserve” 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—call handling functions that are accounted for and the percent of capacity that is being reserved for growth. A.3 Processing capacity computation (for a central processing unit) Capacity information and weighting factors are furnished by the man- ufacturer. Let Fi = weighting factor for originating type i F`j = weighting factor for terminating (disposition) type j. Traffic mix on the CPU is specified by the Administration. Let Pi = fraction of call attempts expected to be originating type i P`j = fraction of call attempts expected to be terminating (disposi- tion) type j. where Pi = 1.0 and P`j = 1.0 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—th call attempt type traffic is: PiFiRi Similarly, the processing capacity required for disposition work asso- ciated with the j—th call type traffic is: P`jF`jR In order to satisfy the performance design objectives in Recommenda- tion Q.543, the reference unit processing capacity (RUPC) must be equal to or greater than the total originating type work plus the total terminating (dis- position) type work: RUPC (CPU) ³ R From which: A.4 Processing capacity computation (for an interface unit) Capacity information and weighting factors are furnished by the man- ufacturer. Let Hi = weighting factor for half—unit type i. Traffic mix on the interface unit is specified by the Administration. Let Pi = fraction of attempts to be half—unit type i. where If, R = the attempt rate in terms of busy hour half—units, the process- ing capacity required for i—th type half—units is: PiHiR In order to satisfy performance criteria, the reference unit call pro- cessing capacity (RUPC) must be equal to or greater than the total process- ing load: RUPC (IU) ³ R From which: A.5 Examples of processing capacity computations A.5.1 For a central processing unit Inputs Information furnished by manufacturer: — RUPC = 100,000 central processor reference capacity units per hour — Weighting factors (see Table A—1/Q.543). TABLE A—1/Q.543 Termination type Originating portion (F) Termination (disposition) portion (F`) Basic analogue access line 0.60 0.40 Analogue access line with supplemen- tary services 0.72 0.48 ISDN access line 0.72 0.56 Interexchange circuit (IXC) 0.50 0.40 Information furnished by the Administration. Expected traffic mix (see Table A—2/Q.543). TABLE A—2/Q.543 Originating call type From — termination type Traffic mix (fraction of total) Telephone Basic analogue access line 0.28 Telephone Analogue acess line with supplementary services 0.32 64 kbit/s switched ISND access line 0.05 Packet switched (setup) ISDN access line 0.02 Incoming—circuit switched Interexchange circuit (IXC) 0.33 Total 1.00 Terminating call type To — termination type Traffic mix (fraction of total) Telephone Basic analogue access line 0.26 Telephone Analogue access line with supplementary services 0.30 64 kbit/s switched ISDN access line 0.05 Packet switched (setup) ISDN access line 0.02 Outgoing—circuit switched Interexchange circuit (IXC) 0.37 Total 1.00 Computation (see Table A—3/Q.543). TABLE A—3/Q.543 Termination type Originating por- tion Terminating por- tion Basic analogue access line 0.28 × 0.60 = 0.168 0.26 × 0.40 = 0.104 Analogue access line with supple- mentary services 0.32 × 0.72 = 0.230 0.30 × 0.48 = 0.144 ISDN access line — circuit switched 0.05 × 0.72 = 0.036 0.05 × 0.56 = 0.028 ISDN access line — packet switched 0.02 × 0.72 = 0.014 0.02 × 0.56 = 0.011 Interexchange circuit (IXC) 0.33 × 0.50 = 0.165 0.37 × 0.40 = 0.148 Total 0.613 0.435 Maximum call attempt rate for the central processor for the specified mix of traffic: R maximum = = 95,420 call attempts per hour 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 capac- ity. A.5.2 Example of a processing capacity computation for an interface unit (see Table A—4/Q.543) Weighting factors are furnished by the manufacturer. Traffic mix is estimated by the Administration. TABLE A—4/Q.543 Call type Weighti ng fac- tor Traffic mix (fraction of total) From: Basic analogue access line Telephone (reference call) 1.00 × 0.14 = 0.14 0 False start/abandon 1.16 × 0.00 5 = 0.00 6 Analogue access line Telephone 1.15 × 0.10 = 0.11 5 False start/abandon 1.20 × 0.00 5 = 0.00 6 Supplementary service No. 1 1.52 × 0.05 = 0.07 6 Supplementary service No. 2 1.31 × 0.01 = 0.01 3 Supplementary service No. n 1.++ × ISDN access line 64 kbit/switched 1.20 × 0.02 5 = 0.03 0 Packet call setup 1.15 × 0.01 = 0.01 2 Supplementary service No. 1 1.44 × 0 Supplementary service No. 2 1.20 × 0.01 = 0.01 2 Supplementary service No. n 1.++ × IXC — CCITT No. 5 Incoming 1.30 × 0.07 = 0.09 1 IXC — CCITT No. 7 Incoming 0.90 × 0.08 = 0.07 2 To: Basic analogue line Telephone 0.65 × 0.13 = 0.08 5 Analogue line Telephone 0.75 × 0.12 = 0.09 0 Supplementary service No. 4 0.80 × 0.03 5 = 0.02 8 ISDN 64 kbit/switched 0.75 × 0.02 = 0.01 5 Packet call setup 0.75 × 0.01 = 0.00 8 Supplementary service No. 5 0.80 × 0.01 = 0.00 8 IXC — CCITT No. 5 Outgoing 1.62 × 0.08 = 0.13 0 IXC — CCITT No. 7 Outgoing 0.83 × 0.10 = 0.08 3 Tota l = 1.02 0 Information from the manufacturer. Reference capacity for an interface unit = 15,000 reference capacity half— units per hour. Computation: R maximum = = 14,705 half—units per hour or 7,352 call attempts per hour 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. The above capacity computation methodology can also be used to study the effects of different traffic mixes on interface units. A.6 Packet handling A.6.1 Definitions A.6.1.1 packet The unit of information exchanged between processors at layer 3. A.6.1.2 user packet A packet of information exchanged between the originating and ter- minating users in a packet switched connection. The length of packets may vary, depending on the protocol used. The number of user packets trans- ferred 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. A.6.1.3 acknowledgement packet Packet switching protocols have various strategies to ensure the reli- able transmission of packets between users. These strategies involve send- ing 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. A.6.1.4 reference packet type 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. A.6.1.5 reference packet work unit The amount of processor capacity required to handle one packet of the reference packet type together with its “share” of capacity required to han- dle associated acknowledgement packets. The reference packet work unit is assigned unit value. A.6.1.6 weighting factor The ratio of the amount of processing capacity required to handle any type of packet [including its “share” of associated acknowledgement pack- ets] to the amount of processing required to handle one reference packet [including its “share” of associated acknowledgement packets]. For exam- ple, 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. A.6.1.7 reference packet processing capacity (RPPC) The total number of reference type user packets that can be handled by the processor in one second while meeting the specified performance cri- teria. This number should be furnished by the manufacturer. It is important 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. A.6.2 Packet calls Packet calls consist of two parts: packet call set—up [and disconnect] and ongoing packet exchanging [packet handling stage]. A.6.2.1 Packet call set—up can be dealt with in the same manner as that described previously for circuit switched call set—up. Appropriate weight- ing factors for the various types of packet call set—up and estimates of packet type calls in the traffic mix are used for computing the capacity of the processor involved. [See § A.5. Packet call set—up was included in the example of call attempt processing capacity computations]. Just as with cir- cuit 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. A.6.2.2 After packet call set—up, each packet exchanged between users dur- ing 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 stan- dard length handled per second. To account for the packet processing capac- ity 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 dura- tion calls originated prior to but extending into the busy hour, must be included. In the exchange architecture shown in Figure A—1/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—up, there is no further demand for process- ing work on the interface unit processor nor the central processing unit pro- cessor 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—up and packet handling, see § A.7.] A.6.2.3 Processing capacity computation for a packet handling processor Weighting factors are furnished by the manufacturer. Let Gk be the weighting factor for handling a user packet of type k [including the handling of an appropriate “share” of associated acknowledgement packets]. The data traffic mix (fractions of total) and volumes is forecast by the Administration. Let Qk be the fraction of user packets of type k. Note that: Qk = 1 If Rp = user packet arrival rate, then the amount of processing capac- ity required for work associated with user packet traffic of the k—th type is: Qk Gk Rp In order to satisfy performance criteria the reference packet process- ing capacity (RPPC) must be equal to or greater than the total packet han- dling work. Thus: RPPC ³Rp From which the maximum packet processing capacity Rp max is: A.6.2.4 Example of a packet processing computation for an interface unit packet processor Information furnished by the manufacturer: a) RPPC = 10000 reference packet work units per second b) Weighting factors (G): — X.25 type data = 1.00 (reference type) — X.75 type data = 0.70 Estimated data traffic mix (furnished by the Administration): Type Traffic portion (Q) X.25 0.52 X.75 0.48 Computation Packet type Processing factor X.25 data 1.00 × 0.52 = 0.520 X.75 data 0.70 × 0.48 = 0.336 Total 0.856 Maximum processing capacity for the above data traffic mix: Rp max = = 1168 packets per second If the estimated data packet arrival rate (Rp) 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 termi- nated 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 inter- face units. A.7 Capacity computation for exchange architectures other than that assumed in Figure A—1/Q.543 If the same processor is used for both call set—up (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 or 1,000 packets per sec- ond, for every 100 packets per second of packet handling capacity required, the call processing capacity will be reduced by 10,000 calls. A.8 Conclusion 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 effec- tively. Trade—offs can be made between the use of capacity for various pur- poses. For example, in Figure A—1/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 sup- port that terminal. The remainder of the processing capacity can be allocated effectively by using information generated in the call processing computa- tion methodology. 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 “normal” operating conditions with the exchange performing all the operations and administrative func- tions expected of it during the busy hour. Figure A—1/Q.543 - T1107770-87