Method and apparatus for call event processing in a multiple processor call processing system

Abstract

Techniques for determining the eagerness of a call processing unit within a multiple processor call processing system to accept a new call or call upgrade, as well as call admission control and other call event processing, as well as systemwide load balancing through query of such eagerness are disclosed. Fuzzy logic and associated analysis is used to determine this eagerness. Eagerness for a particular call processing unit is determined in part with reference to the actual load of a call as well as an estimated load approximated using a probabilistic distribution function, such as a Gaussian distribution.

Description

TECHNICAL FIELD

[0002] This invention generally relates to communications infrastructure and techniques, and particularly concerned with load estimation, load balancing and call admission control in call processing systems including plural call processing units.

BACKGROUND

[0003] In light of recent tightening of the credit markets and general drop-off in demand, telecommunications carriers are increasingly pressured to maximize return on their existing infrastructure and/or make wise choices when purchasing and deploying new telecommunications gear. Due in part to their cost and potential performance bottlenecks, especially when stretched beyond nominal loads, call processing systems within the carrier's network have drawn heightened scrutiny.

[0004] Traditional time-domain switched, voice-oriented communications typically included a single call processing unit tightly coupled to and servicing a given switch fabric or a dedicated portion thereof. Smaller, enterprise class telecom solutions such as a digital key or private branch exchange included one call processing unit, whereas carrier grade involved a dedicated call processing unit servicing a dedicated portion fabric. TDM switching techniques assured an actual or virtual and maintained for the duration of a call, at the expense of resource

[0005] With the advent of packet voice and softswitch solutions, the call processing system has been decoupled from the actual or virtual switching fabric, and a number of multi call processor designs have been developed, since each call processing unit is now capable of handling almost any call originating from or terminating to the larger system.

[0006] A representative multiple processor call processing system 2500 is shown in FIG. 25. In this system, plural individual call processing units or PMCis, including PMC12515, PMC22520 and PMCK 2525, collectively handle a number of call processing activities and call events. The managing call processing unit, or PMC-M 2510, performs other call processing activities and events. Typically, in known multiple call processing system architectures, the PMCis 2515, 2520 and 2525 handle the bulk of the “individual call” oriented activities and tasks based on the subset of system calls they are assigned to handle, whereas the PMC-M 2510 is primarily responsible for coordinating operation of the PMCis as needed for e.g. system-wide call admission control and load balancing. As such, communication of coordination information (not shown) such as control, status, query and reporting messages occurs between these PMCis 2515, 2520, 2525 and the PMC-M 2510 on a periodic and/or event-driven basis.

[0007] A well-known goal that multiple processor call processing systems (such as the system 2500 shown in FIG. 25) attempt to achieve with respect to call admission control (CAC) and load balancing is to maintain the QoS commitment for the existing calls (failing to introduce delays or packet loss in packet voice environments) while maximizing call capacity, and ultimately maximize efficient use of the call processing system. In particular, the goal is to provide an optimally efficient call handling situation in which all individual call processing units in a multiple processor call processing system are evenly and homogeneously (with respect to call type) loaded. Thus, ideally, call admission control and new call blocking will thus only occur where all these call processing units are already fully or nominally loaded.

[0008] To illustrate, refer to a simplified capacity diagram of a 6 PMCi call processing system 105 shown in FIGS. 1A-1C, generally consistent with the system 2500 shown in FIG. 25. As shown in each of FIGS. 1A-1C, each box within each PMC1 . . . PMC6 represents a call, with a shaded box 110 representing a voice call, a diagonally hatched box 112 representing a streaming call, and a transparent double-sized box 114 representing an interactive call. Each container 107 represents the capacity of a given PMCi. In FIG. 1A, the PMC1 . . . PMC6 of the multiple processor call processing system 105 are evenly and homogeneously loaded; in FIG. 1B, the load is even but not homogeneous; and in FIG. 1C the load is neither homogeneous nor even.

[0009] The risk presented in FIG. 1B is that if there is congestion in a given PMCi, most calls within such PMCi might be of the same nature thus making any call processing remedy more difficult. The risk posed in FIG. 1C is that while there is unused capacity on some PMCis (e.g. PMC2, PMC4, PMC6), other PMCis (e.g. PMC1, PMC3, PMC5) are very close to their nominal load and may not be able to provide sufficient service level guarantees or quality of service to the calls they are handling. As a result, the goal should be to maintain even and homogenous loads, as in FIG. 1A. It should also be noted that even this situation, the call processing system 105 may reach a loading condition where all the PMC1 . . . PMC6 are nominally loaded, and that the system cannot admit further new calls, but this situation happens less often, if the load is even.

[0010] In order to load balance a multiple processor call processing system, it is important to be able to estimate the resource utilization (in terms of e.g. bandwidth or processor loading) on each call processing unit at any given time. Once the per PMCi estimated loading is determined, one can prospectively load balance by admitting new calls based on which PMCi has free resources to handle the call. A simple brute force approach is to assume that each call is taking up its peak resource requirement, and that the estimated load is based on this peak resource requirement multiplied by the number of calls being handled. This obviously results in inefficient resource under-utilization, and cuts against some of the perceived variable bandwidth advantages afforded by packet voice transmission.

[0011] Another known technique for estimating resource utilization is based on a relationship between peak and average resource requirements for a given call type, e.g.: 1$\begin{array}{cc}\begin{array}{c}\mathrm{estimated}\mathrm{resource}\mathrm{utilization}\\ \mathrm{for}a\mathrm{given}\mathrm{call}\mathrm{type}\end{array}=\frac{2*\mathrm{peak}*\mathrm{average}}{\mathrm{peak}+\mathrm{average}}& \left(1\right)\end{array}$

[0012] Once the estimated resource utilitization for the different call types being or expected to be handled within the call processing system is known, each PMCi's loading can be estimated by determining how many of each type of calls are being serviced and multiplying each by this estimated resource utilization. Resources can be reserved within each of the PMCi consistent with the estimated resource utilization and additional capacity can be determined based on remaining unreserved resources.

[0013] FIG. 2 illustrates a plot of the estimated resource utilization curve 202 corresponding to the above equation (1) versus the average resource utilization. It is obvious that in this method, when the average is significantly smaller than the peak resource requirement, the estimated resource utilization approaches twice the average resource requirement (e.g. approaches line 204 having a slope of 2 in FIG. 2). Otherwise, the estimated resource utilization is always a 1 to 2 multiple of the average (e.g. always greater than, but approaching line 206 having a slope of 1). Ergo:

average<<peakestimate=2×average  (2)

average≅peakestimate=average=peak  (3)

[0014] Thus, using this estimated resource utilization technique results in a overly-conservative loading estimation for the PMCis (i.e. more resources are estimated being used than is actually the case) and can potentially result in a false determination that a given PMCi is at nominal loading or overloaded when it still in fact has capacity. The call processing system can refuse to provide additional calls to the so-overloaded PMCi which still in fact has capacity, and worse, may prematurely refuse to admit further calls to the system (assuming the remaining PMCis are estimated at nominal or greater loading). On the other hand, it is unlikely that any one PMCi will be overbooked or oversubscribed, thus this technique is perceived at least being QoS friendly.

[0015] Further, this estimated resource utilization technique does not take into account the number of calls of a given call type being handled by a given call processing unit. It is well-known that the greater the number of calls of a given type are being serviced by a given PMCi, the less is the chance that these behave all the same way or utilize the same amount of resources. For example, it is highly improbable that, in the case of packet voice with silence suppression, that all handled calls will be in the more resource demanding active, vs. silent state. To account for this, it is generally known that a provisionable reservation coefficient may be used to augment the above to permit the PMCis and the call processing system generally to accept more calls than the above-described conservative estimation technique calls for, and in the typical and aggressive cases, more than the PMCis and the call processing system as a whole can actually handle. This overbooking is justified, especially as the number of calls increases and the probabilistic nature of the calls with respect to actual resource utilization (the probabilistic nature of calls, as used herein, means that the resource utilization for each call varies by time and may have any of a finite or infinite number of values within known limits). However, in known systems, the reservation coefficient, although provisionable, is constant within different hours of a day or days of a week, unless a system operator manually alters or updates it.

[0016] Therefore, it would be advantageous in a multiple processor call processing system if critical resource utilization could be better predicted, and consequently more accurate call admission and load balancing decisions could be made without detracting from overall system performance.

SUMMARY OF THE INVENTION

[0017] The present invention is directed in part to techniques for determining the eagerness of a call processing unit within a multiple processor call processing system to accept a new call or call upgrade. The invention is also directed to call admission control and load balancing through query of such eagerness. In particular, fuzzy logic is used to determine the eagerness.

[0018] Accordingly, consistent with one embodiment of the invention, in a call processing unit capable of supporting a plurality of call classes, method and apparatus are provided which includes attainment of first and second load parameters for the call processing unit, fuzzification of the first and second load parameters according to respective first and second fuzzification functions, comparison of the fuzzified first and second load parameters against a defined set of eagerness rules, defuzzification the result of the comparing, and generation of an eagerness to admit a call based on this defuzzification result. The first and second load parameters may include actual and estimated load parameters for the call processing unit. The estimated load may be approximated using a probabilistic distribution function. Homogeneous may also be consulted in determining this eagerness.

[0019] Consistent with another embodiment of the invention, in system comprising plural call processing units, a call admission apparatus and method are provided which includes monitoring a call admission eagerness for each of the call processing units, perception of a call admission request, selection of a target call processing unit having a relative maximum call admission eagerness, confirmation of the call admission eagerness by this target call processing unit with respect to the call admission request, and admission of the call if the target call processing unit eagerness is confirmed. Predetermined or call class malleable thresholding may be utilized to help determine if a target call processing unit is available. Also, another target may be selected if the eagerness cannot be confirmed by the initial target, and may be recursively performed until either no target call processing units are available, the admission request is withdrawn, or the call is successfully admitted.

[0020] Additional aspects and advantages of this invention will be apparent from the following detailed description of embodiments thereof, which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] FIGS. 1A-1C illustrate the concepts of load balancing and homogeneousness consistent with the present invention.

