Designing tributary networks with multiple ring families

PII:

Computers Ops Res. Vol. 25, No. 12, pp. 1145±1157, 1998 # 1998 Published by Elsevier Science Ltd. All rights reserved Printed in Great Britain S0305-0548(98)00005-7 0305-0548/98 $19.00 + 0.00

DESIGNING TRIBUTARY NETWORKS WITH MULTIPLE RING FAMILIES John G. Klincewicz,1{ Hanan Luss1 and Dicky C. K. Yan2 1 AT&T Labs, Holmdel, NJ 07733, U.S.A. AT&T Network and Computing Services, Bedminster, NJ 07921, U.S.A.

2

(Received 1 June 1997; accepted 1 January 1998) Scope and PurposeÐAdvances in telecommunication technology result in improved service, but can also lead to dicult and challenging network design problems. For example, networks in which nodes are connected by rings of optical ®ber can now be used to provide rapid service restoration in the event of a failure. However, as a result, network designers are faced with the new problem of designing networks based on topological ring structures. In this paper, we consider the particular case of tributary network design. In a tributary network, a group of nodes are connected to a hub node, which is used as a point of interconnection with other parts of the network. For a particular network architecture, we describe an algorithm to determine how many topological ring structures are required, and which nodes should be included on each. We highlight connections between this problem and problems in vehicle routing. AbstractÐA common architecture for a telecommunications network consists of several tributary (often called access) networks, which connect locations to hubs, and a backbone network, which interconnects the hubs. This paper describes a heuristic approach for designing tributary networks based on selfhealing rings (SHRs). The tributary network consists of multiple ring families, and each of those is comprised of one or more SHRs, called ``stacked'' rings. The SHRs in a given ring family are routed over the same cycle of optical ®ber cables, but each SHR serves only a subset of the locations along the cycle. Each demand location is assigned to a single SHR on one of the ring families, whereas the hub is assigned to all SHRs on all ring families. A link that is used by some ring family incurs a ®xed cost plus a variable cost per SHR associated with that family. Each SHR is constrained by the demand volume it can handle and by the number of locations it can serve. This tributary ring network design problem can be viewed as a complex version of a vehicle routing problem with a single-depot and multiple vehicles. Our algorithm is initiated with numerous ring families. It then attempts to merge these families, while ensuring that savings are realized in terms of the sum of ®xed and variable costs. # 1998 Published by Elsevier Science Ltd. All rights reserved Key words: Network design, telecommunications networks, routing, combinatorial heuristics

1. INTRODUCTION

A telecommunications network interconnects a set of locations (nodes) in order to be able to serve a set of point-to-point trac demands. In a network design, one must indicate which node-pairs are to be linked by transmission facilities, as well as how demand is to be routed over these links. A common architecture for a telecommunications network consists of several tributary (often called access) networks, joined by a single backbone network. Each tributary network connects a subset of the network nodes to a hub. The backbone network then interconnects the hubs. This architecture allows nodes in di€erent tributary networks to communicate with each other via the hubs. Designing an overall backbone/tributary network is very complex. Given a large set of nodes, it is necessary to ®rst determine which nodes will act as hubs and be assigned to the backbone network. Algorithmically, this is often accomplished by using a combination of add, drop, and exchange heuristics. (Results could be enhanced through the use of more recent techniques such as simulated annealing, tabu search, etc. [13].) Since many combinations of backbone nodes are evaluated, this task is computationally expensive and the facility and routing costs are estimated using rough approximations. Often, in practice, certain nodes may be designated a priori to be included among the hubs because they have high trac volumes or {To whom all correspondence should be addressed. 1145

1146

John G. Klincewicz et al.

because they are gateways to other networks, etc. Once the backbone nodes are determined, remaining nodes are assigned to tributary networks. Thereafter, the various tributary networks and the backbone network are designed with detailed facility and routing decisions. Typically, tributary networks have consisted of topologies such as ``stars'' (i.e. each node in the tributary network is connected directly to the hub), ``trees'' (i.e. nodes are connected to the hub via multi-point or multi-drop lines) or ``loops'' (i.e. nodes in the tributary network form a cycle). Many well-known algorithms exist for designing such tributary networks, e.g. Ref. [7]. However, in recent years, developments in synchronous (SONET/SDH) transmission products have led to considerable interest in using self-healing rings (SHRs) in both tributary and backbone networks. SONET/SDH ring networks have the advantage of providing very rapid service restoration, within milliseconds, in the event of a single-link or single-node failure. Figure 1 depicts an SHR with seven demand nodes, labeled as nodes 0, 1, . . ., 6. These nodes are arranged in a cycle and linked by a pair of optical ®bers. An add-drop multiplexer (ADM) is located at each node to handle the demand that originates or terminates at the node. The ring has two ®bers, one for carrying demand in a clockwise direction and the second for carrying demand in a counter-clockwise direction. An SHR has both ``working capacity'' and ``protection capacity''. Working capacity is used to serve demand under ordinary circumstances; protection capacity is used in the event of a single link or single node failure. The ``capacity'' of an SHR refers to the ``working capacity'' and is the same as the ADM capacity. All ADMs around a ring have the same capacity, e.g. OC-3 (155.52 Mbps), OC-12, etc. One type of SHR is the two-®ber uni-directional ring. The ®ber in one direction, say clockwise, is the ``working'' ®ber, whereas the other ®ber is the ``protection'' ®ber. The demand between any node-pair utilizes the working ®ber over the entire ring. As a result, the capacity of the working ®ber on a uni-directional ring must be as large as the sum of all point-to-point demands that are carried on the ring. A di€erent type of ring is the two-®ber bi-directional ring, where, again, one ®ber carries demand clockwise and the second ®ber carries demand counter-clockwise. However, the capacity of each ®ber is equally divided between working capacity and protection capacity. The demand between any node-pair is routed on the working capacity of both ®bers, using only some of the links along the ring. For example, the demand between nodes 1 and 5 in Fig. 1 may use either the two ®bers on the path comprised of links connecting nodes 1, 2, 3, 4 and 5, or the two ®bers on the path with links connecting nodes 5, 6, 0 and 1. In case of failure of a link or a node along the selected path, the demand is rerouted on the protection capacity of the second path. The total demand carried on the working capacity of any link around the ring cannot exceed the ADM capacity. Algorithms to ``balance'' trac loads among the links of bi-directional rings are given, for example, by Cosares and Saniee [5], Harshavardhana et al. [6], Myung et al. [12], and Schrijver et al. [14]. Since in bi-directional rings the demand between every pair of nodes is routed only on some of the links, these rings can handle more demand than uni-directional rings. Four-®ber bi-directional rings are similar to two-®ber rings with two ®bers for working capacity, one in each direction, and two ®bers for protection capacity. For more detailed

Fig. 1. A self-healing ring.

Tributary networks with multiple ring families

1147

Fig. 2. A tributary ring network.

explanations of SONET technology and SHRs, see, e.g. the book by Wu [17]. The literature on SONET ring network design has been growing in recent years. A sample of references include Cosares et al. [4] and Wasem et al. [16] who describe network design procedures for ring-based SONET networks, and Luss et al. [11] who describe an algorithm for selecting inter-networked rings from among a large set of candidate rings. We describe an approach for designing a tributary network using SHRs. We call this the tributary ring network design problem (TRNDP). The tributary network is assumed to be part of a larger telecommunications network with a backbone/tributary architecture. We assume that a hub and a particular set of demand nodes have already been speci®ed for the given tributary network. Note that the demand nodes may exchange trac with nodes in other tributary networks. Since this trac must pass through the hub, it is treated as demand between a demand node and the hub. The architecture of our tributary network is illustrated in Fig. 2. There, each of the 10 demand nodes is assigned to one of two ring families, where a ring family is de®ned as a cycle of optical ®ber cables. The hub is assigned to all ring families. Thus, ring family 1 includes the hub node and demand nodes 1 through 6, while ring family 2 includes the hub node and demand nodes 7 through 10. The demand between two nodes residing on di€erent ring families must be routed through the hub. In order to increase network reliability, it may be desired to connect each tributary network to two hubs. This will be discussed in Section 5. Now, suppose that the trac that needs to be carried on ring family 1 exceeds a single SHR's capacity (the ADM capacity). In that case, multiple SHRs, called stacked rings (also called parallel or concentric rings), must be designed. In a stacked ring design, each SHR in a ring family follows the same cycle, but it serves only a subset of the demand nodes associated with the ring family. In our model, we assume that each demand node is assigned to a single SHR, whereas the hub is assigned to all SHRs. Thus, in ring family 1 of Fig. 2, demand nodes 1, 3 and 4 are assigned to SHR 1, whereas demand nodes 2, 5 and 6 are assigned to SHR 2 (the assignment of nodes to the SHR is depicted by the number in the nodes). Again, trac between nodes on di€erent SHRs are routed through the hub. Note that, in our model, each demand node requires a single ADM. The hub in Fig. 2 requires four ADMs residing on four SHRs. Alternatively, at the hub, we may install a single Digital Cross Connect (DCS) machine instead of the multiple ADMs. Such a DCS machine would have SONET interfaces so that ADMs would not be needed at the hub. TRNDP is driven by two cost elements. Each link used by a ring family incurs a ®xed cost plus a variable cost per SHR associated with that ring family. The ®xed cost may represent the cost of installing a conduit and/or of acquiring right-of-way. The variable cost may represent the ®ber cost of an SHR as well as the cost of regenerators that need to be installed on each SHR along the link. Large ®xed cost would tend to generate fewer, but larger ring families. In

1148

John G. Klincewicz et al.

the extreme, a single ring family would be proposed as it typically results in the lowest overall ®xed cost. On the other hand, large variable cost would tend to favor a larger number of smaller ring families in order to reduce total SHR-miles. The ADM costs are ignored since each demand node has a single ADM, independent of the design. Overall, this represents a slight approximation since the number of ADMs at the hub does depend on the total number of SHRs over all ring families. TRNDP can be viewed as an extension of a single-depot vehicle routing problem with multiple vehicles, where each vehicle serves many customers. Each vehicle forms, in our context, a ring family. The nodes served by a ring family are analogous to the locations served by a vehicle. The number of SHRs on a ring family may be viewed as the vehicle size needed to serve the locations along its route. For a review of vehicle routing problems, and of the Traveling Salesman Problem see [2]. Since the vehicle routing problem is NP-hard, so is TRNDP. Even some of the subproblems that need to be addressed while solving TRNDP are NP-hard. These include the design of a minimum-cost cycle for a ring family (this is the Traveling Salesman Problem), assigning nodes to each of the SHRs in a ring family, and balancing the load in bidirectional SHRs. Models for a single ring family, where each demand node can be assigned to multiple SHRs are presented in Armony et al. [1] and in Laguna [10]. Kang et al. [8] present a clever algorithm to solve a variant of TRNDP for uni-directional SHRs. Their algorithm may, however, require excessive computing time for realistic network sizes. Given the complexity of TRNDP, we focus on developing computationally ecient heuristics for the various subproblems that need to be addressed and on integrating them into an e€ective solution method for large tributary networks. In Section 2, TRNDP is described. Section 3 provides the solution approach, and Section 4 presents computational results. Several extensions are described in Section 5. 2. THE TRIBUTARY RING NETWORK DESIGN PROBLEM

We describe TRNDP in terms of the input parameters, design decisions, constraints, and the objective function. 2.1. Input parameters The input parameters describe the demands, costs, and constraints. We use the following notation: i (or j)=Indices for nodes; i = 0 represents the hub and i (or j) = 1, 2, . . ., n represent demand nodes, where n is the total number of demand nodes. dij=Demand between nodes i and j. By convention, the demands are de®ned for 0 Ri < jR n. Demand d0j includes demands between nodes at other tributary networks and node j. (i, j)=Link connecting nodes i and j. The links are undirected. fij=Fixed cost of establishing a link between nodes i and j. vij=Cost per SHR on a link between nodes i and j. C=SHR capacity (i.e. ADM capacity). This is the maximal demand volume that can be carried on any link along the SHR. All SHRs have the same capacity. E=Maximal number of demand nodes (in addition to the hub) that can be assigned to a SHR.

Note that in many applications the ®xed and variable costs of a link are proportional to its length. If a link should not be used, then its ®xed cost is set at a high number. 2.2. Design decisions The decisions include the design of ring families and SHRs on each ring family. Each ring family serves the hub and a subset of the demand nodes. The ring family topology is a single cycle that passes through each of its nodes precisely once. Each SHR on a given ring family follows the same cycle as the ring family, but serves only a subset of the demand nodes assigned to

Tributary networks with multiple ring families

1149

that ring family. Note that a segment between two successive nodes on an SHR is comprised of one or more links of the corresponding ring family. Whereas the hub resides on all SHRs, each demand node is assigned to only one SHR. Let: L=Number of ring families to be designed. l (or m)=Index for ring families, l (or m) = 1, 2, . . ., L. Nl=Set of demand nodes served by ring family l, not including the hub. Rl=Set of links describing the cycle of ring family l. For example, in Fig. 2, R2={(0, 7), (7, 8), (8, 9), (9, 10), (10, 0)}. S(l)=Number of SHRs in ring family l. s=Index for SHRs in ring family l, s = 1, 2, . . ., S(l). r=Index for links on ring family l, r = 1, 2, . . ., vRlv. For example, in ring 2 of Fig. 2, we may denote link (0, 7) as r = 1, link (7, 8) as r = 2, etc. Nsl=Set of demand nodes assigned to SHR s on ring family l, not including the hub. For example, in Fig. 2, N12={7, 9} and N22={8, 10}. Since each demand node is assigned to only one SHR, any demand that originates or terminates at a demand node in Nsl must be routed on SHR s on ring family l. If node i is on one SHR and node j on another (in the same or di€erent ring family), then demand dij is routed on both SHRs through the hub. Demand d0j between the hub and node j is routed on the SHR which serves node j. In each bi-directional SHR, additional decisions are made regarding the routing selected for demand dij, where either i or j, or both, are contained in Nsl. The routing is determined by employing a load balancing algorithm. (We assume that load balancing enforces a single route for each dij. The case where demands can be split can also be handled [12].) Let: Bsl (r)= Set of node-pairs {i, j}, where either i or j, or both, are contained in Nsl, and whose demand dij is routed through link r on SHR s of ring family l.

2.3. Constraints The constraints can be classi®ed into those imposed on ring families and into those imposed on SHRs. For simplicity, only some of these are formulated below via mathematical notation. Precise formulations of constraints to ensure, for example, that links form a cycle are standard in vehicle routing problems [2], and would add very little to the exposition here. Consider ®rst the ring families. The topology of each ring family must follow a cycle, where each demand location is assigned to a single ring family and the hub is assigned to all ring families. Since a ring can use a link at most once, each ring family must include, in addition to the hub, at least two demand nodes. Consider now the SHRs. The SHRs associated with a given ring family follow the same topology as the ring family, but where each demand node of the ring family is assigned to a single SHR. The hub is assigned to all SHRs. In uni-directional SHRs, the demand between all nodepairs on the SHR cannot exceed the capacity C. Thus, the capacity constraint for each unidirectional SHR is: X …1a† dij RC for each SHR s in ring family l, l ˆ 1,2, . . . ,L, where the summation is over {i, j} pairs such that either i or j, or both, are contained in Nsl. Thus, the summation in equation (1a) accounts for all demands that any demand node in SHR s shares with other nodes on the same SHR, as well as with all other nodes that are not on the same SHR. In a bi-directional SHR, the demand routed through each link cannot exceed the capacity C, that is, X dij RC for each link r and SHR s in ring family l, l ˆ 1,2, . . . ,L: …1b† fi,j g2Bsl …r†

1150

John G. Klincewicz et al.

Note that if only one of the nodes i or j is in Nsl, the demand is routed between the hub and that node. The second constraint imposed on each uni-directional or bi-directional SHR simply ensures that the number of nodes assigned to each SHR does not exceed E, i.e. jNsl jRE

for each SHR s in ring family l,

l ˆ 1,2, . . . ,L:

…2†

In summary, a feasible uni-directional SHR must satisfy constraints (1a) and (2). A feasible bidirectional SHR must satisfy constraints (1b) and (2). Constraint (1b) implies ®nding the routing through a load balancing algorithm and ensuring that the resulting load carried on any of the links does not exceed C. Although not required by our algorithm, in practice, SHRs in a given tributary network are either all uni-directional or all bi-directional. 2.4. Objective function Each link that is part of ring family l incurs a ®xed cost plus a variable cost per SHR. Therefore, the cost incurred by ring family l is X ‰ fij ‡ S…l†ij Š: …3† Wl ˆ …i,j †2Rl

The objective function is, thus, expressed as Minimize

 X L Wl ,

…4†

lˆ1

where the number of ring families L is an outcome of the design. Since each demand node is assigned to a single SHR, it needs precisely one ADM, independent of the design. Hence, the ADM costs are not included in the model. Note, however, that the number of ADMs at the hub equals to the total number of SHRs, which, in turn, is determined by the design. Although we ignore the costs of these ADMs, our solution approach attempts to minimize the number of SHRs, so that this omission is reasonable. A similar argument holds if a DCS (instead of ADMs) is used at the hub.

3. ALGORITHM FOR THE TRIBUTARY RING NETWORK DESIGN PROBLEM

As discussed above, due to the complexity of TRNDP, we develop ecient heuristics to solve various components of the problem, and integrate them so that they form an e€ective solution method for the overall problem. The n demand nodes must be grouped into multiple ring families, where each demand node is assigned to a single ring family. Within each ring family, one or more SHRs need to be designed in order to satisfy the constraints. The heuristic is initiated with numerous ring families. It then attempts to merge pairs of ring families, based on ®xed and variable cost considerations. Essentially, ring-pair [l, m] (abbreviation used for pair of ring families) is a candidate for merger if the ratio of demand to ®xed cost dij/fij is large for some i $ Nl and some j $Nm. An outline of the algorithm is given below. 3.1. The TRNDP algorithm Step 1. Design initial ring families. Create n ring families, where ring family l includes the hub and node l; i.e., Nl={l} for l = 1, 2, . . . , n. These ``ring families'' serve only as a starting point; since each of these ring families has only two nodes, none of them will be in the ®nal solution. Set the cost Wl=2(f0l+v0l) for all l. Step 2. Prepare list of merger candidates. Compute pij=dij/fij for 1 Ri < jR n and sort the pij's in non-increasing order. Put the elements {i, j} in an ordered list LIST1. Note that if i $ Nl and j $ Nm, then {i, j} corresponds to ring-pair [l, m]. Initialize a list LIST2 of ring-pairs whose merger was unsuccessfully attempted (initially, LIST2 is empty).

Tributary networks with multiple ring families

1151

Step 3. Attempt to merge ring-pairs on candidate list LIST1. Repeat this step until all elements on LIST1 are processed. Suppose the next element is {i, j} where i $ Nl and j $ Nm. If l = m or the ring-pair [l, m] is in LIST2, go to the next element in LIST1. Otherwise, invoke the Ring Merging Routine, described below, for ring-pair [l, m]. There are two cases: . The ring families are not merged: add [l, m] to LIST2. . The ring families are merged: provide a new index to the merged ring families; revise the relevant parameters and sets that de®ne the new ring family and its SHRs; delete from LIST2 all pairs that include l or m. Step 4. Attempt to merge remaining ring-pairs. Repeat this step for each remaining ring-pair that is not on LIST2. Invoke the Ring Merging Routine and follow one of the two cases described in step 3. Step 5. Merge remaining initial two-node rings. Suppose remaining ring family l has only two nodes (0 and l). Set Wl arbitrarily large. Find the lowest ®xed cost flj from among all j, and suppose node j is assigned to ring-family m. Invoke the Ring Merging Routine with ring families l and m, and update relevant parameters and sets. The algorithm is greedy in nature, since a merger in step 3 is implemented if it is deemed economical, without considering its e€ect on possible future mergers. The resulting solution may depend on the ordered list prepared at step 2. As discussed in Section 5, other ordering criteria which give more weight to, say, the ®xed cost, can also be used. In particular, an ordering based on pij=dij/(fij)2 has also been used successfully. Although LIST1 includes many elements (on the order of O(n2)), the Ring Merging Routine is invoked in step 3 for only a small fraction of the number of elements on LIST1. In particular, when only a few ring families remain, most of the ring-pair candidates would be on LIST2. Step 4 is particularly important when only a small fraction of the demands dij are positive. In general, though, the number of merger attempts in this step is expected to be relatively small. Step 5 is rarely invoked. It ensures that all demand nodes are included in proper ring families. Consider the merger of a ring-pair [l, m]. An optimal design of a ring family should minimize the sum of all ®xed and variable costs incurred by the links used by the ring. We decompose this problem by ®rst ®nding a cycle that minimizes the sum of the ®xed costs, and thereafter, minimize the number of SHRs that need to be built along that cycle in order to serve all the nodes included in the ring family. Although this decomposition may lead to sub-optimization, it is quite reasonable as both the ®xed and variable costs of each link tend to be proportional to its length. An outline of the routine is given below. 3.2. The ring merging routine (for ring families l and m) Step 1. Initialization. Let q be the temporary index for the merged group. Construct the set of nodes in q, Nq=Nl [ Nm. Step 2. Design the cycle (ring topology) for the merged ring family. Use a Traveling Salesman Problem heuristic to ®nd a near-optimal cycle that connects the nodes in Nq [ 0, based on the ®xed costs associated with the links. The selected links form the set Rq. Step 3. Find a near-optimal solution for ring family q. Invoke the Stacked Ring Design Routine, described P below, to minimize the number S(q) of needed SHRs for ring family q. Compute the cost Wq= …i,j †2Rl [fij+S(q)nij]. Step 4. Accept or decline a merger. If Wq
1152

John G. Klincewicz et al.

adding a new link, as done in the ``savings algorithm'' of Clarke and Wright [3]. Then, only if the merged ring family looks promising, a 2-opt heuristic can be used to further improve the topology. The Stacked Ring Design Routine, invoked in step 4, assigns the demand nodes associated with a ring family to SHRs in a way that attempts to minimize the number of SHRs (and hence the variable costs), while satisfying the constraints. This problem is related to a component grouping problem in manufacturing [9]. The goal is to have demand nodes with relatively large demand between them on the same SHR. This would tend to minimize the number of SHRs, since it would minimize the amount of trac exchanged at the hub and carried on two SHRs. Our approach attempts to assign nodes to SHRs by incrementally combining group of nodes. Each time we try to add one or more nodes to an SHR, the appropriate constraints (namely, constraints (1a) and (2) for uni-directional rings, or constraints (1b) and (2) for bi-directional rings) are checked for the a€ected SHR to determine feasibility. An outline of the routine is given below. 3.3. The stacked ring design routine (for ring family l) Step 1. Initialization. Prepare a list of all demands dij with i, j $ Nl sorted in non-increasing order. Step 2. Design initial SHRs. Repeat this step until the list becomes empty. Choose the next node-pair, say nodes i and j, from the ordered list. There are three cases: . Neither node in the pair currently belongs to an SHR: open a new SHR with nodes 0, i and j, provided it satis®es the constraints. Otherwise, open two new SHRs, one with nodes 0 and i, and the other with nodes 0 and j. . One node (say, i) belongs to an SHR; the other (node j) does not: add node j to the SHR that has node i, provided the constraints are satis®ed. Otherwise open a new SHR with nodes 0 and j. . Each node in the pair is assigned to a di€erent SHR: Merge the two SHRs into one, provided the constraints are satis®ed. Otherwise, do nothing. Step 3. Assign nodes that were not on the list. If a particular node does not share demand with any other node in ring family l, then it was not assigned to any SHR. Add such nodes, one at a time, to an existing ring with the least number of nodes, provided the constraints are satis®ed. If a node cannot be added to any of the SHRs without violating a constraint, open a new SHR. Step 4. Reduce number of SHRs. Attempt to combine pairs of SHRs until further merging is not possible. Typically, step 2 searches through a large number, on the order of O(Nl2), of possible combinations for SHRs. Checking constraint (1a) for uni-directional rings requires very little computing e€ort. However, checking constraint (1b) for bi-directional rings requires solving a load balancing problem which requires signi®cantly more computing e€ort, depending on the balancing heuristic deployed. Step 3 simply takes care of nodes that share demand only with nodes on other ring families. Step 4 serves as a safeguard in the event that only a small fraction of the node-pairs share demand, in which case the number of combinations evaluated in step 2 may not suce. Further improvement in the solution, at the expense of additional computing e€ort, can be achieved by implementing a randomized scheme for selecting the next element to be processed in step 2 from among the top elements on the list, and repeating the heuristic multiple times [9]. 4. COMPUTATIONAL RESULTS

The algorithm for TRNDP that was described in Section 2 has been implemented in a C language program. Computational experiments were performed in a UNIX1 environment on a Sun Sparc 5 Workstation, with 64 MB of memory, using the SUN OS 4.1.4 operating system. As noted in Section 2, for bi-directional rings, step 2 of the Stacked Ring Design Routine requires that constraint (1b) be checked for feasibility. This requires solving a load balancing

Tributary networks with multiple ring families

1153

Table 1. Results for OC-12 rings No. of nodes

Total No. of demands demands in DS1s V/F (%) dij

Design I no. of ring families

20

190

1051

25

300

1592

30

435

2397

35

595

3228

5 25 50 5 25 50 5 25 50 5 25 50

1 1 1 1 2 2 2 2 3 2 3 4

no. of stacked rings

Design II

CPU time (s)

cost of design

no. of ring families

1.8 1.8 1.8 2.0 1.9 1.8 4.2 4.0 4.4 3.6 3.0 3.4

3.85 5.25 6.99 5.25 8.74 12.19 6.96 12.98 18.01 6.97 11.86 16.41

1 1 1 1 1 2 1 3 3 2 3 4

2 2 2 4 5 5 8 8 9 11 12 11

no. of stacked rings 2 2 2 4 4 5 8 8 8 11 11 12

CPU time (s)

cost of design

1.5 1.5 1.5 1.9 1.9 2.0 3.4 2.9 2.9 3.2 3.0 3.3

3.85 5.25 6.99 5.25 8.75 12.19 7.13 11.51 16.71 6.97 11.32 16.53

problem. Cosares and Saniee [5] were the ®rst to present several load balancing heuristics for bidirectional rings. In their simplest heuristic, at each iteration, the largest unrouted demand is routed so as to achieve the lowest possible load on the most loaded link along the ring. This method can be extended (proposed by Richard Wong) to evaluating, at each iteration, 2k routing combinations of the k largest unrouted demands in order to determine the routing of the largest unrouted demand. We found this heuristic attractive for testing purposes, as it can be used with di€erent values of k (in the experiments reported below, we used k = 3). Test problems were randomly generated. In particular, node location coordinates were generated randomly on the unit square, and one of these locations was randomly chosen to be the hub. For problems with 20±55 nodes, the demand between each pair of nodes was uniformly generated as an integer between 1 and 10 DS1s. For problems with 75±100 nodes the demand was uniformly generated as an integer between 1 and 5 DS1s. We assume that all links, between every pair of nodes, can be used. The ®xed cost for a link is proportional to its length. The variable cost associated with a given link is taken to be a speci®ed fraction of the ®xed cost. In our computational experiments, examples were run where the variable cost was 5%, 25% and 50%, respectively, of the ®xed cost. Experiments were performed for cases of bi-directional OC-12 (336 DS1s) rings and bi-directional OC-48 (1344 DS1s) rings. Table 1 displays the results for OC-12 rings and Table 2 the results for OC-48 rings. In these tables, the ®rst column lists the number of nodes in each Table 2. Results for OC-48 rings No. of nodes

Total No. of demands demands in DS1s V/F (%) dij

Design I no. of ring families

40

780

4197

45

990

5615

50

1225

6787

55

1485

8252

75

2775

8359

100

4950

14753

5 25 50 5 25 50 5 25 50 5 25 50 5 25 50 5 25 50

1 1 1 1 2 3 1 1 3 1 1 3 1 2 3 2 4 4

no. of stacked rings 3 3 3 3 4 4 4 4 5 6 6 6 6 6 6 11 12 11

Design II

CPU time (s)

cost of design

no. of ring families

9.0 8.7 9.4 15.0 8.9 10.3 19.9 21.0 14.1 26.0 31.3 31.4 54.3 71.3 52.1 72.1 48.6 60.4

6.07 9.24 13.21 6.88 9.87 12.23 6.96 11.60 13.66 7.48 14.38 18.22 9.48 14.21 16.84 11.36 17.12 24.18

1 1 2 1 2 4 1 1 2 1 1 3 1 4 4 2 4 4

no. of stacked rings 3 3 3 3 3 4 4 4 5 6 6 6 6 7 6 11 12 12

CPU time (s)

cost of design

5.9 6.1 6.0 11.8 14.5 8.6 14.5 18.8 10.7 19.6 23.8 24.5 54.4 47.2 38.8 49.4 46.5 47.1

6.07 9.24 12.88 6.88 10.18 11.76 6.96 11.60 16.20 7.48 14.38 19.71 9.48 13.23 16.10 10.92 15.99 23.01

1154

John G. Klincewicz et al.

Fig. 3. Solution for 45-node problem with V/F = 5%.

problem. The total number of demands dij generated (in our examples, all dij>0), and the total volume of demand (in DS1 units), is shown, for each problem, in columns 2 and 3. In the next column, ``V/F'' denotes the ratio between the variable (per stacked ring) link cost and the ®xed link cost. In the tables, each row corresponds to one set of nodes and demands, and the three sub-rows of each row corresponds to results obtained using cost ratios of 5%, 25% and 50%, respectively. Each problem was solved under two di€erent ordering criteria in step 2 of the TRNDP Algorithm. In design I, we used pij=dij/fij, giving equal weight to the demands and distances between the node-pairs. In design II, we used pij=dij/(fij)2, giving more weight to the distances between the node-pairs. For each problem, the next four columns list the solution obtained under design I (number of ring families, total number of stacked rings, the CPU time, and the cost of the design). The last four columns list the solution under design II. Out of the 30 examples shown, designs were identical in 14 cases. Design I was better in 6 cases by an average of 4.9%, whereas design II was better in 10 cases by an average of 5.9%. Thus, it appears that giving more weight to distances over demands produced slightly better solutions. The characteristics of the solutions obtained under design I and design II were very similar. Comparing the V/F = 5%, the V/F = 25% and the V/F = 50% solutions for the same set of nodes and demands, we see that the algorithm obtains solutions with more ring families as the cost ratio increases. Consider, for example, design I for 45 nodes. The solution generated for V/F = 5% has a single ring family with three stacked rings. The solution generated for V/F = 25% has two ring families, with a total of four stacked rings (two on one ring family and two on the other). For V/F = 50%, the solution generated has three ring family with a total of four stacked rings. These solutions are depicted in Fig. 3 (corresponding to V/F = 5%), in Fig. 4 (corresponding to V/F = 25%), and in Fig. 5 (corresponding to V/F = 50%), where the numbers associated with the nodes index the stacked rings. In general, as the variable cost increases, it becomes more expensive for a stacked ring to traverse a cycle. By increasing the number of ring families, the average lengths of a ring family and of a stacked ring are decreased. (See the discussion of cost/distance trade-o€s in Section 1.) Note, in Table 1, that for the 20-node problem, the solution generated has an average of 10 nodes per stacked ring. However, for the 35-node problem, the solutions have about 3 nodes per stacked ring. This is due to the fact that, as the number of nodes n increases, the number of pairwise demands increases proportionally to n2. Thus, as can be seen by examining column 3,

Tributary networks with multiple ring families

1155

Fig. 4. Solution for 45-node problem with V/F = 25%.

the demand per node increases. For this reason, OC-48 rings were used for the larger problems in Table 2. In Table 2, a similar pattern can be observed as the number of nodes increases. The CPU times for di€erent problems are quite small, varying from under 2 s for 20-node problems, 6±10 s for 40-node problems, and 47±72 s for 100-node problems. These run times appear to be, roughly, on the order of O(n3). In our examples we set all dij>0 (quite reasonable for tributary networks). Thus, the number of demand-pairs and, in turn, the problem size (as

Fig. 5. Solution for 45-node problem with V/F = 50%.

1156

John G. Klincewicz et al.

depicted by the size of the list LIST1) are quadratic in n. Hence, we conclude that Algorithm TRNDP is ecient in practice, and that even larger problems can readily be solved in reasonable computing time. Furthermore, the run times may be decreased through simple changes with minor e€ect on the solution quality. For example, as discussed in Section 3, an estimate of the potential savings of a merger could ®rst be obtained by using a simple merger of the two ring topologies and a simple load balancing heuristic, leaving improved heuristics to be invoked only if the merger appears to lead to cost reduction. 5. EXTENSIONS

The design of a ring family can be signi®cantly enhanced by considering junction nodes. These represent nodes that do not have to be included on any ring since they do not serve as sources or destinations for demand-pairs. However, since they may serve as end-points for lowcost intermediate links (e.g. representing existing facilities), inclusion of some of these nodes may lead to more economical rings. This is so, since an expensive direct link may be replaced by a cheaper path whose intermediate nodes are junction nodes. Consider ring family l. Finding a cycle that traverses through all nodes in Nl [ 0 and possibly through some of the junction nodes is a generalization of the Traveling Salesman Problem. Wasem [15] extends the nearest neighbor heuristic to this problem. Essentially, the nearest neighbor is then found by ®nding the cheapest path to all unassigned nodes, rather than the cheapest direct link. We note that the resulting ring family topology can be improved by implementing, for example, a 2-opt heuristic. Instead of exchanging two pairs of links, the heuristic would attempt to exchange two pairs of paths. Note that although each junction node is allowed to be included in a ring family only once, it may be shared by multiple ring families. As a word of caution, note that the ring family topology is designed based on the link ®xed costs. The extension described above for junction nodes is appropriate, provided the variable costs are relatively small. Otherwise, the savings realized by using the junction nodes may be o€set by an increase in the variable costs. If the latter are signi®cant, an estimate of these costs (which implies estimating the number of SHRs needed) should be included in the link cost. As the number of SHRs is not known at that stage, an iterative procedure may be needed in order to revise the link costs from one iteration to the next. Kang et al. [8] solved a variant of TRNDP for uni-directional SHRs, where the ring families may traverse through demand nodes and junction nodes. They used a column generation method where the rings (represented by columns in the master program) are generated by solving an integer program with a branch and bound scheme. They dealt with the variable cost by considering several possible sizes for each ring candidate. Their computational results are limited to very small problems with up to 12 demand nodes and 29 positive demand-pairs dij. Using their algorithm to solve problems of the sizes reported here appears to be impractical. Instead, a heuristic method would be needed to generate good ring candidates as input to the column generation master problem. TRNDP assumes that each demand node is assigned to a single SHR. This would lead to signi®cant trac exchange at the hub even for node-pairs that are on the same ring family. The other extreme would consider assigning all nodes of a ring family to each SHR in that family (provided n + 1 RE). This would lead to fewer SHRs at the expense of having many ADMs. A natural extension is then to consider the ADM costs and allow each demand node to be assigned to one or more SHRs. Armony et al. [1] and Laguna [10] examined this problem for a single ring family. Extending TRNDP to consider possible assignment of demand nodes to multiple SHRs may be of interest. In TRNDP, we assume that there is a single hub. This implies that in the event that the hub fails, demand cannot be routed from one SHR to another SHR in the same or a di€erent ring family. Moreover, the entire tributary network is disconnected from the rest of the network. Hence, it may be desired to assign two hub nodes for each tributary network. The two hubs are often selected as adjacent nodes on the backbone network. Note that this raises the issue of optimal selection of the two hubs for each tributary network, an interesting topic for further exploration. The TRNDP Algorithm can readily be used, with minor changes, to handle problems with two hubs. Instead of searching for ring families that start and end at a single hub,

Tributary networks with multiple ring families

1157

we search for tours that start at one hub and end at the other. The ring is completed by using the link that connects the two hubs. AcknowledgementsÐThe authors would like to thank Muayyard Al-Chalabi, Yufei Wang, and Richard Wong for helpful discussions. In particular, the latter two participated in an earlier e€ort that focused on a model with a single tributary ring.

REFERENCES 1. Armony, M., Klincewicz, J. G., Luss, H. and Rosenwein, M. B., Design of stacked self-healing rings using a genetic algorithm. Journal of Heuristics, 1998, to appear. 2. Bodin, L. D., Golden, B. L., Assad, A. A. and Ball, M. O., Routing and scheduling of vehicles and crews. Computers and Operations Research, 1983, 10(2), 63±211 (Special Issue). 3. Clarke, G. and Wright, J., Scheduling of vehicles from a central depot to a number of delivery points. Operations Research, 1964, 12, 568±581. 4. Cosares, S., Deutsch, D. N., Saniee, I. and Wasem, O. J., SONET toolkit: a decision support system for designing robust and cost-e€ective ®ber-optic networks. Interfaces, 1995, 25(1), 20±40. 5. Cosares, S. and Saniee, I., An optimization problem related to balancing loads on SONET rings. Telecommunications Systems, 1994, 3, 165±181. 6. Harshavardhana, P., Johri, P. K. and Nagarajan, R., A note on weight-based load balancing on SONET rings. Telecommunications Systems, 1996, 6, 237±239. 7. Gavish, B., Topological design of telecommunication networks Ð Local access design methods. Annals of Operations Research, 1991, 33, 17±71. 8. Kang, D., Lee, K., Park, S., Park, K. and Kim, S.-B., Design of Local Networks Using USHRs. Department of Industrial Engineering, Korea Advanced Institute of Science and Technology, Taejon, Korea, 1997. 9. Klincewicz, J. G. and Rajan, A., Using GRASP to solve the component grouping problem. Naval Research Logistics, 1994, 41, 893±912. 10. Laguna, M., Clustering for the design of SONET rings in interoce telecommunications. Management Science, 1994, 40, 1533±1541. 11. Luss, H., Rosenwein, M. B. and Wong, R. T., Topology network design for SONET ring architecture. IEEE Transactions on Systems, Man and Cybernetics 1998, to appear. 12. Myung, Y.-S., Kim, H.-G. and Tcha, D.-W., Optimal load balancing on SONET bidirectional rings. Operations Research, 1997, 45, 148±152. 13. Reeves, C. R. (Ed.), Modern Heuristic Techniques for Combinatorial Problems. Wiley, New York, 1993. 14. Schrijver, A., Seymour, P. D. and Winkler, P., The ring loading problem. SIAM Journal of Discrete Mathematics, 1998 (to appear). 15. Wasem, O. J., An algorithm for designing rings for survivable ®ber networks. IEEE Transactions on Reliability, 1991, 40, 428±432. 16. Wasem, O. J., Wu, T.-H. and Cardwell, R. H., Survivable SONET networks Ð Design methodology. IEEE Journal on Selected Areas in Communications, 1994, 12, 205±212. 17. Wu, T.-H, Fiber Networks Service Survivability, Artech House, Boston, 1992.