Method and apparatus for connection admission control in cell or packet-based networks

[0002] The present invention relates to the Connection Admission Control (CAC) finctions in a broadband Integrated Service Digital Network (TSDN) using cell/packet-based technologies of, either Asynchronous Transfer Mode (ATM) switch designs for both satellite and terrestrial applications, or new Internet Protocol (IP) router designs with Grade or Service (GoS) concepts such as differentiated service or Multi-Protocol Label Switching (MPLS) architectures.

[0003] New generations of broadband ISDN technologies that integrate many of the communications services required by the user (i.e., voice, data, moving images, etc.) have recently emerged in communications networks. Information from a large number of calls is transported via fixed-sized packets (or cells in ATM terminology) and then multiplexed onto a single medium whose capacity (in bits per second) is either expressed in a physical size (i.e, link capacity) or a virtual quantity (i.e. effective bandwidth allocation). At connection set-up, the user declares a set of traffic parameters and a required Quality of Service (QoS) from which the carrier must decide whether or not it is possible to establish a path of sufficient bandwidth between the sender and receiver that will satisfactorily accommodate the user's requirement, Connection Admission Control (CAC) is the traffic control function within the network that performs this decision CAC typically depends on a resource allocation algorithm that determines if there are sufficient network resources (including bandwidth and buffer memory) throughout the communication path. In the event of insufficient resources the connection is denied.

[0004] Several prior art CAC models have been developed for determining solutions to the effective bandwidth (or effective cell rate) in large network traffic, however the software implementation of these algorithms has generally been too complicated to meet the real-time requirement for the bandwidth solution and the CAC “go/no-go” decision. In order to reduce computation time, many network designers have resorted to simplified approximations such as the “on-off” fluid flow approximation used in U.S. Pat. Nos. 5,862,126 and 5,917,804 (Shah et al, Jan. 19, 1999 and Jun. 29, 1999). Others have chosen empirical models such as the fuzzy logic decisions used in U.S. Pat. No. 5,341,366 (Soumiya et al, Aug. 23, 1994), and the methods for controlling priority levels in both U.S. Pat. No. 5,267,232 (Katsube et al, Nov. 30, 1992), and Canadian Patent Application No. 2,208,096 (M. Aida, Dec. 18, 1997). The bandwidth solutions developed in all of the known prior art CAC models, whether complex solutions or simplified approximations, are implemented in software only.

[0005] Other prior art schemes are described in references [1] to [7] listed at the end of this section. All such schemes are relatively complex in one or more of the following aspects

[0006] (a) Computation Speed

[0007] The CAC algorithms described in references [1], [3] and [5] are too complicated for real-time applications, such as: Terabit switch/router designs or Low Earth Orbiting satellite access/switching applications, where a relatively large amount of connections need to be processed or handed-off within a few seconds. In such real-time applications, a faster low-level CAC method that would be more suitable for hardware implementation is desirable.

[0008] (b) Robustness

[0009] When the network is down for some reason, the CAC solutions described in references [1], [3] and [5] may not offer sufficient robustness to recover the same connection on a link due to their complicated method for calculating the effective cell rate (ECR).

[0010] (c) Flexibility

[0011] As the Internet market grows, major carriers are paying more and more attention to fractal (self-similar) traffic, in addition to the non-self-similar traffic. References [1] and [5] describe a CAC implementation for non-self-similar cases only. Reference [3] describes a case for a self-similar application, however, neither this reference nor any other known report has described the implementation of self-similar cases. Given that data and video traffics are self-similar in nature, as shown in reference [3], and that these traffics are expanding at a considerable pace, there is clearly a need for a CAC implementation that handles both self-similar and non-self-similar traffic at the same time.

[0012] (d) Reliability

[0013] Careless (or malicious) users may, inadvertently or deliberately, provide a set of traffic parameter values that could render a complicated CAC algorithms invalid, possibly causing the processor performing the computation to crash. In this respect, the complexity of the CAC solutions as described in references [1], [3] and [5] may not permit the system to be sufficiently reliable for mission-critical applications such as telebanking and telemedicine.

[0014] (e) Accuracy

[0015] The Average Burst Size (ABS) is a traffic parameter that neither the ATM Forum Specifications described in reference [4], nor other known prior art CAC solutions have taken into account. Conventional CAC methods assume that the ABS and the Maximum Burst Size (MBS) are relatively the same, which is not accurate. As a result of this assumption, present CAC solutions based solely on the input descriptor MBS tend to over-estimate the effective bandwidth, leading to low bandwidth and buffer efficiency. It is desirable to have a CAC implementation that takes both ABS and MBS into account to more effectively remedy this problem.

[0016] (f) Automation

[0017] Existing CAC solutions such as those described in references [1] and [5] rely on complementary manual tuning of the CAC formula by a trained network operator. This manual operation is not a cost-effective approach to network management. It is therefore desirable to have a more cost-effective self-tuned CAC implementation.

[0018] [1] Harry G. Perros and Khaled M. Elsayed, “Call Admission Control Schemes: A Review,” IEEE Communications Magazine, November 1996.

[0019] [2] Mehrvar, H. R. and Le-Ngoc, T., “Estimation of Degree of Self-Similarity for Traffic Control in Broadband Satellite Communications,” CCECE'95, Montreal, September 5-8, (1995).

[0020] [3] I. Norros, “On the use of Fractional Brownian Motion in the Theory of Connectionless Networks,” JSAC, Vol. 13, No. 6, 1995, pp. 953-962.

[0021] [4] ATM Forum, UNI3.0 Specification, 1993.

[0022] [5] R. J. Gibbens and P. J. Hunt, “Effective Bandwidths for the Multi-type UAS. Channels” Queueing Systems9, 1991, pp. 17-28.

[0023] [6] A. G. Greeberg, R. Srikant, W. Whitt, “Resource Sharing for Book-Ahead and Instantaneous-Request Calls” IEEE/ACM Trans. On Networking, pp. 10-pp22, February, 1999.

[0024] [7] Y. Chen, Z. Deng, and C. L. Williamson, “A Model for Self-Similar Ethernet LAN Traffic: Design, Implementation and Performance Implementations”, University of Saskatchewan, Dept. of Computer Science, working paper, 1997.

[0025] It is an object of the present invention to provide an improved apparatus and method for Connection Admission Control (CAC) solution, that solves the self-similar implementation problem in order to satisfy both fractal (self-similar) and non-self-similar traffic requirements in emerging broadband ISDN networks, such as virtual satellite networks and new internet protocol designs.

[0026] It is another object of the invention to simplify and reduce the mathematical calculations of the CAC solution, thereby minimizing the computational time to allow for a real-time implementation.