[0022] FIG. 2 illustrates conventional load estimation.

[0023] FIG. 3 illustrates resource utilization modes and probabilities.

[0024] FIGS. 4A-4C illustrate Gaussian characteristics of load estimation consistent with the present invention.

[0025] FIG. 5 is a flowchart illustrating resource knowledge base processing according to an embodiment of the invention.

[0026] FIG. 6 is a flowchart illustrating load estimation processing according to an embodiment of the invention.

[0027] FIG. 7 is a flowchart illustrating load estimation processing according to an alternative embodiment of the invention.

[0028] FIGS. 8, 9 and 10 are flowcharts illustrating eagerness determination processing according to respective alternative embodiments of the invention.

[0029] FIG. 11 is a flowchart illustrating PMCi call event processing according to an embodiment of the invention.

[0030] FIG. 12 is a flowchart illustrating PMC-M call admission processing according to an embodiment of the invention.

[0031] FIG. 13 is a simplified block diagram of a PMCi 1300 consistent with eagerness determination processing shown in FIGS. 8 and 9.

[0032] FIG. 14 is a simplified block diagram of a PMCi 1400 consistent with eagerness determination processing shown in FIG. 10.

[0033] FIG. 15 is a simplified block diagram of a PMC-M 1500 consistent with the PMCi arrangements shown in FIGS. 13 and 14.

[0034] FIG. 16 is a simplified block diagram of a PMC-M 1600 consistent with the PMCi arrangement shown in FIG. 13.

[0035] FIG. 17 is a simplified block diagram of a PMCi consistent with the PMC-M arrangement shown in FIG. 18.

[0036] FIG. 18 is a simplified block diagram of a PMC-M consistent with the PMCi arrangement shown in FIG. 17.

[0037] FIG. 19 diagrammatically illustrates fuzzification of the actual load parameters according to an embodiment of the invention.

[0038] FIG. 20 diagrammatically illustrates fuzzification of the estimate load parameters according to an embodiment of the invention.

[0039] FIG. 21 diagrammatically illustrates fuzzification of the homogeneousness parameters according to an embodiment of the invention.

[0040] FIG. 22 illustrates threshold malleability by cost of service according to an embodiment of the invention

[0041] FIG. 23 illustrates eagerness reporting conservation according to an embodiment of the invention.

[0042] FIG. 24 illustrates a two variable fuzzy logic rules base according to an embodiment of the invention.

[0043] FIG. 25 is a simplified block diagram of a call processing system including plural individual call processing units coordinated by a single managing call processing unit.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0044] Unless otherwise noted, the listed terms below, including abbreviations and symbols, will have the following meaning ascribed to them:

term  meaning
Kbps  kilo bits per second
MIPS  Mega Instructions Per Second
msec  milliseconds
pdf   Probability Distribution Function
pmf   Probability Mass Function
PMCi  individual call processing unit
PMC-M master or managing call processing unit
CoS   Class of Service or allocation-retention priority UMTS
QoS   Quality of Service
UMTS  Universal Mobile Telecommunications System
K     number of PMCis
L     number of inputs to a fuzzy logic
N     number of call classes
R     number of rules in a fuzzy logic
fi    i-th fuzzified value
mi    load in state i
pi    probability of state i
β     CoS coefficient
ε     CAC threshold
γ     activation of a rule
θ     class type
μ     mean
σ     standard deviation
σ2    variance
Θ     nominal load
ζ     probability of exceeding the nominal load 0
φ     eagerness
Φ     eagerness vector
ω     balance target
Ω     balance target vector

[0045] For simplification purposes only, and not meant to limit the teachings of the present invention in any fashion, the disclosed embodiments presumes a single master call processing unit (PMC-M) coordinating several individual call processing units or PMCis (e.g. on the order of 50-60). See, e.g. FIG. 25. Further, each call is presumed follows a probabilistic behavior in accordance with a finite number of predefined states and that that resource utilization associated with such states can be determined.

[0046] In determining whether to admit a new call, one should see if the necessary resource such as processing load or bandwidth for the new call is available. If the resources are available, the new call can be admitted. An important action in packet switching systems with QoS requirement is resource reservation. It means that by admitting each new call, the call processing system or constituent call processing unit should restraint its eagerness to accept more new calls.

[0047] Load Estimation Theory

[0048] As previously discussed, if the reservation is made based on the maximum possible resource utilization or a relationship that disregards or oversimplifies the number of actual calls and their probabilistic nature, the efficiency of the call processing system will be less than optimal. Hence, consistent with one aspect of the present invention, the disclosed embodiments of the present invention utilize a probabilistic estimation of the load, based on the mean and variance of the resource utilization for a given call type and experienced call distribution.

[0049] In particular, the call processing system according to a specific embodiment generates a probability distribution function (pdf) of the total resource usage. Then based on this pdf, this call processing system calculates the probability of exceeding a nominal load value on a per call processing unit basis. This probability should be kept lower than a given threshold, by rejecting some calls if they are coming at the time of heavy load. So, in CAC and load balancing consistent with the present invention, this probability gives this call processing system a measure to accept or reject the new call or, if sufficient capacity exists at the system level, to determine which PMCi should handle the call.

[0050] To ease understanding, one or more of the disclosed embodiments selectively perform “static” load balancing of the call processing system based at least in part on the aforementioned estimated load results. Such load balancing seeks to make load balancing decisions (which call processing unit, if any?) with respect to a call only during admission of the call. However, the teachings of the present invention are not intended to be so limiting, and, as will be appreciated by those ordinarily skilled in the art, can be easily applied to dynamic load balancing of calls where, in addition to balancing at admission, calls can be transferred from one call processing unit to another on fly. See, e.g. Willebeek-LeMair et al., “Strategies for Dynamic Load Balancing on Highly Parallel Computers”, IEEE Transactions on Parallel and Distributed Systems, Vol. 4, No. 9, September 1993 incorporated herein fully by reference.

[0051] In the disclosed embodiments, assume that an individual call processing unit or PMCi can handle a limited number of call types or classes of service: θ1 . . . θN. Each class has a different set of QoS requirements.

[0052] For each call type or class, there is basically a different probabilistic pattern. The probabilistic pattern identifies the probability (or percentage) of being in a set of discrete states or modes (active/non active or silence/speech, for example). Assuming there is usually 1 to 3 discrete states and that the resource usage in each state individually is known through empirical data, predictive analysis, or otherwise. For example, in packet voice conversation, there are two basic states: silence and speech. The probabilities of being in each one of these two states is p1 and p2, where p1+p2=1. The resource utilization for each state is m1 and m2, respectively. The goal is to estimate the load (resource utilization) based on the a priori knowledge about these classes and the number of existing calls in each type or class. The probabilistic behavior of the calls is usually reflected in the active/silence mode of voice or the burstiness (of data).

[0053] For discussion purposes only, assume the call types or classes to be conversation (mainly voice), streaming, interactive (web data), and background (email), as listed below. In other embodiments, other call types such as fax, telecommands, etc may be considered as will be appreciated by those ordinarily skilled in the art.

	call type	p1	m1	p2	m2
	conversation	60%	12.2 Kbps	40%	1.95 kbps
	streaming	100%	128 Kbps	0	0
	interactive	10%	128 Kbps	90%	0
	background	100%	128 Kbps	0	0

[0054] For illustration purposes, bandwidth is presented in the above chart as the required resource. However, as will be discussed in more detail below, the processing load or CPU consumption of a PMCi will be also be used, as it can be the more the scarce type of call processing resource, especially in larger call processing environments.

[0055] As an example, FIG. 3 depicts a discrete probability mass function (pmf) of one call within a type/class (say, the voice class, here). The horizontal axis represents the resource requirement, here bandwidth expressed as a bit rate. As shown in the FIG., the probability that the resource requirement 300 will be in discreet state 1 (i.e. silence) is 40%, with a characteristically low resource requirement 302 (m1) of 1.95 Kbps. Likewise, the probability that the resource requirement 300 will be in discrete state 2 (active conversation) is 60%, with a characteristically higher 12.2 Kbps bandwidth requirement 304 (m2). Likewise, the probability.

[0056] In the following subsections, we first show how to obtain the pdf of a number of calls in each class and then we obtain the pdf of the total load within a PMC. The mean and variance are calculated as follows:

μ=p1·m1+p2·m2=8.1 kbps.  (4)

[0057] And the variance is:

σ2=p1·(m1−μ)2+p2·(m2−μ)2=25.21.  (5)

[0058] Which yields a standard deviation of σ=5.02.

[0059] The well-known central limit Theorem states that “by summing up a sufficient number of independent stochastic variables, we get a new variable, which has a Gaussian distribution”. This approach has been already used for connection admission for satellites as described in Yeong Min Jang's “Central limit approximation approach for connection admission control in broadband satellite systems”, IEE Electronics Letters Vol. 36, No. 3, Feb. 3, 2000 incorporated herein fully by reference. The mean and variance of this Gaussian distribution are easily calculated as follows: 2$\begin{array}{cc}{\sigma }^2=\sum _{i=1}^N{\sigma }_i^2& \left(6\right)\\ \mu =\sum _{i=1}^N{\mu }_i& \left(7\right)\end{array}$

[0060] Where μ1 and σ2i are respectively the mean and variance of one call. As a result, if we keep the example of the previous subsection, by adding N calls, the mean and variance will be: μ=8.1*N Kbps and σ2=25.21*N. For instance, N=100 gives μ=8100 Kbps and σ2=50.21 Kbps.

[0061] The mean value calculated here for the total distribution is simply the sum of all the average values. The variance is also the sum of the variances attributed to all of the calls. When, for example, 100 calls of one type together, the mean value gets 100 times bigger; so does the variance; however, the standard deviation, σ, gets only 10 times bigger. This means that the more calls are added up in a PMCi, the bigger is the mean and the standard deviation, but the smaller would be their ratio μ/σ2. A generalized plot of the probability distribution function in accordance with this algorithm is shown in FIG. 4B, with the μ 406 and the σ 408 denoted.

