Methods of routing for networks with feedback

Abstract

Example embodiments are directed to methods of routing requests within a system having a plurality of server pools. At least one of the methods provides a method of routing requests within a system having a plurality of server pools. The method includes receiving a request at the system, first determining a first value associated with a first request type of the received request and second determining a probability of routing based on the first value and a probability of rerouting. The first value is a virtual queue value for requests of the first request type. The second determining is performed without determining an input rate at which the requests of the first request type are received. The received request is routed to at least one of the plurality of server pools based on the probability of routing.

Description

BACKGROUND

Example embodiments relate to networks of server pools, such as call centers, for example.

In a network with server pools, a control strategy is often implemented. The control strategy may include a method of routing calls incoming to the network. A routing method applies to a network that may be flexible in the sense that service speed depends on a customer (e.g., request) type and the server pool where the customer is served. Types of requests may include calls requesting account transactions, loan applications and technical support, for example. In the art, request and customer may be used interchangeably. It should be understood that a customer may have multiple requests.

When a request is received (customer arrives) the routing method should route the received request when there are available servers in at least one pool.

A network where a customer's request is completed by a server and the customer then requires another service (e.g., another request) is referred to as a network with feedback. An example of a network with feedback is a network that allows a customer to check an account balance and then require another transaction, e.g., apply for a loan.

Conventional routing methods for networks with feedback require explicit a priori knowledge or explicit measurement of customer input flow rates, per each customer type. The input rate is used to explicitly solve an underlying optimization problem, which may be a linear program, for example. The solution to the linear program is then used to guide actual routing of customers to and between the servers.

The approach based on explicitly solving the linear program has high complexity and is not robust because different iterations of the linear program need to be performed when input rates change. Moreover, input rates are generally not known in advance and the times when they change are not known in advance. Thus, the linear programming approach does not respond quickly to sudden changes in input rates.

SUMMARY

Example embodiments are directed to routing methods in networks with feedback. Example embodiments include “running” a virtual (shadow-system) queuing system based on actual arrivals of requests to the network. Example embodiments produce routing automatically, without explicitly solving the linear program and measuring input rates. The state of the shadow system “guides” routing decisions in the real system. Thus, example embodiments have a lower implementation complexity and higher robustness.

Example embodiments do not require a priori knowledge or explicit measurement of input rates of different request types. Moreover, example embodiments disclose methods for server pool load balancing when a system is not overloaded, and other methods for managing system revenue when the system is overloaded. Methods for managing system revenue include methods for picking customers that should be blocked, i.e., denied service, for maximizing system average revenue.

At least one example embodiment provides a method of routing requests within a system having a plurality of server pools. The method includes receiving a request at the system, first determining a first value associated with a first request type of the received request and second determining a probability of routing based on the first value and a probability of rerouting. The first value is a virtual queue value for the first request type. The second determining is performed without determining an input rate at which the requests of the first request type are received. The received request is routed to at least one of the plurality of server pools based on the probability of routing.

In at least another example embodiment, a method of controlling a routing system includes receiving a request having a first request type, updating the first value periodically based on mean service times of processing requests of different types by different server pools, the probabilities of rerouting, and at least a second value associated with a second type of request, without determining an input rate at which the requests are received. The first value is a virtual queue value for the first request type and the second value is a virtual queue value for the second request type. Routing probabilities are updated based on the updated first value and the request is routed based on the updated routing probabilities.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings. FIGS. 1A-3 represent non-limiting, example embodiments as described herein.

FIGS. 1A-1C illustrate methods of routing requests according to an example embodiment;

FIGS. 2A-2C illustrate methods of routing requests according to an example embodiment; and

FIG. 3 illustrates a system for routing requests according to an example embodiment.

DETAILED DESCRIPTION

Various example embodiments will now be described more fully with reference to the accompanying drawings in which some example embodiments are illustrated.

Accordingly, while example embodiments are capable of various modifications and alternative forms, embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that there is no intent to limit example embodiments to the particular forms disclosed, but on the contrary, example embodiments are to cover all modifications, equivalents, and alternatives falling within the scope of the claims. Like numbers refer to like elements throughout the description of the figures.

It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

