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.
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.
Example embodiments will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings.
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
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 pik(j), brings a system operator a reward wik(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
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 that
iε={1, . . . ,I} (2A)
and
jε={1, . . . ,J} (2B)
Load Balancing
It should be understood that the methods of
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:
The minimization of ρ is subject to:
The algorithm implemented in the methods of
For each request type i and server pool j, variables Aij, Ā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 Aij. Aij and Āij are initialized to zero at the beginning of the algorithm. Small parameters, η and η1 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 η1 may be between 1/r and 1/sqrt(r), assuming βj is one and r is a large value.
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
is satisfied, wherein τ and c are parameters greater than zero, pij(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 pik(j), service rates μij, and rewards wij(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,
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 Sj, and updates values i*, i and Ai*j at S120 for each server pool 1−J.
At S120, the algorithm first picks:
The algorithm determines Sj, and updates i*, i and Ai*j as follows:
Sj=min{Qi,cτβjμi*,j} (11)
Qi*:=Qi*−(1−pi*,i*)Sj (12)
Qi:=Qi+pi*,iSj, iε, i≠i* (13)
Ai*,j:=Ai*,j+Sj (14)
Once the algorithm determines Sj, and updates i*, i and Ai*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 pij(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:
Once the probability of routing Φij and Āij are updated, Aij 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
It should be understood that the methods of
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:
The maximum is subject to:
The algorithm implemented in the methods of
For each request type i and server pool j, variables Aij, Āij, Φij, Ai0, Āi0, and Φi0 are maintained. Φi0 is a probability that a request type i request will be blocked. Ai0 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
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 Vi for the request of request type i at S105, thus,
Vi:=[Vi−1]+, (21)
and
Ai0:=Ai0+[Vi−1]− (22)
where [Vi−1]− is a number of requests which are block or dropped. In other words, the virtual queue Vi for each request type i models or represents a number of requests of the request type i in a virtual queue.
While
For a value of j, at S210, the algorithm determines whether a first condition,
is satisfied, wherein pij(j) is a probability that request type i served by pool j is rerouted as request type k (probability of rerouting), and Vk is a queue value for request type k. In other words, the virtual queue Vk 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 Vi*, Vi, Ai*j and Ai0 at S215 for each server pool 1−J.
At S215, the algorithm first picks:
The algorithm updates values Vi*, Vi, Ai*j and Ai0 as follows:
Vi*:=Vi*+τβjμi*,j(1−pi*,i*) (25)
Vi:=[Vi−τβjμi*,jpi*,i]+, iε, i≠i* (26)
Ai*,j:=Ai*,j+τβjμi*,j (27)
Ai0:=Ai0+[Vi−τβjμi*,jpi*,i]−, iε, i≠i* (28)
Once the algorithm updates values Vi*, Vi, Ai*j and Ai0, 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:
Once the probability of routing Φij and Āij are determined, Aij 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.
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
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
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 Mi1−Min and Mk1−Mkn for the requests of request types i and k, respectively. Once the requests are routed and served, each request has a probability pik(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 wij(j). Additionally, each request has a probability pi0(j) of exiting the system 300, and the corresponding reward wi0(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.
Number | Name | Date | Kind |
---|---|---|---|
6175869 | Ahuja et al. | Jan 2001 | B1 |
6338089 | Quinlan | Jan 2002 | B1 |
7207043 | Blythe et al. | Apr 2007 | B2 |
20030195962 | Kikuchi et al. | Oct 2003 | A1 |
20060031536 | Eydelman et al. | Feb 2006 | A1 |
20070150329 | Brook et al. | Jun 2007 | A1 |
20110072436 | Gilat et al. | Mar 2011 | A1 |
20110161980 | English et al. | Jun 2011 | A1 |
Entry |
---|
Stolyar, Aleksandr “Maximizing Queueing Network Utility Subject to Stability: Greedy Primal-Dual Algorithm”. Queueing Systems 50, pp. 401-457, 2005. |
Number | Date | Country | |
---|---|---|---|
20120005370 A1 | Jan 2012 | US |