[0062] It should be noted that this algorithm is an approximation that becomes more accurate for larger values of N. However, this approximation is believed good enough in providing an estimated load commensurate with the goals of the invention. In fact, a well known method to construct a random variable with Gaussian distribution is to add N (usually 12) random variables with uniform distribution (such as using rand( ) in the “C” programming language).

[0063] Alternatively, the exact form of the distribution can be obtained by applying N times convolution of the original pdf with itself. The more accurate calculation is that for this case, the distribution of the sum is a series of impulses at i*m2+(N−i)m1, where 0<=i<=N. The probability at each point is CNi·p21p1N−1, as shown in FIG. 4A. The absolute maximum 402 and minimum 404 possible values for x are respectively N*m1, N*m2 or 1220 Kbps to 195 Kbps in the example where N=100 as described above.

[0064] Though not implemented in the embodiments disclosed below, there is another point here which applies to the classification of the calls in different classes. Some calls, for some reasons may have different resource usage than others, although they may be in the same class. For instance, a voice call may have “A” times processing power requirement than others, because of the special conditioning or additional processing to be applied to the call, such as silence suppression or ciphering. Therefore, provision may made to count such a call A times more than “an ordinary call”.

[0065] The next step is to add the variables obtained in each class, to obtain the pdf of the whole resource usage in all of the classes for a given PMCi. Again, the central limit Theorem implies that “the sum of any number of variables with Gaussian distribution, is a new variable with a Gaussian distribution.” The mean and variance of the new variable can be simply obtained by summing up the mean and variances of the elements.

[0066] As discussed above, the total pdf has a mean and a variance that can be obtained from simple arithmetic. The pair of values (mean, standard deviation) are the only parameters we need when using the Gaussian distribution's error function. In FIG. 4C, which again shows a Gaussian approximation of the probability distribution function, Θ 412 (maximum allowable resource utilization or nominal load) and ζ 414(probability of exceeding the nominal load—the hatched area 412 under the curve410) defined such that: p(x>Θ)=ζ.

[0067] For each PMCi, based on the current number of the admitted calls in each class, we can calculate the probability of having the total resource usage exceeding the maximum allowable value set for the resource (say for example, 2 Gbps for bit rate or 99% of CPU usage). In other words, we can determine the probability of having the total resource utilization for a PMCi exceeding the nominal load specified for that PMCi.

[0068] Alternatively, having a provisioned tolerable probability for exceeding the nominal value, we can determine for each PMCi, whether the value corresponding to this probability is smaller or greater than the maximum allowable resource utilization.

[0069] A load estimation algorithm according to an embodiment of the invention, based on the statistical analysis and Gaussian distribution discussed above will now be disclosed. Unlike the above, however, the scarce resource is now processing load (in the unit of instruction cycles/sec or any other measure of processor utilization within a call processing unit)

[0070] In each one of the N classes (here N=4 for voice conversation, streaming, web data interactive and streaming), assume that there are two modes: active and non-active. The probability of being in each state is also considered to be known (p1, p1, respectively). The ratio p1/p2 is a main characteristic of each class. It should be understood that this is a simplifying assumption to have only two modes (active and non-active) and that in reality, more than two modes might be possible. However, this does not affect the disclosed algorithm as long as one can translate these numbers to form a Gaussian distribution with a known μ, σ2.

[0071] The first action is to measure the number of instruction cycles/sec (processing resource utilization) corresponding to each of the two modes: active and non-active for given call class or type. These two parameters are known as m1 and m2. Note here that there are however a number of other parameters that affect the number of instruction cycles being used to support the call mode. These parameters may include some or all of the following parameters in an e.g. UMTS call processing environment, including:

enum     TTI (10, 20, 40, 80 msec.)
boolean  CRC
boolean  Ciphering (on or off)
enum     RLC_mode (TM, AM, UM)
boolean  PS/CS
int      No_of_RL (1 <= No_of_RL <= 6 but usually 1, 2, or 3)
int      No_of_TB
int Rate (up to 2 Mbps)

[0072] The term PS here refers to Packet Switching and CS refers to Circuit Switching. The Boolean PS/CS indicates whether a UMTS call is either packet or circuit standard respectively. The CRC Boolean indicates whether Cyclic Redundancy Coding is used with a given UMTS Call. RLC_mode refers to the UMTS radio link mode associated with a call (TM: transparent mode; AM: acknowledged mode; and UM: unacknowledged mode). TTI refers to the Transmission Time Interval. The No_of_TB refers to the number of traffic bearers. Finally No_of_RL refers to the number of UMTS radio links available for the UMTS call.

[0073] A fast look at these parameters may suggest that the actual number of classes is more than what was assumed above (here N=4). However, despite the fact that based on the actual values of these parameters some of the statistical characteristics of the call varies, some others remain intact. The ratio p1/p2, for instance does not change and, that in most cases, both m1, m2 are assumed to change proportionally. Once more, as will be appreciated by those ordinarily skilled in the art, this is a simplifying hypothesis which may inject some inaccuracy in the modeled probability distribution function. However, as will be discussed below, fuzzy logic may be conveniently implemented to interpret this statistical model such that simplification inaccuracies will not deter from arriving as a correct result.

[0074] First, for each class of call (say voice conversation for example) consider a set of given call parameters such as:

TTI	CRC	Ciphering	RLC_mode	PS/CS	No_of_RL	No_of_TB	Rate
20	0	0	TM	CS	3	1	12.2
msec							Kbps

[0075] Then, based on these parameters, m1 is obtained for the active mode and m2 for the non-active mode. Next, a different set of parameters is assumed, which results in a new ({overscore (m)}1, {overscore (m)}2) pair. By making the assumption that m1/m2 is close enough to {overscore (m)}1/{overscore (m)}2 for load estimation purposes consistent with the present embodiment, classification is greatly simplified. The rational behind this assumption is twofold: first, it appears that most of these parameters influence the complexity in the same way. And second although some inexactitude may be encountered with this assumption, in average it will not be a big problem. Finally, the resulted simplification is worth this small inexactitude.

[0076] As a result, in accordance with the present embodiment, one can characterize a class with 2 states or modes, each with associated probabilities (p1, p2) and corresponding resource requirements (m1, m2) which can be obtained directly through empirical measurements. Several combinations of the call parameters discussed above are considered and for each set the load is measured. Then an algorithm may be used to fit a function to those parameters. The derived mode probability and resource requirements in turn give the representative pair of μ, σ2 as described above.

[0077] Consider the following table showing a restrained number of the combinations of the call parameters (ciphering Y/N, CRC enabled Y/N) in an UMTS multiple processor call processing system:

	call type	ciphering	CRC	μ	σ2
	conversation	y	—	2.496	0.000864
	″	—	y	2.066	0.000024
	″	—	—	1.900	0.000000
	streaming	y	—	4.110	0
	″	—	y	3.250	0
	″	—	—	3.120	0
	interactive	y	—	1.374	0.831744
	″	—	y	1.279	0.431649
	″	—	—	1.257	0.385641
	background	y	—	4.110	0
	″	—	y	3.250	0
	″	—	—	3.120	0

[0078] Although not presented herein, more columns in this table should be provided which represent other parameters having some influence on the values of μ, σ2, such as the bit rate, or the number of radio links in a wireless system (e.g. 1-6 links in a UMTS system). Additionally, other real world factors may be considered and the resource requirement algorithm made more complex to accommodate such factors. For example, in a wireless call processing system implementation, the number of radio links which has also a probabilistic character may be investigated. In such a case, the variances obtained will be substantially higher for conversation calls, and not necessarily zero for streaming calls.

[0079] When more extensive parameter combinations are considered, a neural network be may employed to make this function fitting, when more combinations are considered. See e.g. Bernard Widrow et al., “30 Years of Adaptive Neural Networks: Perceptron, Madaline, and Backpropagation”, Proceedings of the IEEE Vol. 78, No. 9, September 1990 which is incorporated herein fully by reference. The well known error backpropagation algorithm can be used to train the neural network and the resulted neural network will be optimized to have the smallest error for the set of empirical measurements. The generalization characteristic of the neural network acts so that it will have good performance for the sets of parameters out of its training set, as well. In case that one uses a neural network with no hidden layer, this solution simplifies to a linear combination but by having at least one hidden layer and nonlinearity in it, very complex nonlinear functions can also be approximated. A table outlining load estimation based on capacity measurement & Gaussian distribution with ciphering:

		m1		m2	Mean	standard dev
Call Type	p1	(MIPS)	p2	(MIPS)	(MIPS)	(MIPS)
Conversional	60%	2.520	40%	2.460	2.496	0.0294
Streaming	100%	4.110	0%	0	4.110	0
Interactive	10%	4.110	90%	1.070	1.374	0.912
Background	100%	4.110	0%	0	4.110	0

[0080] Though not considered above, it should be noted that a class of service (“CoS”) dependent parameter β can be multiplied to mean and variance for each call, which will reflect the importance of each class, or alternatively, call allocation or retention priority as contemplated within a UMTS communications system. For example, in “gold”, “silver” and “bronze” classes of service, we can have β=1.4, 1.2, 1 respectively. This will mean that there will be higher estimated resource requirements and consequently more resource reservation performed for calls in higher classes compared to the calls in lower classes.

[0081] In this embodiment, it is envisioned that each PMCi manages a table of its admitted calls including call type or class, μ, σ2 either within the admitted call table or as part of a separate resource knowledge base. Consider the following admitted table with class mean and variance individually specified:

call #	class	μ	σ2
0	voice
1	stream
2	data
3	voice
. . .	. . .	. . .	. . .
T	email

[0082] The call type is simply the indicator of one of the N classes. For each class we make a summation over the μ, σ2 values, namely μ(conversational), μ(streaming), μ(interactive), μ(background). For instance, μ(conversational)=sum of μ's for all conversational calls in this PMC. The variance σ2 of each class is obtained in the same way. Finally, total μt, σ2t for the PMC are obtained by summing the μ, σ2 for all the classes. The values of μt, σ2t can be updated once a new call is admitted or an existing call is terminated (or modified) by simply adding or subtracting the corresponding μc, σ2c.

