Momentos del duelo

A private telephone company exploits a network, represented in Figure12.4, between five cities: Paris, Nantes, Nice, Troyes, and Valenciennes.

Nice Valenciennes 300 70 Troyes Nantes Paris 120 300 80 200

Figure 12.4:Structure of the network of the company

The number beside each edge (connection) is the capacity of the link in terms of circuits. This issue is worth some further explanation. Suppose that a person A at Nantes calls a person B at Nice. The company needs to find a path formed by non-saturated edges from Nantes to Nice to route the binary flow corresponding to the digitized voice of A. But the conversation is only possible if a flow from Nice to Nantes is established so that B may answer A. In digital telephone networks, the binary flows all have the same throughput standard (often 64 kbps). The associated capacity is called a channel. The return channel uses the same edges as the first channel, but in the opposite direction. This linked pair of channels necessary for a telephone conversation is a circuit.

The routing of the return channel through the same edges is due to the fact that the call could fail if one waited until the callee picked up the phone before searching for a non-saturated return path. This is why, at the moment of the call, the routing system constructs the path edge by edge and immediately reserves the edges of the return channel. As a consequence, as the capacity of an edge is consumed in increments of a bidirectional circuit, we do not consider any directed flows. For example, there may be 10 persons calling from Nantes to Nice and 20 from Nice to Nantes, or the opposite: in both cases, 30 circuits are used.

At a given moment, the company is facing demands for circuits given in the following table. Is it possible to satisfy the demands entirely? If this is not possible, try to transmit as much as possible. In every case, indicate the corresponding routing, that is, the access paths used.

12.3.1

Model formulation

In the maximum flow problem in Section15.1(water supply management) the task is to maximize the total throughput of a single product flow that traverses a limited capacity network between an origin

Table 12.3:Demand of circuits Names of the cities Circuits Nantes-Nice 100 Nantes-Troyes 80 Nantes-Valenciennes 75 Nice-Valenciennes 100 Paris-Troyes 70

(source) and a destination (sink). Here, we are dealing with a generalization called the multi-commodity network flow (MCNF) problem: several flows that may not be mixed and that correspond to different products use the same network, every flow having its own source and sink. The objective is still to maximize the total throughput. Here, a ‘product’ corresponds to the totality of calls exchanged between two given cities. The calls between two different pairs of cities may not be mixed: calls between Nantes and Nice must not end in Troyes!

The MCNF problem is a difficult combinatorial problem. In the classical maximum flow problem, Linear Programming uses flow variables flownmfor every arc (n, m). The simplex algorithm automatically finds integer-valued optimal flows if the arc capacities are integers. It is possible to generalize this model to solve the MCNF problem in a directed graph with variables flowknm for the flow of product k on the arc (n, m) but the values at the end of the LP are not usually integers. Optimally rounding the fractional flows is very difficult because there may be several flows that are routed through the same saturated arc. Furthermore, the model with three-index variables requires certain tricks for dealing with an undirected network as is the case in the present example. We are therefore going to use a simpler formulation called arc-paths.

This formulation is based on different elementary paths (without intermediate nodes in common) that may be used between pairs of cities that are communicating. Instead of using variables flowknmfor every pair of cities k and every arc (n, m), this formulation uses a single variable flowp for the flow all along a path p, where this path corresponds to a known pair of cities. The flow conservation laws per node are therefore implicitly fulfilled. This formulation cannot be employed in dense networks with an enormous number of possible paths. But for telecommunication networks that have a skeleton-like structure it is better than modeling with three-index flow variables.

For the data, we use ARCS for the set of (undirected) arcs, CALLS for the set of city pairs between which there are demands for calls, and PATHS the set of paths. Let CAPadenote the capacity of an arc and DEMc the demand for a city pair c. We also need to know which pair of cities is at the ends of every path, given by the call index CINDEXp. The arc-paths formulation is then remarkably easy. It is called ‘arc-paths’ because it works with arcs and paths, but not with nodes.

maximize X p∈PATHS flowp (12.3.1) ∀a ∈ ARCS : X p∈PATHS a∈p flowp≤ CAPa (12.3.2) ∀c ∈ CALLS : X p∈PATHS CINDEXp=c flowc≤ DEMc (12.3.3) ∀p ∈ PATHS : flowp∈IN (12.3.4)

The objective function is to maximize (12.3.1), the sum of the flows on all paths that may be used. The constraints (12.3.2) consider every arc a: the sum of flows on the paths passing through a must not exceed the capacity of a. The constraints (12.3.3) concern every pair of cities c: the sum of flows exchanged between them over the various paths must not exceed the demand for circuits. The integrality constraints (12.3.4) are necessary because the MCNF problem is not automatically integer at its linear optimum.

12.3.2

Implementation

