Internet Standards/CD2.mdf/ccitt/1992/q/q543_a.asc

Text File | 1993-08-15 | 27KB | 1,071 lines

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