[0027] It is a further object of the invention to provide a minimum hardware implementation of the CAC solution that uses logarithmic operations in a pure additive/subtractive process to speed up the CAC computation at a real-time rate unmatched by traditional software approaches.

[0028] It is another object of the invention to provide a hardware implementation that permits the recovery of traffic connection in case of a link failure.

[0029] It is another object of the invention to detect, measure and calculate the Average Burst Size (ABS) and the Hurst value for each applicable service class in order to avoid over-estimation (which wastes system resources) or under-estimation (which jeopardizes the system performance).

[0030] It is a further object of the invention to provide automated measurements when deriving the CAC solutions in order to resolve the inefficiencies associated with manual operation.

[0031] To achieve the above objectives of the present invention, there is provided a cell or packet-based CAC method and apparatus for calculating the effective bandwidth in large network traffic that uses either ATM switches for both satellite and terrestrial applications or new Internal Protocol (IP) router designs with GoS concepts such as differentiated services or Multi-Protocol Label Switching (MPLS) architecture. The invention provides a real-time hardware implementation of CAC that satisfies the complex Effective Bandwidth equations for both self-similar and non-self-similar traffics. The invention provides a minimum hardware implementation that uses logarithmic principles in a pure additive formula to speed up the complex CAC computation and provide near real-time solutions that are unmatched by traditional software designs.

[0032] In accordance with an aspect of the present invention there is provided a system for Call Admission Control (CAC) within a data network for a new call having a class of service, said system comprising:

[0033] a) means for periodically obtaining from said data network data flow information and a set of parameter values corresponding to a set of network resource parameters;

[0034] b) a Hurst meter block for determining Hurst parameter (H) value from the data flow information based on the class of service;

[0035] c) a TF block for determining a Tuning Factor (TF) value from the data flow information;

[0036] d) an ECR calculator block responsive to the Hurst meter block and the TF block for determining an Effective Cell Rate (ECR) value;

[0037] e) an accumulator block responsive to the ECR calculator block for estimating required Total Effective Cell Rate (TECR) value;

[0038] f) a BF block for determining a Reference Effective Cell Rate (RECR) value from the data flow information and the set of parameter values; and

[0039] g) a comparator block responsive to the accumulator block and the BF block for comparing the values of TECR and RECR and providing a go-no-go sign indicating that the new call is to be accepted when TECR<RECR, and that the new call is to be rejected otherwise;

[0040] wherein the value of TECR is updated within the accumulator block when the new call is accepted.

[0041] The set of network resource parameters includes buffer size (BS), peak cell rate (PCR), sustainable cell rate (SCR), and user specified Cell Loss Ratio (CLRs) corresponding to the class of service.

[0042] In an embodiment of the present invention, the ECR calculator block determines the ECR value by first extracting a Maximum Burst Size (MBS) value from the data flow information, and then using the formula of:

[0043] ECR=SCR/[CLRs(SCPR/PCR)]^{MBS/(BS/TF)/(2−2H)}

[0044] To perform the calculations for this formula, the ECR calculator block includes a hardware circuit having a multiplier, an exponentiator and a plurality of dividers for calculating the ECR value.

[0045] In a preferred embodiment, the ECR calculator block calculates the ECR value by first extracting a Maximum Burst Size (MBS) value from the data flow information, and then using the formula of:

[0046] Log ECR=Log SCR−[Log CLR+Log SCR−Log PCR]×Exponent

[0047] where Exponent=[MBS/(BS/TF)]/(2−2H).

[0048] To perform the calculations for this formula, the ECR calculator block includes a hardware circuit having a plurality of subtractors, adders, log tables, and an anti-log table calculating the ECR value in a plurality of logarithmic operations. At least one of the plurality of log tables is preceded by a multiplexer and succeeded by a demultiplexer to permit sharing of said table among a plurality of logarithmic operations.

[0049] In yet another embodiment, the set of resource parameters includes link capacity (LC) and user specified Cell Loss Ratio (CLRs), and wherein the BF block determines the RECR value by setting a booking factor (BF) value, and calculating RECR as LC/BF. The BF block derives from the data flow information a measured Cell Loss Ratio (CLRm) value by dividing the number of discarded cells over the number of transferred cells, and then compares the values of CLRm and CLRs, such that the BF value is decreased when CLRm<CLRs, and increased when CLRm>CLRs. The BF block sets a predetermined upper bound for the BF value such that when the BF value reaches the upper bound, an incremental increase in buffer threshold is effected for said class of service. In this same embodiment, the T7 block determines the TF value by deriving an Average Burst Size (ABS) value and extracting a Maximum Burst Size (MBS) value from the data flow information based on the class of service, and then calculating the TF value as ABS/MBS for each applicable class of service The Hurst meter block sets the value of H to 0.5 for non-self similar traffic. The accumulator block estimates the TECR value by keeping track of calls released and calls to be accepted by the data network.

[0050] In another embodiment, the CAC system further comprising an ECR recovery block for updating the TECR value within the accumulator block upon recovery from an interrupted connection.

[0051] In another aspect of the present invention, there is provides a method of Call Admission Control (CAC) within a data network for a new call having a class of service, said method comprising the steps of:

[0052] a) periodically obtaining from said, data network data flow information and a set of network parameter values corresponding to a set of resource parameters;

[0053] b) determining a Hurst parameter (T) value;

[0054] c) determining a Tuning Factor (TF) value,

[0055] d) determining an Effective Cell Rate (ECR) value;

[0056] e) estimating a required Total Effective Cell Rate (TECR) value;

[0057] f) determining a Reference Effective Cell Rate (RECR) value;

[0058] g) comparing the values of TECR and RECR such that the new call is to be accepted when TECR<RECR, and the new call is to be rejected otherwise;

[0059] h) updating the value of TECR when the new call is accepted.

[0060] The set of network resource parameters includes buffer size (BS), peak cell rate (PCR), sustainable cell rate (SCR), and user specified Cell Loss Ratio (CLRs) corresponding to the class of service. The H value is determined from the class of service and data flow information. The ECR value is determined by using the H value, the TF value and said set of resource parameters.

[0061] In an embodiment of this invention, the step of determining the ECR value includes the steps of:

[0062] (i) exacting a Maximums Burst Size (MBS) value from the data flow information; and

[0063] (ii) calculating the ECR value by using the formula of:

[0064] ECR=SCR/[CLRs(SCR/PCR)]MBS/(BS/TF)/(2−2H)

[0065] In another embodiment of this invention, the step of determining the ECR value includes the steps of:

[0066] (i) extracting a Maximum Burst Size (MBS) value from the data flow information; and

[0067] (ii) calculating the ECR value by using the formula of:

[0068] Log ECR=Log SCR−[Log CLR+Log SCR−Log SCR]×Exponent

[0069] where Exponent=[MBS/(BS/TF)]/(2−2H).