It should also be noted that in some alternative implementations, the functions/acts noted may occur out of the order noted in the figures. For example, two figures shown in succession may in fact be executed substantially concurrently or may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which example embodiments belong. It will be further understood that terms, e.g., those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Portions of example embodiments and corresponding detailed description are presented in terms of software, or algorithms and symbolic representations of operation on data bits within a computer memory. These descriptions and representations are the ones by which those of ordinary skill in the art effectively convey the substance of their work to others of ordinary skill in the art. An algorithm, as the term is used here, and as it is used generally, is conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of optical, electrical, or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

In the following description, illustrative embodiments will be described with reference to acts and symbolic representations of operations (e.g., in the form of flowcharts) that may be implemented as program modules or functional processes including routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types and may be implemented using existing hardware at existing network elements or control nodes (e.g., a scheduler, router or gateway). Such existing hardware may include one or more Central Processing Units (CPUs), digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, or as is apparent from the discussion, terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical, electronic quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Note also that the software implemented aspects of example embodiments are typically encoded on some form of tangible (or recording) storage medium or implemented over some type of transmission medium. The tangible storage medium may be magnetic (e.g., a floppy disk or a hard drive) or optical (e.g., a compact disk read only memory, or “CD ROM”), and may be read only or random access. Similarly, the transmission medium may be twisted wire pairs, coaxial cable, optical fiber, or some other suitable transmission medium known to the art. Example embodiments are not limited by these aspects of any given implementation.

Example embodiments are directed to routing methods in networks with feedback. Example embodiments include “running” a virtual (shadow-system) queuing system based on actual arrivals of customers to the network. Example embodiments produce routing automatically, without explicitly solving the linear program and measuring input rates. The state of the shadow system “guides” routing decisions in the real system.

Example embodiments do not require a priori knowledge or explicit measurement of input rates of different request types. Moreover, example embodiments disclose methods for server pool load balancing when a system is not overloaded, and other methods for managing system revenue when the system is overloaded. Methods for managing system revenue (reward) pick customers that should be blocked, i.e., denied service.

Algorithms implemented in the methods shown in FIGS. 1A-1C and 2A-2C may be implemented by the system shown in FIG. 3. The system shown in FIG. 3 is described after the description of the methods according to example embodiments.

In example embodiments, there may be 1−I request types (type of request) where i is one of the request types 1−I having a rate of exogenous arrivals equal to λ_ir, where r is a scaling parameter. Example embodiments, however, do not need to know in advance or explicitly measure the rates λ_ir.

It should be understood that the terms “request” and “customer” may be used interchangeably.

There may be 1−J server pools where j is one of the server pools having β_jr servers and thus, β_j is proportional to the number of servers in the server pool j. All servers within the same server pool j have similar or identical service skills. A mean service time of a request type i customer by a type j server is 1/μ_ij.

After completion of the request type i request by the pool j server, the request with a rerouting probability p_ik^(j), brings a system operator a reward w_ik^(j) and changes to a request type k, where k is one of the request types 1−I or equal to zero. Reward may be referred to as an immediate (e.g., transaction fee) or expected future revenue due to a completed service of the request. When a request changes and returns to the system as another request, possibly of a different request type, the system treats the changed request the same way as an externally received request, except the returning call (changed request) does not trigger an initial update in the virtual system. This is described in more detail below with reference to FIGS. 1A-2C. When a request changes to a request type zero, the request leaves the system.

The following notation is applicable to example embodiments:x⁺=max{x,0}  (1A)x⁻=[−x]⁺=−min{x,0}  (1B)

Example embodiments disclose methods for server pool load balancing when a system is not overloaded (load balancing), and other methods for managing system revenue when the system is overloaded. Each of these methods is described in detail.

Throughout example embodiments, there may be multiple request types i and server pools j such thatiε={1, . . . ,I}  (2A)andjε={1, . . . ,J}  (2B)Load Balancing

FIGS. 1A-1C illustrate methods of routing requests according to an example embodiment of load balancing. The methods illustrated in FIGS. 1A-1C may be implemented by an algorithm for a system that is not overloaded (e.g., a maximum load ρ<1), for example.

It should be understood that the methods of FIGS. 1A-1C may be implemented in the system shown in FIG. 3, which is described in detail below.

Load balancing according to example embodiments results in rates at which a server pool j serves request type i requests (including requests that turn to request type i after a service), being close to the rates λ_ijr such that a maximum load ρ of server pools is minimized:

$\begin{array}{cc}\underset{\left\{{\lambda }_{\mathrm{ij}}\right\},\rho }{\min }\rho & \left(3\right)\end{array}$

The minimization of ρ is subject to:

$\begin{array}{cc}\sum _i{\lambda }_{\mathrm{ij}}\text{/}\left({\beta }_j{\mu }_{\mathrm{ij}}\right)\le \rho ,\forall j,& \left(4\right)\\ {\lambda }_{\mathrm{ij}}\ge 0,\forall i,j,& \left(5\right)\\ \sum _j{\lambda }_{\mathrm{ij}}\ge {\lambda }_i+\sum _{k\in \left\{1-I\right\}}\sum _{j\in \left\{1-J\right\}}{p}_{\mathrm{ki}}^{\left(j\right)}{\lambda }_{\mathrm{kj}},\forall i& \left(6\right)\end{array}$

The algorithm implemented in the methods of FIGS. 1A-1C maintains a virtual queue _i for each request type i. Virtual is used to describe variables that are maintained by the algorithm. In other words, the virtual queue _i for each request type i models or represents a number of requests of the request type i in a virtual queue. It should be understood by one of ordinary skill in the art that the algorithm and methods of FIGS. 1A-1C may be implemented in hardware or software of the system, such as software in a router or other devices used for routing requests.

For each request type i and server pool j, variables A_ij, Ā_ij, Φ_ij are maintained. Φ_ij is the probability of routing a request of request type i (exogenous or rerouted) to server pool j. Ā_ij is the long term average of A_ij. A_ij and Ā_ij are initialized to zero at the beginning of the algorithm. Small parameters, η and η₁ are greater than zero and are set to control a tradeoff between a responsiveness of the algorithm and accuracy. In at least one example embodiment, η and η₁ may be between 1/r and 1/sqrt(r), assuming β_j is one and r is a large value.

FIG. 1A illustrates a method of routing requests upon exogenous arrivals (requests arriving from outside of the system). At S101, the system receives a request from outside of the system. The request may be a customer call, for example. A request type is associated with the request, such as requesting an account balance.

At S103, the request is routed to a server pool j based on the routing probabilities. The system routes the request using a random number generator having values 1−J with probabilities of being output Φ_i1-Φ_iJ, respectively. For example, if the random number generator generates a “1”, the request is routed to server pool 1. At S105, the algorithm increases a queue value _i, thus,_i:_i+1  (7)

While FIG. 1A illustrates that the queue value _i is updated after the received request is routed, it should be understood that the request may be routed after the queue value _i is updated. The method shown in FIG. 1A may be implemented by the algorithm every time a new exogenous request is received by the system when the system is not overloaded.

FIG. 1B illustrates a method of routing requests when a request that has been rerouted within the system is received. The system knows when a request is reroute because the system reroutes the requests. As shown, the request is received within the system at S107. At S109, a server pool j is determined by the algorithm based on the probabilities of routing and is routed by the system to the server pool j. More specifically, the system routes the request using a random number generator having values 1−J with probabilities of being output Φ_i1-Φ_iJ, respectively. The method shown in FIG. 1B may be implemented by the algorithm every time a rerouted request is received within the system.

FIG. 1C illustrates a method of updating routing probabilities for the methods of routing requests that are shown in FIGS. 1A and 1B. The method shown in FIG. 1C may be run continuously and may be implemented without determining input rates of different request types. At S110, the algorithm determines whether a first condition,

$\begin{array}{cc}-1+\sum _j\underset{i}{\max }c{\mathrm{\tau \beta }}_j{{\mu }_{\mathrm{ij}}\left[\eta Q_i-\sum _{k=1}^I{p}_{\mathrm{ik}}^{\left(j\right)}\eta Q_k\right]}^{+}\ge 0& \left(8\right)\end{array}$ is satisfied, wherein τ and c are parameters greater than zero, p_ij^(j) is a probability that request type i served by pool j is rerouted as request type k (probability of rerouting), and _k is a queue value for request type k. In other words, the virtual queue _k for each request type k models or represents a number of requests of the request type k in a virtual queue. Probabilities of rerouting p_ik^(j), service rates μ_ij, and rewards w_ij^(j) may be determined from historical statistics and/or empirical testing and occasionally updated. The hardware or software implementing the algorithm chooses positive parameters τ and c; where c is chosen so that a minimum, over (i,j) with μ_ij greater than zero, of the values of cβ_jμ_ij, is greater than Σ_iλ_i.