[0083] When the call's parameters are changed, new mean and variance are calculated and put in the table but before that the old values are subtracted from the sums. There is no need to rebuild the μt, σ2t values from scratch each time, though such processing is contemplated below with reference to FIG. 7. Thus, the following rules may be established: 1) the initial values of μ, σ2 (for all classes) are zero. 2) Upon the admission of a new call, the values of μ, σ2 are increased. 3) Upon termination of each call, the values of μ, σ2 are decreased. And, 4) upon alteration of each call, the values of μ, σ2 are first decreased by the old value from the table and then increased by its new value.

[0084] In this stage, for each class, c, we have the corresponding μ(c), σ2(c). We add these values over all the classes to obtain one μt, σ2t pair representing the whole load on a PMC.

[0085] By calculating μt, σ2t, we know all that we need to know about the distribution. Usually we want to calculate the probability, ζ, of exceeding a nominal value of the resource usage, Θ. 3$\begin{array}{cc}\zeta =\frac{1}{2}\mathrm{erfc}\left(\frac{\Theta -\mu }{\sigma \sqrt{2}}\right)& \left(8\right)\end{array}$

[0086] where erfc(·) is the complementary error function of a normal distribution (a built-in function call in “C” and also implementable as a look-up table).

#include “math·h”

double y=erfc((Theta−mean)/(sqrt(2)*stdev))/2;

[0087] Where Theta, mean, stdev respectively stand for Θ, μ, σ. This function can be kept in a table, for simplicity. The following table lists the value of error probabilities ζ for the various (Θ−μ)/σ. For example, we see that for having a ζ=1%, Θ should be equal to μ+2.33*σ. At μ+5*σ, ζ is practically zero.

ζ          (Θ-μ/σ)
10%        1.28
5%         1.65
3%         1.88
2%         2.06
1%         2.33
0.05%      3.30
0.0000287% 5.00

[0088] Either value can serve as a guideline to decide either to accept or to reject a new call. The use of this estimate, along with some other estimates is the subject of the next section where we explain a fuzzy logic controller for this effect and we show how to use this parameter along with a couple of other ones to determine the eagerness of each PMC to receive a new call. It is also noteworthy that since ζ is an input to a fuzzifier, we can simply directly feed (Θ−μ)/σ to the fuzzifier.

[0089] What's our a priori estimation of the total σt/μt? The intervening parameters are multiple: first the number of calls in each class and second the characteristic that we consider for each class. For instance the more calls of streaming type we have, the narrower is the Gaussian distribution. Below we examine a few examples.

[0090] In the following examples, we give some numerical values to the different classes of calls and at the end verify the aggregated traffic.

EXAMPLE 1

Conversation Class

[0091] Let's assume that we have only 150 voice calls.

μ=p1·m1+p2·m2=2.496MIPS  (9)

σ2=p1·(m1−μ)2+p2(m2μ)2=864.36M, so σ=20.4KIPS  (10)

[0092] Then μt=374.4 MIPS and σ2t=1.29654*1011 and σt=360KIPS. In other terms, in this scenario, we have a narrow Gaussian distribution, in part because of the big number of voice calls that we consider.

EXAMPLE 2

Streaming Class

[0093] For streaming, the situation is simpler, because basically we have p1=1 and p2=0. So σ2=0 and the problem is not probabilistic anymore. Considering 5 streaming calls with m1=4.11 MIPS, we have μt=20.55 MIPS and σt=0.

EXAMPLE 3

Interactive Class

[0094] Data, however, has usually a more probabilistic manner, as we may experience bigger σ2 values for data. Here, we just create an example for data:

p1=0.1, p2=0.9  (11)

m1=4.11MIPS, m2=1.07MIPS  (12)

μ=p1·m1+p2·m2=1.374MIPS  (13)

σ2=p1·(m1−μ)2+p2·(m2−μ)2=831744MIPS, so σ=0.912MIPS  (14)

[0095] If we consider 20 data calls, it comes to μt=27.48 MIPS and σ2t=16.6312. and σt=4.078 MIPS.

EXAMPLE 4

Aggregated Traffic on a PMCi

[0096] By adding all the voice, streaming and data calls in the three previous examples, we calculate μt, σt as in the following table. In the table, we give also the mean and standard deviation values for some other numbers of different types of calls.

Convers.	streaming	interact.	backgr.	μ	σ	ζ
150	5	20	0	422.43	4.093 MIPS	0
				MIPS
20	5	150	0	275.49	11.170 MIPS	0
				MIPS

[0097] Consider that the total permitted instruction cycles on the board is Θ=450 MIPS. This means that the probability of exceeding Θ from the above-mentioned formula is practically zero ζ=0. In fact, ζ can be reasonably assumed to be zero for μt=5σt=442.9 MIPS.

[0098] Call Admission Control (“CAC”) and Load Balancing

[0099] In this section, CAC decision and the load balancing according to several distinct embodiments are explained. The CAC decision is made in two steps: the initial step where the PMC-M make a guess on the best PMCi able to handle the call based on reported eagerness. An early CAC algorithm can be included here for assisting the managing call processing unit make the decision of either to accept or to reject a call, if none of the PMCis are eager enough to accept the new call. In the second step, the chosen PMCi itself reviews if it is really in the state of accepting the call or not. Consistent with these embodiments, fuzzy logic is used in parts of both processing to arrive at CAC and load balancing decisions.

[0100] The disclosed embodiments all try to even the load on the individual PMCis to reduce risk of overloading and underloading PMCi capacity, as well as enhance efficient use of scarce and expensive processing resources. In addition, several of the disclosed embodiments attempt to homogenize the load among the PMCi's. Homogenizing herein means that the ratio between the effect of different types and service classes be approximately the same in all PMCi's. In other words, if half of the total load (in all PMCi's) in the call processing system is voice, the same ratio is maintained in all PMCi's. By doing so one equalize the chances of exceeding the nominal load in all PMCis.

[0101] The following arguments explain why a homogenous load is advantageous: (1) various classes have different types of QoS requirement. For instance some are more sensitive to delay and some are more sensitive to discard. By having a homogenous load, that is assurance that those natural differences can be handled by the PMCi's. In contrast to this, if all delay sensitive calls are in one PMCi, and all non delay sensitive calls in another PMC, there will be little if any flexibility for any special case handling technique to operate successfully—for instance, the PMCi having all delay sensitive calls can not handle the situation by delaying some of the calls.

[0102] The disclosed models supporting these embodiments are based on a partial knowledge of the system; modeling for some classes is better than for others. By having a homogenous load, one avoids that most of the inexactitude because of the inaccurate modeling fails to gather in a single PMCi and increase estimate inaccuracies disproportionately.

[0103] Finally, as different classes of calls have different variances for their pdf's, if one forces an evenly distributed load is enforced but not necessarily load homogeneity, a call processing system may end up in a situation where for some of the PMCi's the probability of exceeding the nominal value is small but for some others, it is not. This would be the case, for instance when most voice calls go to one PMCi; most data to one and most streaming and background each to another PMCi. As streaming calls have insignificant variance, they show a very narrow pdf, while interactive calls show very large variances.

[0104] Though not disclosed as part of the specific embodiments, other criteria may be also important and should be considered as will become apparent to those ordinarily skilled in the art. For instance, consider the ability to maintain the QoS of existing calls (delay, BER, dropping). This means that there would be a feedback from the overload module to the CAC (and load balancing) functions. If a given PMCi experiences packet discard, or excessive delay (for delay sensitive calls), the PMCi should be marked as to be less eager to accept new calls. This concept introduces some kind of adaptability to the system.

[0105] Moreover, consider time of the day/week in which the call is or intended to take place. Also, the time span of a call: a voice call has an average duration of about 90 seconds while some interactive and streaming calls may have much longer durations. This fact may also be considered as an input to the CAC and load balancing decisions.

[0106] Consistent with one or more embodiments of the invention and based on the following parameters that are available about each PMCi, an initial guess on CAC and the optimum PMCi is selected based on: 1) the ensemble of calls which yield the pdf (μ2, σ2t) in each PMC; 2) the periodically updated measurement of the PMC loads; and 3) the QoS type and CoS (requirements of the new call).

[0107] In the disclosed embodiments, a resource knowledge base (e.g. knowledge base 1310 in PMCi 1300 shown in FIG. 13 or knowledge base 1310 in PMC-M 1800 shown in FIG. 18) is used to retain call class mean and variance information, either for a specific PMCi or the PMC-M. Resource knowledge base development according to an embodiment of the invention will now be detailed with reference to FIG. 5. Assembly of this knowledge base may be performed upon call processing unit installation, upgrade or other change, or on an as-needed basis when the types of supported call classes change.

[0108] Referring to FIG. 5, control first passes to step 510, in which the operational modes for the supported call classes of interest are determined. This may constitute all of the supported classes if the knowledge base is being assembled from scratch, or a subset thereof when only certain call class information needs to be corrected or updated. As mentioned above, each supported call class most likely have at least two discrete states of operation, as in the example of “active” and “silence” for the voice call class. Control thereafter passes to step 512, in which resource utilization or each of the operational modes as well as the probability of being in such operational mode is then obtained. Such resource utilization and probabilities information may be obtained through empirical measurement of actual call conditions or predicted using appropriate predictive techniques, as described herein or as is well known in the art. Thereafter, in step 514, the mean and variance for each of the call classes of interest will be calculated using the obtained resource utilization in operational mode probabilities obtained in step 512. Thereafter, in step 516, the knowledge base of supported call classes is updated with the new mean variance information. Knowledge base creation or update processing according to the present embodiment then terminates naturally.