[0070] In yet another embodiment of this invention, the set of resource parameters includes link capacity (LC) and user specified Cell Loss Ratio (CLRs), wherein the step of determining the RECR value includes the steps of:

[0071] (i) setting a booking factor (BF) value; and

[0072] (ii) calculating RECR as LC/BF.

[0073] The step of setting the BF value includes the steps of:

[0074] (i) deriving from the data flow information a measured Cell Loss Ratio (CLRm) value as the number of discarded cells over the number of transferred cells; and

[0075] (ii) comparing the values of CLRm and CLRs, such that the BF value is decreased when CLRm<CLRs, and increased when CLRm>CLRs.

[0076] A predetermined upper bound is set for the BF value such that when the BF value reaches the upper bound, an incremental increase in buffer threshold is effected for said class of service.

[0077] The step of determining the TF value includes the steps of:

[0078] (i) deriving an Average Burst Size (ABS) value and extracting a Maximum Burst Size (MBS) value from the data flow information based on the class of service; and

[0079] (ii) calculating the TF value as ABS/MBS for each applicable class of service. The value of H is set to 0.5 for non-self similar traffic.

[0080] The step of estimating TECR is performed by keeping track of calls released and calls to be accepted by the data network. This TECR value is updated upon recovery from an interrupted connection.

[0081] Prior art methods for calculating the Effective Bandwidth (EB) are typically complicated, computationally difficult, and depend greatly on mathematical assumptions Yet, the operator in the field is still required to manually adjust the CAC to meet the real traffic situation as traffic profiles evolve, rendering the sophisticated calculations non-useful. The present invention overcomes this problem by offering a simple, “back-to-basics”, self-tuned hardware CAC implementation that needs little or no manual in the field.

[0082] Advantages of the present invention over prior art include a considerable increase in computational speed, flexibility in implementing the complex formula for both self-similar and non-self-similar traffic, increased accuracy by taking both the ABS and MBS factors into account, increased reliability for mission-critical applications, robustness in recovering connection in case of a link failure, and a more cost-effective automated approach to resolving the inefficiencies associated with manual operation.

[0083] In a cell/packet based network, including ATM and IP networks for all service categories that transmit Data Units, each ATM switch or IP router must allocate enough bandwidth and buffer to guarantee that the required QoS for each virtual channel (or GoS for each flow) will be satisfied. As a preventive mechanism for network congestion, CAC is performed at connection (or flow) set-up time to determine if the new connection (or flow) can be accepted in terms of both its own service requirements and any impact it may have on already existing connections (or flows). Logically the “go/no-go” decision of the CAC function must be performed for each statistical element of the network. For example, in satellite environments these elements include the transmitting queue in the ground terminal, the up-link ingress queue, the fabric queue, the down-link queue is in the on-board switch, and the receiving queue in the ground terminal. For each of these elements, a CAC engine can be implemented.

[0084] For convenience, a glossary of acronyms used in this description is given below.

[0085] ABR Available Bit Rate

[0086] ABS Average Burst Size

[0087] ATM Asynchronous Transfer Mode

[0088] BF Booking Factor

[0089] BFBS Buffer with Factor scaled Size

[0090] BS Buffer Size

[0091] CAC Connection Admission Control

[0092] CBR Continuous Bit Rate

[0093] CFI Cell (or data) Flow Information

[0094] CLR Cell Loss Ratio

[0095] CLRm Measured value of Cell Loss Ratio

[0096] CLRs User Specified Cell Loss Ratio

[0097] CoS Class of Service

[0098] EB Effective (or equivalent) Bandwidth

[0099] ECR Effective Cell Rate

[0100] GFR Guaranteed Frame Rate

[0101] GoS Grade of Service

[0102] H Hurst parameter

[0103] HST Hurst Smoothness of Traffic

[0104] IP Internet Protocol

[0105] LC Link Capacity

[0106] MBS Maximum Burst Size

[0107] MIB Management Information Base

[0108] PCR Peak Cell Rate

[0109] QoS Quality of Service

[0110] RECR Reference Effective Cell Rate

[0111] SCR Sustainable Cell Rate

[0112] TECR Total Effective Cell Rate

[0113] TF Tuning Factor

[0114] UBR Unspecified Bit Rate

[0115] VBR Variable Bit Rate

[0116] Exemplary embodiments of the invention will now be further described with references to the drawings in which same reference numerals designate similar parts throughout the figures thereof, and wherein:

[0117] FIG. 1 illustrates, in a block diagram, a typical switching element that incorporates a CAC engine;

[0118] FIG. 2 illustrates, in a block diagram, the composition of the CAC engine in accordance with an embodiment of this invention and its interconnection with the switching hardware and other elements of the network;

[0119] FIG. 3 illustrates, in a block diagram, the booking factor block shown in FIG. 2;

[0120] FIG. 4 illustrates, in a block diagram, the tuning factor block shown in FIG. 2;

[0121] FIG. 5 illustrates, in a block diagram, the Hurst meter block shown in FIG. 2;

[0122] FIG. 6 illustrates in a more detailed block diary, the accumulator block shown in FIG. 2;

[0123] FIG. 7 illustrates, in a block diagram, a hardware configuration for performing direct mathematical operations within he ECR calculator block shown in FIG. 2;

[0124] FIG. 8 illustrates, in a block diagram, the composition of the CAC engine in accordance with an alternative embodiment of this invention based on performing log conversion operations;

[0125] FIG. 9 illustrates, in a block diagram, the log conversion operations performed within each of the logarithmic tuning factor block, logarithmic ECR calculator block, and logarithmic booking factor block of the CAC engine of FIG. 8;

[0126] FIG. 10 illustrates in a block diagram, the logarithmic calculations performed within the booking factor block of FIG. 8;

[0127] FIG. 11 illustrates, in a block diagram, the logarithmic calculations performed within the tuning factor block of FIG. 8;

[0128] FIG. 12 illustrates, in a block diagram, the logarithmic operations performed within the ECR calculator block of FIG. 8;

[0129] FIG. 13 compares in a graph the relationship between CLR and Hurst obtained from simulated results versus analytic results;

[0130] FIG. 14 illustrates in a graph the values of CLR versus Load performance obtained from real simulation results.

[0131] Table 1 compares the number of mathematical operations in this invention relative to prior art solutions;

[0132] Table 2 compares the calculated ECR values in this invention relative to the prior art;

[0133] Table 3 shows information requited in the MNB for different Service Categories and Classes;

[0134] Table 4 shows additional data required in the MIB for different Service Categories and Classes; and

[0135] Table 5 compares simulated CLR values with analyzed CLR values for different Hurst parameter values.

[0136] Throughout is description the following terms are used in accordance with their respective definitions given below.