The software and/or hardware implementing the algorithm, determines the first condition at S110 periodically and/or at regular time intervals. For example, the algorithm performs S110 at time points τ/r, 2τ/r, 3τ/r and so on. One of ordinary skill in the art should understand that τ may be changed to alter the responsiveness of the algorithm.

If the first condition of (8) is not satisfied, the algorithm determines the probability of routing Φ_ij and Ā_ij at S135, which is described in further detail below. If the first condition of (8) is satisfied, the algorithm determines for each server pool j, whether a second condition,

$\begin{array}{cc}\underset{i}{\max }{\mu }_{\mathrm{ij}}\left[\eta Q_i-\sum _{k=1}^I{p}_{\mathrm{ik}}^{\left(j\right)}\eta Q_k\right]>0& \left(9\right)\end{array}$ is satisfied at S115.

If the second condition of (9) is not satisfied, the algorithm determines whether all of the server pools have been checked at S125. If the second condition of (9) is satisfied then the algorithm determines a number S_j, and updates values _i*, _i and A_i*j at S120 for each server pool 1−J.

At S120, the algorithm first picks:

$\begin{array}{cc}{i}^{*}\in \underset{i}{\arg \max }{\mu }_{\mathrm{ij}}\left[\eta Q_i-\sum _{k=1}^I{p}_{\mathrm{ik}}^{\left(j\right)}\eta Q_k\right]& \left(10\right)\end{array}$

The algorithm determines S_j, and updates _i*, _i and A_i*j as follows:S_j=min{Q_i,cτβ_jμ_i*,j}  (11)Q_i*:=Q_i*−(1−p_i*,i*)S_j  (12)Q_i:=Q_i+p_i*,iS_j, iε, i≠i*  (13)A_i*,j:=A_i*,j+S_j  (14)

Once the algorithm determines S_j, and updates _i*, _i and A_i*j, the algorithm determines if all of the server pools have been checked at S125. If all of the server pools have not been checked, then the algorithm proceeds to the next server pool j+1 at S130 and determines if the second condition is met for the next server pool at S115.

When all of server pools 1−J have been checked, the algorithm updates the probability of routing Φ_ij and Ā_ij based on the queue value and the probability of rerouting p_ij^(j) and, more specifically, steps S105-S130 at S135.

The algorithm determines the probability of routing Φ_ij and Ā_ij for all (i,j) as follows:

$\begin{array}{cc}{\stackrel{\_}{A}}_{\mathrm{ij}}:={\eta }_1{A}_{\mathrm{ij}}+\left(1-{\eta }_1\right){\stackrel{\_}{A}}_{\mathrm{ij}},i\in ,j\in ,& \left(15\right)\\ {\varphi }_{\mathrm{ij}}:=\frac{{\stackrel{\_}{A}}_{\mathrm{ij}}}{\sum _m{\stackrel{\_}{A}}_{\mathrm{im}}},i\in ,j\in & \left(16\right)\end{array}$

Once the probability of routing Φ_ij and Ā_ij are updated, A_ij is set to zero.

Since the algorithm may run at time intervals, the algorithm may wait for the next time point of τ/r, 2τ/r, 3τ/r at S145 and return to S110.

Reward Managing

FIGS. 2A-2C illustrate methods of routing requests according to an example embodiment of reward managing. The methods illustrated in FIGS. 2A-2C may be implemented by an algorithm for a system that is overloaded (e.g., load ρ>1), for example.

It should be understood that the methods of FIGS. 2A-2C may be implemented in the system shown in FIG. 3, which is described in detail below.

When the system load p is greater than its capacity (e.g., ρ>1), some requests should be blocked (dropped). Thus, the system average reward over time, according to example embodiments is maximized, if the average rates λ_ijr (at which the system routes a request of request type i to a server pool j) are such that they are a solution to the following maximization problem:

$\begin{array}{cc}\underset{\left\{{\lambda }_{\mathrm{ij}}\right\}}{\max }\sum _{}\sum _j{\lambda }_{\mathrm{ij}}\sum _{k=0}^I{p}_{\mathrm{ik}}^{\left(j\right)}{w}_{\mathrm{ik}}^{\left(j\right)}& \left(17\right)\end{array}$

The maximum is subject to:

$\begin{array}{cc}\sum {\lambda }_{\mathrm{ij}}\text{/}\left({\beta }_j{\mu }_{\mathrm{ij}}\right)\le 1,\forall j,& \left(18\right)\\ {\lambda }_{\mathrm{ij}}\ge 0,\forall i,j,\mathrm{and}& \left(19\right)\\ \sum _j{\lambda }_{\mathrm{ij}}\le {\lambda }_i+\sum _{}\sum _{}{p}_{\mathrm{ik}}^{\left(j\right)}{\lambda }_{\mathrm{kj}},\forall i.& \left(20\right)\end{array}$

The algorithm implemented in the methods of FIGS. 2A-2C maintains a virtual queue V_i for each request type i. It should be understood by one of ordinary skill in the art that the algorithm and methods of FIGS. 2A-2C may be implemented in hardware or software of the system, such as software in a router.

For each request type i and server pool j, variables A_ij, Ā_ij, Φ_ij, A_i0, Ā_i0, and Φ_i0 are maintained. Φ_i0 is a probability that a request type i request will be blocked. A_i0 is a number of request of request type i that are blocked (dropped) in the virtual system (as opposed to actually being dropped) in the algorithm shown in FIG. 2C. Φ_ij is the probability of routing the request of request type i to server pool j. Ā_ij is the long term average of A_ij. A_ij and Ā_ij are initialized to zero at the beginning of the algorithm. Small parameters, η and η₁ are greater than zero and are set to control a tradeoff between a responsiveness of the algorithm and accuracy.

FIG. 2A illustrates a method of routing requests upon exogenous arrivals. At S201, the system receives a request from outside of the system.

At S203, the request is blocked or routed to a sever pool j based on the queue value and probabilities of routing Φ_ij and blocking Φ_i0. The system blocks or routes the request using a random number generator having values 0−J with probabilities Φ_i0-Φ_iJ, respectively. If a value of “0” is generated, then the request is blocked.

At S205, the algorithm decreases a queue value V_i for the request of request type i at S105, thus,V_i:=[V_i−1]⁺,  (21)andA_i0:=A_i0+[V_i−1]⁻  (22)where [Vi−1]⁻ is a number of requests which are block or dropped. In other words, the virtual queue V_i for each request type i models or represents a number of requests of the request type i in a virtual queue.

While FIG. 2A illustrates that the queue value V_i is updated after the received request is routed, it should be understood that the request may be routed after the queue value V_i is updated. The method shown in FIG. 2A may be implemented by the algorithm every time a new exogenous request is received by the system when the system is overloaded.

FIG. 2B illustrates a method of routing requests when a request that has been rerouted within the system is received. As shown, the request is received within the system at S207. At S209, the request is blocked or routed to a sever pool j based on the queue value and probabilities of routing Φ_ij and blocking Φ_i0. More specifically, the system blocks or routes the request using a random number generator having values 0−J with probabilities Φ_i0-Φ_iJ, respectively. If a value of “0” is generated, then the request is blocked. The method shown in FIG. 2B may be implemented by the algorithm every time a rerouted request is received within the system.

FIG. 2C illustrates a method of updating routing probabilities for the methods of routing requests that are shown in FIGS. 2A and 2B. The method shown in FIG. 2C may be run continuously and may be implemented without determining input rates of different request types. Similar to the load balancing algorithm described with reference to FIG. 1C, the software and/or hardware implementing the algorithm runs steps S210-S230 periodically and/or at time intervals. For example, the algorithm performs S210 at time points τ/r, 2τ/r, 3τ/r and so on. One of ordinary skill in the art should understand that τ may be changed to alter the responsiveness of the algorithm.

For a value of j, at S210, the algorithm determines whether a first condition,

$\begin{array}{cc}\underset{i}{\max }{\mu }_{\mathrm{ij}}\left[\sum _{k=1}^I{p}_{\mathrm{ik}}^{\left(j\right)}\left(w_{\mathrm{ik}}^{\left(j\right)}-\eta V_i+\eta V_k\right)+p_{i0}^{\left(j\right)}\left(w_{i0}^{\left(j\right)}-\eta V_i\right)\right]>0& \left(23\right)\end{array}$

is satisfied, wherein p_ij^(j) is a probability that request type i served by pool j is rerouted as request type k (probability of rerouting), and V_k is a queue value for request type k. In other words, the virtual queue V_k for each request type k models or represents a number of requests of the request type k in a virtual queue.