[0109] Load estimation performed by either the interested individual PMCi call processing unit (see e.g. load estimator 1330 in PMCi 1300 of FIG. 13 or the load estimator 1430 in PMCi 1400 of FIG. 14) or the master PMC-M call processing unit (e.g. see the load estimator in the resource utilization unit 1850 in the PMC-M 1800 of FIG. 18) according to an embodiment of the invention will now be described with reference to FIG. 6. Here, the estimated load is recalculated every time a call event such as a new call admission, an admitted call termination or an admitted call classification modification event has occurred with respect to an individual call processing unit, whether or not responsive action is taken by that individual call processing unit or the master call processing unit. More particularly, the current collective mean (μt) and variance (σ2t) values which are used to generate the estimated load measure for a particular PMCi (e.g. PMCp) are selectively updated upon detection of a call event involving such PMCp, by either the PMC-M or the PMCp as well as the particular type of call event.

[0110] Turning now to FIG. 6, processing begins at step 602, in which a determination is made whether the detected call event involves a new call admission request. If so, control passes to step 608 in which a “new” estimated load mean and variance for the involved individual call processing unit, e.g. PMCp, is determined by adding the requested “new” call class (θx) load mean μ and variance σ2 values to the current estimated load mean (μt) and variance (σ2t) values for the entire PMCp as specified in the resource knowledge base corresponding to the PMCp. It should be noted that this is made possible through application of the central limit Theorem discussed above. Thereafter, control passes to step 610 in which the load estimator determines the estimated load measure (e.g. ζ(p) or x2(p)) based on the new estimated load mean and variance values calculated in step 608.

[0111] If, however, in step 602, a determination is made that the detected call event does not specify a new call admission request, control instead passes to 604. In step 604, a determination is made whether the detected call event specifies an admitted call termination request. If so, control passes to step 606, in which the new mean and variance values for the estimated load are calculated by subtracting the class load mean and variance values associated with the terminated call, as contained in the corresponding resource knowledge base, from current estimated load mean and variance values. Thereafter, control passes to step 610, where again the estimated load measure is determined based on the new mean and variance values for the estimated load as calculated in step 606.

[0112] If, however, in step 604, a determination is made that the detected call event in step 604 does not specify an admitted call termination event, control instead passes to step 612. In step 612, a determination is made whether the detected call event specifies an admitted call class modification request. Call class modifications, such as in-process call upgrades or downgrades, can be specified for an admitted call. Examples include requesting a call type modification (such as from voice to data) for an existing call, a call class modification within a common type (such as from interactive data type call to a streaming data call or requesting a transition in class-specific call parameter (such as the toggling the presence or absence of ciphering in voice calls or changing the bit rate for data calls). If the detected event specifies a call class modification event , control passes to step 614, in which the new estimated load mean and variance values are calculated by first subtracting the existing call class load mean and load variance values as specified in the resource knowledge base for the call currently undergoing modification and subsequently adding the new class mean and load variance values in the resource knowledge base specified for the call class the call of interest is evolving into. Control thereafter passes to step 610 in which again the estimated load measure based on the new estimated load mean and load variance for the entire processing unit is determined.

[0113] It should be noted that the estimated load measure may comprise any number of values suitable to quantatively represent the estimated load, including the aforementioned probability of exceeding a nominal load—ζ(p)—or a ratio between the nominal load and the estimated load mean, equation x2(p) mentioned above. Alternatively, other expressions of the estimated load measure may be used as would be understood by those ordinarily skilled in the art.

[0114] Once the estimated load measure has been determined, control thereafter passes to step 620 in which an estimated load parameter corresponding to, or at least based on, the estimated load measure is issued by the load estimator of interest. The estimated load parameter is used by the PMCp and/or by the managing call processing unit PMC-M to help undertake eagerness determination and ultimately load balancing and call admission control according to the disclosed embodiments. Thereafter event driven load estimation updating terminates naturally.

[0115] Load estimation according to another embodiment of the invention will now be detailed with reference to the flowchart of FIG. 7. In this embodiment, current load estimation is calculated based on the call information contained in the admitted call table at a particular time (e.g. time X in the figure). Referring to FIG. 7, control initiates at step 702, in which a distribution of the call classes in the admitted call table (such as table at a given time X is made). This distribution identifies how many calls within a given call class are contained in the admitted call table. This distribution is used to help develop an estimated load mean and load variance value for the entire call processing unit based on the class distribution. Control thereafter proceeds to step 704, in which the estimated load mean (μt) and variance (σ2t) for the entire call processing unit PMCp is calculated using the class distribution obtained in step 702 along with the class load mean and variance values contained in the resource knowledge base. In particular, this is done by multiplying the number of calls in the class as recorded in the class distribution by its associated class load mean and variance values contained in the resource knowledge base corresponding to the call processing unit of interest. This is done for each class represented in the class distribution calculated in step 702. Thereafter, in step 706, the estimated load measure (e.g. ζ(p) or x2(p)) based on the new estimated load mean and new estimated load variance for the call processing unit PMCp is determined. As such, information may be used to generate the eagerness or willingness of the PMCp to accept new calls or call upgrades. Thereafter in step 708 in this embodiment, an estimated load parameter based on the aforementioned load measure is then issued for further processing, including eagerness determination for the PMCp of interest. Thereafter load estimation calculation according to this alternative embodiment terminates.

[0116] Eagerness determination processing according to an embodiment of the invention will now be detailed with reference to FIG. 8. In this embodiment, the eagerness φ(p) of a given individual call processing unit PMCp is generated with respect to fuzzy logic analysis of the actual load x1(p) and estimated load (ζ(p) or x2(p)) parameters for the PMCp. In this embodiment, homogeneousness of the PMCp is not taken into consideration. Such eagerness processing may be conveniently undertaken within the PMCp itself, such as within the resource utilization and fuzzy logic units 1320, 1325 of the PMCi 1300 shown in FIG. 13. Alternatively, such processing may be carried out on the behalf of the PMCp by the master call processing unit, such as through the resource utilization and fuzzy logic units 1850, 1860 of the PMC-M 1800 shown in FIG. 18, although in such case input from the weighting engine 1640 would not be utilized, nor would x3(p) be realized by the resource utilization unit 1850.

[0117] Turning to FIG. 8, eagerness processing within this embodiment begins at steps 812 and 810 in parallel, in which the actual load parameter x1(p) is generated by the e.g. the load monitor 1325 shown in FIG. 13 (step 812) and the estimated load parameter (ζ(p) or x2(p)) is generated by e.g. the load estimator 1330 shown in FIG. 13 pursuant to load estimation described above with reference to FIG. 6 or 7. Control thereafter passes to steps 814 and 816 in parallel, where these actual and estimated load parameters are each fuzzified into respective fuzzy logic states representative of the conditions they quantify, such as through fuzzifier 11342 and fuzzifier 21344 respectively.

[0118] In particular, the first fuzzifier 1342 acts on the actual load parameter x1(p). For each PMCi(p), x1(p) is compared to Θ(p) which is the nominal load for the PMCp in terms of its information processing resources or CPU MIPS. A value of 0 for x1 means absolutely no load; x1=Θ means fully loaded. Referring to the membership response curve employed by the first fuzzifier 1342 shown in FIG. 19, Θ(p) 1960=450 MIPS, and five discrete membership states are specified: vl (very low) 1910 associated with a range between 0 and 150 MIPS, lo (low) 1920 ranging from 50 to 250 MIPS, me (medium) 1930 ranging from 150 to 350 MIPS, hi (high) 1940 ranging from 250 to 450 MIPS, and vh (very high) 1950 ranging from 350 to Θ(p). Note that utilizing measured load values normalized to the nominal load Θ(p) of the PMCp, where x1(p)/Θ(p) ranges from 0 to 1 may be alternatively used with equal results, and may be advantageously implemented in a call processing environment including PMCis of mixed resource capacities (such as differing CPU resources). An efficient use of the PMCp resources dictates the need to keep f1(p) in “hi” region.

[0119] To simplify fuzzifier design in this embodiment, first fuzzifier 1342, along with the second fuzzifier 1344 and the third fuzzifier 1448 (FIG. 14) are designed such that: 1) at most two fuzzy variables will have non zero values for the same input; and that the sum of the membership functions of all fuzzy variables for each input value would be 1. However, other configurations can be used without departing from the teachings of the present invention.

[0120] Thus, referring to FIG. 19, assuming that x1(p)=400 MIPS, the output f1(p)of the first fuzzifier 1342 would be f1(p)={(vl=0), (lo=0), (me=0), (hi=0.5), (vh=0.5)}.

[0121] As shown in FIGS. 13 and 20, the second fuzzifier 1344 acts on the load estimation parameter x2(p), or, alternatively, the probability of exceeding the nominal load (ζ) directly, where ζ itself is obtained from the Gaussian distribution error function explained above. To ease design of the second fuzzifier 1344, however, x2(p) may be preferred, wherein x2(p)=(Θ−μt)/σt, where σt=standard deviation of μt, or |σ2t)|1/2. Similar to FIG. 19, FIG. 20 illustrates the membership response curve for the second fuzzifier 1344, which again defines five discrete membership states or fuzzy result values vh 2010, hi 2020, me 2030, lo 2040, and vl 2050. Here, if assuming that μt=300 MIPS, σt=100 MIPS and Θ=450 MIPS, x2(p)=1.5, and f2(p)={(vh=0.5), (h=0.5), (me=0), (lo=0), (vl=0)}. Alternatively, the probability ζ in this instance=6.68%.

[0122] In another example, if ζ(p) is very small (approaching 0), f2(p)is “vl”. In yet another example, if x2(p)=4.5, ζ(p)=3.39767*10−6 and then f2(p) is both “lo” and “vl” with a membership function of 0.5.

[0123] Returning to FIG. 8, once fuzzification steps 814 and 816 have been carried out, control passes to step 820, wherein an inference mechanism such as a rules base, part of the PMCi load balancing fuzzy logic 1346 in FIG. 13 or the fuzzy logic unit 1860 of the PMC-M 1800 of FIG. 18, applies a finite series of rules against the possible combinations of the f1(p) and f2(p) in order to arrive at a rules result. E.g., if rule #0: if (f1=vl) & (f2=vl) then eagerness0=1 . . . rule #R-1: if (f1=vh) & (f2=vh) then eagernessR-1=0, where eagerness0, . . . , eagernessR-1 are the rules results from the application of each individual rule. The final eagerness φ(p) is a weighted average of all rules. In this embodiment, though not required, for each combination of f1(p) and f2(p), there is one rule specified. FIG. 24 illustrates, in the form of a lookup table, rules results based on the possible combinations of f1(p) and f2(p). Here, an individual rules result approaching 1 indicates that the PMCi is very eager to accept a new call or call upgrade, and an individual rules result approaching 0 indicates that the PMCi of interest is not eager at all to accept a new call or call upgrade. Dashed line 2410 represents the threshold to the right of which the individual PMCi(p) decides to reject the call admission or upgrade. The rules are determined with a “common sense” logic, for each different case.