[0137] Throughout, the term cell is used to imply the general meaning of a data unit as defined above, which is applicable to any type of data network as defined above. Also, the two terms bandwidth and cell rate are interchangeably used to imply the general meaning of the rate of data flow within any type of data network as defined above.

[0138] Before describing alternative embodiments of the present invention, the following explains the derivation of formulas for calculating the Effective (or equivalent) Bandwidth (EB), expressed in Effective Cell Rate (ECR) in cells/second.

[0139] First, a relatively simple formula for calculating ECR, is obtained from a Markovian (M/M/1) queue model as:

[0140] ECR=BF×SCR/(CLR×SCR/PCR)^(MBS×TF/BS)

[0141] where BS is the buffer size for a theoretical queue, IMS is the maximum burst size, TF is the tuning factor and BRF is the booking factor. The parameters CLR (Cell Loss Ratio), SCR (Sustainable Cell Rate), and PCR (Peak Cell Rate) are resource parameters, the values of which are obtained from the user system. The CLR parameter is the ratio of the number of cells discarded within a user's data switch over the number of cells entered into the switch during a specified period of time. The Tuning Factor and Booking Factor are used to adjust the aggressiveness of the calculation. The switch vendor provides the initial default values, while the operational values are to be tuned in the field. In most cases, these values are left untouched in the field unless the network operator wants to override the settings.

[0142] A buffer is physically located in each statistical multiplexing element of the data network where the CAC functions are executed. For example, in satellite communications these elements include the transmitting queue in the ground terminal, the up-link ingress queue, the fabric queue, the down link queue in the on-board switch, and the receiving queue in the ground terminal. Within such a buffer, different Classes of Service (CoS) have different traffic characteristics. For example, a Constant Bit Rate (CBR) service has a relatively smooth traffic with an almost fixed rate, and thus requires a smaller buffer space than a Variable Bit Rate (VBR) service having by traffic. In the extreme case where the VBR service sends its cells at a maximum line rate followed by a quiet period during which no cells are sent, a relatively large buffer space is required. The ATM Forum has defined a number of different classes of service CoS, as documented in reference [4] In order to accommodate such different classes, the total buffer space has to be partitioned among these classes. It should be noted that, since the CAC functions have to be performed for each service class of queues, in actual practice the theoretical Buffer Size (BS) corresponds to the buffer threshold for each service class.

[0143] Based on the above M/M/1 queue formula and using a wavelet-like method, a simple Effective Bandwidth (EB) formula for a self-similar (i.e. fractal) traffic is further derived from a Fractional Brownian Motion (FBM/M/1) queue model as per the following.

[0144] The multiplexing of a large number of connections in a network is modelled from a fundamental FBM/M/1 queue in order to derive the following formula for calculating the Cell Loss Ratio after applying simple approximations:

[0145] CLR≅(SCR/EB)^{(BS/AB)×(2−2H)}

[0146] where (BS/ABS) is the equivalent number of cells in the queuing system, and H is the Hurst parameter obtained from statistical measurements for applicable traffic containing specific service and traffic parameters. In theory, the value for H value ranges from 0.5 to 0.99, depending on the type of traffic. In practice, H typically ranges from 0.7 to 0.9 for self-similar traffic and has a value of 0.5 for non-self-similar traffic.

[0147] When the number of connections is not too large, the aggregate traffic may not be as smooth as a Poisson distribution. Therefore the burstiness ratio (PCR/SCR) should be taken into account when calculating the CLR value. Since this ratio is proportional to the traffic burstiness, an approximate expression for the above CLR equation is then expressed as:

[0148] CLR≅(PCR/SCR)×(SCR)×(SCR/EB)^{(BS/ABS)×(2−2H)}

[0149] Solving for the unknown EB, we get

[0150] EB(or ECR)=SCR/[CLR×(SCR/PCR)]^{(ABS/BS)/(2−2H)}

[0151] Since ABS/MBS=TF, then ABS/BS=[TF×(MBS/BS)], and

[0152] ECR=SCR/[CLR×SCP/PCR]^{(TF×MBS/BS)/(2−2H)}

[0153] Since BFS=BS/TF and HST=2−2H, the ECR formula can also be expressed as

[0154] ECR=SCR/[CLR×SCR/PCR]^{(MBS/BFS)/(HST)}

[0155] The last two formulas are the ones mainly used in calculating the CLR value in alternative embodiments of this invention, the former in embodiments using logarithmic operations and the latter in embodiments using direct mathematical operations, as will be described further below.

[0156] It should be noted that the above two formulas are also applicable for Multi-Protocol Label Switching (MPLS) being developed for future applications, except that the traffic units would be in bytes/second instead of cells/second, and the MBS would correspond to the maximum packet size.

[0157] FIG. 1 is a top-level block diagram showing a typical switching element that incorporates a CAC engine which physically resides and operates within a real-time control processor 1 and logically sits between the user and network interface, interacting with the software part of a signaling and Management Information Base (MIB) 2 of the switch. In addition to performing CAC functions, the real-time processor 1 computes and processes top level calls and interactions between all of the elements. The MIB 2 records all call processes related to the system and traffic parameters. A signaling extractor 3 extracts relevant traffic parameters from the data unit flow during the call set-up phase. The switch hardware 4 is the physical board where data unit flow is processed. The data unit flow terminates at a receiver.

[0158] FIG. 2 is a block diagram illustrating a CAC engine 5 in accordance with an embodiment of the present invention. This figure also shows the relationship among the CAC engine 5, the switch hardware 4, the MIB 2 and the control processor 1. The Signaling Extractor 3 provides CAC engine 5 the following traffic and network information from an analysis of the data unit flow in switch hardware 4 and from the remainder of the data network:

[0159] 1. from the switch hardware 4: Cell Flow Information (CFI), which is used by the CAC engine 5 to obtain the Average Burst Size (ABS) and the maximum burst size (MBS);

[0160] 2. from the MIB 2: the Hurst parameter (H), the Link Capacity (LC) and the Buffer Size (BS); and

[0161] 3. from the signaling extractor 3: the Peak Cell Rate (PCR), the Sustainable Cell Rate (SCR), the Quality of Service (QoS), a user specified value of the Cell Loss Ratio (CLRs), the Class of Service (CoS), the Call_Goes signal (CG) and the Call_Comes signal (CC).

[0162] Within the thick dotted lines of FIG. 2, the CAC engine 5 contains the following blocks: a Tuning Factor (TF) block 6, a Hurst meter block 7, a Booking Factor (BF) block 8, an ECR calculator block 9, an ECR recovery block 10, an accumulator block 11, and a comparator block 12. The following is a functional description of each of the above blocks and their interaction with one another and with the remainder of the switching system shown in FIG. 2.

[0163] (a) Booking Factor (BF) Block