If the first condition of (23) is not satisfied, the algorithm determines whether all of the server pools 1−J have been checked at S220.

If the first condition of (23) is satisfied then the algorithm updates values V_i*, V_i, A_i*j and A_i0 at S215 for each server pool 1−J.

At S215, the algorithm first picks:

$\begin{array}{cc}{i}^{*}\in \underset{i}{\arg \max }{\mu }_{\mathrm{ij}}\left[\sum _{k=1}^I{p}_{\mathrm{ik}}^{\left(j\right)}\left(w_{\mathrm{ik}}^{\left(j\right)}-\eta V_i+\eta V_k\right)+p_{i0}^{\left(j\right)}\left(w_{i0}^{\left(j\right)}-\eta V_i\right)\right]& \left(24\right)\end{array}$

The algorithm updates values V_i*, V_i, A_i*j and A_i0 as follows:V_i*:=V_i*+τβ_jμ_i*,j(1−p_i*,i*)  (25)V_i:=[V_i−τβ_jμ_i*,jp_i*,i]⁺, iε, i≠i*  (26)A_i*,j:=A_i*,j+τβ_jμ_i*,j  (27)A_i0:=A_i0+[V_i−τβ_jμ_i*,jp_i*,i]⁻, iε, i≠i*  (28)

Once the algorithm updates values V_i*, V_i, A_i*j and A_i0, the algorithm determines if all of the server pools have been checked at S220. If all of the server pools have not been checked, then the algorithm proceeds to the next server pool j+1 at S225 and determines if the first condition is met for the next server pool at S210.

At this point, the loop on j ends. When all of server pools 1−J have been checked, the algorithm updates the probability of routing Φ_ij and Ā_ij based on the queue value and a probability of rerouting and, more specifically, steps S205-S220 at S230.

The algorithm determines the probability of routing Φ_ij and Ā_ij for all (i,j) as follows:

$\begin{array}{cc}{\stackrel{\_}{A}}_{\mathrm{ij}}:={\eta }_1{A}_{\mathrm{ij}}+\left(1-{\eta }_1\right){\stackrel{\_}{A}}_{\mathrm{ij}},i\in ,j\in ,j=0& \left(29\right)\\ {\varphi }_{\mathrm{ij}}:=\frac{{\stackrel{\_}{A}}_{\mathrm{ij}}}{\sum _m{\stackrel{\_}{A}}_{\mathrm{im}}},i\in ,j\in ,j=0& \left(30\right)\end{array}$

Once the probability of routing Φ_ij and Ā_ij are determined, A_ij is set to zero.

Since the algorithm may run continuously at time intervals, the algorithm may wait for the next time point of τ/r, 2τ/r, 3τ/r at S240 and return to perform steps S210-S230.

Moreover, the system may tag requests, instead of blocking or dropping the requests. Thus, the tagged requests may still be routed for service according to the same rule, but treated with lower priority while receiving or waiting for service.

FIG. 3 illustrates a system for routing requests according to an example embodiment. As shown, a system 300 includes a router 310 and server pools 320_1-320_n. In FIG. 3, n equals 3, but it should be understood that n may be any number greater than or equal to 1.

While “router” is used to refer to 310, it should be understood that the router 310 may be a gateway or any other element that is configured to receive requests and include the algorithm of FIGS. 1A-1C and 2A-2C implemented in software or hardware.

The router 310 is configured to receive requests of request types i and k. For the sake of simplicity, two types of requests are used to describe example embodiments, however, it should be understood that example embodiments are not limited to two types of requests. The router includes a virtual system 315. The virtual system 315 is either implemented in hardware or software of the router 310. The virtual system 315 is configured to implement the algorithm as described with reference to the methods shown in FIGS. 1A-1C and 2A-2C.

The virtual system 315 is configured to implement the algorithm when a request is received and at certain time points. The router routes the request according to the current values of routing probabilities to at least one of the server pools 320_1-320_n. For example, if the system 315 is overloaded, the system 315 blocks or routes the request using a random number generator having values 0−J with probabilities Φ_i0-Φ_iJ, respectively. If a value of “0” is generated, then the request is blocked.