[0124] Still referring to the flowchart of FIG. 8, once the rules results are obtained in step 820, these rules results are “deffuzified” to obtain the eagerness of accepting a new call or a call modification upgrade φ(p), which again may be conveniently carried out by the fuzzy logic units1346, 1860. In particular, an averaging algorithm called “centroid defuzzification” may be utilized (also known as “center of gravity” defuzzification). The formula for the deffuzification is as follows: 4$\begin{array}{cc}\phi \left(p\right)=\frac{\sum _{i=1}^R{b}_{i}x\gamma \left(i\right)}{\sum _{i=1}^R\gamma \left(i\right)}& \left(15\right)\end{array}$

[0125] where bi is the center of the membership function recommended by the consequent of rule i; γ(i) is the certainty of rule i; R is number of rules. 5$\begin{array}{cc}\gamma \left(i\right)=\prod _{j=1}^L{f}_i\left(j\right)& \left(16\right)\end{array}$

[0126] where f1(j) is the membership (fuzzified value) of the input j to the condition of rule i and L is the number of conditions to each rule (the same as the number of inputs of the fuzzy logic; 2 in our case). Because of our assumption that the sum of memberships for any given input is equal to one, this formula simplifies as: 6$\begin{array}{cc}\phi \left(p\right)=\sum _{i=1}^R{b}_{i}x\gamma \left(i\right)& \left(17\right)\end{array}$

[0127] As a result, we can simply calculate the center of gravity of all the rules: 7$\begin{array}{cc}\phi \left(p\right)=\frac{\sum _{i=0}^{R-1}\mathrm{activation}\left(i\right)\times {\mathrm{eagerness}}_i}{\sum _{i=0}^{R-1}\mathrm{activation}\left(i\right)}& \left(18\right)\end{array}$

[0128] Where activation(i) denotes the product of the membership functions of the inputs of the rule i. For instance,

activation(0)=(f1=vl)*(f2=vl)

activation(R-1)=(f1=vh)*(f2=vh)

[0129] In either case, the final output is also a fuzzy variable, as a result, the eagerness has always a value between 0 and 1.

[0130] Once φ(p) is obtained, eagerness determination processing according to the embodiment of FIG. 8 terminates.

[0131] To illustrate further, consider the following example:

[0132] PMCp, where Θ=450MIPS, μt=434.85 MIPS, σt2=56.11 MIPS

[0133] measured PMCp CPU load at time t=x1(p)=270 MIPS

[0134] x2(p) at time t=(Θ−μt)/σt=2.02

[0135] referring to FIG. 19, vector f1(p)={0,0,0.6,0.4,0}

[0136] referring to FIG. 20, vector f2(p)={0,0, 0.022, 0.978, 0}

[0137] applying rule combinations of FIG. 24, the following activation results are implicated (i.e.nonzero result):

[0138] (f1=me)*(f2=me)=0.6*0.022=0.013

[0139] (f1=me)*(f2=hi)=0.6*0.978=0.587

[0140] (f1=hi)*(f2=me)=0.4*0.022=0.009

[0141] (f1=hi)*(f2=hi)=0.4*0.978=0.391

[0142] applying equation (18), 8$\begin{array}{cc}\phi \left(p\right)=\frac{0.013*\left(0.5\right)+0.587*\left(0.3\right)+0.009*\left(0.3\right)+0.391*\left(0.2\right)}{0.013+0.587+0.009+0.391}=0.26& \left(19\right)\end{array}$

[0143] It should be noted that in the embodiment of FIG. 8, steps 810 and 812, and steps 814 and 816 are shown executing respectively in parallel. However, the teachings of the invention are not intended to be so limited, and in fact nonparallel execution of these steps can occur as long as f1(p) and f2(p) can be obtained such that rules can be applied to their combination as described above without either becoming stale.

[0144] Eagerness determination processing according to an alternative embodiment of the invention will now be detailed with reference to FIG. 9. In this embodiment, the homogeneousness of the given individual call processing unit PMCp load is ascertained along with fuzzy logic anaylsis of the actual load and estimated load parameters for the PMCp as described above with reference to FIG. 8. Eagerness determination according to this embodiment may be conveniently performed by the resource utilization 1320 and fuzzy logic unit 1340 of the PMCi 1300 shown in FIG. 13 in combination with the homogeneousness realization 1650 and eagerness determination unit 1660 of the PMC-M 1600 shown in FIG. 16, although other configurations may be utilized, as will be recognized by those of ordinary skill in the art.

[0145] In comparing the embodiment shown in FIG. 9 to the embodiment described above with reference to FIG. 8, the following differences are noted. First, homogeneousness or the related parameter x3(p) in step 918 of FIG. 9 is calculated, here in parallel with fuzzification of the actual and estimated loads (steps 814 and 816). Sequencing this after step 810 is important since homogeneousness or x3(p) is dependent in part on the new estimated load mean μt calculated in step 810 as a precursor to obtaining either x2(p) or ζ(p). However, step 918 need not occur in parallel with either step 814 or 816 as shown in FIG. 9, and can occur at any point in time after the new estimated load mean is determined (such as by the load estimator 1330 shown in FIG. 13) and before the new eagerness value for the PMCp is determined (step 924).

[0146] The homogeneousness parameter, x3(p), is determined in accordance with the following equation: balance target for the new or upgraded call class minus the (new or upgraded call class mean/new estimated load mean for the PMCp), or ω(θx)−μ(θx)/μt. The balance target is the ratio of the number of calls in class θx to the total number of calls in the call processing system managed by the master call processing unit, such as PMC-M 1600 shown in FIG. 16. It should be noted that in order to obtain a valid balance target ω(θx), the PMC-M should have access to the admitted call tables for every PMCi it services (including the PMCp), if not a copy locally accessible to it, such as admitted call tables 1634 contained in local memory 1630. As shown in FIG. 16, a weighting engine 1640 forming part of the PMC-M may be utilized to maintain and update balance targets ω for all supported call classes and current state of all PMC1 . . . PMCk admitted call tables. When needed for homogeneousness parameter determination or otherwise, particular balance target information for a call class of interest, such as one for a new call or an upgraded existing call, may be issued by the weighting engine to a homogeneousness realization unit (such as unit 1650 within PMC-M 1600 or unit 1435 forming part of the resource utilization unit 1420 for the PMCi 1400 shown in FIG. 14.

[0147] Ideally, x3(p) should approach 0, so that the ratio of calls of class θx to the total number of calls being handled by the PMCp matches the overall ratios experienced by the entire call processing system, from which ω(θx) is derived. If x3(p)<0, this means that the PMCp has more than the average number of admitted calls of class θx, and admission of the new or upgraded call of class θx should be rejected or at least disadvantaged. Conversely, if x3(p)>0, this means that the PMCp has less than the average number of admitted calls of class θx, and the admission of the new or upgraded call of class θx should be encouraged.

[0148] Determination of homogeneousness as specified in step 918 may be conveniently implemented by a homogeneousness realization unit adapted to calculate x3(p) as discussed above. This homogeneousness realization unit may be situated onboard the PMCp for which eagerness is being determined, as is best shown in FIG. 14 through homogeneousness realization unit 1435 accepting the new estimated load mean and new or upgraded call class mean (contained in the resource knowledge base 1310) from the load estimator 1430 local to such PMCp). In such case, the ω(θx) is sent from the PMC-M including the aforementioned weighting engine, such as PMC-M 1800, to the PMCp. In the alternative, as shown in FIG. 16, the homogeneous realization unit may be situated locally within the PMC-M, such as that shown in FIG. 16, where the PMCp sends the new estimated load mean and new or upgraded call class mean to the PMC-M to permit such realization to occur.

[0149] As for further differences with the embodiment of FIG. 8, eagerness determination processing according to the embodiment of FIG. 9 also includes obtaining an intermediate eagerness {overscore (φ)}(p) in step 922, followed by final φ(p) which takes into account {overscore (φ)}(p) and the aforementioned x3(p) calculated in step 918. In this embodiment, a simple linear function of {overscore (φ)}(p) and x3(p) is used to obtain φ(p), such as:

φ(p)=A*{overscore (φ)}(p)+(1−A)*x3(p)  (20)

[0150] where A=positive constant between 0 and 1, e.g. A=0.9

[0151] Eagerness determination for individual call processing unit according to yet a further alternative embodiment will now be detailed with reference to FIG. 10. Processing according to this embodiment differs from processes previously described with reference to FIGS. 8 and 9 in that homogeneousness is also fuzzified (step 1010) with respect to a 3 membership state (H 2110 “high” to indicate that the ratio of calls of class θx being handled by the PMCp exceeds the θx balance target average for the entire call processing system, M 2120 “medium” to indicate that this ratio within the PMCp is approaching the balance target, L 2130 “low” means that the PMCp is handling fewer calls of class θx than average for the entire call processing system) fuzzification response curve shown in FIG. 21. Once fuzzification of all three parameters has been performed, including the actual load parameter x1(p) (step 814), the estimated load parameter x2(p) (step 816) and the homogeneousness parameter x3(p) (step 1010), the rules base is applied to all three fuzzified parameters in step 1020. The following table illustrates such a rules base, if f1(p) and f2(p) are simplified to 3 member states each as well:

f1	L	M	H
f2	L	M	H	L	M	H	L	M	H
f3
L	1	0.75	0.5	1	0.75	0.25	0.5	0.25	0
M	1	0.5	0	0.75	0.5	0	0.25	0	0
H	0.25	0.25	0	0.25	0.25	0	0	0	0