The translation of the mathematical model for Mosel is given in the following program. This is a typical case where after the formulation of the mathematical model some work still is left to do for the formu- lation of the model with Mosel since no direct representation of the paths is immediately available. The pairs of cities are named as represented in Table12.3. Similarly, the arcs are named with the cities they connect: Nantes-Paris, Nantes-Nice, Paris-Nice, Paris-Valenciennes, Troyes-Nice and Troyes-Valenciennes. The paths are coded as a two-dimensional array ROUTEpa, every line of which corresponds to a path and

contains the list of edges it uses. In the worst case, a path may contain all the arcs since the paths are ele- mentary and do not visit any city twice. The size of the second dimension of the array ROUTE is therefore given by the number NARC of arcs in the problem. The following table lists the complete set of paths and the corresponding city pairs at the ends of every path (array CINDEXp). With this representation, the model can now be implemented easily.

Table 12.4:Definition of paths Path City pair List of arcs

1 Nantes-Nice Nantes-Nice

2 Nantes-Nice Nantes-Paris, Paris-Nice

3 Nantes-Nice Nantes-Paris, Paris-Valenciennes, Valenciennes-Troyes, Troyes-Nice 4 Nantes-Troyes Nantes-Paris, Paris-Valenciennes, Valenciennes-Troyes

5 Nantes-Troyes Nantes-Paris, Paris-Nice, Nice-Troyes 6 Nantes-Troyes Nantes-Nice, Nice-Troyes

7 Nantes-Troyes Nantes-Nice, Nice-Paris, Paris-Valenciennes, Valenciennes-Troyes 8 Nantes-Valenciennes Nantes-Paris, Paris-Valenciennes

9 Nantes-Valenciennes Nantes-Nice, Nice-Paris, Paris-Valenciennes

10 Nantes-Valenciennes Nantes-Paris, Paris-Nice, Nice-Troyes, Troyes-Valenciennes 11 Nantes-Valenciennes Nantes-Nice, Nice-Troyes, Troyes-Valenciennes

12 Nice-Valenciennes Nice-Nantes, Nantes-Paris, Paris-Valenciennes 13 Nice-Valenciennes Nice-Paris, Paris-Valenciennes

14 Nice-Valenciennes Nice-Troyes, Troyes-Valenciennes 15 Paris-Troyes Paris-Valenciennes, Valenciennes-Troyes 16 Paris-Troyes Paris-Nantes, Nantes-Nice, Nice-Troyes 17 Paris-Troyes Paris-Nice, Nice-Troyes

Making the path inventory is quite tedious, but the collection of data is usually a major problem in Mathematical Programming. In industrial applications, the data files must be constructed automatically by some special purpose software (in the examples of Sections 11.2 or 12.5 we use Mosel for doing some data preprocessing) or be extracted from databases or spreadsheets. The full distribution of Mosel includes modules for accessing databases or spreadsheets directly.

model "G-3 Routing telephone calls" uses "mmxprs"

declarations

CALLS: set of string ! Set of demands ARCS: set of string ! Set of arcs

PATHS: range ! Set of paths (routes) for demands CAP: array(ARCS) of integer ! Capacity of arcs

DEM: array(CALLS) of integer ! Demands between pairs of cities CINDEX: array(PATHS) of string ! Call (demand) index per path index end-declarations

initializations from ’g3routing.dat’ CAP DEM INDEX

end-initializations

finalize(CALLS); finalize(ARCS); finalize(PATHS) NARC:=getsize(ARCS)

declarations

ROUTE: array(PATHS,1..NARC) of string ! List of arcs composing the routes flow: array(PATHS) of mpvar ! Flow on paths

end-declarations

initializations from ’g3routing.dat’ ROUTE

end-initializations

! Objective: total flow on the arcs TotFlow:= sum(p in PATHS) flow(p) ! Flow within demand limits

! Arc capacities forall(a in ARCS)

sum(p in PATHS, b in 1..NARC | ROUTE(p,b)=a) flow(p) <= CAP(a) forall(p in PATHS) flow(p) is_integer

! Solve the problem maximize(TotFlow) end-model

12.3.3

Results

The LP solution to this problem has integer values. 380 out of the required 425 calls are routed, that is all but 45 Nantes-Troyes calls. The following table lists the corresponding routing of telephone calls (there are several equivalent solutions). On the connections Nantes-Paris, Nantes-Nice, Paris-Nice, and Troyes-Valenciennes there is unused capacity; the other arcs are saturated.

Table 12.5: Optimal routing of telephone calls City pair Demand Routed Path

Nantes-Nice 100 100 Nantes-Paris, Paris-Nice

Nantes-Troyes 80 35 Nantes-Nice, Nice-Paris, Paris-Valenciennes, Valenciennes-Troyes

Nantes-Valenciennes 75 75 Nantes-Paris, Paris-Valenciennes Nice-Valenciennes 100 20 Nice-Paris, Paris-Valenciennes

80 Nice-Troyes, Troyes-Valenciennes Paris-Troyes 70 70 Paris-Valenciennes, Valenciennes-Troyes