As shown, the server pools 320_1-320_n may include queues M_i1−M_in and M_k1−M_kn for the requests of request types i and k, respectively. Once the requests are routed and served, each request has a probability p_ik^(j) that request type i served by pool j is rerouted as request type k (or vice versa), shown by the doted arrows returning to the router 310 and brings the system a corresponding reward w_ij^(j). Additionally, each request has a probability p_i0^(j) of exiting the system 300, and the corresponding reward w_i0^(j).

As described above, example embodiments include “running” a virtual (shadow-system) queuing system based on actual arrivals of customers to the network. Example embodiments produce routing automatically, without explicitly solving the linear program and measuring input rates. Thus, example embodiments have a lower implementation complexity and higher robustness.

Example embodiments do not require knowledge or of input rates of different types of requests. Moreover, example embodiments disclose methods for server pool load balancing when a system is not overloaded, and other methods for managing system revenue when the system is overloaded. Methods for managing system revenue (reward) picks customers that should be blocked, i.e., denied service.

Example embodiments being thus described, it will be obvious that the same may be varied in many ways. Such variations are not to be regarded as a departure from the spirit and scope of example embodiments, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the claims.

Claims

1. A method of routing requests within a system having a plurality of server pools, the method comprising: receiving a request at the system;first determining a first value associated with a first request type of the received request, the first value modeling a number of requests of the first request type in a virtual queue;second determining probabilities of routing based on the first value and probabilities of rerouting for further processing, the second determining being performed without determining an input rate of received requests of the first request type; androuting the received request to at least one of the plurality of server pools based on the probabilities of routing.

2. The method of claim 1, wherein the first determining includes, increasing the first value.

3. The method of claim 1, wherein the second determining includes, updating the first value periodically.

4. The method of claim 3, wherein the first determining determines the first value associated with the first request type, the first request type being one of a plurality of request types and each of the plurality of request types having an associated value, the first value being the associated value for requests of the first request type, andthe updating updates the associated values for the plurality of request types.

5. The method of claim 3, wherein the updating is based on a mean service time for requests of the first request type, a probability of rerouting associated with the first request type and a second value, the second value modeling a number of requests of the second request type in a virtual queue.

6. The method of claim 5, wherein the updating updates the first value if

7. The method of claim 6, wherein the updating updates the first value if

8. The method of claim 7, wherein the updating updates the first value Qi and determines values Sj, Qi* and Ai*,j as follows Sj=min{Qi,cτβjμi*,j}Qi*:=Qi*−(1−pi*,i*)Sj Qi:=Qi+pi*,iSj, iε, i≠i* Ai*,j:=Ai*,j+Sj

9. The method of claim 8, wherein the updating includes determining an average of the value Aij and the probability of routing as follows: Āij:=η1Aij+(1−η1)Āij

10. The method of claim 5, wherein the updating updates the first value if

11. The method of claim 10, wherein the updating updates the first value Vi and determines values Ai0, Vi* and Ai*,j as follows: Vi*:=Vi*+τβjμi*,j(1−pi*,i*)Vi:=[Vi−τβjμi*,jpi*,i]+, iε, i≠i* Ai*,j:=Ai*,j+τβjμi*,j Ai0:=Ai0+[Vi−τβjμi*,jpi*,i]−, iε, i≠i*

12. The method of claim 11, wherein the updating includes determining an average of the value Aij and the probability of routing as follows:

13. The method of claim 1, wherein the first determining is not based on measurements of input rates of different request types.

14. The method of claim 1, wherein the first determining includes, decreasing the first value associated with the first request type.

15. A method of controlling a routing system, the method comprising: receiving a request having a first request type, the first request type being associated with a first value, the first value modeling a number of requests of the first request type in a virtual queue;updating the first value periodically based on a mean service time to process the request and at least a second value associated with a second request type, the updating being performed without determining an input rate of received requests of the first request type and, the second value modeling a number of requests of the second request type in a virtual queue; androuting the request based on the updating.

16. The method of claim 15, wherein the updating updates the first value if

17. The method of claim 15, wherein the updating updates the first value if

18. The method of claim 15, further comprising: increasing the first value associated with the first request type when the request is received.

19. The method of claim 15, further comprising: decreasing the first value associated with the first request type when the request is received.

20. The method of claim 15, wherein the updating includes, determining a probability of routing based on the mean service time to process the request, at least the second value and a probability of rerouting, andthe routing routes the request based on the probability of routing.