[0152] Thereafter in step 1022 the rules result to fuzzify to directly obtain the new eagerness value φ(p) for the individual call processing unit (step 1022). Thereafter, eagerness determination processing according to the embodiment of FIG. 10 ends.

[0153] It should be noted that the individual call processing unit arrangement shown in FIG. 14 may conveniently implement the processing described above with reference to FIG. 10. Alternatively, such processing may occur within the managing call processing unit such as that shown in FIG. 18 on behalf of the given individual call processing unit, assuming that the actual load for that call processing unit is made accessible to the PMC-M, such as through realization and transmission of the actual load x1(p) parameter by the individual PMCp to the PMC-M by the load monitor 1325 depicted in the PMCi 1700 shown in FIG. 17.

[0154] Call admission processing according to an embodiment of the invention will now be detailed with respect to the flowchart of FIGS. 11 and 12. In particular, early call admission control or early CAC is handled by the managing call processing unit PMC-M for the entire call processing system based on current eagerness φ values for each of the individual call processing units PMCi constituting the call processing system and is shown and described with reference to FIG. 12. FIG. 11 illustrates call event, including call admission processing undertaken by a given one of the individual call processing units, including when the PMC-M identifies a potential PMCi for call admission based on early CAC processing. Turning first to the flowchart of FIG. 12, early CAC processing within the PMC-M begins at step 1210, in which upon detection of a call admission request, the PMC-M control logic, such the PMC-M management unit 1510 (FIG. 15), 1610 (FIG. 16) or 1810 (FIG. 18) queries the current eagerness values φ1 . . . φk corresponding to each of the individual call processing units PMCi. It should be noted that in this embodiment, it is the responsibility of each PMCi to update it's eagerness value as is appropriate to adequately apprise the PMC-M of it's willingness to take on and manage a new call. However, in other embodiments consistent with the present invention, the PMC-M may prompt each PMCi for this eagerness information as needed or periodically as will become apparent to those ordinarily skilled in the art.

[0155] Once these eagerness values are obtained, control thereafter passes to step 1212, in which the maximum relative eagerness value is determined based on the all the eagerness values (a.k.a. eagerness vector Φ) obtained in step 1210. Thereafter in step 1214, a determination is made whether the maximum eagerness value exceeds a threshold. This threshold can be a uniform threshold for any call or can be based on the type of call, its associated cost of service such as bronze, silver or gold, and or based on other factors such as originator status, intended recipient status, etc. For example, consider the threshold malleability chart of FIG. 22. Here, a bronze CoS call will not be admitted if the reported eagerness for any of the PMCis fails to exceed εB, thus in eagerness situations 2222, 2226 and 2228 the call is rejected, but accepted in situation 2220. Looking at the chart in another way, if situations 2220, 2222, 2226, and 2228 graphically represent the reported eagerness vector Φ:φ1 . . . φ4 at a given time, the only PMCi corresponding to reported eagerness 2220 will be available to confirm acceptance of the bronze class call.

[0156] Likewise, a silver CoS call will not be admitted if the reported eagerness for any of the PMCis fails to exceed εS, so in situations 2236 and 2238 the silver class call is rejected, and in situations 2230 and 2232 it is accepted. And, a gold class call will only fail to be accepted where the reported eagerness for each of the PMCis fails to exceed the gold threshold εg, such as in situation 2248.

[0157] Turning back to FIG. 12, if it is determined in step 1214 that this maximum eagerness value does exceed the specified threshold, control passes to step 1218. At step 1218, the call admission request under scrutiny is transferred to the PMCi exhibiting the maximum eagerness value. In particular, the eagerness value for such call processing unit is recalculated taking into account the call class specified by the call in the new call admission request. Eagerness and load estimate determination as described herein may conveniently be used to confirm the new eagerness value. Thus, the decision to ultimately admit the call pursuant to the call request rests not with the PMC-M here, but by the PMCi exhibiting the maximum eagerness to accept a new call. Control thereafter passes to step 1224.

[0158] At step 1224, the corresponding individual call processing unit's reported eagerness is disadvantaged such as by scaling its corresponding φ by a factor of 0.8-0.9 for at least one iteration. Control thereafter ends. It should be noted that this processing will restart with the disadvantaged φ replacing the previous maximum φ. In such way, a high probability that another PMCi will be selected, and it's eagerness will be self-confirmed, assuming that it's reported eagerness continues to exceed the threshold as performed in step 1214. As one can see, this process continues iteratively until the first of: (1) the maximum queried eagerness value fails to exceed a specified threshold; (2) eagerness to accept the call cannot be confirmed by any PMCi; or the CA request is withdrawn.

[0159] Though not shown in FIG. 12, alternative ways may be used to disadvantage unconfirmed PMCis, such as through removing them from further consideration for the current CA request, or for a longer duration as will be understood by those ordinarily skilled in the art.

[0160] Call event processing according to an embodiment of the invention undertaken by a PMCi such as the PMCi 1300 shown in FIG. 13 or the PMCi 1400 shown in FIG. 14 is now detailed with reference to the flowchart of FIG. 11. Processing begins at step 1110 upon receipt of a call event directed to a given one of the PMCis either internally from calls already admitted or by the managing call processing unit responding to a call admission request, as outlined above with reference to PMC-M processing described with reference to FIG. 12. If at step 1110, a determination is made that the call event includes a call admission request, control passes to step 1112. At step 1112, the PMCi undertakes determination of the estimated load which includes the new call, such through processing described herein with reference to FIGS. 6 and 7. Thereafter, in step 1114, an intermediate or final eagerness value for the PMCi based on this newly obtained estimated load in step 1112 is determined using e.g. eagerness determination processing described herein with reference to FIGS. 8, 9 or 10, based on the configuration and capabilities of the PMCi. At step 1116, the intermediate or final eagerness determined in step 1114 is compared against a threshold (similar if not the same as the threshold used by the PMC-M in step 1214 of FIGS. 12 and 22). If the new eagerness(which as noted above takes into account the new call) fails to exceed this threshold, control passes to step 1118 in which the new call is rejected by the current PMCi and previous estimated load values and eagerness values are restored to reflect the situation prior to consideration of the new call. Control thereafter terminates.

[0161] If however, in step 1116, it is determined that the new eagerness does in fact exceed the threshold, control instead passes to step 1122. At step 1122, the PMCi admits the call. Control then passes to step 1124, in which a determination is made whether the PMC-M should be apprised of the newly calculated eagerness value. There is a design goal in the present embodiment to reduce extraneous traffic between the PMC-M and the PMCis it manages, and one way to help achieve this goal is to reduce notification of reported eagerness changes when such changes are relatively small, particularly where the overall system is relatively insensitive to slight alterations in PMCi eagerness. Thus, in this embodiment, a determination is made in step 1124 whether the new eagerness value constitutes a big change from the previous eagerness value reported to the PMC-M. If so, control passes to step 1126 and the PMCi reports the new eagerness to the PMC-M and call admission event processing ends. However, if in step 1124 it is determined that the new eagerness does not represent a significant change from the previously reported eagerness for the current PMCi, call event processing ends without further reporting.

[0162] In determining whether the new eagerness constitutes a big change, a content-based messaging conservation algorithm may be used as depicted in FIG. 23. In this figure, if the new and previous eagerness both fall within region 2310(i.e. new and old φ(p)<0.25), the eagerness is determined not to be sensitive since the PMC-M will not consider the current PMCi for call admission anyway, as it fails to exceed the minimum threshold discussed above. Likewise, if the new eagerness and old eagerness both fall within region 2330 (i.e. new and old φ(p)>0.75), the current PMCi is deemed eager to admit calls anyway and so is not sensitive to the change. However, if the new eagerness or old eagerness falls in region 2320 (i.e. 0.25<new φ(p)or old φ(p)<0.75), the eagerness is deemed sensitive to the change and so the new eagerness is reported to the PMC-M. In other embodiments, other techniques may be used alternatively or in combination, such as thresholding the change in eagerness between old and new, reporting only after so many determinations, and the like.

[0163] Returning to FIG. 11, if the call event is not in fact a call admission request from the PMC-M, in accordance with FIG. 11 control passes to step 1130, in which a determination is made whether the call event for the current PMCi includes an admitted call class modification request. If so, control passes to step 1132, in which a further determination is made whether the call modification request specifies an upgrade or downgrade from a critical resource utilization perspective. If the modification request constitutes such an upgrade, control passes to step 1112 so that the current PMCi can self-determine whether it has sufficient resources to handle call upgrade using the aforementioned eagerness analysis detailed in steps 1112 to 1126 previously discussed. In this instance, however, the new estimated load is calculated with respect to a difference between the new and prior class characteristics for the call in which modification is requested.

[0164] If, however, in step 1132, it is determined that the call modification request specifies a call downgrade, control instead passes to step 1134 in which the new estimated load is determined based on the downgrade. Then, in step 1136, the new intermediate or final (depending on PMCi resource utilization capabilities) eagerness is re-determined taking into account the new estimated load obtained in step 1134. Thereafter, processing continues with the conditional publication or reporting steps 1124 and 1126 detailed above.

[0165] If, in step 1130, a determination is made that the intercepted call event does not comprise either a call admission request or an admitted call modification request, control passes to step 1140. At step 1140, a determination is made whether the call event includes an admitted call termination event. If so, control passes to step 1134 through 1126 detailed above, with the exception that the estimated load is recalculated without consideration of the terminated call. If, however, in step 1140, it is determined that the call event is not one of a call admission request, a call modification request, or a call termination request, the call event falls through to conventional call management processing (not shown in the FIG.), or in the alternative, is not recognized or acted upon at all by the PMCi of interest.

