InfoMagic Standards 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1993 July / Disc.iso / ccitt / 1988 / ascii / 6_5_03.txt < prev next >

Wrap

Text File | 1991-12-22 | 156.1 KB | 4,556 lines

5i' MONTAGE: FIN DU S 2.3.11 EN T | TE DE CETTE PAGE 2.4 Delay probability - ISDN environment The following notes apply to the delay parameters included in this section: 1) The term "mean value" is understood as the expected value in the probabilistic sense. 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-user confi- guration), the message that is accepted for call handling is the one considered in determining the start of a given delay interval. 3) The terms "received from" and "passed to" 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 func- tions (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-transmission. 2.4.1 user signalling acknowledgement delay User signalling acknowledgement delay is the interval from the instant a user signalling message has been received from the sub- scriber 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. The values in Table 27/Q.543 are recommended. H.T. [T28.543] TABLE 27/Q.543 __________________________________________________________________________ Reference load A Reference load B __________________________________________________________________________ Mean value | 00 ms | 00 ms __________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1000 ms __________________________________________________________________________ | | | | Table 27/Q.543 [T28.543], p. 2.4.2 signalling transfer delay 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. The values in Table 28/Q.543 are recommended for originating and terminating connections. H.T. [T29.543] TABLE 28/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 50 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 28/Q.543 [T29.543], p. For transit connections, the requirements of the appropriate signalling system Recommendation should apply, e.g. CCITT Recommen- dations Q.725 and Q.766 for Tc\duvalue (case of a simple message). Note - User-to-user signalling may imply additional functions in the exchanges, e.g. charging, flow control, etc. The require- ments for user-to-user signalling transfer delay and the impact of user-to-user signalling on exchange performance is for further study. 2.4.3 call set up delay 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. 2.4.3.1 For originating 64 kbit/s circuit switched connections (types I, II and III option a). i) If overlap sending is used, the interval starts when the information message received contains a "sending complete" indication or the address information for call set up is complete. ii) If en-bloc sending is used, the time interval starts when the SETUP message has been received from the user sig- nalling system. For call attempts using overlap sending, the values in Table 29/Q.543 are recommended. H.T. [T30.543] TABLE 29/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1000 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 29/Q.543 [T30.543], p. For call attempts using en-bloc sending, the values in Table 30/Q.543 are recommended. H.T. [T31.543] TABLE 30/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1200 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 30/Q.543 [T31.543], p. 2.4.3.2 For originating supplementary service call attempts: for further study. 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 Tc\duvalue (case of a processing intensive message). 2.4.4 through connection delay 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. 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. The values in Table 31/Q.543 are recommended. H.T. [T32.543] TABLE 31/Q.543 ________________________________________________________________________________________________________________________________________________ Reference load A Reference load B ________________________________________________________________________________________________________________________________________________ Without ancillary function With ancillary function Without ancillary function With ancillary function ________________________________________________________________________________________________________________________________________________ Mean value | 50 ms | 50 ms | 00 ms | 00 ms ________________________________________________________________________________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms | 00 ms | 00 ms ________________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 31/Q.543 [T32.543], p. 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. The values in Table 32/Q.543 are recommended. H.T. [T33.543] TABLE 32/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 32/Q.543 [T33.543], p. 2.4.5 incoming call indication sending delay - (for ter- minating and internal traffic connections) The incoming call indication sending delay is defined as the interval from the instant at which the necessary signalling infor- mation 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. In the case of overlap sending in the incoming signalling sys- tem, the values in Table 33/Q.543 are recommended. H.T. [T34.543] TABLE 33/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1000 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 33/Q.543 [T34.543], p. In the case of en-bloc sending in the incoming signalling sys- tem, the values in Table 34/Q.543 are recommended. H.T. [T35.543] TABLE 34/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1200 ms ___________________________________________________________________________ | | | | | | | | | | | | Table 34/Q.543 [T35.543], p. 2.4.6 connection release delay Connection release delay is defined as the interval from the instant when DISCONNECT or RELEASE message is received from a sig- nalling 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. The values in Table 35/Q.543 are recommended. H.T. [T36.543] TABLE 35/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 35/Q.543 [T36.543], p. 2.4.7 Call clearing delay 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 S 2.4.2). 2.4.8 Timing for start of charging (circuit switched calls) When required, timing for charging at the exchange where this function is performed, shall begin after receipt of an ANSWER indi- cation 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. H.T. [T37.543] TABLE 36/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 175 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 50 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 36/Q.543 [T37.543], p. 2.5 Call processing performance objectives 2.5.1 64 kbit/s switched connections 2.5.1.1 Premature release The probability that an exchange malfunction will result in the premature release of an established connection in any one minute interval should be: P 2 x 10DlF2615 2.5.1.2 Release failure The probability that an exchange malfunction will prevent the required release of a connection should be: P 2 x 10DlF2615 2.5.1.3 Incorrect charging or accounting The probability of a call attempt receiving incorrect charging or accounting treatment due to an exchange malfunction should be: P 10DlF2614 2.5.1.4 Misrouting The probability of a call attempt misrouted following receipt by the exchange of a valid address should be: P 10DlF2614 2.5.1.5 No tone The probability of a call attempt encountering no tone follow- ing receipt of a valid address by the exchange should be: P 10DlF2614 2.5.1.6 Other failures The probability of the exchange causing a call failure for any other reason not identified specifically above should be: P 10DlF2614 2.5.2 64 kbit/s semi-permanent connections This requires further study taking into consideration: - need to recognize an interruption; - probability of an interruption; - requirements for re-establishment of interrupted connection; - any other unique requirements. 2.5.3 n x 64 kbit/s switched connections To be recommended if/when specific services are defined. 2.5.4 n x 64 kbit/s semi-permanent connections To be recommended if/when specific services are defined. 2.6 Transmission performance 2.6.1 64 kbit/s switched connections The probability of a connection being established with an unacceptable transmission quality across the exchange should be: P (Unacceptable transmission) 10DlF2615 The transmission quality across the exchange is said to be unacceptable when the bit error ratio is above the alarm condition. Note - The alarm condition has yet to be defined. 2.6.2 64 kbit/s semi-permanent connections To be recommended. 2.6.3 n x 64 kbit/s switched connections To be recommended, if/when specific services are defined. 2.6.4 n x 64 kbit/s semi-permanent connections To be recommended if/when specific services are defined. 2.7 Slip rate 2.7.1 Normal conditions The slip rate under normal conditions is covered in Recommendation Q.541. 2.7.2 Temporary loss of timing control The case of temporary loss of timing control corresponds to the "holdover operation" defined and recommended in Recommendation G.812. The allowable slip rate will correspond to the maximum relative TIE also recommended therein. 2.7.3 Abnormal conditions at the exchange input 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. 3 Exchange performance during overload conditions 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. This Recommendation identifies requirements for exchange per- formance during overload and for overload mechanisms in the exchange. Network management functions to be supported by an exchange are defined in Recommendation Q.542, S 5. 3.1 Explanation of terms used in definition of overload parameters - load : the total number of call attempts presented to an exchange during a given interval of time (i.e. offered load) - overload : that part of the total load offered to an exchange, in excess of the engineered traffic processing capa- city of the exchange. Overload is usually expressed as a percentage of engineered capacity. - throughput : the number of call attempts pro- cessed successfully by an exchange per unit time. - engineered capacity : the mean offered load at which the exchange just meets all grade of service requirements used by the Administration to engineer the exchange. 3.2 Call processing performance during overload 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 S 3.7. Two basic requirements for exchange performance during over- load are: - to maintain adequate exchange throughput in sus- tained overload - to react sufficiently quickly to load peaks and the sudden onset of overload. 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. Figure 1/Q.543, p. 3.3 Engineered exchange capacity Exchange engineered capacity is the maximum load that the exchange can handle while operating in a "normal" mode (i.e. performing all required operating and administrative func- tions) while meeting performance requirements specified in S 2 or those specified by the Administration. It is not necessarily the point of maximum throughput (see Figure 1/Q.543). 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. 3.4 Overload control strategy 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. 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. 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 con- tinue to process calls in an acceptable manner. 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. Measurements that can provide data as the basis for calcula- tion of X and Y, are identified in S 3.8. Figure 2/Q.543, p. 3.5 Detection of overload The exchange should incorporate suitable means for detecting overload conditions. 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. Overload indications may, for example, be provided by: a con- tinuous 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. Over- load control activation indications should be given to the adminis- tration staff. 3.6 Overload protection 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 con- trols used in conjunction with adjacent exchanges are discussed under "Network management design objectives" in Recommendation Q.542, S 5. 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. 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. As a guideline to providing service during overload condi- tions, the following general principles are applicable: - give preference to the processing of terminating calls, - 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 Mes- sage of a call using CCITT Signalling System No. 7, if an essential service protection capability has been invoked, - defer some or all activities non-essential to handling offered traffic; examples are some administration and maintenance processes in the exchange. (Nevertheless the man-machine communications essential for priority operational tasks should always be preserved. In particular, network management ter- minals and functions associated with interfaces to network manage- ment support systems should be afforded high priority, since net- work management actions can play an important role in reducing exchange overloads), - maintain normal charging and supervisory func- tions, and established connections until the receipt of the appropriate release signal, - assign priorities to specific exchange measure- ments, 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, - give preference to calls already being processed, before accepting new calls. 3.7 Grade of service during overload In general the overall grade of service seen by the sub- scribers 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 protec- tion procedures may require that the exchange not accept all the call attempts offered. Accepted calls may or may not receive a grade of service equal to that received by calls at Reference load B of S 2. In terms of the exchange overload performance, it is sufficient that calls be accepted in such a way that throughput is maximized. 3.8 Performance monitoring during overload control activa- tion The operational measurements in the exchange should be suffi- cient to determine the number of call attempts accepted by the exchange, and the number that are successfully being completed, from the exchange point-of-view. 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. An accepted call attempt is defined to be a call attempt which is accepted for processing by the exchange. This does not neces- sarily mean that an accepted call attempt will complete or receive an acceptable grade of service. 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. 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 ser- vices. A variety of signalling types will be used on subscriber lines and for handling calls over interexchange circuits. Perfor- mance 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 dif- ferent 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. 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 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. 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 switch- ing 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. Figure A-1/Q.543 of this ANNEX shows a block diagram of an exchange design with several processors, which is used as an exam- ple in this ANNEX. a) The Interface Unit 1 through n provide inter- faces to user lines, interexchange circuits, signalling terminals and any other interfaces to entities outside the exchange. A cer- tain amount of call processing (e.g. handling signalling to or from lines or interexchange circuits, digit analysis, etc.) can be per- formed 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-processor lines. b) The Central Processing Unit directs call pro- cessing 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 per- forms other call related and administrative tasks, such as main- taining charging information, 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 Cen- tral Processing Unit and the capacity of the Interface Units to determine which is the limiting factor. In some designs, other ele- ments, 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 capa- city 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 por- tion plus the terminating (or disposition) portion. A.2.2 half unit The processing capacity required to process either the ori- ginating 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 ser- vices, or ISDN supplementary services, or a call entering the exchange on an incoming interexchange 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 ser- vices assigned, or to an outgoing 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 (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 com- pared. (It is suggested that an originating outgoing "local" tele- phone 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 pro- cess an arbitrarily selected half-unit, 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-unit is used as the standard 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 different interface units, the same reference capa- city 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 reference capacity unit for processing the ori- ginating portion and F ` is the fraction 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 (disposition) portions). For example, if a complete reference capacity unit requires 1000 pro- cessor 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 (dispo- sition) types of capacity units and half-units, are required for each processing unit in the exchange in order to make capacity com- putations. 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 process- ing unit) in one hour in an exchange while meeting performance cri- teria specified by the Administration and at the same time perform- ing all the operations and administrative tasks required for normal operation of the exchange. Thus, RUPC is the processing capacity available for call handling. It is the total installed capacity diminished by an amount required for over- head, 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 addi- tions that would be needed in a maximum size exchange for adding new features in the future. To be able to make a realistic com- parison of different systems, it is necessary that the Administra- tion 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 process- ing unit) Capacity information and weighting factors are furnished by the manufacturer. Let Fi = weighting factor for ori- ginating 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 (disposition) type j . 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: Pi Similarly, the processing capacity required for disposition work associated with the j-th call type traffic is: P ` jF ` jR 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: A.4 Processing capacity computation (for an interface unit) Capacity information and weighting factors are furnished by the manufacturer. Let Hi = weighting factor for half-unit type i. Traffic mix on the interface unit is specified by the Adminis- tration. Let Pi = fraction of attempts to be half-unit type i. If, R = the attempt rate in terms of busy hour half-units, the processing capacity required for i-th type half-units is: P In order to satisfy performance criteria, the reference unit call processing capacity (RUPC) must be equal to or greater than the total processing load: 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 capa- city units per hour - Weighting factors (see Table A-1/Q.543). H.T. [T38.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 supplementary services } 0.72 0.48 ISDN access line 0.72 0.56 Interexchange circuit (IXC) 0.50 0.40 _______________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table A-1/Q.543 [T38.543], p. Information furnished by the Administration. Expected traffic mix (see Table A-2/Q.543). H.T. [T39.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 __________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table A-2/Q.543 [T39.543], p. Computation (see Table A-3/Q.543). H.T. [T40.543] TABLE A-3/Q.543 __________________________________________________________________________________________________ Termination type Originating portion Terminating portion __________________________________________________________________________________________________ Basic analogue access line { 0.28 x 0.60 = 0.168 } 0.26 x 0.40 = 0.104 { Analogue access line with supplementary services } 0.32 x 0.72 = 0.230 0.30 x 0.48 = 0.144 { ISDN access line - circuit switched } 0.05 x 0.72 = 0.036 0.05 x 0.56 = 0.028 { ISDN access line - packet switched } 0.02 x 0.72 = 0.014 0.02 x 0.56 = 0.011 Interexchange circuit (IXC) 0.33 x 0.50 = 0.165 0.37 x 0.40 = 0.148 __________________________________________________________________________________________________ Total 0.613 0.435 __________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table A-3/Q.543 [T40.543], p. Maximum call attempt rate for the central processor for the specified mix of traffic: R maximum = .613~+~0.435 ____________ = 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 capacity. 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. H.T. [T41.543] TABLE A-4/Q.543 _______________________________________________________________________________________________________________________________________________ Call type Weighting factor { Traffic mix (fraction of total) } _______________________________________________________________________________________________________________________________________________ From: Basic analogue access line { Telephone (reference call) False start/abandon } 1.00 1.16 x x 0.14 0.005 = 0.140 = 0.006 Analogue access line { Telephone False start/abandon Supplementary service No. 1 Supplementary service No. 2 Supplementary service No. n } { 1.15 1.20 1.52 1.31 1. ++ } x x x x x 0.10 0.005 0.05 0.01 . { = 0.115 = 0.006 = 0.076 = 0.013 } 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. ++ x x x x x { 0.025 0.01 0 0.01 } = 0.030 = 0.012 . = 0.012 IXC - CCITT No. 5 Incoming 1.30 x 0.07 = 0.091 IXC - CCITT No. 7 Incoming 0.90 x 0.08 = 0.072 To: Basic analogue line Telephone 0.65 x 0.13 = 0.085 Analogue line { Telephone Supplementary service No. 4 } 0.75 0.80 x x 0.12 0.035 = 0.090 = 0.028 ISDN { 64 kbit/switched Packet call setup Supplementary service No. 5 } 0.75 0.75 0.80 x x x 0.02 0.01 0.01 = 0.015 = 0.008 = 0.008 IXC - CCITT No. 5 Outgoing 1.62 x 0.08 = 0.130 IXC - CCITT No. 7 Outgoing 0.83 x 0.10 = 0.083 _______________________________________________________________________________________________________________________________________________ Total = 1.020 _______________________________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | Table A-4/Q.543 [T41.543], p. Information from the manufacturer. Reference capacity for an interface unit = 15,000 reference capacity half-units per hour. Computation: R maximum = .020 _____ = 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 max- imum of 14 interface units in order to reserve some processing capacity for future program growth. At this point in the computa- tion, it would be wise to examine the exchange design to verify that hardware configuration, memory or any other possible limita- tions 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 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 fundamen- tal 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 reliable transmission of packets between users. These stra- tegies 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. 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 handle associated acknowledgement packets. The refer- ence 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 ack- nowledgement packets] to the amount of processing required to han- dle one reference packet [including its "share" of associated ack- nowledgement 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. 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 criteria. 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 capa- city 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 weighting 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 S A.5. Packet call set-up was included in the example of call attempt processing capacity computations]. Just as with circuit switched services, there may be packet calls with different pro- cessing 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 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 pack- ets 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. 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 processing work on the interface unit processor nor the central processing unit processor 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 inter- face unit. [For systems that use the same processor for call set-up and packet handling, see S A.7.] A.6.2.3 Processing capacity computation for a packet han- dling processor Weighting factors are furnished by the manufacturer. Let Gkbe the weighting factor for handling a user packet of type k [includ- ing the handling of an appropriate "share" of associated ack- nowledgement packets]. The data traffic mix (fractions of total) and volumes is fore- cast by the Administration. Let Qkbe the fraction of user packets of type k . Note that: If Rp= user packet arrival rate, then the amount of processing capacity required for work associated with user packet traffic of the k-th type is: QkGkRp 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: From which the maximum packet processing capacity Rpmax 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 Administra- tion): H.T. [T42.543] ______________________________ Type Traffic portion (Q) ______________________________ X.25 0.52 X.75 0.48 ______________________________ | | | | | | | | | | | | | | | Table [T42.543], p. Computation H.T. [T43.543] ______________________________________ Packet type Processing factor ______________________________________ X.25 data 1.00 x 0.52 = 0.520 X.75 data 0.70 x 0.48 = 0.336 Total 0.856 ______________________________________ | | | | | | | | | | | | | | | | | | Table [T43.543], p. Maximum processing capacity for the above data traffic mix: Rpmax = .856 ____ = 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 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. 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 pro- cessing capacity of 100,000 calls per hour or 1,000 packets per second, for every 100 packets per second of packet handling capa- city 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 com- puting its processing capacity. It is most important that the exchange architecture be understood, that capacity limiting ele- ments 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-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 support that terminal. The remainder of the processing capacity can be allocated effectively by using information generated in the call processing computation methodol- ogy. It is also very important that the capacity of an exchange should not be calculated using the entire capacity for call pro- cessing. It should be made using the processing capacity available under "normal" operating conditions with the exchange performing all the operations and administrative functions expected of it dur- ing the busy hour. Figure A-1/Q.543, p. ANNEX B (to Recommendation Q.543) An example of a methodology for measuring exchange capacity B.1 General 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. B.2 Theory behind the measurement method The call handling capacity of a processor | 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 ser- vice 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-1/Q.543. Figure B-1/Q.543, p. 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-linearity in the processor utilization versus load characteristic. In the case of a single processor controlled system, Figure B-1/Q.543 represents the processing capacity of the exchange. In a multi-processor system, the capacity is distributed among proces- sors and the exchange capacity is related to the system configura- tion and the exchange processing capacity is a function of the pro- cessors involved in call handling functions. As shown in Figure B-1/Q.543, the processing capacity of a processor is divided between three elements: 1) fixed overhead related to mandatory tasks (e.g. task scheduling and scanning); 2) call processing work (including traffic-related overhead tasks); 3) deferrable (base-level) tasks (e.g. routine maintenance). The tasks which a processor executes are assigned to three levels of priorities, base, medium and high-level tasks (see Figure B-2/Q.543 | ) and Figure B-2/Q.543 | )). Figure B-2/Q.543, p. As the traffic load (call attempts) increases call processing work expands and the processing of deferrable tasks decreases. Measurement of the percentage of time spent by the processor performing base-level tasks gives an indication of the percent or processing capacity required for a particular load on the proces- sor. As shown in Figure B-2/Q.543 | ), at low traffic load, the percentage of time used to perform base-level tasks is relatively high. In Figure B-2/Q.543 | ), at high traffic load, the percentage of time at base-level is relatively low. Thus the measurement of percentage of time used to perform base-level tasks can be used to determine call processing capacity. B.3 Capacity measurement methodology for exchanges 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. 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-level 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 pro- jecting 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. Where multi-processors are involved, the exchange configura- tion, 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). Figure B-3/Q.543, p. Recommendation Q.544 DIGITAL EXCHANGE MEASUREMENTS 1 General This Recommendation applies to digital local, combined, tran- sit 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. This Recommendation includes traffic and performance measure- ments 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 per- formed during specified periods and intervals after which the results are sent to designated local and/or remote exchange termi- nals or operation and maintenance centres (OMC) or any other appropriate data handling centre. In some cases, data may be util- ized in its original form whereas in other cases data may need to be processed to determine when pre-set 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 pro- cessed within the exchange or by an external system. Different types and sizes of exchanges may require different sets of measurements. Also, different Administrations may have dif- ferent requirements for measurements depending on policies, pro- cedures 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 applica- tions some measurements may not be desired. Exchange measurements are required for both national and international service. Requirements for international service take into consideration the following CCITT Recommendations: - Recommendations E.401 to E.427: International telephone network management and checking of service quality; - Recommendations E.230 to E.277: Operational pro- visions relating to charging and accounting in the international telephone service. The aspects of traffic engineering are given in Recommendations E.500 to E.543. Recommendations on traffic meaure- ments for SPC exchanges are provided by Recommendations E.502, E.503 and E.504. Additional measurements in an exchange, not specified in this Recommendation, are required, e.g. for: - Transmission performance (Recommendations Q.551, Q.552, Q.553 and Q.554). - Digital access signalling (Recommendations Q.920 to Q.931). This is for further study. - Packet mode (Recommendations X.25 and X.75). This is for further study. - 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). Note - For the terms and definitions of teletraffic used in this Recommendation, see Recommendation E.600. 2 Measurement processes 2.1 General The activities involved in exchange measurements can be split in four processes as represented by Figure 1/Q.544. Figure 1/Q.544, p. On choice of each individual national Administration, the above four processes can be fully or partially integrated into the exchanges. It is nevertheless recommended that: a) data collection | be fully integrated into the exchange for all types of data; b) data presentation | be integrated into the exchange and/or at the O&M centre at least for the measurements required by O&M personnel. 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. 2.2 Data collection Three different activities of data collection can be identi- fied: - event registration; - traffic registration (traffic intensity and/or volume of traffic); - call records registration. The data generated by event registration and traffic registra- tion are suitable for direct utilization (immediate presentation). Call records can only be utilized after off-line analysis. Processing of call records can generate any type of data, including the event registration and traffic registration. 2.3 Bulk data storage, analysis and processing Data storage for collected data can be required for accumula- tion of a massive data base suitable for subsequent analysis and processing. These data can be held in the exchange for processing at the exchange location or transferred to administrative and engineering centres. 2.4 Data presentation It is the function through which the collected data are becom- ing readable. Features related to the data presentation are: a) location of presentation; 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; 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. 3 Types of measurement data 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 pro- vide an acceptably accurate result. In some cases, externally gen- erated test calls may provide the most practical method of obtain- ing the data. In other cases, call records, such as detailed charg- ing records, may be used. 3.1 Event counts 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-exchange circuit group. In some cases, event counts may be accumulated several ways. 3.2 Traffic intensity 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. 3.3 Call records 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. Call records can be generated and outputted by the exchange to allow the establishment of a data base suitable for off-line pro- cessing 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. 4 Measurement administration 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 capa- ble 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 pro- cessing resources. Criteria for measurement and recording of traffic may be found in Recommendation E.500 and other related E-Series Recommendations. 4.1 Scheduling 4.1.1 Recording periods A recording period is the time interval during which a meas- urement is performed. Measurements can be activated either on-demand or according to a time schedule. 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. 4.1.2 Result accumulation periods 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. The measurement result outputs are to be made available at the end of each result accumulation period and shall refer to that period. More than one result accumulation period may be required for an individual measurement. 4.2 Data output criteria 4.2.1 On schedule 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. 4.2.2 On demand (For further study.) 4.2.3 On exception 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. 4.3 Data output routing 4.3.1 To a local or remote terminal 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. 4.3.2 To an external processing centre Measurement data should be routable to external locations such as OMC that provide data collection and analysis functions for mul- tiple exchanges. 4.3.3 To local storage media 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. 4.4 Priorities 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 account- ing. These should not be discontinued during periods of exchange processing congestion (see Recommendation Q.543, S 3.8). Measure- ments that have been suspended should be resumed in an order that is reverse to the order in which they were suspended. When recovery procedures are invoked, records associated with call accounting and billing should be retained. 5 Application of measurements 5.1 Planning and engineering Measurement data is essential for planning efficient telecom- munication networks that meet specified grade-of-service standards. Analysis of data accumulated over a period of time provides infor- mation needed to forecast future demand and to plan and engineer extensions to the network. 5.2 Operation and maintenance Operation and maintenance functions are supported by the fol- lowing types of measurement data: i) performance data pertaining to call handling irregularities and delays; ii) availability data for the exchange, its sub- systems, and its connecting subscriber lines and inter exchange circuits; iii) load on various components of the exchange. The above data may be used to evaluate exchange and network performance and to plan rearrangements to improve the service pro- vided by the existing network equipment. 5.3 Network management Data for network management includes certain traffic and per- formance 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 per- form 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. 5.4 Accounting in international service Accounting in international service needs to be mutually agreed between Administrations; Recommendations E.230 to E.277 apply. 5.5 Subdivision of revenue Subdivision of revenue is a matter of agreement between RPOAs of the same country. Requirements in this area are a national matter. 5.6 Tariff and marketing studies The studies are intended to identify subscriber needs and trends. Requirements in this area are a national matter. 6 Call events definition This section is applicable to 64 kbit/s circuit switched call attempts. Application to other types of calls or Supplementary Ser- vices is for further study. 6.1 General Every call attempt coming from a subscriber line or interex- change circuit moves across a branch of the possible status of call events reference diagram shown in Figure 2/Q.544. 6.2 Call events detailed description 6.2.1 Seizure from a subscriber line or incoming circuit This is the starting point for an incoming/outgoing call attempt. 6.2.2 Valid address The incoming/originating seizure is successfully accepted by the exchange. 6.2.3 Not routed call attempt 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. 6.2.3.1 False start An incoming seizure signal that has been recognized without being followed by digit reception. 6.2.3.2 Incomplete dialling (time out, abandon) An incoming seizure that has been received but the number of received digits is not sufficient to perform call routing. 6.2.3.3 Invalid address An attempt where the received digits do not correspond to an existing or allowed destination. The call is then given intercep- tion treatment (tone or announcements or operators). 6.2.3.4 Call not routed due to the exchange A call attempt where the system cannot perform call routing due to internal reasons (congestion): 1) Blocking through the switching network 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. 2) Unavailability of common resources Unavailability of service circuits or other common resources (e.g. memory areas) 3) System faults Presence of some internal fault in the exchange. Figure 2/Q.544, p. 6.2.4 Calls routed to interexchange circuits 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 measure- ments, these calls can be counted all together. 6.2.4.1 Seizure of outgoing circuit These are calls that are routed to a specific circuit. They have to be separately counted when making measurements on the out- going circuit group. 6.2.4.2 Overflow to next circuit group These are calls that cannot be routed on a specific circuit group but are routed to a subsequent routing-choice circuit group. They have to be counted separately when making measurements on the outgoing circuit group. Measurement of the subsequent events asso- ciated with these calls are only associated with circuit group on which the calls are routed. 6.2.5 Calls not routed due to network conditions 6.2.5.1 Calls in overflow from the last routing choice (all circuits busy) These are calls on which the system cannot perform routing due to the unavailability of outgoing circuits towards the required destination. 6.2.5.2 Calls blocked by network management controls These are call attempts that are suppressed by the exchange as a consequence of the application of network controls. 6.2.6 Successful backward call set-up signal These are calls for which a backward signal is received, indi- cating the conclusion of call routing at a remote exchange, but not answered. The set of signals typically includes: - end of selection - address complete - subscriber line free 6.2.7 Unsuccessful call attempts 6.2.7.1 Receiving an unsuccessful backward call set-up sig- nal This occurs when a backward signal is received indicating the impossibility of setting up the call. These backward signals typically are: - congestion signals - subscriber line busy signals - signals defined as part of the UBM (Unsuccessful Backward set-up information Message) group of messages in CCITT Signalling System No.7 (see Recommendation Q.723). 6.2.7.2 Not receiving a backward call set-up signal These are calls that are abandoned or forced-out before recep- tion of any backward call set-up signal. They include: - calls abandoned by the calling party - calls forced out by the expiration of timers. 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: - ring-back tone - busy tone - congestion tone - announcements - no tones or announcements - incompletely dialled calls 6.2.8 Calls routed to subscriber line These are call attempts that are successfully routed to a sub- scriber line. 6.2.9 Calls not routed due to called line conditions These are unsuccessful call attempts which do not reach answer status due to the particular condition of the called subscriber line: - busy - out-of-service - rerouted call - no free outlet - etc. 6.2.10 Answered calls These are calls that reach the "answered" status. Depending on the signalling protocol answered status can be reached in one of the following ways: - reception of an answer signal - reception of a metering pulse - immediate answer status on seizure (of the sub- scriber line/outgoing interexchange circuit). The following events are not included in this class of calls: - reception of Re-answer signal - answer from an intercepting device (automatic or manual) due to call diversion at the transit exchange. 6.2.11 Not answered call attempts 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: - calls forced-out by the expiration of timers - calls abandoned by the calling party after listening to ring-back tone. 7 Traffic measurements This section is applicable to 64 kbit/s circuit switched traffic. "Application to other types of traffic or supplementary services is for further study." 7.1 General 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. Figure 3/Q.544, p. 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 switch- ing 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. Measurements may be combined into sets appropriate to a specific type of exchange, for example, local or transit. In par- ticular, Administrations may consider that, by the use of a few measurement sets, it is possible to satisfy the majority of their requirements. 7.2 Overall measurements 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. 7.2.1 Originating traffic a) Originating call attempts. b) Invalid call attempts for example: - no dialling, - incomplete dialling, - invalid number dialled. c) Call attempts not routed due to the exchange, for example, due to: - blocking through the switching network, - unavailability of common resources, - system faults. d) Internal call attempts. 7.2.2 Incoming traffic a) Incoming seizures. b) Invalid call attempts for example: - incomplete dialling, - invalid number dialled. c) Call attempts not routed due to the exchange, for example, due to: - blocking through the switching network, - unavailability of common resources, - system faults. d) Transit call attempts. 7.2.3 Terminating traffic a) Call attempts routed to subscriber lines. b) Call attempts not routed due to line condition. 7.2.4 Outgoing traffic a) Outgoing call attempts routed to an interex- change circuit. b) Call attempts not routed due to network condi- tion. c) Unsuccessful call attempts. 7.2.5 Service utilization 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. 7.3 Interexchange circuit groups The measurements apply to individual circuit groups. All cir- cuit 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. 7.3.1 Incoming traffic Incoming traffic is understood to be: - the traffic on incoming circuit group, - the incoming traffic on both-way circuit groups. The following parameters should be measured: a) traffic intensity, b) number of seizures. 7.3.2 Outgoing traffic Outgoing traffic is understood to be: - the traffic on outgoing circuit groups, - the outgoing traffic on both-way circuit groups. The following parameters should be measured: a) traffic intensity, b) number of seizures, c) number of call attempts overflowing from the group, d) answered call attempts. 7.4 Subscriber line groups 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. a) Originating calls i) Number of call attempts ii) Number of call attempts resulting in an outgo- ing seizure iii) Number of answered calls iv) Traffic intensity b) Terminating calls i) Number of call attempts ii) Number of answered calls iii) Traffic intensity c) Internal (e.g. intra-concentrator calls) i) Number of call attempts ii) Number of answered calls iii) Traffic intensity 7.5 Auxiliary units Auxiliary units provide functions such as multifrequency sig- nalling, tones, announcements, and access to operators. Grouping of auxiliary units may vary with system implementation characteris- tics. Groups in this section refer to system independent functional groups. Some systems may allow calls to wait for an auxiliary cir- cuit of one is not immediately available. 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. Measure- ments 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 addi- tion to the traffic data for each circuit group: a) traffic intensity, b) number of seizures, c) number of bids not served. 7.6 Control unit(s) 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, plan- ning, and grade of service monitoring of the exchange. 7.7 Call attempt destinations (see also S 9.3) These measurements are used to assess the probability of suc- cess 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: a) number of call attempts, b) number of call attempts resulting in an outgoing seizure, c) number of answered calls. Intensity measurements for specified destination codes may be required by some Administrations for traffic engineering purposes. 8 Exchange performance and availability measurements 8.1 Performance measurements 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 monitor- ing. However, other processing delays (see relevant paragraphs of Recommendation Q.543) may be observed for complete monitoring of the exchange grade of service. 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. Operating procedures of Administrations will impose con- straints 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. 8.2 Availability measurements 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 per- mit the determination of the number and identity of terminations affected if possible. 9 Data for network management 9.1 General 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 func- tions must be able to provide traffic and status data to other exchanges and network management centres on a pre-arranged 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. Details of traffic measurement requirements for network management are found in Recommendation E.502. Most of the informa- tion required for network management operations can only be gen- erated by the exchanges and consist of two general categories of data: a) Network status information, for example: - busy/idle status of circuit groups - individual equipment's availability - alarms - network management action (controls) in effect Status information generally does not require measurements. b) Network traffic load and performance informa- tion, for example: - number of bids per route per hour - answer/seizure ratio per route per destination. This type of information requires "real-time" monitoring of network performances via exchange measurements, and it is specifi- cally the subject of this part of the Recommendation. The objects and entities of measurement are given in full details by SS 9.2, 9.3 and 9.4. The exchange generated information can be: - utilized at the source exchange, if network management actions are taken locally, - transmitted to other exchanges or elements of the TMN (typically to network management centres) for possible network management actions. It should be noted that exchange internal overload controls are complementary to network management functions, and the informa- tion 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, S 3. 9.2 Management on interworking circuit groups 9.2.1 General 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. 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 outgo- ing circuit groups while a local exchange may only require monitor- ing on a few groups. It should be possible to readily activate/deactivate measure- ments on circuit groups. 9.2.2 Entities to be measured on interexchange circuit groups The following measurements should be made on outgoing interex- change circuit groups for network management purposes: a) outgoing bids (see Note) b) outgoing seizures (see Note) c) overflow bids (see Note) d) answers received e) count of calls affected by network management circuit group controls. Note - Any two of these measurements are necessary. The third can be derived from the other two. 9.2.2.1 Additional measurements required on international circuit groups at international transit exchanges - transit bids (international traffic only) - incoming seizures (international transit traffic only). 9.2.3 Calculated network performance parameters The entities of measurement in S 9.2.2 can be used to calcu- late all the network management performance parameters required for network management on the basis of (Draft) Recommendation E.411 as follows: a) bids per circuit per hour b) seizures per circuit per hour c) percentage overflow d) answer/seizure ratio e) answer/bid ratio f) mean holding time per seizure. 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 dis- tribution of the network management functions in the TMN. 9.3 Measurements on call destinations 9.3.1 General 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 destina- tions 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. Measurement by destination is essential for the implementation of the hard-to-reach 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 pos- sible to readily expand the scope of the measurements within a focused area when certain thresholds are exceeded. 9.3.2 Entities to be measured on call destinations The following are the entities that should be measurable per destination for network management purposes: a) outgoing bids; b) outgoing circuit seizures; c) answers; d) counts of calls affected by network management controls by type of control. 9.4 Measurements on exchange resources 9.4.1 General The exchange should be able to monitor the level of utiliza- tion 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). Since the common resource monitoring function is also required for overload protection purposes, the same mechanisms of measure- ment can be used for both functions, namely, exchange overload pro- tection and network management. 9.4.2 Objects and entities to be measured on exchange resources 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 there- fore left to individual Administrations or Operating Agencies. Blanc