[0164] Further details of the BF block 8 are illustrated in FIG. 3. As indicated above, the Booking Factor is used to adjust the aggressiveness of the calculation. The switch vendor provides the initial default values, while the real values are tuned automatically in the field. In most cases, these values are left untouched in the field unless the network operator wants to override the settings.

[0165] The BF block 8 contains a Booking Factor (BF) calculator 14, which provides the BF value to a reference ECR calculator 13, within the BF block 8. The BF Calculator 14 fetches the CLRs value from the signaling extractor 3 and the data flow information, expressed for this embodiment as Cell Flow Information (CFI), from the switch hardware 4. A set of counters for each service class in the switch hardware 4 record the number of cells discarded within the switch and the number entered into the switch during, a specified period. The BF calculator 14 then derives from the CFI the measured value of CLR (CLRm) as the ratio of the number of discarded cells over the number of entered cells, and calculates the BF value from the CLRs and CLRm values. If CLRm is less than CLRs, the BF calculator 14 decreases the BF by a pre-defined amount, typically 0.1. On the other hand, if CLRm is greater than CLU, the BF value is increased by the same predefined amount. Otherwise the BF value remains the same. The value of BF typically ranges from a lower bound of 0.1 and an upper bound of as high as 10. If the upper bound is reached but still does not meet the required CLRS, then the BF calculator 14 will send a Change Buffer (CB) signal to the MIB 2 in order to increase the buffer threshold corresponding to the Class of Service (CoS) of the call in progress.

[0166] The buffer threshold value of the particular CoS refers to the amount of the buffer space that is allocated to that CoS. Thus it corresponds to the buffer size that such CoS can actually account on Typically a CBR service has a lower threshold than a VBR service. These thresholds are configurable. The threshold value for each class is stored in the MIB 2. When the BF calculator 14 updates these values in the MIB 2, the statistical element in the data network will reallocate the buffer space among the classes concerned. As the total buffer is fixed at the time of manufacture, such a change in threshold setting will undesirably decrease the buffer threshold of the next lower CoS by a pre-defined configuration setting (typically 10 cells at a step). However, such a decrease is only expected when the traffic profile encounters major changes.

[0167] In some cases, laboratory or field measurements indicate that a theoretically calculated threshold is too low, i.e. not enough buffer space is allocated to a VBR class of service to meet its specified CLR. There, an increase in the buffer space is accommodated by reducing the threshold (i.e. buffer space) for another lower priority class such as a UBR class of an unspecified bit rate. Although the BF value can possibly be manually over-ridden by the network operator, it is not recommended to manually reconfigure the buffer thresholds without approval from equipment vendor. The buffer thresholds are normally configured at the time of manufacturing, on the basis of sophisticated priority based queueing theory; or extensive simulations for complicated weighted fair queue schemes. Therefore, any change of these values should preferably go through all these sophisticated procedures. The BF value is then provided to the reference ECR calculator 13, which also receives from the MIB 2 the Link Capacity (LC) resource parameter, representing the rate at which data units (or cells) are moved out of the buffer through an exit communication link. The reference ECR calculator 13 then calculates the Reference ECR (RECR) value as:

[0168] RECR=LC/BF

[0169] and outputs the result to the next stage in the CAC engine 5, i.e. the comparator block 12.

[0170] It should be noted that performing a mathematical operation to update the value of BF is not necessary for every call set up, but is rather done on a periodic basis, ranging from hourly to daily. The frequency of updating the BF value is determined by the level of accuracy of the CLR measurement required by the network operator. For more accurate measurements, longer updating intervals are needed, together with more overhead for the measurement from both implementation and operation points of view. For a given accuracy or confidence of measurement, the updating interval is inversely proportional to the outgo link speed. For example, at an E1 rate (2.048 Mbps), a few days are needed in order to observe hundreds of millions of cells for performing the CLR measurement. However, for the OC12 link (622.08 Mbps), a shorter updating interval is needed as thousands of millions cells go through the communication link only in a few hours In general, 10 to 100 cells/CLRs need to be accumulated before gaining confidence in the CLRm value for updating the BF value.

[0171] (b) Tuning Factor Block

[0172] Further details of the Tuning Factor (TF) block 6 are illustrated in FIG. 4. As indicated above, the TF value is used to adjust the aggressiveness of the calculation. The TF block 6 contains a TF calculator 16, which provides the TF value to a Buffer with Scaling Size (BSS) calculator 15. The BSS calculator 15 fetches the Buffer Size (BS) resource parameter from the MIB 2 and the CoS from the Signaling Extractor 3. The TF calculator 16 fetches from the switch hardware 4 the Cell Flow Information (CFI) and performs statistical measurements thereon to derive from it the Maximum Burst Size (MBS) and the Average Burst Size (ABS) corresponding to a given Class of Service (CoS). The burst size is the ratio of the number of cells over the number of packets. As indicated above, a set of counters for each service class in the switch hardware 4 records both the number of cells and the number of packets entered into the switch during a specified time period The TF calculator 16 then calculates the TF value as:

[0173] TF=ABS/MBS.

[0174] The BSS calculator 15 uses the CoS value received from the signaling extractor 3 as a pointer to pick up the TF value corresponding to the CoS of the call in progress. For example, a real-time VBR class has a different value of TF from that of a non-real-time VBR class. The BSS calculator 15 then calculates the value of “Buffer with Factor Scale Size” (BFS):

[0175] BFS=BS/TF

[0176] corresponding to the present CoS. This BFS value is provided to the next stage of operation in the CAC engine 5, i.e. the ECR calculator block 9. The purpose of this operation is to minimize the network operator's manual involvement and allow for automatic processing.

[0177] (c) Hurst Meter Block

[0178] As illustrated in FIG. 5, the Hurst meter block 7 fetches the CoS from the signaling extractor 3 and records the CFI from the switch hardware 4. The Hurst meter block 7 contains a Hurst factor calculator 7awhich performs statistical measurements on the CFI and sends the number of cells within a specified period for each concerned CoS to the MIB 2 to be recorded therein. A software program/agent residing in the MIB 2 will retrieve these data and calculate the H value when sufficient data is collected by the Hurst meter block 7, and writes back this value into the MIB 2. The value of H is updated regularly within a predefined update interval depending on the required accuracy. Typically, the update interval of H value ranges from 10 to 1000 times the interval of updating the BF value discussed above. The computation of the Hurst value H in the MIB 2 is drawn from the Index of Dispersion for Counts formula known in the art, as provided in reference [2].

[0179] The Hurst meter block 7 then obtains from the MNB 2 a Hurst value H corresponding to the given CoS. For example, a real-time VBR class (eg. carrying a video signal with H=0.85) has a different value of H from that of non-real-time VBR class (e.g. carrying an email message with H=0.95). Finally, the Hurst factor calculator 7acalculates the HST value (representing the Hurst smoothness of traffic) as:

[0180] HST=2−2H

[0181] In a preferred embodiment of this invention, a dedicated hardware is chosen to compute HST. Alternatively, this equation is computed by the software residing in the MIB 2.

[0182] (d) ECR Calculator Block

[0183] The ECR calculator block 9 shown in FIG. 2 fetches from the signaling extractor 3 the values of the resource parameters PCR, SCR, MBS and CLRs together with the Call_Comes (CC) signal. The ECR calculator block 9 also fetches the BFS value from the TF block 6 and the HST value from the Hurst meter block 7. From these input parameters, the ECR calculator block 9 calculates the of the ECR value for every call set-up request, using either one of the two the formulas derived above, while substituting CLPs for CLR.

[0184] (e) ECR Recovery Block

[0185] The ECR recovery block 10 receives the Call_Goes (CG) signal from the signaling extractor 3 and retrieves the ECR_Go (ECRG) indication from the MIB 2. From this information the ECR recovery block 10 derives and sends a signal (ECRG') to the accumulator block 11 to update the previous total ECR value when the call is to be released or to recover all interrupted connections upon a link failure.

[0186] The process of ECR recovery takes place after one of two conditions:

[0187] (a) a normal call releasing operation; and

[0188] (b) an abnormal link failure (e.g. an optical fibre line is physically cut by accident, or an air link fades due to heavy rain).

[0189] Under the former condition, when a call is handed off, the ECR recovery block 10 fetches the ECR value from the MIB 2 based on the call identification obtained from signaling extractor 3, and forwards this ECR value to the accumulator block 11 for subtraction from the TECR value.

[0190] Under the latter condition, when a link failure has been indicated by the signaling extractor 3 and a reconnection is requested, the ECR recovery block 10 will respond accordingly to re-establish the connection as follows. When the signaling extractor 3 requests a connection recovery, the ECR recovery block 10 will first check whether or not the connection has an entry in the MIB 2. If not, the ECR recovery block 10 will request the signaling extractor 3 to set up the call as a new comer. If yes, the ECR recovery block 10 will request the accumulator block 11 to provide the same TECR value to the comparator block 12, so that a “go” signal is issued by the comparator block 12. That way, any connection that bas been accepted prior to the link failure, will not be rejected upon recovery from the link failure. In the case that an extended link failure was caused by persistent rain fading, and that a routing part of the data network decided to choose an alternate route, the ECR recovery block 10 will release that link. The ensuing process will be the same as under the formerly mentioned condition of a normal call release.

[0191] (f) Accumulator Block

[0192] The accumulator block 11 keeps track of the total required bandwidth in terms of Total ECR (TECR). A more detailed illustration of this block is given in FIG. 6. The accumulator block 11 contains a current ECR holder 49, an adder/subtractor unit 50, and a previous TECR Holder 51. The adder/subtractor unit 50 is constructed from standard logical gates such as AND, NAND, OR, NOR gates. The Current ECR Holder 49 and the Previous TECR Holder 51 are constructed from standard shift registers, and both receive the Go/No-Go (GNG) signal fed back by the comparator block 12. When a call is accepted, an ECR_Come (ECRC) signal is outputted by the Current ECR Holder 49 to the MIB 2 to be recorded therein for later use, after which the Accumulator 11 is updated. When a call is rejected, this operation is not executed.

[0193] The adder/subtractor unit 50 receives the calculated ECR value from the ECR calculator 9, ECRG from the ECR recovery block 10, and the current ECR value from the previous TFCR Holder 51. The adder/subtractor unit 50 provides a TECR output to the next stage of the CAC Engine 5, i.e. the comparator block 12. The newly calculated ECR value is provided as the TECR output value when a call is accepted. Otherwise, the previous TECR value is provided as the TECP output value when a call is rejected.

[0194] (g) Comparator Block

[0195] The comparator block 12 receives the value of RECR from the BF block 8, the value of TECR from the accumulator block 11, and the Call_Come (CC) signal from the signaling extractor block 3. The comparator block 12 compares the value of TECR representing the required bandwidth, with the value of PECR representing the link capacity divided by the booking factor. If TECR is less than RECR, then the new call is accepted and the previous total ECR is updated. Otherwise the call is rejected and the previous total ECR is not changed.

[0196] As indicated above, the value of ECR is obtained by direct mathematical calculation in one alternative embodiment, and by logarithmic calculation in another alternative embodiment.

[0197] FIG. 7 illustrates details of the ECR calculator block 9 as part of an embodiment of this invention where direct mathematical operations are performed for calculating the value of ECR. In such an embodiment, the ECR calculator block 9 contains first to fourth dividers 17, 18, 20 and 22 respectively, a multiplier 19, and an exponientiator 21.

[0198] The inputs to the ECR block 9 are the resource parameters SCR, PCR, CrRs and MBS obtained from the signing extractor block 3, the value of BFS from the TF block 6 and the value of HST from the Hurst meter block 7. The first divider 17 receives the values of SCR and PCR and outputs a first ratio D17 equal to SCR/PCR to the multiplier 19. The multiplier 19 also receives the CLRs parameter and then outputs a multiplication result (CIRs(SCR/PCR)) M19 to the exponentiator 21.

[0199] The second divider 18 receives the AMS and BFS values and outputs a second ratio D18 equal to MBS/BFS to the third divider 20. The third divider 20 also receives HST and then outputs the division result D20 equal to (MBS/BFS)/HST to the exponentiator block 21. The exponentiator block 21 then performs the exponential operation of the two inputs received from the multiplier 10 and the third divider 20 to produce an exponent value E21 for (SCR×SCR/PCR)^{[(MBS/BFS)/HST]}, which is provided to the fourth divider 22. The fourth divider 22 also receives the SCR value to generate the ECR value according to the formula derived above and repeated below:

[0200] ECR=SCR/[CLRs(SCR/PCR)]^{(MBS/BFS)/(HST)}

[0201] In an alternative exemplary embodiment of this invention, the direct mathematical calculation performed in the ECR calculator block 9 as shown in FIG. 7 is implemented in hardware by using a commercial off the shelf FPGA chip to implement the ECR formula.

[0202] In a preferred embodiment, only additive/subtractive calculations are performed by using logarithmic operations in order to substantially reduce computation time. FIG. 8 illustrates a configuration of the CAC engine 75 based on performing logarithmic conversion operations. This configuration is similar to that of the CAC engine 5 shown in FIG. 2, except for two differences. First, the TF block 6, the BF block 8 and the ECR calculator block 9 of FIG. 2 are replaced by a logarithmic TF block 76, a logarithmic BF block 78 and a logarithmic ECR calculator block 79. Second, the function of the Hurst meter block 7 of FIG. 2 is embedded in the logarithmic ECR calculator block 79 of FIG. 8.

[0203] The following description applies to an exemplary hardware embodiment containing the various blocks shown in FIG. 8. One example of such hardware embodiment is implemented in a Field Programmable Gate Array (FPGA) chip or, alternatively, an Application Specific Integrated Circuit (ASIC) chip. Nevertheless, in alternative embodiments both hardware and software designs are combined for implementing the configuration of FIG. 8.

[0204] FIG. 9 illustrates a logarithmic operator block 60 used within the CAC Engine 75 of FIG. 8, for performing the log or antilog conversion. The logarithmic operator block 60 contains an address engine 61 followed by a look-up table 62, preferably in the form of a Read-Only Memory (ROM). The address engine 61 receives a parameter value and accordingly addresses the table 62, when performing a log or anti-log conversion. The granularity of the conversion depends on the size of the table, which is designed just big enough to cover the actual operational range and provides the desired accuracy. Typically a size of 1024 bits will provide three effective digits of accuracy, with an expected relative error within 1%, which is sufficient for practical usage. Two types of tables are used: a log table, which is 14 bits per address and a 900-byte (1K) address; and an anti-log table, which is 10 bits per address and a 900-byte (1K) address. In this particular embodiment, the table is preceded by a multiplexer and succeeded by a demultiplexer to permit its sharing by more than one logarithmic operation, as is manifest in FIGS. 10-12.

[0205] FIG. 10 illustrates the logarithmic BF block 78 shown in FIG. 8. Here, the logarithmic BF block 78 contains in a serial configuration, a BF extractor 23, followed by a multiplexer 24, a log lookup table 25, a de-multiplexer 26, a substractor 27 and an anti-log look-up table 28. The BF extractor 23 extracts the value of RF from the Cell Flow Information (CFI) in the switch hardware 4, and provides such value to the multiplexer 24, which also receives the Link Capacity (LC) value from the MIB 2. The multiplexer 24 multiplexes the values of BF and LC as addresses to the log table 25. The corresponding log values Log LC and Log BF obtained from the log table 25 are then demultiplexed, by the de-multiplexer 26, and provided as inputs to the subtractor 27. The subtractor 27 subtracts these two Log values and outputs the difference S27 as an address to the anti-log Table 28. Finally, the output RECR of the anti-log table 28 is obtained as:

[0206] RECR=LC/BF

[0207] FIG. 11 illustrates the logarithmic TF block 76 shown in FIG. 8. Here, the logarithmic TF block 76 contains in a serial configuration, a multiplexer 29, followed by a log look-up table 30, a de-multiplexer 31, a first subtractor 32 and a second subtractor 33. The values of the BS, ABS and MBS parameters are multiplexed by the multiplexer 29 as addresses to the log table 30, which provides corresponding values of Log BS, Log ABS and Log MBS to the demultiplexer 31. The first subtractor 32 receives Log ABS and Log MBS from the demultiplexer 31 to generate:

[0208] LogTF=Log ABS−Log MBS

[0209] The second subtractor 33 receives Log BS from the demultiplexer 31 and log TF form the first subtractor 32 to generate:

[0210] Log BFS=Log BS−Log TF

[0211] as the final output of the logarithmic TF block 76. Log MBS is also outputted from the logarithmic TF block 76 to the logarithmic ECR calculator block 79.

[0212] FIG. 12 illustrates the logarithmic ECR calculator block 79 shown in FIG. 8. The calculations for:

[0213] Log(Exponent)=Log[(MBS/(BS/TF)/(2−2H)]

[0214] are performed by using the Log MBS and Log BFS values obtained from the logarithmic TF block 76 shown in FIG. 11 and the H parameter obtained from the MIB 2.

[0215] The logarithmic ECR calculator 79 contains a first subtractor 35, which receives Log MBS and Log BFS to generate a first difference signal S35 (Log MBS−Log BFS), which is fed into a second subtractor 38. A shift register 34 receives the H parameter and feeds the value 2H to an operator unit 36, which performs the basic operation 2−2H. A first Log look-up Table 37 receives this value as an address and provides a corresponding value of Log (2−2H) to the second subtractor 38, which in turn subtracts Log (2−2H) from first difference signal S35 to produce a second difference signal S38 as:

[0216] Log(Exponent)=(Log MBS−Log BFS)−Log HST

[0217] where HST=2−2H.

[0218] The calculations for:

[0219] Log(Power)=[(Log CLRs+Log SCR)−Log PCR)]×Exponent

[0220] are then performed by using the values of CLRs, SCR and PCR obtained from the signaling extractor 3 shown in FIG. 2 and the second difference signal S38 obtained from the second subtractor 38. The input parameters CLRs, SCR and PCR are multiplexed by a multiplexer 39 as addresses to a second Log look-up Table 40. The corresponding values of Log CLRs, Log SCR and Log PCR are then demultiplexed by a demultiplexer 41. A first adder 42 receives Log CLRs and Log SCR from the demultiplexer 41 to generate a first addition signal A42 (Log CLRs+Log SCR) fed to a third subtractor 43 together with Log PCR obtained from the demultiplexer 41 to generate a third difference signal S43:

[0221] Log(Base)=(Log CLRs+Log SCR)−Log PCR

[0222] The third difference signal S43 is fed as an address to a third Log Look-up Table 44 to generate signal L44 which is representative of

[0223] Log(Log (Base))=Log[(Log CLRs+Log SCR)−Log PCR].

[0224] L44 is fed together with the second difference signal S38 to a second adder 45 to generate a second addition signal A45:

[0225] Log(Log(Base))+Log(Exponent)=Log [(Log CLRs+Log SCR)−Log PCR]+[(Log MBS−Log BFS)−Log HST]

[0226] The second addition signal A45 is then inputted as an address to a first Anti Log Look-up Table 46 to generate a first anti-log signal AL46:

[0227] Log(power)=[(Log CLRs+Log SCR)−Log PCR]×Exponent

[0228] where Exponent=[MBS/(BS/TF)]/(2−2H).

[0229] A fourth subtractor 47 receives this first anti-log signal AL46 and Log SCR obtained from the demultiplexer 41, to generate a fourth subtraction signal S47:

[0230] Log ECR=Log SCR−[(Log CLRS+Log SCR)−Log PCR]×Exponent

[0231] This signal is fed as an address to a second anti-Log look-up table 48 to generate ECR in terms of the final expression:

[0232] ECR=SCR/[CLRs(SCR/PCR]^{(MBS/(BS/TF)/(2−2H)}

[0233] Of course, numerous variations and adaptations may be made to the particular embodiments of the invention described above, without departing from the spirit and scope of the invention, which is defined in the claims.

[0234] The design of the CAC engine of the present invention is also tailored for use in other broadband ISDN networks, such as Virtual Satellite Networks (VSN) and Low-Earth-Orbiting (LEO) satellites. In the case of VCN, a random early call rejection scheme is used when there is sharing between networks. A call will be rejected according to a certain probability that varies with the total system load, as described in reference [6]. In the case of LEO satellites, the hardware CAC embodiment of the present invention is used. At the first call set-up time, the ECR value is recorded in a table for the hand-over process in the MIB 2.

[0235] The longest signal path in a hardware design is from the MBS input at the TF block 6 to the output of the ECR calculator block 9 (see FIGS. 2 and 8). To complete all of the computations of this path, using a regular 100 MHz clock rate of a standard FPGA board, a maximum of 12 clocks are required. This means that only 120 ns are consumed per call. With 3 digits of accuracy provided by current FPGA technology, we found (based on the Altera™ 10K FPGA specification) that 2400 gates are needed to implement the Log/Anti-Log look-up Tables and 1600 gates are needed to implement the logic units, yielding a total gate count of only 4000.

[0236] In a software implementation on the other hand, we found that, by choosing a very fast 40 MHz real-time software computation (such as the Vx Works™ by WindRiver™), 15 ticks are needed to perform 1,000,000 mathematical operations, where each tick consumes {fraction (1/60)} seconds. This means that eight mathematical operations will require 2 micro seconds to complete the software computation for the ECR equation. This does not include the comparison function and memory read/write times, which consume more than the computation time itself.

[0237] It is therefore concluded that the hardware implementation of the ECR formula, based on pure additive computations, will be executed by approximately two orders of magnitude faster than a software implementation.

[0238] Analytical results of an embodiment of the Present CAC invention (PCAC) are compared with those of two prior art CACs: an IBM™ CAC (ICAC) based on the M/M/1 queue algorithm described in reference [1] and a VTT™ CAC (VCAC) based on the FBM/M/1 queue algorithm described in reference [3].

[0239] Table 1 compares the number of arithmetic computations required by each of the above CAC algorithms. From this table it is seen that the present CAC embodiment has considerably less computations than the other two.

[0240] Using a standard Belcore™ traffic test set for three different Variable Bit Rate models (VBRI, VBRII, VBRIII), Table 2 compares the ECR values required by each of the above CAC algorithms. This table shows that the ECR values obtained by the three different CAC methods are quite close, and therefore indicates that the present CAC invention is just as efficient as the other two relatively more complex algorithms.

[0241] When several service categories are to be supported, additional information will need to be stored in the MIB. For the switch used in the above comparative analyses, the network may support five service categories and eight distinct priorities, as given in Table 3. Buffer size, cell loss ratio and Link Speed will also need to be individually fetched from the MIB, as shown in Table 4. Table 4 shows the priority numbers for traffic in a presently preferred embodiment. Continuous bit rate (CBR) traffic from a CBR source is assigned priority 1. Priority 2 is assigned to Real-Time Variable Bit Rate 1 (RTVBR1) class traffic from VBRI and VBRII sources. Priority 3 is assigned to Real-Time Variable Bit Rate 2 (RTVBR2) class traffic from VBRI and VBRII sources. Priorities 4, 5 and 6 are given to Non-Real-Time Variable Bit Rate 1, 2, and 3 (NRTVBR1, NRTVBR2, NRTVBR3) classes of traffic respectively, from VBRI and VBRIII sources. Priority 7 is given to Guaranteed Frame Rate (GFR) class traffic from Transmission Control Protocol (TCP) sources. Priority 8 is given to Unspecified Bit Rate (UBR) traffic from User Datagram Protocol (UDP) sources.

[0242] (a) Procedure for Theoretical Simulation

[0243] The general procedure is to simulate a single First-In-First-Out (FIFO) queue using a given homogeneous input signal, find the Cell Loss Ratio (CLR), and compare this loss with that of the analytic derivation. The CLR value for the analytic derivation is given by the formula:

[0244] CLR=load^(BS×3H)

[0245] where J=(2−2H)/3−2H).

[0246] Simulation for a load=0.9 and BS=100 using the techniques described in reference [7], was obtained as shown in Table 5 and graphically shown in FIG. 13.

[0247] (b) Procedure for Benchmark Simulation

[0248] The general procedure is to simulate a single FIFO queue using a given homogeneous input signal, find the cell loss curve, and compare this loss with that of the analytic derivation. The cell loss for the analytic derivation is given by the formula: $\mathrm{CLR}=\frac{\mathrm{TF1}\times \mathrm{PCR}}{\mathrm{SCR}}\times {\left(\frac{\mathrm{BF}\times \mathrm{SCR}}{\mathrm{EB}}\right)}^{{\left(\frac{\mathrm{TF2}\times \mathrm{MBS}}{\mathrm{BS}}\right)}^{\mathrm{TF2}\times \left(2H-1\right)-1}}$

[0249] where the tuning factor values TF1, TF2, and TF3, and the Hurst value H are chosen for different service categories, as shown below. For the simulation, a link speed of 155 Mb/s, a T1 CBR and a DS-3 VBR are assumed, and the sources (bit-rate models) are varied in order that the load varies from 0.6, 0.7, 0.8, until 0.9.

[0250] For the CBR service category a Bellcore CBR model is used as source to tune the three tuning factors, starting with centre values of:

[0251] TF1=0.1, TF2=1, TF3=1

[0252] For the RT-VBR service category, a Bellcore VBR model is used as source to tune the three tuning factors, starting with the centre values of:

[0253] TF1=0.2, TF2=0.5, TF3=0.7

[0254] Furthermore, based on the FBM model, the default traffic parameter “H” is tuned by using average values of existing measurements, starting with the centre value of:

[0255] H=0.7

[0256] For the NRT-VBR service category, a Bellcore VBR model is used as source to tune the three tuning factors, starting with the centre values of:

[0257] TF1=0.25, TF2=0.2, TF3=0.7

[0258] Moreover, based on a WWW model, the default traffic parameter “H” is tuned by using average values of existing measurements, starting with the centre value of:

[0259] H=0.8

[0260] For the GFR/ABR service category, a Poisson model (as a TCP model) is used as source to tune the three tuning factors, starting with the centre values of:

[0261] TF1=0.3, TF1=1, TF3=1

[0262] For the UBR service category, a Poisson (or Pare to Modulated General Process) model is used as source to tune the default ECR parameter, starting with a centre value of:

[0263] ECR=10 cells/sec

[0264] (c) Real Simulation

[0265] The general procedure is to stimulate a switch using a given heterogeneous input signal, find the CLR, and fine-tune the factors. An example of this procedure is described in reference [7]. One result of this simulation process is graphically shown in FIG. 14.