[0166] Turning briefly to FIG. 13, FIG. 13 depicts an individual call processing unit PMCi 1300 arrangement which includes a resource utilization unit 1320 and fuzzy logic unit 1340 capable of determining intermediate or final eagerness values based on actual and estimated load parameters. As such, the PMCi 1300 may conveniently implement estimated load processing discussed above with reference to FIGS. 6 and 7, and eagerness determination according to embodiments shown in FIGS. 8 and 9. In the case of eagerness determination consistent with FIG. 9, the PMCi 1300 coordinates with a PMC-M capable of determining a final eagerness including homogeneousness realization, such as PMC-M 1600 shown in FIG. 16. In the case of eagerness determination consistent with the embodiment of FIG. 8, the PMCi 1300 self determines a final eagerness which may then be reported to a PMC-M such as PMC-M 1500 shown in FIG. 15.

[0167] FIG. 14 illustrates an alternative PMCi 1400 arrangement which includes on-board homogeneousness realization and fuzzification consistent with the present invention. As such, the PMCi 1400 may conveniently implement eagerness determination consistent with the embodiment shown in FIG. 10, and may coordinate results with any PMC-M including a mechanism for generating and managing balance targets, such as PMC-M 1600 (FIG. 16) or PMC-M 1800 (FIG. 18).

[0168] FIG. 17 illustrates yet another alternative PMCi 1700 arrangement in which the PMCi 1700 does not include any fuzzy logic for load balancing or call admission control but does include a load monitor 1325 capable of obtaining x1(p) as described above. It is contemplated that in this embodiment, such load balancing and call admission control functionality will be undertaken by the managing call processing unit, such as the PMC-M 1800 shown in FIG. 18.

[0169] It will be obvious to those having skill in the art that many changes may be made to the details of the above-described embodiments of this invention without departing from the underlying principles thereof. For example, the processing described above may be conveniently implemented by one or more general (e.g. a microprocessor or microcontroller) or specific purpose information processors (e.g. a network processor or DSP) programmed to undertake one or more of the involved processing steps. In the alternative, or in combination such information processing resources, one or more steps of the above-described processing may be undertaken by a discrete logic and/or circuitry, including application specific integrated circuits and/or analogous devices. The scope of the present invention should, therefore, be determined only by the following claims.

Claims

1. In a call processing unit capable of supporting a plurality of call classes, a method for determining an eagerness to admit a call, comprising: obtaining first and second load parameters for the call processing unit; fuzzifying the first and second load parameters according to first and second fuzzification functions respectively; comparing the fuzzified first and second load parameters against a defined set of eagerness rules; defuzzifying a result of said comparing; and generating the eagerness based on said defuzzification result.

2. The method of claim 1, wherein the first load parameter comprises an actual load of the call processing unit at a given time; and wherein the second load parameter comprises an estimated load measure of the call processing unit.

3. The method of claim 2, wherein the estimated load is approximated using a probabilistic distribution function.

4. The method of claim 1, wherein said defuzzifying step comprises defuzzifying the result of said comparing step as a load eagerness; and wherein said generating step comprises generating the eagerness to accept the call based on the load eagerness and a homogeneousness parameter for the call processing unit.

5. The method of claim 1, further comprising the step of obtaining a homogeneousness parameter for the call processor based on the second load parameter; wherein said fuzzifying step comprises fuzzifying the first load parameter, the second load parameter, and the homogeneousness parameter according to first, second and third fuzzification functions respectively; and wherein said comparing step comprises the fuzzified first and second load parameters and the fuzzified homogeneousness parameter against the defined set of eagerness rules.

6. The method of claim 1, wherein the eagerness comprises a plurality of eagerness values, each eagerness value corresponding to one of the supported plurality of call classes.

7. A computer program product, comprising computer readable program code causing an information processor within a call processing unit to perform at least one of the following, comprising: obtaining first and second load parameters for the call processing unit, the call processing unit being capable of supporting a plurality of call classes; fuzzifying the first and second load parameters according to first and second fuzzification functions respectively; comparing the fuzzified first and second load parameters against a defined set of eagerness rules; defuzzifying a result of said comparing step; and generating the eagerness to admit the call based on said defuzzification result.

8. A call processing unit capable of supporting a plurality of call classes, comprising: a resource utilization unit to obtain first and second load parameters for the call processing unit; a first fuzzifier coupled to said resource utilization unit to fuzzify the first load parameter according to a first fuzzification function; a second fuzzifier coupled to said resource utilization unit to fuzzify the second load parameter according to a second fuzzification function; and a load balancing fuzzy logic unit, comprising: a rules inference engine coupled to said first and second fuzzifiers to compare the fuzzified first and second load parameters against a defined set of eagerness rules; a defuzzification unit responsive to said rules inference engine to defuzzify a result of comparison between the fuzzified load parameters and the defined set of eagerness rules; and a generation unit responsive to said defuzzification unit to generate the eagerness to admit a call based on the defuzzification result.

9. The call processing unit of claim 8, wherein the first load parameter comprises an actual load of the call processing unit at a given time; and wherein the second load parameter comprises a measure of an estimated load of the call processing unit.

10. The call processing unit of claim 9, wherein the estimated load is approximated using a probabilistic distribution function.

11. The call processing unit of claim 8, wherein said defuzzification unit defuzzifies the result of the comparison as a load eagerness; and wherein said generating unit generates the eagerness to admit the call based on the load eagerness and a homogeneousness parameter for the call processor.

12. The call processing unit of claim 8, further comprising: a homogeneousness realization unit coupled to said resource utilization unit to realize a homogeneousness parameter based on the second load parameter; a third fuzzifier coupled to said homogeneousness realization unit to fuzzify the homogeneousness parameter according to a third fuzzification function; wherein said rules inference engine is further coupled to said third fuzzifier to compare the fuzzified homogeneousness parameter with the fuzzified first and second load parameters against the defined set of eagerness rules; and wherein said defuzzification unit defuzzifies a result of comparison between the load parameters, the a rules inference engine coupled to said first and second fuzzifiers to compare the fuzzified first and second load parameters against a defined set of eagerness rules; a defuzzification unit responsive to said rules inference engine to defuzzify a result of comparison between the fuzzified load parameters, the fuzzified homogeneousness parameter and the defined set of eagerness rules.

13. The call processing unit of claim 8, wherein the eagerness comprises a plurality of eagerness values, each eagerness value corresponding to one of the supported plurality of call classes.

14. A call processing system, comprising: an individual call processing unit, comprising the call processing unit of claim 8, wherein said generation unit to generate the eagerness as a load eagerness for the individual call processing unit; and a managing call processing unit comprising: a homogeneousness realization unit communicatively coupled to said resource utilization unit of said individual call processing unit to realize a homogeneousness parameter based on the second load parameter; and load balancing logic responsive to said generation unit and said homogeneousness realization unit, said load balancing logic to derive a call admission eagerness for the individual call processing unit based on the load eagerness and the homogeneousness parameter.

15. A call processing unit capable of supporting a plurality of call classes, comprising: means for obtaining first and second load parameters for the call processing unit; means for fuzzifying the first load parameter according to a first fuzzification function; means for fuzzifying the second load parameter according to a second fuzzification function; and a load balancing fuzzy logic means, comprising: means for comparing the fuzzified first and second load parameters against a defined set of eagerness rules; means for defuzzifying a result of comparison between the fuzzified load parameters and the defined set of eagerness rules; and means for generating the eagerness to admit a call based on the defuzzification result.

16. In a system comprising plural call processing units for handling a plurality of call classes, a method for admitting calls to the system, comprising: (A) monitoring a call admission eagerness for each of the call processing units; (B) perceiving a call admission request; and (C) when the call admission request has been perceived, performing the following: (1) selecting one of the call processing units having a relative maximum call admission eagerness as a target call processing unit; (2) having the target call processing unit confirm the call admission eagerness with respect to the call admission request; and (3) having the target call processing unit admit a call specified by the call admission request if the call admission eagerness is confirmed.

17. The method of claim 16, wherein said selecting (C1) comprises selecting one of the call processing units having a relative maximum call admission eagerness as the target call processing unit if the relative maximum call admission eagerness exceeds a predetermined threshold.

18. The method of claim 17, wherein the predetermined threshold is selected in accordance with the call specified by the call admission request.

19. The method of claim 16, further comprising: (C4) having the target call processing unit reject the call admission request if the call admission eagerness cannot be confirmed; (C5) selecting another one of the call processing units having a relative maximum call admission eagerness other than the target call processing unit as a second target call processing unit; (C6) having the second target call processing unit confirm the call admission eagerness with respect to the call admission request; and (C7) having the second target call processing unit admit the call specified by the call admission request if the call admission eagerness for the second target call processing unit is confirmed.

20. The method of claim 16, further comprising: (C8) recursively performing C4 through C7 in sequence until one of: call admission eagerness for a given target call processing unit is confirmed with respect to the call admission request; and the relative maximum call admission eagerness fails to exceed a predetermined threshold.

21. A computer program product, comprising computer readable program code causing an information processor within a call processing unit to perform at least one of the following, comprising: (A) monitoring a call admission eagerness for each of the call processing units (B) perceiving a call admission request; and (C) when the call admission request has been perceived, performing the following: (1) selecting one of the call processing units having a relative maximum call admission eagerness as a target call processing unit; (2) having the target call processing unit confirm the call admission eagerness with respect to the call admission request; and (3) the target call processing unit admitting a call specified by the call admission request if the call admission eagerness is confirmed.

22. A call processing system, comprising: plural call processing units for handling a plurality of call classes; an interface communicatively coupled to said plural call processing units; first logic communicatively coupled to said interface to monitor a call admission eagerness for each of the call processing units; second logic to perceive a call admission request; and third logic coupled to said interface and said first and second logic to select one of said call processing units having a relative maximum call admission eagerness as a target call processing unit, have the target call processing unit confirm the call admission eagerness with respect to the call admission request, and have the target call processing unit admit a call specified by the call admission request if the call admission eagerness is confirmed.

23. A call processing system, comprising: means for handling a plurality of call classes; means for interfacing to said handling means; means for monitoring a call admission eagerness for each of said handling means; means for perceiving a call admission request; and means for selecting one of said call processing units having a relative maximum call admission eagerness as a target call processing unit, said selecting means including means for having the target call processing unit confirm the call admission eagerness with respect to the call admission request, said selecting means further including means for having the target call processing unit admit a call specified by the call admission request if the call admission eagerness is confirmed.