Simulation of Telephone Exchanges to Compare Diﬁerent...

Simulation of Telephone Exchanges to

Compare Different Algorithms for Routing

Calls

Anquoc Tran

BSc (Hons) in Computer Science

2006

SIMULATION OF TELEPHONE EXCHANGES TO COMPARE DIFFERENTALGORITHMS FOR ROUTING CALLS

Submitted by Anquoc Tran

COPYRIGHT

Attention is drawn to the fact that the copyright of this thesis rests with itsauthor. The Intellectual Property Rights of the products produced as part of theproject belong to the University of Bath (seehttp://www.bath.ac.uk/ordinances/#intelprop).

This copy of the thesis is has been supplied on condition that anyone who consultsit is understood to recognise that its copyright rests with its author and that noquotation from the thesis and no information derived from it may be publishedwithout the prior written consent of the author.

DECLARATION

This dissertation is submitted to the University of Bath in accordance with therequirements of the degree of Bachelor of Science in the Department of ComputerScience. No portion of the work in this dissertation has been submitted in supportof an application for any other degree or qualification of this or any otheruniversity or institution of learning. Except where specifically acknowledged, it isthe work of the author.

Signed........................................

This thesis may be made available for consultation within the University Libraryand may be photocopied or lent to other libraries for the purposes of consultation.

Signed........................................

ii

Abstract

In a telephone network, calls can be lost from the network and unable to connect toits destination if there is insufficient capacity on the links that make up the requestedroute. There are routing algorithms that have been devised and used in order tolower the loss probability of calls in a network. The trunk reservation algorithm andsticky random routing algorithm are two such routing strategies. Software has beendeveloped in order to model a telephone network and allows the comparison of thedifferent routing algorithms to take place. Experiments are conducted by varyingdifferent conditions on the network and seeing the effect on the performance of therouting algorithms. The results produced from the experimentation are analysedagainst previous work done that was identified in conducting a literature surveyand against a set of hypotheses that were drawn up. The possibility for future workis also given based on the findings of the project, where further investigations intocertain areas are highlighted that may be of interest and importance.

iv

Acknowledgements

I would like to express my thanks and appreciation to my project supervisor Dr.Daniel Richardson for his help, support and advice throughout this project. Iwould also like to acknowledge my family and friends for all their help and supportthroughout the course of this project.

Gratitude is something of which none of us can give too much. For on the smiles,the thanks we give, our little gestures of appreciation, our neighbors build their phi-losophy of life. - A.J. Cronin

v

Contents

1 Introduction 11.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 The Literature Survey 42.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 The History of Research into Telephone Networks . . . . . . . . . . . 52.3 Why We Need To Route Calls . . . . . . . . . . . . . . . . . . . . . . 52.4 Loss Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Erlang’s Formula . . . . . . . . . . . . . . . . . . . . . . . . . 62.4.2 Loss Network Model . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Dynamic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 Instability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.2 The Implied Cost of a Circuit . . . . . . . . . . . . . . . . . . 102.5.3 Trunk Reservation . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Dynamic Alternative Routing . . . . . . . . . . . . . . . . . . . . . . 132.6.1 Sticky Random Routing . . . . . . . . . . . . . . . . . . . . . 13

2.7 The Poisson Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7.1 Poisson Process Properties . . . . . . . . . . . . . . . . . . . 152.7.2 The Interarrival Times of a Poisson Process . . . . . . . . . . 16

2.8 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Requirements 183.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . 193.2.2 Non-Functional Requirements . . . . . . . . . . . . . . . . . . 203.2.3 Interface Requirements . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Project Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Design 234.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2 Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4.1 Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.2 Poisson Process . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.3 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

vi

4.4.4 Network Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.5 Routing Algorithms . . . . . . . . . . . . . . . . . . . . . . . 274.4.6 Network Output . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.5 Programming Language . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Implementation 295.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.4 Key Implementation Approaches & Components . . . . . . . . . . . 30

5.4.1 Inner Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4.2 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . 315.4.3 Network Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . 335.4.4 Data Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 Experimental Hypotheses 366.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.1 Loss Probability (Single Link) . . . . . . . . . . . . . . . . . . 366.2.2 Trunk Reservation . . . . . . . . . . . . . . . . . . . . . . . . 376.2.3 Loss Probability (Network) . . . . . . . . . . . . . . . . . . . 37

7 Design of Experiments 397.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 The Simulation Program . . . . . . . . . . . . . . . . . . . . . . . . . 397.3 Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.3.1 Experiment 1 - Loss Probability . . . . . . . . . . . . . . . . 417.3.2 Experiment 2 - The Trunk Reservation Parameter . . . . . . 427.3.3 Experiment 3 - Routing Comparisons (small network) . . . . 437.3.4 Experiment 4 - Routing Comparisons (large network) . . . . 44

8 Experimental Results 468.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468.2 The Experimental Procedure . . . . . . . . . . . . . . . . . . . . . . 468.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

8.3.1 Experiment 1 - Loss Probability . . . . . . . . . . . . . . . . 468.3.2 Experiment 2 - The Trunk Reservation Parameter . . . . . . 488.3.3 Experiment 3 - Routing Comparisons (small network) . . . . 538.3.4 Experiment 4 - Routing Comparisons (large network) . . . . 55

9 Analysis of Results 589.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589.2 Hypothesis Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 58

9.2.1 Hypothesis 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 589.2.2 Hypothesis 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 599.2.3 Hypothesis 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2.4 Hypothesis 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 609.2.5 Hypothesis 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 619.2.6 Hypothesis 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

vii

10 Conclusions 6410.1 Future Work & Development . . . . . . . . . . . . . . . . . . . . . . 6510.2 Personal Reflection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11 Bibliography 6911.1 Further Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

A Source Code 73A.1 Code Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73A.2 Code Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B Experimental Plan 114

C Results 120C.1 Experiment 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120C.2 Experiment 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121C.3 Experiment 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172C.4 Experiment 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

viii

Chapter 1

Introduction

The telephone network plays a key role in many of our lives. Most households inmany societies, spanning the entire globe have a telephone, or at the very least,access to a telephone. How a call is made from one telephone to another is oftentaken for granted by many of us, not realising the mathematics and mechanics thatlie underneath this seemingly simple process. This point is further emphasised whenwe think about a telephone call being made from one side of the world to the other.

In a model of a telephone network, calls arrive as Poisson processes containinginformation about its origin and destination node. A route is determined for carry-ing the call and if a circuit is available at each link then the call is accepted; the callwill be dropped otherwise. In between a call going from its origin to its final desti-nation, the call could be routed to a local exchange, which connects to all phoneswithin a small geographical area such as a village. From the local exchange the callcould pass to a number of main exchanges or international exchanges, dependingon the destination of the call, until the call reaches its desired target, if indeed itdoes.

A key emphasis of this project will be the routing of calls and how it is determined.The routing of a call usually occurs under the following scenario: we suppose thatthere are N cities, each pair of cities is connected by L lines. Calls arise betweencities at some rate R, and calls die at some rate D. If all direct lines from city I tocity J are being used, and a call arises from I to J , it may be rerouted via anothercity K, or it may be lost.

There are different algorithms available that decide the route that is to be taken ifthe direct line between two cities is unavailable. The problem at the heart of thisproject is to compare the different algorithms for the rerouting. The comparisonswill investigate the understanding of which algorithms work best and also whichalgorithms work best under differing conditions and constraints.

There is potential to make a great impact on society and more specifically, forthe actual telephone companies by understanding what the best routing algorithmto use under certain circumstances is and when. If the telephone network is moreefficient, effective, reliable and makes better use of the resources available then thosewho are the users at each end of the telephones would simply receive a better serviceand be less likely to have problems connecting to other people. For the telephone

1

companies, the most obvious benefits would be lower costs, greater profits andmore satisfied customers.

The work that I am doing for this project has the possibility of not just beingconfined to simply the telephone network but may also be applied to other net-works in existence in modern day life. These are networks such as the rail, roadand airline transportation networks, the electricity network, computer and cellularnetworks and many others.

1.1 Aim

The aim of my project is to design and build a simulation of a telephone networkand the exchange of calls within this network in order to compare different routingalgorithms. The simulation of different routing algorithms within the network willalso be executed and compared under different conditions that may occur within atelephone network.

1.2 Objectives

• Investigate algorithms that currently exist for routing calls in a telephonenetwork.

• Design and create a system that simulates a telephone network where differentexisting routing algorithms can be applied under different conditions.

• Compare the results of using certain algorithms in conjunction with certainconditions within the simulated telephone network and analyse and identifypoints of interest.

• Look at the possibility of improving any routing algorithms or implement-ing a new algorithm based on the results obtained from comparing existingalgorithms within the simulated network.

1.3 Document Structure

The first main section of the document will be the Literature Survey in Chapter 2.The Literature Survey will provide the basis and foundation for the rest of project.It will provide background knowledge to the subject of the project and identify anddetail key areas in the field and any relevant previous work that has been conducted.

The development of the software for the project will be covered in Chapters 3, 4 and5 through the requirements, design and implementation of the software respectively.As this project is not a software engineering project but more of an investigationand research project, the content of these sections will not be as detailed as it wouldbe for a project concerned with software development. The important aspects ofthe development for the section concerned will be given. These chapters will aid inthe understanding of the problem and the domain of the project.

The next main body of work will cover the experimentations and investigationsof the project using the software that has been produced. This will begin with

2

Chapter 6, which will be the experimental hypotheses. The hypotheses will be for-mulated mainly as a result of the findings from the Literature Survey. This will leadto the design of experiments in Chapter 7 where the experiments are designed withrespect to the hypotheses of the preceding chapter and the aims and objectives ofthe project. The results of the experiments will be given in Chapter 8, which willallow analysis to take place in Chapter 9. The analysis will involve the evaluationof the hypotheses against the results.

Finally, conclusions to the project are written about in Chapter 10. The achieve-ments of the project and possibilities for future work are detailed in this section.There will also be a personal reflection on the project covering possible improve-ments, lessons learnt, knowledge gathered and the relevance of the project to mystudies.

3

Chapter 2

The Literature Survey

2.1 Introduction

The purpose of the Literature Survey is to provide a deeper understanding of theproject subject through the review of literature pertaining to the area under discus-sion. Reviewing and critically analysing previous work and findings from a varietyof sources will allow me to identify the key issues that lie at the heart of the projectand will also help to provide the direction to take the project towards and recognisethe desired outcomes.

There will firstly be background knowledge covering the history of research thathas been conducted on telephone networks, noting key names in the field of re-search and significant dates. This section will then move onto an explanation as towhy calls need to be routed in a telephone network. In this section there will alsobe details provided on how a routing scheme should perform and work, and whatelements and factors it needs to consider.

The next section of the literature survey will go into detail about loss networks.Erlang’s formula for the loss probability of a network and the general importanceof the formula to network theory are significant contributions and components tounderstanding and modelling loss networks. The mathematical definition of a lossnetwork model as defined by Kelly (1991) and where Erlang’s formula relates to andfits into the whole concept will be presented. Understanding the importance anduse of loss networks is a vital stage before moving onto discussing routing schemesfor telephone networks.

Dynamic Routing is one such scheme for possible routing on a telephone networkand this area provides the next part of this literature review. The idea behind thisrouting scheme and how it actually performs are given here, as well as key issues ofworthwhile consideration such as instability and complexity of a network under thescheme. The Trunk Reservation scheme for routing is a routing scheme with theseconsiderations in mind.

The next main section of the Literature Survey will consider and explain anothermain routing scheme called Dynamic Alternative Routing. This is a routing schemethat compensates for some of the abilities that Dynamic Routing lacks under cer-tain conditions and settings. The concept of Sticky Random Routing is defined andlooked into as part of Dynamic Alternative Routing.

4

The Poisson process is an important area of mathematics that is significant in thestudy and modelling of telephone networks. Therefore there will be an explanationat to what the Poisson process is, its properties and where it fits into the theory ofnetworks.

2.2 The History of Research into Telephone Networks

Telephone networks have been studied since the early 1890’s but it was not untilthe 1960’s - 1990’s that the subject gained notable attention when the subject areaof call routing problems came to the fore. The Danish mathematician A.K. Erlangis regarded as being the first person to systematically study telephone networks andthat brought about his famous formula within the field, concerning the loss prob-ability of a network (Erlang, 1917), see section 2.4.1. Many in the field see Erlangas a pioneer in the study of telecommunications traffic.

Over time the theory provided by Erlang has itself grown, as well as being thebasis by which the whole subject has been allowed to progress. F.P. Kelly andmany others, such as D.J. Songhurst and R. Gibbens, from approximately 1985onwards, have been able to make great strides and insights into the subject withdevelopments such as Trunk Reservation and Dynamic Alternative Routing. Ad-vances in mathematical theory, such as in queuing theory, and also advances intechnology have also helped to perpetuate the work and interest in the subject.

2.3 Why We Need To Route Calls

There are many factors that can affect the performance and functioning of largenetworks. In a network and a telephone network in particular, there can be busyand quiet periods throughout the course of the day. Examples of when sudden,unexpected behaviour to a network may occur, causing network failure, are if apopular television programme has a phone in vote and so will overload the networkat one point, or if a digger was to accidentally cut through a major telephone wirewhile repairing a road. (Gibbens & Turner, 1997)

In order to handle unpredictable events that can befall a network, many leadingmathematicians within this field of work have developed schemes for routing callsand try to prevent them from being lost. This is a subject area that has been lookedat for over 80 years and still continues to interest many people who are looking toimprove the routing schemes available and the performance of networks in general.

Routing schemes work by searching the spare capacity available in a network sothat calls can be routed away from the parts of the network that are broken or full,into the parts that are under-loaded. (Gibbens & Turner, 1997)

A good routing scheme needs to be able to find the spare capacity within a networkwhen called upon and also needs to be simple to obtain the best working use overreal existing networks. Simplicity is a required feature in order for thousands ofcalls a second to be routed instantaneously. The routing scheme also needs to bedecentralised because having a central controller in place to coordinate the routingwould be far too slow to be acceptable, and were it to experience a power failure or

5

get cut off from the rest of the network then the entire network could face disastrousconsequences. (Gibbens & Turner, 1997)

Traffic problems can arise in a system like the telephone network, and are sub-ject to unpredictable fluctuating demands, where the system does not have thecapacity to handle the maximum possible demand adequately. The theory behindteletraffic is therefore based on probability theory and its application is essentiallythrough mathematical modelling and computer simulation. (Songhurst, 1980)

2.4 Loss Networks

Loss networks are a particular class of networks. It can provide a model for telecom-munication networks that have limited resources. If resources on a network are beingused to its full capacity then calls can be blocked. Knowing the probability that acall will be blocked is of great importance concerning the practicality of a network.(Louth, Kelly & Mitzenmacher, 1993)

The successful development over the past few decades on the theory of queuingnetworks has contributed greatly to the encouragement of interest in the mathe-matical theory of loss networks, and in its application to the design and control oftelecommunication systems. The challenge raised by the conceptual issues broughtforward by the advances in the technology of communication systems have also con-tributed to the developments in loss network theory.

The telephone network presents an example of a ”circuit-switching” network. A”circuit-switching” network is defined if one of the characteristics of the networkwas for the sufficient resources, which are the number of circuits in this case, tocheck if they can handle the request before a call can be accepted.

2.4.1 Erlang’s Formula

In 1917, A.K. Erlang published a formula concerning the loss probability of a tele-phone system (2.1).

E(v, C) =vC

C!

[ C∑

i=0

vi

i!

]−1

(2.1)

His formula was devised after studying the telephone exchange for a village. Henoticed how the village would only have a certain number of telephone lines thatwould join the village to the world outside. Erlang’s formula was obtained fromhis development of the concept of statistical equilibrium, and he powerfully demon-strated the formula’s ability to deliver exact formulae for many of the importantand typical problems of telephony.

In Erlang’s formula, v is the rate that calls will arrive at a telephone link as aPoisson process (see section 2.7). C is the number of circuits contained in a link.When a link has all its circuits C, occupied, then a call will be blocked and lost

6

from the network. If a link has spare circuit capacity available then the call can beaccepted and placed into a holding period for the duration of the call on a singlecircuit. The holding periods of calls are independent of each other and are alsoindependent on the time of arrival. The distribution of the call holding periods areset identically with unit mean.

By knowing the values of v and C, with the use of Erlang’s formula it is possi-ble to work out the proportion that calls will not be able to reach its intendeddestination. From Erlang’s formula we can see that if the value of C is increased,the proportion of callers who will find their calls blocked and subsequently lost willdecrease because there are more circuits available to accept calls. If we were toincrease v, the rate of calls, then we should find that the number of lost calls on thenetwork will increase because we will find that more circuits will be in use.

Erlang’s formulaic model provides the basis for the mathematics of many, if notall, of the current existing networks. The mathematics underlying today’s complexnetworks are still based on his work (Gibbens & Turner, 1997). It is a fundamentalpiece of information that is central to previous work and research done on the sub-ject of network routing. Any future developments that will be made will more thanlikely have Erlang’s formula central to its work and findings. Telecommunicationengineers have used this formula for over 80 years to work out if the loss probabilityis acceptable in their line of work by determining the amount of capacity C that isrequired for a given level of traffic, v (Kelly, 1995).

Erlang’s formula needs to be further extended and generalised to accommodatea network system that consists of multiple links. Erlang’s formula is only a consid-eration of loss probability on a single link. A telephone network system does notconsist of a single link but is made up of multiple links, so extending and generalis-ing Erlang’s formula is essential if we want to consider the actual routing algorithmsthat take place for this particular type of network.

2.4.2 Loss Network Model

A loss network model as defined by F.P. Kelly (1991);

A network has J Links, labelled 1, 2, .., J . A link j consists of Cj circuits whereCj ∈ Z+, the non-negative integers. A call on route r uses Ajr circuits from link jwhere Ajr ∈ Z+, the non-negative integers. Let R be the set of possible routes; theroutes are labelled r = 1, 2, .., R. Calls requesting route r arrive as a Poisson streamof rate vr (usually referred to as random traffic, see section 2.7), and as r varies,it indexes independent Poisson streams. A call requesting route r is blocked andlost if on any link j, there are less than Ajr circuits free. If a call is lost then thecaller neither queues for service nor retries later. Otherwise the call is connectedand simultaneously holds Ajr circuits from link j for the holding period of the call.The call holding period is independent of earlier arrival times and holding periods.The holding periods of calls on route r are identically distributed with mean µr.

Figure 2.1 shows the linear constraint ΣrAjrnr 6 Cj expressing the condition thatthe number of circuits required from link j by calls in progress cannot exceed thecapacity of link j.

7

Figure 2.1: A Network Model (Kelly, 1995)

This definition of a loss network model, as provided by Kelly (1991), is one that issuitable for modelling a circuit-switched communication network, which is what amodern telephone system is. The parameters that define the system and are crucialto making the system work is the matrix A of circuits from a link j, the capacityvector C and vr, which is the arrival rates of calls.

2.5 Dynamic Routing

The main purpose at the heart of dynamic routing is to ensure that large-scale net-works, such as a telephone network, are able to operate in a reliable and dependablemanner. Reliability of a network can be identified in terms of the robustness of thenetwork’s response to failures and overloads, flexible use of network resources andthe ability to limit errors in forecasting and their subsequent impact. Understand-ing how to decide which resources have spare capacity available and which ones areoverloaded is the major problem that a dynamic routing scheme needs to focus onand address. This decision, based on the resources available, will perhaps vary overtime due to the way that the nature of traffic can randomly alter. The consequencesof asymmetries in traffic and capacity patterns also contributes to the problem ofchoice upon the resources in the same manner.

There are two important issues of particular concern that require significant con-sideration within the Dynamic Routing scheme and the development of the actualschemes within this framework. These are instability and complexity.

2.5.1 Instability

In a network, if blocked routes for calls are encountered and are rerouted onto a moreresource-intensive path then this may cause any subsequent calls to be rerouted.With this cascading effect occurring, the network’s behaviour may change in a waythat causes instability in the network, meaning that disastrous incidents will arise.(Kelly, 1995).

Gibbens & Turner (1997) provide a straightforward overview of the problems thatcan be caused by rerouting calls. If we tried to route a call from a node A to a nodeB in a network and found that the direct link between them is full then we need toroute the call via another node. If that node was C, then this would be an accept-able positive move, provided the network is lightly loaded. If the network is heavilyloaded then most calls have to use an indirect route instead of a direct one, therefore

8

having to use two links instead of one. With each call using twice as many linksas it possibly needs, the network will only be able to carry half as many calls in total.

The effect of this instability problem on a symmetric fully connected network asdefined by Kelly (1995) is as follows;

Suppose we have a complete graph, where every node is connected to every othernode, that has been formed from K nodes. Calls arise at a Poisson rate of v be-tween any two nodes and there is a link capacity C. A call is accepted if thereis spare circuit capacity on a link between two end points of a call. If there is nospare capacity available to accept the call then the call chooses at random one ofthe K − 2 two-link paths joining its end points. So a call will now be accepted ifboth links for the path created have a spare circuit, otherwise the call will be lost.The holding period of an accepted call will have unit mean.

If we make B be the probability that a link will be full, as we increase K, whichis the number of nodes in the network, the probability of B approaches a solutiongiven by the equation

B = E(v[1 + 2B(1−B)], C) (2.2)

where E is Erlang’s formula (2.1).

This conclusion has been reached from the work done by Crametz & Hunt (1991),and Graham & Meleard (1993) on the consequence of limit theorems.

The equation (2.2) has a number of solutions as the parameters of v and C arevaried over significant ranges (Nakagome & Mori, 1973).

Ackerley (1987) and Gibbens et al (1990) investigated the model presented andNakagome and Mori’s work, through the use of simulation and approximation. Thework that has been done has shown that given certain parameter values, we findtwo distinct locally stable modes of behaviour.

They found that there was a lagging of effect behind the cause of varying a pa-rameter value. If v is varied slowly then the mode that is obtained will perhapsdepend not only on the current value of v but also how v approached its value;either from above or below.

Gibbens et al (1990) provide an intuitive explanation for this. The mode of be-haviour of a network can be either one where blocking of calls is low with the othermode being when blocking is high. The solution attributed to the mode of whereblocking of calls is low shows calls are mainly routed directly and there are fewcalls that are carried on two-link paths. The solution where blocking is high, manycalls are carried over two-link paths. Therefore the system may be kept in a highblocking mode due to a form of positive feedback.

9

Figure 2.2: The Implied Cost (Kelly, 1995)

2.5.2 The Implied Cost of a Circuit

The implied cost of a circuit is the expected net effect upon the network when acircuit is used by a call. It is measured in terms of the calls that have been lost thatwould have otherwise have been carried.

Gibbens’ and Kelly’s work on investigating the implied cost of a circuit is demon-strated when they looked at a link with a capacity of 120 circuits. They found thatwith C = 120, the implied cost rises steeply to a value of almost 2 when the orderedtraffic is approximately at a value of v = 107. This is illustrated in Figure 2.2. Atthe point where v is roughly 107, carrying an additional directly routed call causesnearly two calls to be lost as a result. Why an additional direct call can on averagecause the amount of lost calls given is because it can force subsequent calls to bererouted, which uses up more of the network’s resources.

The behaviour of implied costs is a much more sensitive indicator of inefficiencythen the onset of instability because if we look at the cascading effect that is beingcaused and model it as a branching process, instability corresponds to supercriti-cality of the branching process and to an infinite implied cost. So for a networkwhere C = 120, if a call is only allowed one alternative route then there will be noinstability.

2.5.3 Trunk Reservation

The trunk reservation scheme is a very simple scheme and easy to implement inreal networks (Gibbens & Turner, 1997). Trunk reservation is a method of giv-ing priority at a link to certain streams of traffic by reserving some capacity oneach for directly routed calls. It performs a certain control over the onset of in-stability whereby a link can reject alternatively routed calls if the number of idlecircuits is less than or equal to a certain value, so for example, if a link is becomingfull according to this certain value then no indirect calls are accepted onto the link.This certain value is a parameter s, called the trunk reservation parameter of a link.

10

Figure 2.3: The Implied Cost: Comparing with and without trunk reservation (Kelly,1995)

Songhurst (1980) said that with trunk reservation in place, alternative routing iscapable of improving performance, and trunk reservation is widely used in telephonenetworks.

Figure 2.3 shows the improved performance of trunk reservation for a network forthe case where C = 120. The implied cost is significantly lower when compared totrunk reservation not being used.

One of the effects of trunk reservation is that at times we refuse to carry callsthat could fit in. However, trunk reservation is throwing away a few harmful callsso that far greater calls can be carried overall (Gibbens & Turner. 1997).

Using trunk reservation requires the consideration of the best choice of trunk reser-vation parameter for the various values of alternative routes allowed. Figure 2.4shows the minimal loss probability as the trunk reservation parameter varies ac-cording to the value of alternative routes allowed.

Gibbens & Turner (1997) claim that only a small amount of reserved capacity is re-quired, maybe space for half a dozen calls on a link that could carry several hundred.Bertollini, Mocci and Scoglio (1999) looked at what the optimal amount of trunkreservation should be and called this value the trunk reservation threshold. Using avalue of 100 for all link capacities and offered traffic of 150 (66% general overload)they found that the when the trunk reservation parameter is increased, the net-work performance increases. However, the rate of improved performances decreasesrapidly and almost the same performance is reached when the trunk reservation isgreater than 2. Figure 2.5 illustrates the results found.

Bertollini, Mocci and Scoglio’s (1999) research also found that the optimal value forthe trunk reservation threshold is dependent on the type and size of the overloadon the network. They looked at the blocking probability for different overload con-ditions when the trunk reservation was set to 2. One of their

11

Figure 2.4: Minimal Loss Probabilities (Kelly,1995)

Figure 2.5: Network Blocking Probability vs. Trunk Reservation parameters (66% generaloverload) (Bertollini, Mocci & Scoglio, 1999)

conclusions was that the blocking probability increases as the type of the over-load of the network became more dense and the offered traffic is increased.

The curve that is labelled 0 in Figure 2.4 shows Erlangs’s formula and the curvelabelled ∞ is the unbounded number of alternative routes. Figure 2.4 shows that”trunk reservation is not only simple to define and implement, it has also been shownrecently to be asymptotically optimal as the number of nodes increases” (Hunt &Laws, 1992, 1993). This is in the sense that the curve labelled ∞ is a lower boundon the loss probability under any dynamic routing scheme, and is approached bya trunk reservation policy as the number of nodes and alternative routes increases(Kelly, 1995).

12

2.6 Dynamic Alternative Routing

Most networks are not symmetric, especially the telephone network. So a dynamicrouting scheme is required to cope with the mismatch between traffic and capacitypatterns. Dynamic Alternative Routing is such a scheme whereby local rules aremade use of, in order to solve the matching problem described.

Trunk reservation was able control instability and approach optimality in symmet-ric networks. However when the traffic patterns and capacity are asymmetric thenthe problem arises as to choosing which routes should now be used as alternatives.Dynamic Alternative Routing is a mechanism that offers a way of making the choiceof which route should be taken.

Dynamic Alternative Routing was developed by researchers at Cambridge and BTLaboratories at Martlesham. In 1996, the British Telecom network implementedDynamic Alternative Routing.

2.6.1 Sticky Random Routing

Sticky Random Routing is a term that was created by Mees (1986). It is used todescribe part of the dynamic alternative routing scheme.

Gibbens and Turner’s definition of this scheme is that within Sticky Routing wesuppose that a call is to be connected between two nodes A and B. If all the directlinks between A and B are currently busy then the sticky routing strategy needs tofind a longer path to get from A and B which is able to carry the call. To searchfor this required longer path, node A needs to remember an intermediate node C.Node C is now used for the overflow calls and attempts to set up a connectionfrom A to B via C. If this connection is accepted then the call can use this two-link route and will be remembered for future calls that take place between A and B.

If the two-link connection is currently too busy then the connection is rejectedand the call is refused. The intermediate city is reset to being a new node chosen atrandom. Therefore when the next overflow call between A and B occurs it will at-tempt to use the new path defined by the newly randomly chosen intermediate node.

The sticky routing principle will stick to the same two-link route as long as itdoes not get too congested. It switches to a new path when congestion will occur.This means that the sticky routing strategy searches for and uses any spare capacitythat exists in the network.

Dynamic Alternative Routing can be seen as a routing scheme that combines theideas of both trunk reservation and sticky routing. The following is the definitionof the scheme by Kelly (1995).

Suppose there are K nodes in a network. The link {i, j} is a link joining nodesi and j and has a capacity Cij . Each link is assigned a trunk reservation parametersij . Each source-destination pair (i, j) stores the identity of it’s current tandemk(i, j) for use in two-link alternative routes.

13

A call between i and j is firstly offered to the direct link and a call is alwaysrouted along that link if a free circuit is available. If it is not available then the callattempts the two-link alternative route via tandem node k, with trunk reservationbeing applied to both links. If the call fails to be routed via k, this call is lost andfurthermore the identity of the tandem node is reselected, perhaps at random, fromthe set {1, 2, ., K} \ {i, j}. The tandem node is not reselected if the call is able tobe routed successfully, either through a direct link or on the two-link alternativeroute. Mees (1986) came up with the term sticky random routing because of thisparticular property of the routing scheme.

It has been found in practice that it is simpler to reselect a tandem node by cyclingaround a fixed random permutation. This means that reselection of a tandem isnot based on any collected data, only the important information that a call has justfailed.

Let pk(i, j) denote the long-run proportion of calls between i and j which are offeredto tandem node k. and let qk(i, j) be the long-proportion of those calls betweeni and j and offered to tandem node k which are blocked. Then under uniformreselection

pa(i, j)qa(i, j) = pb(i, j)qb(i, j) a, b 6= i, j. (2.3)

We can observe that result is exact for either random reselection or fixed permuta-tion reselection.

Suppose the Dynamic Alternative Routing scheme for reselection of the tandem nodebetween i and j chooses node k with long-run frequency fk where

∑k 6= i, jfk = 1.

Then each selection of node k is paired with a failed call via node k, so

pa(i, j)qa(i, j) : pb(i, j)qb(i, j) = fa : fb a, b 6= i, j. (2.4)

We can see that if the blocking qk(i, j) is high on the path through the tandem nodek, the proportion of overflow routed via node k will be low. This shows us how thisrouting scheme can implicitly adapt to overloads and failures.

We also need to consider the effects of mismatches between traffics and capacities.If traffic is greater than the capacity for certain links and on other links the trafficis less than the capacity, a major question that needs to be answered is whetheror not it is possible for the excess traffic from overloaded links to be assigned toalternative routes which do not clash with one another. If it is possible then weneed to further consider if this can be achieved by a simple algorithm. A simplegreedy algorithm will be able to do the job for the problem considered and the Dy-namic Alternative Routing scheme is effectively a dynamic version of this algorithm.

14

Figure 2.6: The Poisson process: Call events randomly spaced in time

Investigation into the performance of Dynamic Alternative Routing has been con-ducted by a number of key figures. Stacey and Songhurst (1987), Gibbens (1988),Gibbens et al (1988, 1995), Key (1988) and Key and Whitehead (1988) are identi-fied as being significant stages of work by Kelly (1995).

Mathematicians have shown that although Dynamic Alternative Routing uses verysimple ideas, it performs almost as well as any current scheme at all could possiblyperform. This involved proving that there is an upper limit to the performance ofany scheme. (Gibbens & Turner, 1997)

2.7 The Poisson Process

An understanding of the Poisson process is a fundamental element in the contextof this project. The Poisson process provides the rate at which calls request a route.

The Poisson process is a sequence of events that are randomly spaced in time (seeFigure 2.6). Therefore in the context of this project, an event would be a new callstarting and requesting a route.

2.7.1 Poisson Process Properties

• The rate λ of a Poisson process is the average number of events per unit time.

• For a length of time t, the probability of n arrivals in t units of time is

Pn(t) =(λt)n

n!e−λt (2.5)

15

• For 2 non-overlapping intervals, (s1, s2) and (s3, s4), the number of arrivals in(s1, s2) is independent of the number of arrivals in (s3, s4).

2.7.2 The Interarrival Times of a Poisson Process

If we let 0 be the start point in time and let τ1 be the time until the next arrivalthen this gives the probability

P (τ1 > t) = e−λt (2.6)

Therefore the cumulative distribution function is

Fτ1(t) = 1− e−λt (2.7)

and the probability density function is

fτ1(t) = λe−λt (2.8)

so τ1 has an exponential distribution.

If we let τ2 be the time between first and second arrival then we can show that

P (τ2 > τ1 + t|τ1 = s) = e−λt s, t > 0 (2.9)

We can define τ3 as the interval between the second and third arrival in the sameway and similarly so for τ4, τ5... etc.

The random variables τ1, τ2, τ3, .....τn are called the interarrival times of the Poissonprocess. They are independent of each other and have an exponential distributionof mean 1

λ .

16

2.8 Considerations

There are a couple of aspects which will need some further consideration, as thereis a feeling that they have not been defined with enough clarity from the varioussources used during the literature review process.

When calls are requested on a route between 2 nodes there is ambiguity as towhether there is a separate link between nodes depending on the direction orwhether the same link is being used. For example if there we had nodes A andB and calls were requested from both A to B and B to A, would those calls usethe same single link between the nodes or are there two separate links based on thedirection of the call request.

An assumption can be made that there would be a different set of results thatwould be generated and obtained from using either one or two links between nodes.This is because of the parameters that each link has and they would have differenteffects on the network with respect to the amount of links that are given. Each linkhas a capacity for the number of calls it can hold at any one time so if only one linkexisted then all calls arising between the nodes of the link would make use of thatsingle link. The amount of connected calls and lost calls recorded would probablybe dissimilar between the two approaches even when the capacities on the two linksare set to values that would make it comparable to one link. Another parameterthat would have similar concerns is the trunk reservation parameter that is held,for use when applying certain routing schemes.

There is also a lack of detail given about the actual simulation models used. Mosttexts simply refer to a simulated model being used and not going any further thenthat. It would have been useful if further information of the simulation model wasgiven because this knowledge would help in the further stages of the project whendesigning and implementing the software for the experimentations that will takeplace.

2.9 Conclusion

The main focus of the project will be on loss networks, Dynamic Routing andDynamic Alternative Routing. Performance of each routing scheme can be analysedand certain conditions and parameters can be varied to look at the effect caused.This will provide a real insight into the problems and matters at hand and couldpossibly allow exploration into other areas of particular concern.

17

Chapter 3

Requirements

3.1 Introduction

The aim of this project is to simulate a telephone network and the exchanges thattake place within it in order to compare different routing algorithms. The need of asimulator to be able meet the project aim is therefore required in the project. It isessential to create a simulator so that the necessary and appropriate experimenta-tion can be conducted using this software. The accuracy of the simulator will onlyneed to be sufficient enough to give back accurate results from which analysis canbe drawn from.

The requirements document has been derived and drawn together from the researchand findings that was undertaken from the Literature Survey. The key findings andissues that were brought up by the Literature Survey have provided a real under-standing of the requirements that are necessary in the system.

There has been a process conducted to look for similar existing systems to theone that will be developed. This was carried out in order to aid in the definitionof the requirements and also help in the design and implementation. The researchprocess was unable to find any specific telephone network simulation models but didmanage to find simulation models for specific algorithms and also for applicationsthat modelled the Poisson process. Although these applications were not specificallyusing or making use of telephone networks there were many elements that could beobserved, which proved to be useful.

The requirements section forms a fundamental part of the project. It will pro-vide the basis for which the design and implementation can be carried out. Therequirements will define and cover the functionality and services that will be re-quired by the system and also the non functional needs that will be desirable in theapplication. There will also be an outline of the project requirements, which willdetail the scope and constraints of the project and in certain cases the effect theywill have on the definition of the system requirements.

3.2 System Requirements

The system requirements detail the features that the system is expected to havepresent in the desired system. The system requirements can be categorised intofunctional requirements, non functional requirements and interface requirements.

18

3.2.1 Functional Requirements

Functional requirements are requirements that are related directly to the functionof the system and the functions that it should provide to the user.

The following is the essential functionality that the system must provide.

1. The simulator must have the ability to specify the nodes and links that existbetween nodes

The user should have the ability to input into the application the nodes andlinks between nodes that will make up the network that will be simulated.

2. The simulator must allow the choice of routing algorithm to be used

The simulator must be able to perform a simulation of the telephone networkeither using no routing algorithm, the trunk reservation scheme or the stickyrouting scheme. The user must be given the ability to select which algorithmis to be used.

3. Each created link must have a maximum capacity

Each link that appears in the current simulation environment needs to havea value attached to it to indicate the maximum capacity of the link that itcan hold calls at any one time. A lost call on a link or the need to reroutethe call can be determined in the instance where the call attempts to createa connection but the maximum capacity of the link has been reached at thatgiven point in time.

4. Each created link must store a value for the average new call rate for that link

Each link in the network to be simulated needs to hold a value indicatingthe average rate that new calls are started for that link. New calls can bestarted on a link by the simulator by taking the value given and calculatingthe Poisson rate so that calls begin at random points in time but distributedaccordingly.

5. Each created link must have a trunk parameter value

Each link in the network is required to have a trunk parameter value for usewhen the trunk reservation routing and sticky random routing schemes arebeing used.

6. Each created link must have an average call duration value

When a link has been created between nodes the link needs to store a valuefor the average length of time that a call will last and be connected for. Thiswill allow calls to end at random times bounded by the value given.

7. Each link must have a current capacity value

The current capacity value of a link will store the number of calls that arecurrently occupying the link. As new calls start and end on the link thecurrent capacity value will need to alter accordingly. Keeping hold of thecurrent capacity allows the maximum capacity on the link to not be exceededor decide whether or not to take into account the trunk parameter if applicable.

19

8. The simulation must be able to run for the length of time specified

The length of time that the simulation will run for needs to be a user input.The simulation will run in real time for the amount of time that is given.

9. The simulator must be able to return and display the results from a simulationrun

The key data that needs to be returned to the user are:

• The number of calls started

• The number of calls lost

• The number of calls connected directly

• The number of calls connected indirectly via routing

• The percentage of calls that have been lost with respect to the numberof calls started

The system needs to return this data for the total network and also for eachindividual link.

This requirement will allow analysis of data to take place, which will eventuallyallow conclusions to be reached.

10. The simulator must record when a call is lost or when a call has been connected

When a call has been lost from the network this needs to be recorded by thesimulator when it occurs. Calls lost need to be recorded with respect to theentire network and also the link that the call was started on. Similarly, whena call has been connected then this should be recorded by the simulator butneeds to be recorded distinctively for calls that are connected directly, wherebyno routing has been used, and indirectly, whereby a routing algorithm hasbeen applied to connect the call. Like the lost calls, any calls that have beenconnected are recorded in terms of the entire network and the specific linkconcerned. This requirement also facilitates requirement 9 and allows thisrequirement to be fully achieved.

3.2.2 Non-Functional Requirements

Non-Functional requirements are requirements for the system that are independentof the functions of the system.

1. Reliability

The simulator is expected to be able to run for a lengthy amount of time andtherefore a high level of reliability is required. For the system to be useful itneeds to operate reliably. It should be capable of running for large periods oftime without the need for any intervention from the user.

2. Robustness

If errors or faults arise during a run then the system needs to react in theright manner. The data collected should still be obtainable. The simulatorwill be running in real time and many calls will be starting and ending duringa simulation, so the system needs to be be capable of handling this demand.

20

3. Accuracy

The data the simulator returns to the user needs to be accurate otherwise itwould not be useful for analysis, leading to wrong interpretations and con-clusions to be made. The routing algorithms need to work as accurately asexpected and required for the same reasons given.

4. Speed

The simulator is required to run in real time and during this time calls willstart and end within the network. The speed of the running simulation needsto be maintained throughout and calls must start and end exactly at theirgiven times.

5. Maintainability

The code behind the system needs to be structured in such a way so thatit is easily maintainable with further additions and upgrading an acceptablepossibility. This will allow further work that may be carried out after thecompletion of the project to be made if required.

3.2.3 Interface Requirements

The system will need to be able to display the results and figures that are gener-ated by the simulation. These will be the results giving key data as identified inthe functional requirements as requirement 9 (see section 3.2.1). This will help toeffectively and accurately analyse the performance of the different algorithms.

The system will need to display a running clock. The clock will indicate thatthe simulation is currently running and also show how much time has elapsed sofar. The absence of a clock in the simulator would make it difficult for the user tointerpret how much time the simulator has left to run and when and if the simula-tion has stopped.

A graphical interface is not an essential, necessary requirement for the project buthaving one in place will help to convey the workings of the telephone network andthe different routing algorithms. The system may graphically show the nodes andconnections between nodes. Some of the data for each of the links may also bemade displayable. Further interpretations and inferences may be able to made froma graphical display of the telephone network as it is being simulated.

3.3 Project Requirements

The project requirements will allow for the scope of the project and the constraintsthat need to be considered on the project to be gaged. A consideration of the re-quirements of the project will have an effect on the system requirements in termsof feasibility against the constraints of the project. This will all in turn cause im-plications for the design and implementation stages of the project.

One of the constraints of the project is the limited time available to conduct andcomplete this project. The time constraint is also hindered by other commitmentsthat there will be, so focus as well as time is taken away from the project and

21

therefore the necessary and appropriate considerations and actions need to be putinto place to counter these concerns.

Due to the identification of time and commitment being compromised, certain meth-ods of working and certain requirements on the project can be considered. It shouldbe ensured that the main functionality of the system has been implemented and tonot implement anything unnecessary unless time allows it and it can enhance thesystem in some way. For example, the user interface of the system is not as impor-tant as other implementations in the overall scope of the project.

One of the factors in the choice of programming language to use for the imple-mentation of the system will be based on the project constraints. If a programminglanguage was able to be used that I was knowledgable in and comfortable withusing, then a lot of time can be saved and utilised. There should however, not bean overlook of the overall aim of the project and there should be an assurance thatfirst and foremost the programming language chosen is suitable for the aims of theproject and the outcomes intended.

In terms of the actual implementation of the system, keeping the code as mod-ular as possible will allow testing of the software to be more structured and allowtesting to occur continuously during the implementation phase rather than aftermajor increments at the end of phases. Also, if changes need to be made to thecode then this can be done without having to possibly effect other components,which in turn can be separately tested.

22

Chapter 4

Design

4.1 Introduction

In this section of the project I will walk through the design component of the system.The significant design decisions and choices to be made are detailed along with theapproach to be taken at certain points. The design will provide appropriate solu-tions to the requirements that were specified (see Chapter 3) and give an overviewto the solution. This section will also allow for progression to be made on the im-plementation stage of the project because it will provide a stronger understandingof what will be necessary.

4.2 Design Methodology

Choosing the right design methodology to use for this project is vital in being ableto obtain the details of the proposed solutions to the previously identified require-ments. There are many different design methods available to consider so it wasnecessary to look at the main criteria that will be required from both the designmethod and the overall project.

The criteria for choosing the correct design methodology includes being simple andeasy to adopt and carry out. It was important not to take up time on carrying outany procedures that are essentially unnecessary and can be avoided. Efficiency inthe design process will allow there to be greater productivity spent elsewhere. Fora similar reason and on a personal level, choosing a design method that suits myselfand the way I like to work is important.

Another important factor in the choice of design methodology is its ability to helpidentify and generate the solutions for the system. Certain methods of workingmay be more applicable to the project itself and thus can provide better clarity tocertain parts of the process.

A design methodology that works with the implementation stage will be benefi-cial and something worth considering when choosing a design method. One of themain purposes of the design stage of the project is to allow the implementation ofthe system to begin, with use of the information and knowledge gathered from thedesign process. It would therefore be most useful if the design procedures take intoaccount the implementation of the system.

23

Taking all the criteria given above into consideration, the design methodologyadopted will be an object-orientated approach but with an ad hoc approach beingused as well. An object oriented approach allows the requirements to be analysedand eventually draw solutions and conclusions from them. The implementationstage was also a major factor with an object-oriented approach being consideredhere for the reasons given earlier. The ad hoc process will be necessary because itis likely that design will be modified during the implementation of the system. Italso allows aspects to be more adaptable and flexible.

A bottom-up approach to the design of the system will be used. This means theimplementation will follow the same approach. Here, the main functionality will bedesigned first and then the more complex functionality will be built upon it. Thisallows for a more modular approach that will help to manage the complexity anddependencies of the system.

4.3 System Architecture

The system can be broken into smaller sub-systems and components and the sys-tem architecture as shown by Figure 4.1 illustrates this. The links and connectionsbetween the different components are also shown, which convey the communicationand transfer of data that takes place.

Figure 4.1: System Architecture

The actual details of each of the sub-components of the system and the links betweenthem will be discussed in the following section.

24

4.4 Functionality

This section identifies the key parts and components of the design. They aim toresolve the issues that were raised from the analysis of requirements. The approachtaken will be given, along with reasoning as to why one approach was taken aboveother possibilities. There will also be some consideration as to the user interface ofthe system concerning some of the components of the system.

4.4.1 Calls

When the simulation is started, the system needs to search through the array of allthe links that exist. For each link found, a new thread needs to started. The threadfor each link will use the link data for the call rate on the link to start calls on thelink. A new call will be started at the point in time of the simulation given by thePoisson process (see section 4.4.2).

Each new call that is started on the network belonging to a link will run a newthread in the system. The route that the call is requesting is checked to see if thereis capacity on the link available to connect the call. If there is no available capacitythen the routing strategy that is being used comes into play (see section 4.4.5).

The reason behind the use of multithreading here is because it allows the exe-cution of multiple tasks to be carried out simultaneously and started independentlyof the user. The simulation has to be able to handle a number of links starting anumber of calls. Synchronisation of the threads is important so that the calls startas expected and the output data that is generated is correct.

Another advantage of using threads is that to model a call being connected, thethread can be put to ’sleep’ for the duration of the call that is given. When theend of the call has been reached the thread concerned can be terminated and thenetwork data can be updated appropriately, whereby the current capacity on thelink is reduced.

Working with the timer component (see section 4.4.3), when the thread controllingthe timer has ended because the simulation’s run has finished, a call to terminateall running threads can be used. This gives another benefit from using threads inthis instance.

4.4.2 Poisson Process

When the simulation has been started, new calls need to start within the network,requesting a route at a Poisson rate. Therefore data from the network about whichlinks exist and the individual link data concerning the call rate of the average num-ber of calls starting per minute on the link needs to be used.

To distribute the calls starting at a Poisson rate the system needs to calculate thewait time between calls starting. The wait time is calculated using the followingformula;

w =log(x)

λ(4.1)

25

where x is a random number and λ is the call rate.

Similarly calls also need to end at a Poisson rate and so the link data concern-ing the average call duration needs to be used to make this so. In this circumstancewe take the formula (4.1) and make λ be the call duration. This will give a randomvalue that is bounded by the average call duration of the link for the length of thecall. Therefore calls will end at random times at a Poisson rate.

4.4.3 Timer

Using the network parameter for the simulation run duration, the length of timethat the simulation runs for can be defined. The timer can regulate when the var-ious actions of the simulation, such as the start of calls, can begin and when theyend. When the end of the simulation has been reached all processes and threadsneed to be ceased and terminated. A timer thread will need to be implemented.

The interface needs to show the time elapsed and time remaining as the simula-tion is running so that the user is aware of whether or not the simulation is runningand how long the simulation has been currently running.

4.4.4 Network Inputs

The user needs to be able to input the data that will make up the network thatthe simulation will take place on. The data that the user will need to specify isthe nodes, the links between nodes and specific data on the links. The link datarequired is the capacity, trunk parameter, call rate and call duration.

How the user will input the data for the nodes and links could be through graphi-cal user interface interaction whereby clicking on the screen can produce the nodesand links. An alternative approach could be to use an editable table of data. It ispossible that both approaches could be implemented.

The nodes can be stored in a single array and the links can be stored within adouble array. The indices of the double array would correspond to the start andend nodes of the link and so identify which nodes the link is attached to.

In terms of the creation of the links between nodes a choice needed to be madethat was discussed in section 2.8 of the Literature Survey. This was about usingone or two links between nodes. The decision has been made to use two links be-tween nodes, so there is a separate link between nodes depending on the directionof the link corresponding to the source and destination of a call. There was noreal advantage from choosing one option over the other but it was important thata decision was made and one of the alternatives was chosen so that nothing else iseffected otherwise. As the direction of the link is of importance, the use of a doublearray for the storage of a link will also help indicate the direction of the link that acall requests a route from.

26

Another network input will be the simulation’s run duration length. The userwill give the the time in minutes that the simulation will run for. This input willallow the timer component of the system to execute what it needs to do (see section4.4.3).

4.4.5 Routing Algorithms

The simulation can either run with no routing algorithm, with the trunk reservationrouting scheme or with the sticky routing scheme. The user needs to be allowed toselect which one is being used at any one time. This can be provided by using aselection drop down box on the user interface of the system.

Where no routing algorithm is being used, when a link has reached its full ca-pacity and can no longer accept any more calls it can simply record any new callsas lost calls and the call does not become connected and no new thread for the callis generated.

If the trunk reservation algorithm has been selected then when the full capacityof a link has been reached any new calls starting on the link are rerouted via thetrunk reservation scheme. When running the trunk reservation routing algorithmthe first thing that occurs is to find all the available nodes that the call can berouted through and store them in an array. When all possible nodes for routing arefound one of the nodes is selected at random from the array of stored values andthis will be the node that a call will be routed through. The routed links are thenchecked to see if there is sufficient capacity on the two links that will need to beused. This will involve taking the value of the trunk parameter of the links con-cerned into account. When checking the current capacity of a link it needs to see ifthe maximum capacity of the link minus the trunk reservation parameter has beenexceeded. If it has, then the call can be connected, otherwise the call is recorded asbeing lost.

In the case of the sticky routing algorithm being used, at the beginning of thesimulation each link of the network is assigned a tandem node to route calls by.The tandem node for a link is randomly assigned and stored for that link. Allthe possible nodes to route by are found and can be stored into an array, which isthen used to randomly select a node from. When a call has to be routed, the nodethat the call will attempt to route through will be the link’s assigned tandem node.Sufficient capacity on the route is checked to see if the call does not exceed themaximum capacity with trunk reservation parameter. If there is enough capacityto route the call then the call is connected. If there is not enough spare capacityavailable then the call is lost and the tandem node is reassigned. The reassignmentof the tandem node works in the same way as to how the initial tandem node wasassigned except that the current tandem node is no longer considered as a possiblenode for routing.

4.4.6 Network Output

The data that is generated by the simulation needs to be outputted and displayedto the user otherwise the results of the simulation cannot be viewed and analysed,making the system pointless. The data needs to be viewable from the applicationand this can be done by having an option to generate a table of results. The data

27

also needs to be written to an external file and saved so that results are storedfor further, deeper analysis and referral. The files can later be deleted if no longernecessary and redundant in its use.

The data that will be returned to the user is the data that was identified for re-quirement 9 (see section 3.2.1).

4.5 Programming Language

The choice of which programming language to use for the system is very importantas it has a major bearing on the progress that can and is required to be made on theproject. There were many possibilities to choose from but the chosen implementa-tion programming language is Java. The decision was based on the considerationof a number of factors.

The decision took into account the requirements for both the project and the systemand also the design considerations that have been highlighted. The choice of pro-gramming language also meant that some of the design considerations themselveswere based and influenced by this choice.

Java allows the implementation of the system to be done in an object-orientatedfashion, which would be in line with the design methodology that was chosen. Thesystem can be identified in terms of classes and objects so using an object-orientedapproach seemed to be a logical step to take. Using an object-oriented programminglanguage has certain advantages over other possibilities, such as the belief that it isbetter at modelling the real world and that it is much more easier to maintain andmodify. The development process would be speeded up because the reuse of codeand objects is more of a feasible possibility.

The simulation will require the use of threads and Java allows me to implementthreads and use some of the tools and methods that are available. Threads willneed to be used for each call request and for the timer that will run as the simula-tion progresses.

Another influence on the programming language choice was from the findings thattook place during the requirements stage of the project. When looking at existingsystems, some of the simulation models that I found and particularly the ones thatmodelled the Poisson process specifically, were coded in Java as Java applets. Thisallowed for a certain sense of assurance that implementing the system in Java wasa feasible option.

From a personal perspective, I have had a lot of experience with using Java and Ialso feel that I am very knowledgable about this language. Being able to easily use alanguage and being comfortable with it helps to speed up the process of developmentand makes errors less likely to occur. As highlighted in the Project Requirements(see section 3.3) time is a major constraint on the project so any opportunity to beefficient and time effective is vital and worthwhile. Using C++ to implement myproject is probably equally as good, if not better, than using Java but because ofmy lack of experience with using C++ I decided against this option.

28

Chapter 5

Implementation

5.1 Introduction

This chapter of the project will detail the implementation process undertaken forthe software system that has been developed for the project. As this project is moreof an investigation and research project and not a software engineering project thischapter will not go into too much detail about the various implementation decisionsand it will not present the entire set of implementation issues that were confronted.A general overview of the software will be presented and certain implementationissues will be discussed.

The implementation made use of the information from the preceding chapter inthe design. The design formed the basis from which the majority of the work forthe various parts of the implementation was built upon.

5.2 Source Code

The source code for the implemented software system can be found in AppendixA. There is also a short overview of the code to accompany the listing of the code.The source code can also be found on the CD that is provided with this projectdocument.

5.3 Prototype

A prototype version of the software was implemented initially. One of the purposesof the prototype was to see if certain aspects of the design were feasible enoughto be implemented. Not all of the functionality was implemented in the prototypebut the main ones, where there are lots of dependencies on it, were present in theprototype. It was possible to determine that if the main functionality that was im-plemented in the prototype was feasible then the majority of the other componentswould also be. The prototype also determined if the whole implementation conceptin terms of the programming language and approach was pratical.

The prototype was able to show that the approach to be taken for the implementa-tion was possible and so the prototype could form the basis from which the actualsoftware implementation could be built upon. The opportunity to reuse code inthe final implementation that had already been developed for the prototype was asensible approach to take because of the utilisation of time and resources. Progress

29

would have taken a backward step if the implementation was started again fromits initial stages. This would only have had to be necessary if the analysis of theprototype determined this course of action.

The development of a prototype also served to help generate new ideas for theimplementation and this also includes the processes and procedures that will beused to implement the software. The actual development of the prototype can beused as a form of guidance, whereby awareness of what to avoid and and what arethe more successful options become more apparent. The prototype has also lead tothe required action of having to go back to the design and making modificationsand refinements where necessary.

5.4 Key Implementation Approaches & Components

This section will detail some of the important aspects of the implementation thatare of particular interest and helps to convey part of the implementation processes,techniques and decisions that was undertaken.

5.4.1 Inner Classes

The implemented system is composed of inner classes, where classes are definedentirely inside another class. This decision was chosen because of the nature of theapproach taken to implement the system and because of some of the design deci-sions that were chosen beforehand. With the system being implemented as a Javaapplet, the use of inner classes is a common and consistent approach that is oftenused for these types of applications. Any deviation from this methodology for imple-menting Java applets would simply have added to the implementation complexity,which needed to be balanced with the time and resources available to implementthe project.

Another reason why the use of inner classes is a necessary approach to take forthe development of this software is because of the use of event handling that willoccur. Inner classes provide a regular technique that can be used in programmingto implement event handling in an application, which is also one of the reasons whymost Java applets are built using inner classes. Inner classes are appropriate forevent handling because it can be used when you do not need to extend the classoutside the containing class. The system contains event handling for mouse actionevents for user input.

Another advantage to the use inner classes and thus to the implementation is theobject-orientated nature that this approach gives to the program. This is in linewith the design and implementation methodology that was adopted (see section4.5) and therefore allowed me to progress in the way intended, making use of thereasons why an object-oriented manner was decided upon.

In terms of the structure of the implemented system, using inner classes allowedme to turn things into objects, which are not necessarily able to be turned into ob-jects and are not really objects. These are the different facets of the interface suchas the panels, frames and canvas that make up the representable system. Withinthese classes are the components, methods and perhaps further inner classes, whichare concerned with the type and subject of the class under consideration.

30

The application requires the use of global variables and because Java does not havesuch variables they need to be wrapped in class declarations. This gives anotheropportunity to make use of inner classes in the program. All the necessary classesare able to gain access and make use of these global variables.

5.4.2 Multithreading

Multithreading presents a critical part of how the system works and will ultimatelydetermine how successful the system will be in the context of this project. Multi-threading is used in some of the core functionality of the system during the actualsimulation taking place and running. The use of the multithreading programmingconcept tool essentially drives the simulation and dictates the data that will beproduced.

Threads will be produced and used in the areas of functionality that were iden-tified in the design stage of the software development as documented in section 4.4.These were in starting and handling new calls and the timer that regulates theduration and running of the simulation. These areas of functionality, which makeuse of multithreading, depend upon a lot of other components of the system, whichin turn have dependencies towards them. For example, threads to start new callscan only occur when the necessary data inputs are provided. This point serves toaccentuate the importance of this aspect of the implementation.

Timer

There is an inner class in the program for the timer, which is implemented as anaction listener. This is to enable it to listen out for an event, which will indicatewhether to start the timer or stop and terminate the timer when it is used as anargument for one of the parameters of the Timer class provided by the javax.swingpackage. The event it will listen out for would be for a button to be clicked on tostart or end the simulation. Therefore when the relevant button to start the sim-ulation is clicked on, a new thread for the timer is started by calling the start()method of the Timer class and applying it to an object created of type Timer. Thestop() method is used when the simulation is ended by way of the appropriatebutton being pressed to terminate the thread created for the timer.

One of the other parameters of the Timer class is to set the delay time betweenevents. In constructing the object of type Timer, a delay value of 1000 millisecondsis set so that the timer can be used to display the current time elapsed and timeremaining in the simulation in seconds. Therefore after every second, a counter forthe current time elapsed and for the current time remaining is stored and incre-mented or decremented, depending, after every second. The stored counter valuesare used for what is displayed on the interface.

The user specifies the length of time that the simulator runs for and this vari-able is held globally in the program to allow the timer component to gain access toit. This allows the value of the counter for the time remaining to begin countingdown from the correct amount of seconds. When the value for the time elapsed hasreached the run duration time, the thread governing the timer is stopped.

31

The call to stop the timer thread also serves as a notification to the program to stopany other threads from running in the simulation. These threads are the threadsgenerated for managing the calls that are started in the telephone network.

Calls

The threads that are concerned with calls are started in response to the timer threadstarting when the appropriate button on the program’s interface is pressed. Thiswill call and start a method called runSimulation() that is within the NetworkAreaclass, which is a class created in the program that extends Java’s Canvas componentfrom the Abstract Window Toolkit package. This gives an area which allows theuser to input events and subsequently certain parameters and data into the applica-tion. This will be discussed in more detail in section 5.4.3. The runSimulation()method is placed with the NetworkArea class in order to allow it to gain easieraccess to these user input events and data.

The runSimulation() method loops through the array of nodes in the networkand the double array of capacities of all links in the network. A condition thattests whether the capacity is greater than 0 for each index of the double array ofcapacities is used to determine the existence of a link between nodes of a certaindirection. This allows a new thread to begin for each link found. To do this anothermethod named startCalls() is called when the condition is met and within thismethod an inner class is defined called CallThread which extends Java’s Threadclass.

An object is created using the CallThread class and the thread can be startedfrom this object. In the thread, as it runs, the arrival time of the next call is calcu-lated by calculating the wait time between calls. This is done by calling a method todetermine this Poisson process distribution called getWaitTime(). Using the valuegiven by the wait time, the sleep() method can be called to delay the thread.When the thread restarts after the delay a new call can be started on the link.

Each new call started also determines the start of a new thread in the system.A method is called when a call is to be started on a link called connectCall() andthis contains an inner class, ConnectThread, in order to create the specific threadsneeded. One of the important aspects of what occurs in the thread is, if a call can beconnected on the route requested after checking if there is sufficient capacity, thenthe thread can be put to ’sleep’ using the sleep() method. The length of time thatthe thread is put to sleep is given by the duration of the call which is determinedby calling the getWaitTime() method to produce random lengths of time. Afterthe call has been resumed after its delay, the thread can be terminated because thecall has ended. This is done by calling the stop() method of the Thread class.

Certain bits of information are updated as the threads are run. The current ca-pacity on a link is incremented when the call can be connected in the call thread.When the call, and thread controlling the call is ended, the current capacity on thelink can be decremented accordingly. The total number of calls started and callslost on the specific link concerned and in the total network can be updated in asimilar fashion at the appropriate times of the application.

32

5.4.3 Network Inputs

The application gives the user the ability to input values for certain parameters ofthe program, which are used by the simulation to carry out its required implementedtasks and produce the results that are accurate, expected and required. There aredifferent methods available as to how the user inputs data into the application used.

In terms of creating the telephone network that will be simulated and experimentedon, mouse button events making use of Java’s java.awt.Canvas component is used.The nodes and links between nodes can be created through the method that hasbeen chosen and implemented. A class called NetworkArea provides the code be-hind the canvas that will be used to capture events that are input from the user inthis area and also allows the user to draw on the area to represent the nodes andlinks graphically.

There are set of possible current actions that the user can take, in accordancewith the canvas. The important ones in terms of the creation of the network arethe ’Create Node’ and ’Create Link’ actions. The user can select which action tocurrently use from a drop down box that has been implemented.

With the ’Create Node’ option selected, the user can input a node by clickingthe mouse on the canvas to produce a graphically represented node. The node isstored in an array with a class type that uses Java’s Point class from the java.awtpackage. The coordinates of the node are stored in the array and the index of thearray makes the identification of the node possible.

How the links are created follows the same notion as the creation of nodes to acertain extent. The user needs to select the current action to be ’Create Link’ anda link can only be created if there are nodes available. The user has to click on anode and drag the mouse to another node. This provides one of the reasons whythe coordinates of the node were stored in an array. When creating a link, thestart point and end point coordinates are stored in separate double arrays using thenodes as the indices for storage. These arrays are used to determine what appearson screen. For each link created there are also double arrays for the capacity, cur-rent capacity, trunk parameter, call rate and call duration. The capacity array isused throughout the program to identify if a link between nodes exists by checkingif there is a positive value held in the contents of the appropriate index of the array.

The values that are stored for the capacity, current capacity, trunk parameter,call rate and call duration on a link when a link is created are default values. Thedefault values that are used in these instances can be changed by the user. Thereis a settings window that has been implemented where these default values can bechanged as well as other settings that can be altered for the network. These arethe maximum number of nodes that can be created and the run duration of thesimulation. If the user wants to change the value of a specific link then there areuser actions to do this depending on the link parameter that is to be changed. Withthe right user action selected, there is a small node in the centre of a link that whenclicked on allows the user to enter in the new value desired. The appropriate arrayis updated to take into account the changes made.

33

Another area where the user needs to provide input before the simulation can beginis with the routing algorithm to be used. There is a drop down box provided fromwhich the user can select the routing algorithm they wish to use for the simula-tion. There are three options available which are to use no algorithm, the trunkreservation algorithm or the sticky random routing algorithm.

5.4.4 Data Output

This section is concerned with how the results from the simulation can be obtainedand made viewable to the user.

In the design of the software, the intention for the implementation was to out-put the results to an external file. Unfortunately this was not possible because oferrors produced for reasons not fully known and able to be fixed in the attemptsused. Time available was also another factor in being unable to get to the root ofthe problem and solving it. Therefore a work-around has had to be implemented,which is enough to achieve the main objectives of what was originally intended.

Instead of the program outputting the results to a file, it prints out the resultsto the command shell. Therefore the applet needs to be run from an integrateddevelopment environment and not through a browser to obtain the results. The re-sults then need to be manually transferred to a new file through copying and pastingof the text that will be produced. This is not the most ideal solution because timeis taken up from having to carry out this procedure and is generally inconvenient.

The application also makes it possible to view the results from the interface. Thedata that is generated is also viewable as the simulation is running to provide thecurrent set of results at any point in time. The data for the entire network is madedisplayable on the interface and the data for the individual links of the networkcan be viewed in a separate window that needs to be opened. The informationconcerning the total network is displayed in labels whereby the text of the labelsare updated as the relevant data is updated. The link data is displayed in a tableand when the window that holds the display is opened it provides the data at thepoint of time the window was opened.

5.5 Testing

The main objective and purpose of this project was not software development andtherefore the procedures and techniques used to test the system were not so formaland structured. It also means only an overview of the testing procedure will be doc-umented here. The testing methodology used should be sufficient and wide rangingenough to identify any problems and errors that seriously hinder the program frombeing used and being accurate in its use. This decision was taken to minimise anytime being spent on anything that would be unnecessary.

When any major significant work was added into the program, like some pieceof functionality or a new module, then testing would take place on that componentto determine its correctness. The type of testing that is applied would depend onwhat was being tested specifically. If any problems were found from this round oftesting then the necessary fixes are applied and the testing takes place again. Thisis continually done until what is being tested has been passed as acceptable with

34

no errors and adverse results. The other areas of the program that are effected anddepend on the newly implemented component are also tested in the same manner.

When the entire program was deemed to be complete, the program was testedthrough each of its different aspects such as modules, functionality and usability.Any errors found would require having to go back to the code and making thenecessary changes. Once the changes were made, a new round of testing would bestarted to find any errors. This would continue on until no more errors were foundand the program would allow the experimentation to take place.

35

Chapter 6

Experimental Hypotheses

6.1 Introduction

Using the background to the problem that was identified in the Introduction tothe project and the research that was conducted for the Literature Survey a set ofhypotheses have been produced that will be tested under experimentation as partof the investigations into the subject matter of the project.

The previous work that was identified and analysed during the Literature Surveywas the main source for providing an indication as to the possible outcomes fromthe simulation of a telephone network and thus allow the formulation of the set ofhypotheses that will be experimented on. The hypotheses will ultimately look tomeet the aims and objectives of the project.

The definition of the experimental hypotheses in this section will allow the subse-quent sections concerning the experimental design and experimental testing, whereresults will be generated, to be carried out.

6.2 Hypotheses

As mentioned in the introduction, the main source from which the experimental hy-potheses were derived from is the Literature Survey, which can be found in Chapter2 of this document. Therefore for some of the background that is provided to thehypotheses, one should refer to the Literature Survey for further details if required.

6.2.1 Loss Probability (Single Link)

Erlang’s formula for the loss probability of a telephone system is an important sub-ject in the context of this project and the following hypotheses are concerned withthis. The hypotheses looks at how changing certain variables in Erlangs’s formulaseffects the loss probability of a network. The variables in question are the capacityon a link and the rate of calls on a link.

Hypothesis 1: When the capacity of a link is increased the probability of lostcalls will decrease.

Hypothesis 2: When the rate of calls that arrive at a link is increased the proba-bility of lost calls will increase.

36

The reasoning behind the two hypotheses is that if we were to increase the ca-pacity on a link, then from Erlang’s formula the loss probability of calls shoulddecrease because there are more circuits available to accept calls and so the linkis less likely to reach its maximum capacity for accepting calls. If the rate of callswas increased then the number of calls lost increases because there will be a higherprobability that the circuits on a link are being used.

6.2.2 Trunk Reservation

Dynamic routing can prevent many calls from being lost from the network but be-cause subsequent calls may be rerouted after initial calls are blocked and moved toa more acceptable path, this may cause instability to occur, especially on a heavilyloaded network. One of the possible adverse effects is that the network will not beable to carry as many calls as it could do because if most calls are using an indirect,two-path link then each call in this case would be using twice as many links then itneeds to and so the network is carrying only half as many calls overall.

The use of the trunk reservation scheme for routing calls leads towards the nextexperimental hypothesis.

Hypothesis 3: The number of calls that can be carried on a network will be in-creased when trunk reservation is used in Dynamic Routing than without.

Trunk reservation attempts to compensate for some of the deficiencies of usingdynamic routing and by doing so the probability of lost calls on the network shoulddecrease. This is because trunk reservation gives priority at a link by reserving anamount of capacity on the link for directly routed calls only.

The amount of reserved capacity (the trunk reservation parameter) to use for trunkreservation is the subject and background to the next hypothesis.

Hypothesis 4: The trunk reservation parameter used for the trunk reservationscheme need only be a small value which will be dependent on the the conditions ofthe network.

Looking back on the findings from the Literature Survey on previous work done,there is an indication that the amount of reserved capacity that needs to be heldfor each link only needs to be a small value. Bertollini, Mocci & Scoglio’s (1999)investigations are the main reasoning behind this hypothesis. Their work also leadthem to believe that the actual amount given for the trunk reservation parameteris influenced by the type and size of the overload on the network.

6.2.3 Loss Probability (Network)

The following hypotheses covers the comparison of the two routing schemes, trunkreservation and sticky random routing.

Hypothesis 5: The sticky random routing scheme should perform better in termsof loss probability of calls than the trunk reservation scheme.

37

Hypothesis 6: The sticky random routing algorithm should be significantly betterthan the trunk reservation scheme when the network is asymmetric and/or non-complete.

Sticky random routing attempts to handle the disharmony between capacity andtraffic patterns. It makes an attempt to search for any spare capacity that is avail-able in the network and then use it. This is the sense behind what has been declaredfor hypotheses 5 and 6. Sticky random routing should perform significantly betterwhen the network is asymmetric and non-complete because of its ability to findthe spare capacity in a network, which would be available in certain parts of thenetwork. Trunk reservation routing may not be able to find the spare capacity toroute by because of the randomness that it chooses to route calls.

38

Chapter 7

Design of Experiments

7.1 Introduction

This chapter will set out to detail the experimentation and choice of experimentsthat will take place in order to test the experimental hypotheses of the project in-vestigation and meet some of the aims and objectives that have been set out forachievement.

Software was created specifically for the purpose of carrying out the experimen-tation on it. This section will discuss why and how the software can be used inorder to produce the correct results for further analysis.

The details of the experimentation in this section will allow the work to be re-peated by another individual if they choose to do so. The reader will be able toidentify what is necessary and expected for the experiments to be deemed as beinga success.

7.2 The Simulation Program

The software that was developed and detailed earlier in this document within theRequirements, Design and Implementation chapters provides the main resource thatthe experiments will be designed around. The software will provide the environ-ment where the experimentation will take place and also where the results will beproduced from. The software contains the necessary functionality to carry out theexperiments and the functionality itself helps to define how the experiments will berun.

In the time after the implementation stage of the project, extra functionality hasbeen added that is a result of the design of experiments. The extra functionalityhas been specifically added to aid in the execution of the experiments and ensurethat the tests are performed using the correct parameters thus producing accurateresults. What has been inserted into the program is the ability to quickly producean example network, which can then be experimented on.

The example network produces a network that will be based on user defined param-eters. The settings that can be applied to the production of an example networkare whether it will be a small network or large network, whether the network will

39

Figure 7.1: The Settings Window.

be complete or non-complete and whether the network will be symmetric or asym-metric (see Figure 7.1).

A small network corresponds to a network consisting of five nodes and a largenetwork will produce a network with eight nodes. The reason why a value of eightwas chosen for the number of nodes for a large network was because of the result ofan oversight in the design and implementation of the software. There was a failureto take into account the amount of threads that could be running at any one timeand thus use up processing capacity. With the number of nodes given by a largenetwork, when the network is complete, there is no risk that the program becomesunstable and inaccurate. It is also sufficiently large enough for the performance ofcertain experiments that will be defined later.

The ’complete’ setting sets the example network to be a complete network where ev-ery node is connected to every other node for all possible paths. If the user changesthe setting of the network to be non-complete then the network will be missing afew links between certain nodes.

A symmetric example network will produce all the links in the network to con-tain link data that is equal. The link data would be the capacity, trunk parameter,call rate and call length. The values used would be the default values given in thesettings (see Figure 7.1). If an asymmetric setting is applied, then the link data israndomly assigned to a link to provide a network consisting of varying values foreach link. The values are randomly generated between certain boundaries depend-ing on the parameter concerned. For the capacity on a link the range is between50 and 300, for the trunk parameter it is 0 to 10, the call rate is 50 to 300 andthe range for the call duration is 1 to 4. These boundary values represent realisticvalues that will be used for experimentation.

Figure 7.2 gives an example of a small, complete, symmetric network that is pro-duced as an example network under these parameters.

40

Figure 7.2: A small, complete, symmetric example network

7.3 Experiments

The values that have been chosen to be used in the experiments have been selectedbecause of the research that was found when looking at previous work during theLiterature Survey. A lot of the values used appeared to be standard values, such as100 for the link capacities and ordered traffic of around the same value.

The order of the experiments is of significant importance. This is because thenext experiment should logically follow from the previous one and will require someof the data that is generated from the previous experiments.

The experiments will be deemed a success if the simulation software is able torun without any errors occurring and there is no corruption to the data that hasbeen input into the application and will be output from the simulation.

The experimental plan that has been created as a result of the design of experimentswill cover all of the experiments and will be used to conduct the experimentations.It can be found in Appendix B.

7.3.1 Experiment 1 - Loss Probability

This set of experiments will test how the loss probability of calls are effected whenthe capacity and call rate link parameters are changed. A series of tests and simu-lation runs will be undertaken.

In this experiment the run duration of the simulation is set to 2 minutes, the calllengths on each link are set to 1 minute and the trunk reservation for each link isset to its default value of 5. The routing algorithm to be used will be set to ’none’.These parameters will remain the same for each run of the simulation for this setof experiments. The reason why these values are not altered at all is because theyare not significant in what is being investigated in this case, and in the instance of

41

the trunk reservation parameter, it will not effect the results of the experiment. Itwill be the capacity and call rate parameters that will be changed where appropri-ate and required in the experimentation. For the run duration and the call lengthparameters, the values chosen should be sufficient enough to obtain the correct andaccurate results desired from the simulation.

The first set of tests will run the simulation using a capacity of 100 and call rateof 100. This will form the basis from which the subsequent tests will be run. Thecapacity and call rate parameters will be incremented from these initial values tolook at the differences that may occur. The simulation will be run on one linkbetween two nodes and this will be done for a total of twelve times.

The next set of tests in this experiment will look at the effect increasing the capac-ity on a link has on the loss probability of calls. The simulation will be run witha capacity of 110 and call rate of 100 on one link between two nodes. This willbe carried out for a total of twelve times. The results from these experiments willdetermine if it is necessary to run the simulation for a capacity of 120, which willin turn determine if a capacity of 130 is required and so on. This is because if itis possible to say with certainty that from looking at the results no calls are lostwhen the capacity is 110 then it is logical to assume that any capacity above thisvalue will also have no calls lost. Therefore it would be unnecessary to run furtherexperimentations by changing the capacity value.

In the final set of tests, how the loss probability of calls is effected by changingthe call rate of a link is investigated here. The simulation will first be run with acapacity of 100 and a call rate of 110 on a single link between 2 nodes. As withthe other tests in this experiment the simulation will be run twelve times. The callrate is then incremented by 10 to 110 then 120 and then 130 and the experimentswill be run in the same way as before for each different value. If further tests arerequired because the results are insufficient then it will be possible to carry on in-crementing the call rate by 10 and running the simulation until what is requiredhas been gathered.

In these experiments the decision has been taken to run each part of the exper-iment twelve times and this should be enough to be able to get a strong set ofresults which can be fully analysed. If it is found during the experimentation thattwelve simulation runs is either too large or too small then there will be scope tobe able to change this value as long as this is the case for all experiments that areconcerned.

7.3.2 Experiment 2 - The Trunk Reservation Parameter

For these experiments, the optimal amount of trunk reservation to give to a link isinvestigated. This will involve having to run the simulation through a number oftests and changing certain conditions in the given network.

Each of the experiments that will be run in this section will use a complete, sym-metric network. The network parameters that will be used and will remain thesame are the call durations of the links and the run duration of the simulation. Thesimulation will run for two minutes for each of the experiments. The average calllength will be set to one minute, which should be a sufficient value to use under the

42

conditions that the network will be experimented on. The routing algorithm willbe set to ’trunk reservation’ throughout this series of experiments.

The experiments will run using a 3 node, complete, symmetric network to beginwith. The experiments will then move onto testing a 4 node network and then a 5node network. The capacity will be set to 100 and the call rate for each link willbe 130 to begin with. The reason why the capacity and call rate has been set tobe so is to create a heavily loaded network so that links are more likely to reachtheir maximum capacity and the routing of calls through the use of the trunk reser-vation scheme will be required as a result. These values for the capacity and callrate should allow for the creation of the conditions needed but it will be necessaryto look at the results from Experiment 1 to confirm this and if essential, differentvalues based on the findings from the first experiment will need to be used. The callrate will then be changed to be 180 and then 230 and the experiments are executedfor 3, 4 and 5 nodes like before for each case for the call rate.

For each of the different networks with a different number of nodes and differ-ent parameter conditions set, the trunk reservation parameter will be changed. Theexperiments will begin with using a trunk parameter value of 0 and then incre-menting this value by one, up to a trunk reservation parameter of 6. A large trunkreservation value of 20 will also be experimented with. For each different trunkreservation parameter used the simulation will be run twice.

If at any time an insufficient amount of data from the experiments has been ob-tained and not enough tests have been run then there is always the possibility ofslightly amending the design of this experiment to allow what needs to be achievedto be reached. There will be a need to look at and analyse the results of the testsduring the experiments to see if this is necessary.

7.3.3 Experiment 3 - Routing Comparisons (small network)

This experiment will cover the actual comparisons between the different routingschemes and their performance under different conditions.

This experiment is where the example network that was discussed in section 7.2will be used. For all the experiments in this section of the experimental design,the network will be a 5 node network and so will use the ’small’ network settingfor the example network. The other example networks will be changed for certainexperiments as part of the differing conditions that the network will be tested under.

The network will be tested under four different forms. They will be as a com-plete and symmetric network, non-complete and symmetric network, complete andasymmetric network and finally as a non-complete and asymmetric network. Theexample network functionality of the software will produce the appropriate networkgiven the correct user defined parameter settings.

Depending on whether a symmetric or asymmetric network is used for experimen-tation, a different plan and procedure will be used and executed. This is becauseone would not be able to obtain the right accuracy and level of results required ifthe test procedure was not adapted to the network being considered.

43

Where the network is a complete and symmetric network and a non-complete andsymmetric network, the experiments will cover four different conditions and foreach condition the simulation will be run four times. The different conditions willbe where no routing algorithm is used, where the trunk reservation algorithm isused with a trunk parameter of 0, where the trunk reservation algorithm is usedbut this time with a trunk parameter of 5 and where the sticky random routingscheme is used with a trunk reservation parameter of 5.

A trunk reservation parameter of 5 has been chosen to be used because this valueshould be sufficient for the trunk reservation routing scheme and sticky randomrouting scheme to be useful. The results of Experiment 2 will need to be looked atto see if this value is the right one to use. If another value for the trunk reservationparameter has been found to be suitable from looking at the results of Experiment2, the design of this aspect of the experiment will need to be altered appropriately.

The parameters that will remain the same for all the experiments concerning sym-metric networks are the capacity, call rate and call lengths of the links of the network.The capacity is set to a value of 100, the call rate is given 110 and the call lengthis assigned 1 for all existing links. The run duration of the simulation is set to 2minutes throughout.

In the instances where the network under experimentation is either complete andasymmetric or non-complete and asymmetric, the experiments will also cover threeconditions similar to what will be used for symmetric networks. These are whereno routing algorithm is used, where the trunk reservation algorithm is used andwhere the sticky random routing scheme. No trunk reservation will need to be setwith these experiments because they will be randomly generated for each link. Thedifference in the experimentation between the symmetric and asymmetric will behow the procedure for the experiments will cover the different conditions.

The example network will randomly produce values for certain parameters of theasymmetric networks and so it is necessary that all three different conditions aretested using the same network with the same randomly generated network parame-ters. Therefore the experiments will be run as follows. Three different asymmetricnetworks will be produced for both the complete network condition and for the non-complete network condition. For each network, all three of the different conditionswill be run twice. The run duration is set to two minutes for all the experiments inthis case.

7.3.4 Experiment 4 - Routing Comparisons (large network)

Experiment 4 will, like Experiment 3, cover the actual comparisons between thedifferent routing schemes and their performance under different conditions.

The purpose behind this experiment is to make comparisons with Experiment 3to find out if having a network with many nodes and links has any effect worthnoting and discussing.

This experiment will run in the same way as Experiment 3 with one of the maindifferences being the the number of nodes and links that will be used in the networkunder experimentation. The ’large’ setting for generating the network example will

44

be applied in this case and this will produce an 8 node network containing 56 linkswhere the network is complete.

Another slight difference to the experimentation procedure between Experiment3 and what will occur for Experiment 4 is that no experiment will be run for thetrunk reservation routing scheme with a trunk parameter of 0 where the networkis non-complete and symmetric. This is because the same non-complete networkwith the same links defined is required to be used consistently for all the differentrouting algorithms being experimented with. The trunk parameter will thereforeneed to be manually changed for each link, which is a lengthy process. The deci-sion has therefore been taken to not perform any experiments in this circumstancebecause enough results should be produced from the other experiments to interpretthe performance of the trunk reservation scheme without a trunk parameter.

45

Chapter 8

Experimental Results

8.1 Introduction

This chapter will detail how the experiments were carried out with respect to theexperimental design that was devised in Chapter 7. The results for each experimentwill be presented in this chapter and will be conveyed to the reader in appropriateforms to give more clarity for better understanding and interpretation. The resultswill also be discussed to a certain extent, especially where there are results thatneed to be made clearer and need to be summarised. The results will be discussedto a fuller and greater extent in the next chapter, The Analysis of Results.

8.2 The Experimental Procedure

The experiments were undertaken using the experimental deign that was devisedand discussed in the preceding chapter, Chapter 7. The experiments also followedthe experimental plan that was produced (see Appendix B). The experiments werecarried out in the order that is given in the experimental design and from the ex-perimental plan. All the experiments and tests were successfully completely andproduced all the necessary data that should be required for analysis. All the exper-iments were run and executed on the software that was produced for this projectto allow the experimentation to be carried out.

8.3 Results

The entire set of results that were generated from the experiments can be found inAppendix C.

8.3.1 Experiment 1 - Loss Probability

The full results for this experiment can be found in section C.1 of Appendix C.

46

Figure 8.1: The change in the average percentage of lost calls when the link capacity ischanged. The link call rate is set to 100.

Figure 8.2: The change in the average percentage of lost calls when the link call rate isincreased. The link capacity is set to 100.

With the link call rate remaining the same, when the capacity on a link is in-creased, the probability of lost calls decreases. This is illustrated by Figure 8.1.When the capacity was set to 10 units higher than the call rate, it was enough toensure that no calls would be lost on the network.

In this section of experimentation, the results also showed that as the call rateon a link is increased, the number of lost calls on a link will increase when thecapacity on the link is the same throughout. Figure 8.2 shows this point and alsoshows how sharp the increase in the percentage of lost calls is when the link callrate is continually increased by 10.

47

8.3.2 Experiment 2 - The Trunk Reservation Parameter

The results from Experiment 2 can be found in section C.2 of Appendix C.

Figure 8.3: The average percentage of lost calls in a 3, 4 and 5 node complete networkgiven a trunk reservation parameter. The call rate is set to 130.


48


The experiment showed that from the results there is a definite significant impactby applying a trunk parameter for the links in the network. Figure 8.3, 8.4 and 8.5illustrate this point. Where the trunk parameter has been set to 0 for all the linksin the network, the average percentage of lost calls in the network is at its highestpoint. There is approximately a 5% - 8% difference in lost calls between using atrunk parameter for reserved capacity and not using it.

In terms of looking for the optimal trunk reservation value to use, the results showthat after using a trunk reservation parameter of 2, any other values used abovethis value generally have the same performance produced. It is possible to see fromFigures 8.3, 8.4 and 8.5 that the average percentage of lost calls appears to plateauas the trunk parameter is increased from a value of 2. There is roughly a 4% range,which the values plateau around.

The effect of changing the type and size of the overload on the network producedresults that showed little and no significant difference. The overload was increasedalong with the number of nodes and links that make up the network, but Figures8.3, 8.4 and 8.5 are able to highlight that the performance is quite consistent andsimilar.

49

Figure 8.6: The average percentage of lost calls in a 3 node complete network given atrunk reservation parameter. The call rate is set to 130, 180 and 230.


50


The graphs presented in Figures 8.6, 8.7 and 8.8 also show that the effect of chang-ing the type and size of the overload on the network has little and no significantdifference in the conditions experimented on. The pattern in performance appearsconsistent throughout whereby the average percentage of lost calls decreases as thetrunk parameter is increased up to a value of 2 and then generally remains the sameafterwards.

What this experiment was also able to produce and what is clear to see from Figures8.6, 8.7 and 8.8 is how the the probability of lost calls is increased when the callrate is increased. This supports and falls into line with part of the results foundfrom Experiment 1.

Figure 8.9: The average number of indirect calls connected in a 3, 4 and 5 node completenetwork given a trunk reservation parameter. The call rate is set to 130.

51



The effect that having a trunk reservation parameter for Dynamic Routing canbe seen in Figure 8.9, 8.10 and 8.11. The number of calls that use a routed pathfalls dramatically as there is reserved capacity for more direct routes. The numberof indirect calls eventually reach very low figures. There is no difference in thisoccurrence when the overload on the network is increased or when the number ofnodes and links is increased.

52

8.3.3 Experiment 3 - Routing Comparisons (small network)

The results of this experiment can be viewed by referring to section C.3 of AppendixC.

Figure 8.12: Comparison of routing algorithms when the network is complete and sym-metric in a 5 node network.

Figure 8.13: Comparison of routing algorithms when the network is not complete andsymmetric in a 5 node network.

53

Figure 8.14: Comparison of routing algorithms when the network is complete and asym-metric in a 5 node network.

Figure 8.15: Comparison of routing algorithms when the network is not complete andasymmetric in a 5 node network.

In the results for this experiment, the significant difference in performance is ap-parent between using a routing strategy and having none at all. This is the casefor all the different network conditions that were experimented on. The averagepercentage of lost calls is always highest when no routing algorithm is applied andthe difference when compared to the routing algorithm is quite a large percentagerelative to the conditions of the network.

Figure 8.12 and 8.13 for the symmetric networks shows the trend of how usinga trunk reservation parameter helps to lower the probability of lost calls. The dif-ference is quite small in the results from the experimentation but nevertheless thereis still a difference and the difference is always in favour of the trunk reservationrouting scheme using a trunk reservation parameter.

54

In the complete and symmetric network, the trunk reservation scheme was outper-formed by the sticky routing scheme but this was not the case for a non-completeand symmetric network. The difference is about 0.50% under the experimentationthat was undertaken in both network type cases.

In the case of the asymmetric networks, the performance of the sticky routingalgorithm was in the majority of cases much better than the trunk reservation rout-ing scheme, producing fewer lost calls in the network. The instances where trunkreservation algorithm did outperform the sticky routing algorithm, both would havea very low average percentage of lost calls and the difference would be very smallbetween the two routing algorithms.

8.3.4 Experiment 4 - Routing Comparisons (large network)

The results for Experiment 4 can be found in section C.4 of Appendix C.

Figure 8.16: Comparison of routing algorithms when the network is complete and sym-metric in an 8 node network.

55

Figure 8.17: Comparison of routing algorithms when the network is not complete andsymmetric in an 8 node network.

Figure 8.18: Comparison of routing algorithms when the network is complete and asym-metric in an 8 node network.

56

Figure 8.19: Comparison of routing algorithms when the network is not complete andasymmetric in an 8 node network.

The main purpose of this experiment was to compare the results gathered fromExperiment 3 to see if there is any effect from using a network with a larger numberof nodes and links.

The performance and results produced were similar and in line with what wasproduced from Experiment 3. One of the differences between Experiment 3 andExperiment 4 were that for complete and symmetric networks the sticky routingalgorithm outperformed trunk reservation routing in Experiment 3 but not in Ex-periment 4. Another difference was that for non-complete and symmetric networks,in Experiment 4 the sticky routing algorithm produced a lower probability of lostcalls than the trunk reservation algorithm. This was the opposite case for what wasfound in the results from Experiment 3.

The difference between the trunk reservation algorithm and sticky random rout-ing algorithm in the circumstances given above were of a very small percentage ofless than 0.5%.

57

Chapter 9

Analysis of Results

9.1 Introduction

In this chapter of the project the results that were produced and obtained fromthe experiments will be analysed in order to allow the hypotheses that were definedearlier on in the project to be evaluated. The results should indicate whether ahypothesis was correct and is supported or not correct and disproved. The analysisof the results should allow reflection on the importance and implication of what hasbeen generated from the experiments.

Whether or not the experiments and method of experimentation used was appro-priate will also be given and detailed where necessary. This may be indicated bylooking at how useful the results produced actually were. If required, details willbe provided as to how the experiments could have been altered in order to be moreuseful in producing a set of more conclusive results.

9.2 Hypothesis Evaluation

The hypotheses that were produced before the experimentation can be found inChapter 6 of the document. The hypotheses will be evaluated using the resultsfrom the experiments that can be found in the preceding chapter and in AppendixC.

9.2.1 Hypothesis 1

Experiment 1 was conducted to cover this hypothesis. This experiment can be usedin the evaluation of this hypothesis because the value of the link capacity was var-ied as part of these experiments and the other parameters of the network were leftunaltered.

This hypothesis is supported and correct when based upon and set against theresults from the appropriate experiments. The results were able to clearly showthat as the capacity of a link is increased, the probability of lost calls decreases,which matches the prediction given for Hypothesis 1.

When the capacity and call rate parameter values both matched each other ata setting of 100 the average percentage of lost calls in the network was just under1%. Having a capacity that had 10 more units when the call rate was set to 100 was

58

enough to connect all calls and prevent any calls that were started in the networkfrom being lost. Therefore having the capacity set above the call rate will help toensure the prevention of lost calls.

The significance of the results in this domain is that understanding the effect thatthe capacity has on a link will help to determine what is the sufficient capacity touse in order to prevent calls being lost in a telephone network. Also, by making surethat the right capacity is being used will help to lower costs in terms of resourcesand maintenance.

In terms of the actual experiments that were carried out to attempt to supportthis hypothesis, it may have been more appropriate and useful if more experimentswere carried out to provide a more stronger and conclusive evaluation of this hy-pothesis. The link capacity was only experimented on using two values, 100 and110. After the results were produced from the experimentation using a capacity of110, it was deemed unnecessary to carry any further experiments by incrementingthe capacity because the average percentage of lost calls was 0 and increasing thecapacity from 110 would have produced a value of 0 as well.

More experiments could have been performed using smaller increments between100 and 110 for the capacity. This would have help show the rate of change andshow more clearly that the loss call probability decreases as the capacity increases.

9.2.2 Hypothesis 2

The results from Experiment 1 and 2 can be used to evaluate this hypothesis. Thisis because the rate of calls on a link were varied within these experiments while theother conditions and parameters remained the same.

The relevant results show that as the call rate on a link is increased the proba-bility of lost calls increases. The results therefore support Hypothesis 2 as beingcorrect. It is interesting to note that the rate of increase in the percentage of lostcalls gets steeper and sharper as the call rate is increased. The increase appears tobe exponential but further experimentation with more increments to the call ratewill need to be undertaken to be sure of this, with a certain high level of accuracy.

The importance of recognising and understanding the effect that the call rate ofnew arrivals on a link has on a network follows the same idea and argument thatwas given in Hypothesis 1 for the link capacity parameter. Being aware of theconsequences that the call rate has on the network and the number of lost calls,provides the ability to identify what is the right amount of capacity to provide ona link, which in turn has its own advantages, such as lower costs. Certain parts ofthe telephone network are also likely to have specific periods with a heavy load ofnew, incoming calls. Therefore knowing how to react to the effect of this will beessential to maintaining the performance of the network.

As mentioned earlier, more experiments could have been executed to provide moredetailed results for more extensive and expansive analysis. Running the simulationwith further values for the call rate would have helped to determine the actual rateof growth in the percentage number of lost calls. It would also aid in strengtheningthe results and the support of the hypothesis.

59

9.2.3 Hypothesis 3

The results that were produced from Experiment 2 will allow Hypothesis 3 to beevaluated after analysis. This experiment was specifically designed and conductedin order to analyse the trunk parameter it terms of its effect and how it is effectedby other conditions. It is also possible that part of Experiments 3 and 4 can be usedto add to the evaluation because the trunk reservation scheme with and without atrunk reservation parameter are compared.

This hypothesis stated that the number of calls that can be carried on a networkwill be increased when trunk reservation and a trunk reservation parameter is usedin Dynamic Routing than without. The results from Experiment 2 confirm the hy-pothesis to be true. In all instances of the experimentation, there was a significantdifference when no trunk parameter was applied to any of the links in comparison towhen there was. The average percentage of lost calls within the network was foundto always be at a higher rate then when trunk parameters were used. This was thecase for all the different conditions that were placed on the network, whereby thecall rate on the links were increased and the number of nodes and consequently thenumber of links were increased.

This experiment and hypothesis emphasises how effective and important reserv-ing some capacity on a link for direct calls is when using a dynamic routing scheme.A dynamic routing scheme with the absence of a trunk reservation parameter is stillable to dramatically save a number of calls from being lost in the network but it canbe further improved by ensuring the links in the network contain a trunk reservationparameter. This is all shown more specifically in the results from Experiment 3 andExperiment 4 and Figure 8.12, 8.13 and 8.16.

The experimentation that was conducted to evaluate the hypothesis under consid-eration proved to have the ability to produce useful and applicable results. Thereis always the possibility of carrying out more experimentations to create a greatersample of results for analysis but the amount that was used was sufficient for whatwas required.

9.2.4 Hypothesis 4

This hypothesis is concerned with the trunk reservation parameter that is used inthe trunk reservation scheme. Therefore, like Hypothesis 3, the results from Exper-iments 2, 3 and 4 can be and will be used to evaluate this hypothesis.

The results generated that apply to this hypothesis were significant enough to beable to conclude that only part of Hypothesis 4 is correct. This was the part of thehypothesis that stated that only a small value for the trunk reservation parameter isnecessary. The other part of the hypothesis, which said that it would be dependenton the conditions of the network was not able to be supported by the results ofthe experiments because they appeared to contradict the hypothesis and were notconclusive enough.

The results showed that the loss probability of calls in a network does fall as thetrunk reservation parameter is increased up to a value of 2. When the trunk param-eter is increased beyond a value of 2 the performance generally remains the same,

60

fluctuating by a small percentage. This is the case even when a large value, whichin the case of the experiments was 20, was applied for the trunk reservation param-eter. This therefore supports the part of the hypothesis about trunk reservationonly needing to be a small value.

Why the entire hypothesis cannot be supported is because the same pattern forthe effect of using a different trunk parameter is present when the conditions ofthe network and call traffic overload was altered. When the size of the overloadand the number of nodes and links was increased in the experiments there was nodifference in terms of finding an optimal trunk parameter to suit the conditions.The appropriate value for the trunk parameter appears to be 2 and above.

The experimentation requires modification in order to provide more conclusive re-sults, which is possibly a factor behind the reason why the hypothesis could notbe entirely supported. A larger sample of results will need to be collected and theconditions need to be varied much more widely. The experiments only tested 3, 4and 5 node networks and it would have been more useful to the hypothesis if morenetworks of other sizes, especially much larger networks, were looked at.

Another area where the experimentation could have been improved to provide moredetailed and conclusive results is the range of trunk parameter values that wereexperimented on. The experiments were undertaken using a range of 0 to 6 andan additional value of 20 for the trunk parameter. What would have been betterand what would improve the results is to use the maximum possible range that isavailable. Therefore in the case of these experiments the trunk reservation parame-ters that should have been experimented on would have been from 0 to 100. Timeconstraints in the project made this an unrealistic procedure for the experiment andso was not considered.

The importance of the results in being able to find the optimal trunk reservationparameter is to essentially get the best performance out of the trunk reservationrouting scheme and also the sticky routing scheme because it makes use of the trunkreservation parameter as well. Being able to find the best number to use for thetrunk parameter, given differing conditions, would mean that both the network androuting algorithm would be able to adapt to those different conditions in order toproduce the most effective solutions.

9.2.5 Hypothesis 5

Hypothesis 5 will use the results that were produced from Experiment 3 and Ex-periment 4 in order to see if the hypothesis can ultimately be supported or denied.

This hypothesis is supported only to a certain extent by the results because thereare a couple of inconsistencies which were unexpected. The sticky random rout-ing scheme does in the majority of experiments outperform the trunk reservationscheme. The cases where it did not was when a 5 node, non-complete, symmetricnetwork was experimented on and also when an 8 node, complete, symmetric net-work was used. This could lead to the conclusion that the sticky routing schemedoes not work as well the trunk reservation algorithm when the number of nodes isincreased in a complete, symmetric network and when the number of nodes is de-creased in a non-complete, symmetric network. Whether or not this is the case will

61

require further experimentation to be carried out to see if this result is consistentand reliable.

The difference in the average percentage of lost calls between the two routing al-gorithms in the cases given above where the results were not as expected is quitesmall with around a 0.5% difference. Also, in these circumstances, the lost callpercentage is of a low rate to begin with, of around 1%. Therefore the fact that onerouting algorithm performed better than the other could be seen as insignificantbecause the network was not as heavily loaded and the performances were similarlyclose. It can be viewed that the circumstances of the experiments simply dictatedthat one would perform better than the other. This further strengthens the point ofneeding further experimentation to produce more results to see what is truly correct.

There appears to be no difference in the comparative performance of the rout-ing algorithms when more nodes were applied in the network except for the casehighlighted above. This highlights another area where the experimentation couldhave been improved. The experiments and analysis would be better served if thecomparisons between differing sizes of networks was made with much bigger net-works containing a large number of nodes such as 50 or 100. Restrictions in thesoftware meant that this was not possible but was an initial intention that was tobe part of the experimental design.

9.2.6 Hypothesis 6

This hypothesis is about comparing different routing algorithms, therefore the re-sults from Experiment 3 and Experiment 4 will provide the source from which thishypothesis can be evaluated.

The results from experiment 3 and 4 can allow me to conclude that the stickyrandom routing scheme is significantly better than the trunk reservation algorithmwhere the network is asymmetric. However, in the case where the network is non-complete, the results proved too inconclusive to be able to make a worthy and strongconclusion.

The reason why the results concerning non-complete networks was not able to meetthis hypothesis is because of the explanation that was also provided for the evalua-tion of Hypothesis 5 (see section 9.2.5) for the two cases that were highlighted thatdid not prove consistent with the results that were looking to be obtained. Theyare also inconsistent in terms of this hypothesis as well.

The improvements to the experimentation procedure and methodology are essen-tially as the suggestions that were brought up in Hypothesis 5 in section 9.2.5. Tobe able to experiment with a greater range and size of samples would have simplyenabled the evaluation of the hypothesis to be more thorough, more reliable andmore consistent. With more time and resources available for experimentation, thesuggested improvements would be possible.

Asymmetric networks are what real-world telephone network systems are like andso this point stresses the importance of this hypothesis and the results that wereproduced to support this hypothesis. If, as the results produced show, the stickyrandom routing algorithm is a much better and consistent performer in preventing

62

lost calls in an asymmetric network then because of its real-world application itwill have much more of an impact in the development of finding an optimal routingscheme.

63

Chapter 10

Conclusions

The overall outcome of this project was the development of software for the sim-ulation of a telephone network, which was used to investigate the performance ofalgorithms for routing of calls. One can conclude that the project was able to meetthe aims and objectives of the project that were set out at the beginning but onlyto a certain extent. Only one of the objectives was never quite reached and thisobjective was to look at the possibility of improving any routing algorithms or im-plementing a new algorithm based on the results obtained from comparing existingalgorithms within the simulated network. This objective will be discussed as possi-ble future work in section 10.1 where certain suggestions will be made based on theresults of this project.

The results produced from this project were able to confirm some of the findingsfound during the Literature Survey of previous and related work done by certainindividuals within the field. It was also able to produce some points of discussionfor work that could be done in the future to build upon the findings of this projectand all other related material. This will be discussed in detail later on in section10.1 of this chapter.

The major aspect of the problem description that was defined at the beginningof the project was to be able to compare different routing algorithms and to do sounder different conditions. This was the case from the project using the softwarethat was developed, which was able to give results of use that allowed analysis andconclusions of which algorithms work best and work best under certain conditionsand constraints.

The sticky random routing algorithm was clearly able to save a considerably highpercentage of calls from being lost in a network and this was the case under all thedifferent conditions that were varied, such as the volume of traffic in the networkand the size of the network. This was also the case when using the trunk reservationalgorithm for rerouting calls. When comparing the two, the sticky routing algorithmwas much better at preventing lost calls than the trunk reservation algorithm onthe whole. The difference appeared to be even more significant when the networkwas asymmetric. These results fall into line with the reasoning why the DynamicAlternative Routing scheme and sticky random routing in particular, was devisedand introduced in the first place, which was to be an improvement on DynamicRouting schemes for asymmetric networks.

64

There are a few achievements that can be derived from this project. The projectwas able to meet its aim, and the objectives have been reached to a certain extent,with the slight exception being what was highlighted earlier. The software that wasbuilt served its purpose and met its requirements and allowed the necessary experi-mentation to be carried out to produce the range of results needed for analysis. Ona more personal level, the project has enabled me to acquire a whole new range ofskills and knowledge and this will be described in more detail later on in section10.2.

10.1 Future Work & Development

The results were able to show that the sticky random routing algorithm was gen-erally better in preventing the occurrence of calls from being lost in a telephonenetwork. This was especially the case where the network is asymmetric where thetraffic and capacity patterns varied. Asymmetric networks, as identified in the Lit-erature Survey, are generally how most networks are set up, especially for telephonenetworks. Therefore the main line of further investigation and work that should per-haps be taken will concentrate on the use of asymmetric networks and also thereforethe sticky random routing algorithm.

The experimental results showed that many calls at a considerable percentage arestill lost through the use of the sticky random routing scheme. Therefore there ispossible scope for improvement to this algorithm and is worth investigating furtherbecause of this. One potential area to explore is the random element of the stickyrandom routing scheme.

The random element of the sticky random routing scheme refers to the way thenode that a call on a route is routed by is initially selected and then reselected ifrequired. In the routing algorithm, the node is randomly chosen from the set of allpossible nodes to route by. If reselection of the tandem node is taking place thenthe current tandem node that was previously used to try to route a call is not con-sidered in the reselection. The randomness of the initial selection and subsequentreselections means that a node could be selected even if it is clear that the routeis already heavily loaded and the call will therefore be lost. It was found in theLiterature Survey that using a fixed permutation for reselection would also producethe same results.

The sticky random routing algorithm may perform better if it was a bit more in-telligent in the choice of tandem node to use. Perhaps, if the algorithm was ableto look at the current network data and make an assessment on the current sit-uation, it would be able to find the optimal node to select and route by. One ofthe possibilities is to look at the current capacities of all the links, seeing whichare lightly or heavily loaded with calls. It would be better to route the call on thelightly loaded links and being able to identify which links these are will help toensure the calls are not lost. There may be other possible sets of information thatcould be used to make the routing algorithm more intelligent and adaptable to thecurrent state of the network and this could be worth investigating. Even the use ofprevious knowledge and data on the workings of the network could be used, such asthrough knowing which parts of the network are normally heavily loaded and when.Consideration also needs to be given about preventing calls from being routed to

65

one particular area of the network. One of the reasons why sticky random routingworks well is because the routing of the calls is spread around the entire networkto a certain extent. Pushing the demand of traffic to specific areas of the networkcould cause instability, leading to calls being lost.

The use of the trunk reservation routing algorithm should not be disregarded com-pletely and further investigation into possible improvements to this algorithm willstill worth considering. Striving to find improvements to this routing scheme mayeventually lead to an algorithm that is at the very least a better performer than thestick routing scheme with a very low probability of lost calls. One of the drawbacksof this routing scheme that was clearly evident from the project investigations andresults is the selection of the node to route by. The node is selected at random eachtime a call cannot be connected through the original, direct link requested. Thelikely improvements that may be considered are essentially as what was suggestedearlier for the sticky random routing scheme. This is to consider the current in-formation that is being generated by the network, information on how the networkis performing and also to consider previous data on the network to grasp certainconsistent patterns.

An area that was not investigated in this project and may be something that onemay wish to look further into, concerns the sticky random routing algorithm. Itwas identified from the material found during the Literature Survey that a fixedpermutation for choosing the tandem node to route calls by when using the stickyrandom routing algorithm produces similar results to the case where the tandemnode is randomly chosen. Therefore, whether or not this is the case could be inves-tigated. Also, there could be differences in performance for different types of fixedpermutations, so again this may be worth investigating in the future.

The software that has been created for this project provides a basis which canbe built upon for improvement. For any person wishing to explore this subjectmatter, the program that has been made for the simulation of telephone networkswill allow the general idea to be understood and will present a particular program-ming perspective that has been used. This will hopefully perpetuate new ideas andimprovements from other individuals who are working in this area.

There are probably many areas where the code can be improved and enhancedto make it more efficient and effective in several aspects. The problem concerningthe amount of threads that are generated and used at any one time as detailed insection 7.2 is certainly a particular area where improvement is required. This mayinvolve having to improve and restructure other aspects of the code to accommo-date the desired changes. The modularisation and object-orientated approach ofthe code should make the process of altering the code in the future a much moreeasy and methodical process.

10.2 Personal Reflection

If the opportunity was given to do the project again there would be certain areasand procedures that would perhaps be done differently and improved upon. Thetesting procedure and methodology that was adopted for the software developmentcould have been more structured, using well known testing procedures to cover all

66

the necessary aspects of the program. There was a failure to identify a major flawin the program that was discussed in section 7.2. This was concerned with theinstability of the program and inaccuracy of results that occurs because too manythreads are created and running at any one time. This made it not possible toexperiment with fully large scale networks that consisted of 50 or 100 nodes, whichwas an original, desired intention. Therefore by perhaps using a different, moreexpansive approach to the testing, this defect could have been identified at the im-plementation stage of the project where the problem could have been rectified or aat the very least provide a work-around.

The experimentation design could have been improved in some areas in order toproduce a greater and wider sample of results that would have allowed for a moredefinitive analysis. The improvements that could have been made to certain ex-periments are detailed in Chapter 9, Analysis of Results. The main reason behindthe size and number of experiments that were undertaken was because of the con-straints on the project in terms of time and available resources. Therefore givenmore time available and perhaps extra assistance, more experiments could havebeen conducted, producing a larger set of results.

There are perhaps other possible considerations as to how the experiments couldhave been conducted better that were not defined in the Analysis of Results chapterof this document. For the experiments where the routing algorithms were specifi-cally being compared between each other, the algorithm options were applied oneafter the other. Therefore, although the relevant parameter settings were all definedas being the same, all calls would start, last and end differently for each experiment.Results would be much more definite and clearer to analyse if for each algorithmoption tested the exact conditions and occurrences were given. To accommodatethis change in experimentation, the code to the software developed would need tobe altered so that each algorithm option runs simultaneously when the simulationis run. There would also need to be alterations to the other components that wouldbe effected, such as the output of results.

This project and the work involved, has given me the opportunity to learn manythings which I can take on board and use in the future. The most significant thingI feel I have learnt is how to go about producing a project and how to conduct aninvestigation. There is also the realisation of the amount of work and effort thatis involved, along with the high level of commitment that is needed in order tobe successful and achieve what is desired. With the experience of working on andcompleting a project in place, if the opportunity arose whereby I would be given thechance to work on something of a similar ilk then I would be much more confident inmy own ability and can apply myself to the work much more readily and effectively.

Another aspect of knowledge that I can take from the project is from the actual sub-ject area the project is about. I now know about how the telephone system works,the components and functions that make up the system and most significantly howcalls can be routed in a telephone network. Working on this project has given me areal appreciation of the intricacies of the telephone system and its impact on society.

On a more technical level, my programming skills have grown over the course ofthe project and my knowledge of using the Java programming language has been

67

greatly enhanced. The project gave me the opportunity to apply my current knowl-edge that I had acquired over the years and then build on it. The new skills andknowledge gained will hopefully prove useful in the future for myself.

This project also emphasised the importance of time management and planningto me. If I was not able to apply these competencies of work to my project I canbe very sure that I would not be able to achieve what I set out to achieve at thebeginning of the project and I would not be able to produce the level of work thatI am capable of.

The relevance that the project has had to my studies at University has been quiteconsiderable. There were many occasions where I was required to draw from myknowledge and experiences from some of the units that I have studied on my de-gree course in order to complete the tasks in question. For example, I would nothave been able to develop and produce the software for the project unless I had therelevant programming skills and knowledge, which I acquired mostly from certainunits on my degree.

68

Chapter 11

Bibliography

ACKERLEY, R.G. (1987). Hysteresis-type behaviour in networks with extensiveoverflow. British Telecom, Technol. J.5, pp.42-50.

BERTOLLINI, A., MOCCI, U. & SCOGLIO, 1999, Routing Algorithms for Ro-bustness. Faro, Portugal, (COST TD257(90)08).

CRAMETZ, J.P. & HUNT, P.J., 1991. A limit result respecting graph structurefor a fully connected loss network with alternative routing. The Annals of AppliedProbability, Vol. 1, No. 3, pp.436-444.

GIBBENS, R.J., KELLY, F.P. & KEY, P.B., 1988. Dynamic Alternative Routing- modelling and behaviour. In: BONATTI, M., ed. Proceedings 12th InternationalTeletraffic Congress, Turin. Amsterdam: Elsevier.

GIBBENS, R.J., KELLY, F.P. & TURNER, S.R.E., 1993. Dynamic Routing inMultiparented Networks. IEEE/ACM Transactions on Networking, Vol. 1, No. 2,pp.261-269.

GIBBONS, R. & TURNER, S.R.E., 1997. Call Routing in Telephone Networks.Public Awareness and Schools Support for Mathematics, issue 2 [online]. Availablefrom:http://pass.maths.org.uk/issue2/dar/ [Accessed 15 Oct 2005].

GRAHAM, C. & MELEARD, S., 1993. Propagation of chaos for a fully con-nected loss network with alternate routing. Stochastic Process and their Appl.,44(1), pp.159-180.

HUNT, P.J. & LAWS, C.N., 1993. Asymptotically optimal loss network control.Mathematics of Operations Research. Vol. 18, pp.880-900

KELLY, F.P., 1991. Loss networks. Annals of Applied Probability, Volume 1, No 3,pp. 319 - 378.

KELLY, F.P., 1995, Modelling Communication Networks, Present and Future. Avail-able from: http://www.statslab.cam.ac.uk/∼frank/CP/ [Accessed 5 Nov 2005].

69

KELLY, F.P., The Mathematics of Traffic in Networks [online]. Available from:http://www.statslab.cam.ac.uk/∼frank/PAPERS/princeton.html [Accessed 18 Oct2005].

KELLY, F.P., Network Routing [online]. Available from:http://www.statslab.cam.ac.uk/∼frank/CP/CPREAD/nr.html [Accessed 15 Oct 2005].

KEY, P.B., 1988, Implied cost methodology and software tools for a fully con-nected network with DAR and trunk reservation. British Telecom, Technol. J.6,pp.52-65.

KEY, P.B. & WHITEHEAD, M.J., 1988. Costeffective use of networks employ-ing Dynamic Alternative Routing. In: BONATTI, M., ed. Proc. 12th Internat.Teletraffic Congress, Turin. Amsterdam: Elsevier.

LAWS, C.N., 1992. Resource pooling in queueing networks with dynamic rout-ing. Advances in Applied Probability, 24, pp.699-726.

LOUTH, G., MITZENMACHER, M. & KELLY, F.P., 1993, Computational Com-plexity of Loss Networks. Theoretical Computer Science 125. pp. 45-59

MEES, A., 1986, Simple is the Best for Dynamic Routing of Telecommunication.Nature, Volume 323, pp. 108.

NAKAGOME, Y. & MORI, H., 1973. Flexible Routing in the Global Commu-nication Network. Proc. 7th Intl. Teletraffic Congress, pp.426.1-426.8.

SONGHURST, D.J., 1980. Protection against traffic overload in hierarchical net-works employing alternative routing. Telecommunications Network Planning Sym-posium, pp.214-220.

STACEY, R.R. & SONGHURST, D.J., 1987. Dynamic alternative routing in theBritish Telecom trunk network. Proc. Int. Switching Symp., March 1987 Phoenix,AZ, paper B12.4.

11.1 Further Reading

ANANTHARAM, V. & BENCHEKROUN, M., 1990, Trunk Reservation based con-trol of Circuit Switched Networks with Dynamic Routing, Proceedings of the 29thConference on Decision and Control [online]. Available from:http://www.eecs.berkeley.edu/∼ananth/1990-1992/Benchekroun/BenchekCDC90.pdf[Accessed 10 Nov 2005].

ASH, G.R. & CHERMOUIL, P., 2004, 20 Years of Dynamic Routing in Circuit-Switched Networks: Looking backward to the Future [online]. Available from:http://perso.rd.francetelecom.fr/chemouil/gcn ieee/DynRout20.pdf [Accessed 12Nov 2005].

70

BEAR, D., 1988. Principles of Telecommunication Traffic Engineering. 3rd Edi-tion. London: Peter Peregrinus Ltd.

CHORAFAS, D.N., 1984. Telephony Today and Tomorrow. New Jersey: Pren-tice Hall, Inc.

DINZEY, W., LAUCHT, C.M. & ARNESON, A.N., 1995. Comparison by Simula-tion of Fixed and Dynamic Routing Telephone While under the Influence of Over-load. pp. 52 - 55.

FARLEY, T., Telecom Fundamentals [online]. Available from:http://www.privateline.com/manual/one.html [Accessed 18 Oct 2005].

FEATHER, C., The BT Network [online]. Available from:http://www.davros.org/phones/btnetwork.html [Accessed 5 Nov 2005].

FLOOD, J.E., ed., 1997. Telecommunication Networks. 2nd Edition. London:The institution of Electrical Engineers.

FREEDMAN, H.T., HARMS, T.R. & KOONTZ, 1979. A Human Simulation Val-idation of a Telephone Loop Network Simulation Model. Proceedings of the 11thconference on Winter simulation - Volume 1, Piscataway, NJ, USA. IEEE Press,pp. 167 - 178.

FRIDERIKOS, V., Introduction to Telecommunication Networks [online]. Availablefrom: http://www.ctr.kcl.ac.uk/lectures/vasilis/vasilis.asp [Accessed 8 Nov 2005].

Graph Theory: Networking [online]. Rensselaer Polytechnic Institute. Availablefrom: http://links.math.rpi.edu/devmodules/graph networking/compat/page1.html[Accessed 5 Nov 2005].

JONES, P.W. & SMITH, P., 2001, Stochastic Processes, London: Arnold, a memberof the Hodder Headline Group.

KUHN, D.R., 1997, Sources of Failure in the Public Switched Telephone Network,Vol. 30, No. 4. [online]. Available from: http://hissa.ncsl.nist.gov/kuhn/pstn.html[Accessed 10 Nov 2005].

LEE, Y. & TIEN, J.M., 2002. Static and Dynamic Approaches to Modelling End-to-End Routing in Circuit-Switched Networks. IEEE/ACM Transactions on Net-working, Vol. 10, No. 5, pp.693-705.

LIU, R.P. & MOYLAN, P.J., 1995. Dynamic Trunk Reservation for TeletrafficLinks. GLOBCOM’95, Volume 1, pp.432-436.

Modelling Telecommunications Networks [online]. Eudoxus Systems Ltd. Avail-able from: http://www.eudoxus.com/mpac9701.html [Accessed 10 Nov 2005].

71

POINTURIER, Y., 2002, Resilience and protection in networks [online]. Availablefrom: http://www.cs.virginia.edu/∼mngroup/projects/mpls/documents/thesis/node12.html [Accessed 12 Nov 2005].

PRABHAKAR, B., 2004, Network Algorithms [online]. Available from:http://www.stanford.edu/class/ee384m/lecture1.pdf [Accessed 8 Nov 2005].

RAMN, E.G., LOPEZ HERNAIZ, J.P., HERRANZ MERUELO, S., MARTINZDALMAU, J.L., GARCA GUTIRREZ, S. & LAPAYESE PUEBLA, I., A compara-tive study of several dynamic routing algorithms with adaptative preselection and se-lection phases [online]. Available from: http://www.tid.es/presencia/publicaciones/comsid/ing/articulos/vol23/routing/routing.html [Accessed 18 Oct 2005].

SMITH, S.F., 1972, Telephony and Telegraphy A. 2nd Edition. London: OxfordUniversity Press.

SNYERS, D., Dynamic Routing and Load Balancing in Telecommunication Net-works [online]. Available from: http://www-iasc.enst bretagne.fr/PROJECTS/SWARM/telecom.html [Accessed 4 Nov 2005].

SOATTHIYANONT, S. & ASWAKUL, C., Study of Rerouting Strategy for Dy-namic Alternative Routing in Symmetric Multiple-Service Networks [online]. Avail-able from: http://pioneer.netserv.chula.ac.th/∼achaodit/paper9.pdf [Accessed 18Oct 2005].

TAYLOR, H.M., 1984, An Introduction to Stochastic Modeling, London: AcademicPress, Inc. Ltd.

TRANGMOE, G., 1995, A Comparative Study of Dynamic Routing in Circuit-Switched Networks [online]. Available from: http://www.ece.arizona.edu/∼trangmoe/greg.html [Accessed 4 Nov 2005].

VALADAS, R.T., 1999, Teaching the Fundamentals of Telecommunication Networks[online]. Available from: http://www.av.it.pt/∼rv/Papers/eaeeie98.pdf [Accessed4 Nov 2005].

ZOBEL, C.W. & WHITE, JR, K.P., 1999, Determining a warm-up period for atelephone network routing simulation. Proceedings of the 1999 Winter SimulationConference., New York, NY, USA. ACM Press pp. 662 - 665.

72

Appendix A

Source Code

A.1 Code Overview

The program is coded using Java and implemented as a Java Applet. The publicclass that has been defined that extends Applet to inherit the behaviour of theApplet class and allow the applet to be created is called Network. All other classesof the program are ultimately inner classes of the Network class.

The program is effectively divided into each of the the different panels of the in-terface, which in turn covers a particular area of the application and certain func-tionality. The TopPanel class contains the code behind all the user action options,the view options, the action buttons and the status panel. There are inner classesdefined for each and added into the TopPanel class. The RunButtonsPanel classis concerned with the buttons of the application that effect the simulation. Thesewould be the buttons to terminate, stop, reset and restart the simulation. Thebutton to produce an example network is also contained in this module of the code.The InformationPanel class contains the code behind the ability to display thenetwork data generated from a simulation. The code to display the running timerof the simulation on the interface is contained in the BottomPanel class.

The ’reset’ button from the RunButtonsPanel class not only has the code to reseta simulation back to its original initial state, it also contains the code to print theresults generated from a simulated run.

The NetworkArea class extends Java’s Canvas class and also implements the Runnableclass. This is to enable user input through the capture of events and allow threadsto be created and run. This class is therefore in part concerned with the code tocreate nodes and links and change data on the links. There is also the code todelete nodes and links here. Mouse events are used to allow these creation anddeletion elements to occur. This class also contains the methods for the actions ofsome of the buttons that exist in the application. The runSimulation() method iscalled by the ’Run’ button belonging to the TopPanel class and starts the simula-tion running. This method in turn calls the method that starts the call threads andis named startCalls(). The various methods for the routing algorithms are alsocontained in the NetworkArea class and called on when are where appropriate. Theactions of the ’Clear’ button to clear a created network and the ’Example’ buttonwhich produces an example network are also contained in this class.

73

There are other classes defined in the program, which are of importance. Thereis another inner class called Globals. This class is used as a wrapper so thatthe program can use global variables. A class called TimerCount has been cre-ated and is concerned with the timer that runs during a simulation. There arealso some classes defined for the production of separate windows that are opened.The SettingsFrame class contains the code behind the settings window and theDataFrame class comprises of the coding behind the data displayed for each net-work link. The LinkDataFrame class handles the window that creates the resultsdata about each network link generated by a simulation.

74

A.2 Code Listing

package code;

/**

* Network.java

* @author: Anquoc Tran

* @date started: February, 2006

* An Applet for the simulation of a telephone network to

* allow different routing algorithms to be compared. The

* simulation can be run in the absence of an algorithm,

* with the trunk reservation algorithm or with the sticky

* routing algorithm. Certain conditions can be defined on

* network created for simulation.

*/

import java.awt.*; import java.applet.Applet; import

java.awt.event.*; import javax.swing.*; import javax.swing.table.*;

import java.io.IOException; import java.io.*; import

java.util.Random; import java.text.DecimalFormat; import

javax.swing.Timer; import java.applet.*;

public class Network extends java.applet.Applet{

NetworkArea networkArea = new NetworkArea(this);

TopPanel topPanel = new TopPanel(this);

RunButtonsPanel runButtonsPanel = new RunButtonsPanel(this);

BottomPanel bottomPanel = new BottomPanel(this);

InformationPanel informationPanel = new InformationPanel(this);

AudioClip phoneRing;

AudioClip dialTone;

AudioClip hangUp;

AudioClip newNode;

public void init() {

setLayout(new BorderLayout());

add("Center", networkArea);

add("North", topPanel);

add("East", runButtonsPanel);

add("South", bottomPanel);

add("West", informationPanel);

// Sound clips

phoneRing = getAudioClip(getDocumentBase(), "ring.wav");

dialTone = getAudioClip(getDocumentBase(), "dialtone.wav");

hangUp = getAudioClip(getDocumentBase(), "hang_up.wav");

newNode = getAudioClip(getDocumentBase(), "new_node.wav");

}

}

/**

* This class provides a wrapper for the Global Variables

*/

class Globals {

// Drop-Down Selections

public static int selectedIndex = 0;

public static int algorithmSelectedIndex = 0;

public static int viewSelectedIndex = 0;

// Settings

public static int maximumNodes = 50;

public static int trunkParameter = 5;

public static int linkCapacity = 100;

public static int runDuration = 2;

public static int avgNumCalls = 110;

public static int avgCallLength = 1;

public static boolean sound = false;

75

// Example Settings

public static int symmetry = 0;

public static int completeNetwork = 0;

public static int networkSize = 0;

// Simulation Run Data

public static boolean running = true;

public static int callsStarted = 1;

public static int callsConnected = 0;

public static int callsLost = 0;

public static int numLinks = 0;

public static int session = 0;

}

class TopPanel extends Panel{

ActionOptions actionOptions = new ActionOptions(this);

StatusPanel statusPanel = new StatusPanel();

ActionButtonPanel actionButtons = new ActionButtonPanel(this);

Network topParent;

TopPanel(Network myParent){

topParent = myParent;


setBackground(Color.lightGray);

Font f = new Font("Serif", Font.BOLD, 16);

Label l = new Label("TELEPHONE NETWORK SIMULATOR", Label.CENTER);

l.setBackground(Color.white);

l.setFont(f);

add("North", l);

add("West", actionOptions);

add("East", actionButtons);

add("South", statusPanel);

}

}

/**

* Class contains the drop down options for the current action, the current

* view and the routing algorithm to be used.

*/

class ActionOptions extends Panel {

Choice actions = new Choice();

Choice algorithm = new Choice();

Choice view = new Choice();

Label lblAction;

Label lblAlgorithm;

Label lblView;

Label lblBlank = new Label("");

Label lblBlank2 = new Label("");

TopPanel parent;

ActionOptions(TopPanel myParent){

setLayout(new GridLayout(2,4));

parent = myParent;

// Current Action options

actions.add("Create Node");

actions.add("Delete Node");

actions.add("Create Link");

76

actions.add("Change Link Capacity");

actions.add("Delete Link");

actions.add("Change Link Trunk P’meter");

actions.add("Change Link Call Rate");

actions.add("Change Link Call Duration");

// Routing Algorithm options

algorithm.add("None");

algorithm.add("Trunk Reservation");

algorithm.add("Sticky Routing");

// Current View options

view.add("Capacities");

view.add("Trunk Parameters");

view.add("Call Rates");

view.add("Avg. Call Durations");


lblAction = new Label("Current Action: ", Label.RIGHT);

lblAction.setFont(f);

lblAlgorithm = new Label("Routing Algorithm: ", Label.RIGHT);

lblAlgorithm.setFont(f);

lblView = new Label("Current Link View: ", Label.RIGHT);

lblView.setFont(f);

add(lblAction);

add(actions);

add(lblBlank);

add(lblBlank2);

add(lblView);

add(view);

add(lblAlgorithm);

add(algorithm);

}

public boolean action(Event evt, Object arg) {

if (evt.target instanceof Choice) {

Globals.selectedIndex = actions.getSelectedIndex();

Globals.algorithmSelectedIndex = algorithm.getSelectedIndex();

if (view.getSelectedIndex() == 0){

Globals.viewSelectedIndex = view.getSelectedIndex();

parent.topParent.networkArea.repaint();

}

else if (view.getSelectedIndex() == 1){



}




}




}

}

return true;

}

}

/**

* Class contains the button options to begin running the simulation, clear a

* created network, view the network data or open the settings window.

*/

class ActionButtonPanel extends Panel{

77

Button btnRun = new Button("Run");

Button btnClear = new Button("Clear");

Button btnSettings = new Button("Settings");

Button btnLinkData = new Button("Data...");

Timer timer;

TopPanel parent;

SettingsFrame set = new SettingsFrame();

ActionButtonPanel(TopPanel myParent){

parent = myParent;

setLayout(new GridLayout(1, 4, 5, 0));

add(btnRun);

add(btnClear);

add(btnLinkData);

add(btnSettings);

}

public boolean action(Event evt, Object arg) {

if (evt.target instanceof Button) {

// Action of the Run button and running the simulation

if (((String)arg).equals("Run")) {

// enable the simulation buttons

parent.topParent.runButtonsPanel.btnTerminate.setEnabled(true);

parent.topParent.runButtonsPanel.btnStop.setEnabled(true);

parent.topParent.runButtonsPanel.btnReset.setEnabled(true);

// disable the option buttons

btnRun.setEnabled(false);

btnClear.setEnabled(false);

btnSettings.setEnabled(false);

btnLinkData.setEnabled(false);

parent.topParent.runButtonsPanel.btnExample.setEnabled(false);

parent.topParent.runButtonsPanel.btnTerminate.requestFocus();

// disable the option selection boxes

parent.actionOptions.actions.setEnabled(false);

parent.actionOptions.algorithm.setEnabled(false);

parent.actionOptions.view.setEnabled(false);

parent.actionOptions.lblAction.setForeground(Color.gray);

parent.actionOptions.lblAlgorithm.setForeground(Color.gray);

parent.actionOptions.lblView.setForeground(Color.gray);

// Show the timer details

parent.topParent.bottomPanel.runInfoPanel.lblActualTimeElapsed.setVisible(true);

parent.topParent.bottomPanel.runInfoPanel.lblTimeElapsed.setVisible(true);

parent.topParent.bottomPanel.runInfoPanel.lblActualTimeRemaining.setVisible(true);

parent.topParent.bottomPanel.runInfoPanel.lblTimeRemaining.setVisible(true);

// Show the Simulation Network Details

parent.topParent.informationPanel.lblTitle.setVisible(true);

parent.topParent.informationPanel.lblTitle.setBackground(Color.cyan);

parent.topParent.informationPanel.lblNumCalls.setVisible(true);

parent.topParent.informationPanel.lblNumCallsConnect.setVisible(true);

parent.topParent.informationPanel.lblNumCallsLost.setVisible(true);

parent.topParent.informationPanel.lblPercentCallsLost.setVisible(true);

parent.topParent.informationPanel.lblNumCallsValue.setVisible(true);

parent.topParent.informationPanel.lblNumCallsConnectValue.setVisible(true);

parent.topParent.informationPanel.lblNumCallsLostValue.setVisible(true);

parent.topParent.informationPanel.lblPercentCallsLostValue.setVisible(true);

78

parent.topParent.informationPanel.btnData.setVisible(true);

parent.topParent.topPanel.statusPanel.showMessage("clear");

// prevent the user from any input on the network area canvas

parent.topParent.networkArea.lock();

// set the total network global variables

Globals.callsStarted = 1;

Globals.callsConnected = 0;

Globals.callsLost = 0;

// clear any previous simulation network details

parent.topParent.networkArea.clearCurrentCapacity();

parent.topParent.networkArea.clearLinkData();

// start the simulation

parent.topParent.networkArea.runSimulation();

// start the timer

TimerCount count = new TimerCount(Globals.runDuration*60, this);

timer = new Timer(1000, count);

timer.start();

// set the session number

Globals.session++;

// check if sound setting is on and play sound file

if (Globals.sound){

parent.topParent.phoneRing.play();

}

}

// Action of the clear button

if (((String)arg).equals("Clear")) {

parent.topParent.networkArea.clear();

}

// Action of the settings button - opens the settings window

if (((String)arg).equals("Settings")) {

set.show();

}

// Action of the Data button - opens the network data window

if (((String)arg).equals("Data...")){

DataFrame frame = new DataFrame(this);

frame.show();

}

}

return true;

}

}

/**

* Class creates the window to show the network data in a table

*/

class DataFrame extends JFrame{

ActionButtonPanel parent;

DataFrame(ActionButtonPanel myParent){

parent = myParent;

createTablePanel();

pack();

}

public void createTablePanel(){

79

JPanel panel = new JPanel();

panel.setLayout(new GridLayout(1,1));

panel.setBorder(BorderFactory.createTitledBorder("Link Data"));

String[] columnNames = {"Node from",

"Node to",

"Capacity",

"Trunk Parameter",

"No. of Calls per min",

"Avg. Call Length (mins)"

};

Object[][] data = new Object[Globals.numLinks][Globals.maximumNodes];

int rows = 0;

for (int i=0; i<Globals.maximumNodes; i++){

for (int j=0; j<Globals.maximumNodes; j++){

if (parent.parent.topParent.networkArea.capacity[i][j] > 0){

for (int columns = 0; columns < 6; columns++){

if (columns==0){

data[rows][columns] = intToString(i);

}

else if (columns==1){

data[rows][columns] = intToString(j);

}


data[rows][columns] =

new Integer(parent.parent.topParent.networkArea.capacity[i][j]);

}



new Integer(parent.parent.topParent.networkArea.linkTrunkParameter[i][j]);

}



new Integer(parent.parent.topParent.networkArea.linkCallRate[i][j]);

}



new Integer(parent.parent.topParent.networkArea.linkCallDuration[i][j]);

}

}

rows++;

}

}

}

final JTable table = new JTable(data, columnNames);

table.setPreferredScrollableViewportSize(new Dimension(750, 200));

// Resize the table columns

TableColumn column = null;

for (int i = 0; i < 6; i++) {

column = table.getColumnModel().getColumn(i);

if (i == 5){

column.setPreferredWidth(100);

}

}

JScrollPane scrollPane = new JScrollPane(table);

panel.add(scrollPane);

getContentPane().add(panel, BorderLayout.NORTH);

}

public String intToString(int i) {

80

char c=(char)((int)’A’+ i);

return ""+c;

}

}

/*

* Class for the user error messages that are displayed when using the application

*/

class StatusPanel extends Panel{

final String maxNodes = new String("Cannot create Node: The maximum number of nodes

has been reached");

final String closeNodes = new String("Cannot create Node: Too close to existing nodes");

final String closeCapacityPoint = new String("Cannot create Node: Too close to link

capacity point");

final String inputNumError = new String("Cannot change link capacity:

Non-numerical character entered");

final String linkOverlap = new String("Cannot create link: Link already exists");

final String nodeDelete = new String("Click on a node to delete a node");

final String createLink = new String("To create a link: Click on a node, hold down the

mouse button and drag it to another node");

final String linkDelete = new String("Click on the link capacity node to delete a link");

final String changeCapacity = new String("Click on the link capacity node to change

link capacity");

final String lockedScreen = new String("Unable to carry out action: The screen is

currently locked");

final String viewDataRunning = new String("Unable to view the individual link data while

the simulator is running");

final String changeTrunkParameter = new String("Click on the link capacity node to change

the trunk parameter of the link");

final String changeCallRate = new String("Click on the link capacity node to change the

call rate of the link");

final String changeCallDuration = new String("Click on the link capacity node to change

the call duration of the link");

Label label = new Label();

StatusPanel(){

setLayout(new GridLayout(1,0));

Font f = new Font("Serif", Font.ITALIC, 12);

label.setFont(f);

label.setBackground(Color.white);

label.setForeground(Color.red);

add(label);

}

public void showMessage(String str){

if (str.equals("maxNodes")){

label.setText(maxNodes);

}

else if (str.equals("clear")){

label.setText("");

}

else if (str.equals("closeNodes")){

label.setText(closeNodes);

}

else if (str.equals("closeCapacityPoint")){

label.setText(closeCapacityPoint);

}

else if (str.equals("inputNumError")){

label.setText(inputNumError);

}

else if (str.equals("linkOverlap")){

label.setText(linkOverlap);

}

else if (str.equals("nodeDelete")){

label.setText(nodeDelete);

81

}

else if (str.equals("createLink")){

label.setText(createLink);

}

else if (str.equals("linkDelete")){

label.setText(linkDelete);

}

else if (str.equals("changeCapacity")){

label.setText(changeCapacity);

}

else if (str.equals("lockedScreen")){

label.setText(lockedScreen);

}

else if (str.equals("viewDataRunning")){

label.setText(viewDataRunning);

}

else if (str.equals("changeTrunkParameter")){

label.setText(changeTrunkParameter);

}

else if (str.equals("changeCallRate")){

label.setText(changeCallRate);

}

else if (str.equals("changeCallDuration")){

label.setText(changeCallDuration);

}

}

}

/**

* Class for the network data generated by the simulation.

*/

class InformationPanel extends Panel {

Network parent;

Label lblTitle = new Label("Total Network Data", Label.CENTER);

Label lblNumCalls = new Label("No. of calls started:", Label.CENTER);

Label lblNumCallsConnect = new Label("No. of connected calls:", Label.CENTER);

Label lblNumCallsLost = new Label("No. of lost calls:", Label.CENTER);

Label lblPercentCallsLost = new Label("% of calls lost:", Label.CENTER);

Label lblNumCallsValue = new Label("0", Label.CENTER);

Label lblNumCallsConnectValue = new Label("0", Label.CENTER);

Label lblNumCallsLostValue = new Label("0", Label.CENTER);

Label lblPercentCallsLostValue = new Label("0.00%", Label.CENTER);



Button btnData = new Button("View Link Data");

InformationPanel(Network myParent){

parent = myParent;


setLayout(new GridLayout(12,1,0,0));


Font f2 = new Font("Times", Font.BOLD, 12);

Font f3 = new Font("Times", Font.PLAIN, 11);

lblTitle.setVisible(false);

lblNumCalls.setVisible(false);

lblNumCallsConnect.setVisible(false);

lblNumCallsLost.setVisible(false);

lblPercentCallsLost.setVisible(false);

lblNumCallsValue.setVisible(false);

lblNumCallsConnectValue.setVisible(false);

lblNumCallsLostValue.setVisible(false);

82

lblPercentCallsLostValue.setVisible(false);

btnData.setVisible(false);

lblNumCalls.setFont(f);

lblNumCallsConnect.setFont(f);

lblNumCallsLost.setFont(f);

lblPercentCallsLost.setFont(f);

lblTitle.setFont(f2);

btnData.setFont(f3);

add(lblTitle);

add(lblBlank);

add(lblNumCalls);

add(lblNumCallsValue);

add(lblNumCallsConnect);

add(lblNumCallsConnectValue);

add(lblNumCallsLost);

add(lblNumCallsLostValue);

add(lblPercentCallsLost);

add(lblPercentCallsLostValue);

add(lblBlank2);

add(btnData);

}

public boolean action(Event evt, Object arg){

if (evt.target instanceof Button){

// open the link data generated by the simulation

if (((String)arg).equals("View Link Data")){

LinkDataFrame frame = new LinkDataFrame(this);

frame.show();

}

}

return true;

}

}

/**

* Class creates the window to show the link data in a table

*/

class LinkDataFrame extends JFrame{

InformationPanel parent;

LinkDataFrame(InformationPanel myParent){

parent = myParent;

createTablePanel();

pack();

}

public void createTablePanel(){

JPanel tablePanel = new JPanel();

tablePanel.setLayout(new GridLayout(1,1));

tablePanel.setBorder(BorderFactory.createTitledBorder("Individual Link Data"));

String[] columnNames = {"Node from",

"Node to",

"Calls Started",

"Direct Calls Connected",

"Indirect Calls Connected",

"Calls Lost",

"% of Lost Calls"};

Object[][] data = new Object[Globals.numLinks][Globals.maximumNodes];

int rows = 0;

DecimalFormat twoDP = new DecimalFormat("0.00");

83



if (parent.parent.networkArea.capacity[i][j] > 0){

for(int columns=0; columns<7; columns++){

if (columns==0){

data[rows][columns] = intToString(i);

}


data[rows][columns] = intToString(j);

}



new Integer(parent.parent.networkArea.callsStarted[i][j]);

}



new Integer(parent.parent.networkArea.directCalls[i][j]);

}



new Integer(parent.parent.networkArea.indirectCalls[i][j]);

}



new Integer(parent.parent.networkArea.callsLost[i][j]);

}



twoDP.format(parent.parent.networkArea.percentCallsLost[i][j]);

}

}

rows++;

}

}

}

final JTable table = new JTable(data, columnNames);

table.setPreferredScrollableViewportSize(new Dimension(750, 200));

table.setRowSelectionAllowed(false);

table.setColumnSelectionAllowed(false);

table.setCellSelectionEnabled(false);

table.setEnabled(false);

// Resize the table columns

TableColumn column = null;

for (int i = 0; i < 7; i++) {

column = table.getColumnModel().getColumn(i);

if (i == 0) {


}

else if (i == 1){


}

else if (i == 2){


}

else if (i == 3){


}

else if (i == 4){


}

else if (i == 5){


}

84

else if (i == 6){


}

else {


}

}

JScrollPane scrollPane = new JScrollPane(table);

tablePanel.add(scrollPane);

JLabel lblLastView = new JLabel("Last viewed after " +

parent.parent.bottomPanel.runInfoPanel.lblActualTimeElapsed.getText(), JLabel.CENTER);

Font f = new Font("Serif", Font.ITALIC, 12);

lblLastView.setFont(f);

getContentPane().add(tablePanel, BorderLayout.NORTH);

getContentPane().add(lblLastView, BorderLayout.SOUTH);

}



return ""+c;

}

}

/**

* Class contains the simulation buttons to terminate the simulation,

* stop the simulation, reset/restart the network and create an example network.

*/

class RunButtonsPanel extends Panel {

Button btnTerminate = new Button("Terminate");

Button btnStop = new Button("Stop");

Button btnReset = new Button("Reset");

Button btnExample = new Button("Example");

Button btnBlank = new Button("");

Button btnBlank2 = new Button("");

Timer resTimer;

Network parent;

RunButtonsPanel(Network myParent){

parent = myParent;

// set the timer when network is reset

TimerCount count = new TimerCount(Globals.runDuration*60, parent.topPanel.actionButtons);

resTimer = new Timer(1000, count);


setLayout(new GridLayout(6,1,0,10));

btnBlank.setVisible(false);

btnBlank2.setVisible(false);

btnTerminate.setEnabled(false);

btnStop.setEnabled(false);

btnReset.setEnabled(false);

btnExample.setEnabled(true);

add(btnTerminate);

add(btnStop);

add(btnReset);

add(btnExample);

add(btnBlank);

add(btnBlank2);

}

85



// action of the terminate button

if (((String)arg).equals("Terminate")){

// disable the simulation buttons

btnTerminate.setEnabled(false);

btnStop.setEnabled(false);

btnReset.setEnabled(false);

// enable the option buttons and example button

parent.topPanel.actionButtons.btnRun.setEnabled(true);

parent.topPanel.actionButtons.btnClear.setEnabled(true);

parent.topPanel.actionButtons.btnSettings.setEnabled(true);

parent.topPanel.actionButtons.btnLinkData.setEnabled(true);

parent.topPanel.actionButtons.btnRun.requestFocus();

btnExample.setEnabled(true);

// enable the option selection boxes

parent.topPanel.actionOptions.actions.setEnabled(true);

parent.topPanel.actionOptions.algorithm.setEnabled(true);

parent.topPanel.actionOptions.view.setEnabled(true);

parent.topPanel.actionOptions.lblAction.setForeground(Color.BLACK);

parent.topPanel.actionOptions.lblAlgorithm.setForeground(Color.BLACK);

parent.topPanel.actionOptions.lblView.setForeground(Color.BLACK);

// hide the timer details

parent.bottomPanel.runInfoPanel.lblActualTimeElapsed.setVisible(false);

parent.bottomPanel.runInfoPanel.lblActualTimeRemaining.setVisible(false);

parent.bottomPanel.runInfoPanel.lblTimeElapsed.setVisible(false);

parent.bottomPanel.runInfoPanel.lblTimeRemaining.setVisible(false);

// hide the simulation network details

parent.informationPanel.lblTitle.setVisible(false);

parent.informationPanel.lblTitle.setBackground(Color.lightGray);

parent.informationPanel.lblNumCalls.setVisible(false);

parent.informationPanel.lblNumCallsConnect.setVisible(false);

parent.informationPanel.lblNumCallsLost.setVisible(false);

parent.informationPanel.lblPercentCallsLost.setVisible(false);

parent.informationPanel.lblNumCallsValue.setVisible(false);

parent.informationPanel.lblNumCallsConnectValue.setVisible(false);

parent.informationPanel.lblNumCallsLostValue.setVisible(false);

parent.informationPanel.lblPercentCallsLostValue.setVisible(false);

parent.informationPanel.btnData.setVisible(false);

// reset the simulation network details

parent.informationPanel.lblNumCallsValue.setText("0");

parent.informationPanel.lblNumCallsConnectValue.setText("0");

parent.informationPanel.lblNumCallsLostValue.setText("0");

parent.informationPanel.lblPercentCallsLostValue.setText("0.00%");

// stop the timer

parent.topPanel.actionButtons.timer.stop();

// stop the reset timer

if (resTimer.isRunning()){

resTimer.stop();

}

// reset the timer details

parent.bottomPanel.runInfoPanel.lblActualTimeElapsed.setText("0 Secs");

parent.bottomPanel.runInfoPanel.lblActualTimeRemaining.

setText(Globals.runDuration*60 + " Secs");

// allow the user to input onto the network area canvas

parent.networkArea.unlock();

86

parent.topPanel.statusPanel.showMessage("clear");

// reset the simulation global variables




Globals.running = false;

// clear the data generated by the simulation on the network

parent.networkArea.clearCurrentCapacity();

parent.networkArea.clearLinkData();

parent.networkArea.repaint();


if (Globals.sound){

parent.hangUp.play();

}

// change the label of the reset button to say "reset"

if (btnReset.getLabel().equals("Restart")){

btnReset.setLabel("Reset");

}

}

// actions of the Stop button

if (((String)arg).equals("Stop")){

// set global variable to indicate simulation no longer running


// stop the timer




resTimer.stop();

}


}

// actions of reset button

if (((String)arg).equals("Reset")){

// print out the data generated by the simulation

printResults();

// reset the simulation network data





// stop the timer




resTimer.stop();

}

// reset the timer details

parent.bottomPanel.runInfoPanel.lblActualTimeElapsed.setText("0 Secs");

parent.bottomPanel.runInfoPanel.lblActualTimeRemaining.

setText(Globals.runDuration*60 + " Secs");

// reset the simulation network details

parent.informationPanel.lblNumCallsValue.setText("0");

parent.informationPanel.lblNumCallsConnectValue.setText("0");

parent.informationPanel.lblNumCallsLostValue.setText("0");

parent.informationPanel.lblPercentCallsLostValue.setText("0.00%");

87

// clear the network data generated by the simulation



parent.networkArea.repaint();

// change the button label to restart

btnReset.setLabel("Restart");


}

if (((String)arg).equals("Restart")){

// start a new simulation session and reset the

// simulation network data

Globals.session++;






// start the timer

TimerCount count = new TimerCount(Globals.runDuration*60,

parent.topPanel.actionButtons);

resTimer = new Timer(1000, count);

resTimer.start();


parent.networkArea.runSimulation();

btnReset.setLabel("Reset");



if (Globals.sound){

parent.phoneRing.play();

}

}

// action of the example button - draws an example network

if (((String)arg).equals("Example")){

parent.networkArea.drawExample();

}

}

return true;

}

// prints the results of simulation to the command shell

public void printResults(){


// Total Network data

System.out.println("Total Network Data:");

System.out.println("Calls Started: " + Globals.callsStarted

+ ", Calls Connected: " + Globals.callsConnected

+ ", Calls Lost: " + Globals.callsLost

+ ", % of Calls Lost: "

+ parent.informationPanel.lblPercentCallsLostValue.getText());

// Link data

System.out.println("Link Data:");



88

if (parent.networkArea.capacity[i][j] > 0){

System.out.println("Node from: " + intToString(i) + ", Node to: "

+ intToString(j)

+ ", Capacity: "

+ parent.networkArea.capacity[i][j]

+ ", Trunk Parameter: "

+ parent.networkArea.linkTrunkParameter[i][j]

+ ", Call Rate: "

+ parent.networkArea.linkCallRate[i][j]

+ ", Call Length: "

+ parent.networkArea.linkCallDuration[i][j]

+ ", Calls Started: "

+ parent.networkArea.callsStarted[i][j]

+ ", Direct Calls: "

+ parent.networkArea.directCalls[i][j]

+ ", Indirect Calls: "

+ parent.networkArea.indirectCalls[i][j]

+ ", Calls Lost: "

+ parent.networkArea.callsLost[i][j]

+ ", % Calls Lost: "

+ twoDP.format(parent.networkArea.percentCallsLost[i][j]));

}

}

}

}



return ""+c;

}

}

class BottomPanel extends Panel{

RunInfoPanel runInfoPanel = new RunInfoPanel(this);

Panel leftPanel = new Panel();

Panel rightPanel = new Panel();

Network parent;

BottomPanel(Network myParent){

parent = myParent;



add("North", runInfoPanel);

}

}

/**

* Class creates the display for the timer details of the simulation

*/

class RunInfoPanel extends Panel{

BottomPanel parent;

Label lblTimeElapsed = new Label("Time Elapsed: ");

Label lblActualTimeElapsed = new Label("0 Secs");

Label lblTimeRemaining = new Label("Time Remaining: ");

Label lblActualTimeRemaining = new Label(Globals.runDuration*60 + " Secs");

RunInfoPanel(BottomPanel myParent){

parent = myParent;

setLayout(new GridLayout(1, 9, 0, 0));

89


lblTimeElapsed.setFont(f);

lblTimeRemaining.setFont(f);






lblTimeElapsed.setVisible(false);

lblActualTimeElapsed.setVisible(false);

lblTimeRemaining.setVisible(false);

lblActualTimeRemaining.setVisible(false);

add(lblBlank);

add(lblBlank2);

add(lblBlank3);

add(lblTimeElapsed);

add(lblActualTimeElapsed);

add(lblTimeRemaining);

add(lblActualTimeRemaining);

add(lblBlank4);

add(lblBlank5);

}

}

/**

* Class for the canvas area which allows the creation and display of the

* network. Also defines methods and inner classes for running the

* simulation.

*/

class NetworkArea extends Canvas implements Runnable{

// Network constants

final int NODEMAX = 50;

final int MAXSIZE = NODEMAX + 1;

final int NODESIZE = 20;

final int NODERADIUS = 10;

// Network data

Point node[] = new Point[MAXSIZE];

int capacity[][] = new int[MAXSIZE][MAXSIZE];

Point linkCapacityPoint[][] = new Point[MAXSIZE][MAXSIZE];

Point linkStartPoint[][] = new Point[MAXSIZE][MAXSIZE];

Point linkEndPoint[][] = new Point[MAXSIZE][MAXSIZE];

int currentCapacity[][] = new int[MAXSIZE][MAXSIZE];

int linkTrunkParameter[][] = new int[MAXSIZE][MAXSIZE];

int linkCallRate[][] = new int[MAXSIZE][MAXSIZE];

int linkCallDuration[][] = new int[MAXSIZE][MAXSIZE];

// Network algorithm running data

int callsStarted[][] = new int[MAXSIZE][MAXSIZE];

int directCalls[][] = new int[MAXSIZE][MAXSIZE];

int indirectCalls[][] = new int[MAXSIZE][MAXSIZE];

int callsLost[][] = new int[MAXSIZE][MAXSIZE];

double percentCallsLost[][] = new double[MAXSIZE][MAXSIZE];

int tandemNode[][] = new int[MAXSIZE][MAXSIZE];

// Network creation data

int numNodes = 0;

int emptySlot = 0;

int nodeHit;

int currentNode1;

int currentNode2;

Point currentPoint = new Point(0,0);

Point previousPoint = new Point(0,0);

// Current action

90

boolean deleteNode = false;

boolean newLink = false;

boolean deleteLink = false;

// Lock the screen when simulation is running

boolean locked = false;

// Random number generator for call wait times and call durations

Random numberGenerator = new Random();

// set the font

Font roman= new Font("TimesRoman", Font.PLAIN, 10);

FontMetrics fmetrics = getFontMetrics(roman);

Network parent;

NetworkArea(Network myParent){

parent=myParent;

setBackground(Color.gray);

}

public void lock(){

locked = true;

}

public void unlock(){

locked = false;

}

public void init() {

}

// clear the network

public void clear(){

numNodes=0;

emptySlot=0;

Globals.numLinks=0;


node[i]=new Point(0, 0);


capacity[i][j] = 0;

currentCapacity[i][j] = 0;

linkTrunkParameter[i][j] = 0;

linkCallRate[i][j] = 0;

linkCallDuration[i][j] = 0;

}

}


repaint();

}

public boolean mouseDown(Event evt, int x, int y){

if (locked){

parent.topPanel.statusPanel.showMessage("lockedScreen");

}

else{

// create node

if (Globals.selectedIndex == 0){

if (nodeClicked(x,y, 40) == false){

if (capacityPointClicked(x, y, 40) == false){

if (emptySlot == 0){

if (numNodes < Globals.maximumNodes){

91

node[numNodes++] = new Point(x,y);


if (Globals.sound){

parent.newNode.play();

}

}

else{

parent.topPanel.statusPanel.showMessage("maxNodes");

}

}

else{

int i;

for (i=0; i<numNodes; i++)

if (node[i].x == -100)

break;

node[i]= new Point(x,y);

emptySlot--;


}

}

else{

parent.topPanel.statusPanel.showMessage("closeCapacityPoint");

}

}

else{

parent.topPanel.statusPanel.showMessage("closeNodes");

}

}

// delete node

else if (Globals.selectedIndex == 1){

if (nodeClicked(x, y, NODESIZE)){

currentNode1 = nodeHit;

deleteNode=true;

}

else{

parent.topPanel.statusPanel.showMessage("nodeDelete");

}

}

// create link



if (newLink == false){

newLink = true;

currentPoint = new Point(x, y);


}

}

else{

parent.topPanel.statusPanel.showMessage("createLink");

}

}

// change link capacity


if (capacityPointClicked(x, y, 5)){

try {

String inputCapacity = JOptionPane.showInputDialog("Enter New

Link Capacity");

92

if (inputCapacity != null && !inputCapacity.equals("")){

int newCapacity = Integer.parseInt(inputCapacity);

capacity[currentNode1][currentNode2] = newCapacity;


}

else{


}

}

catch (NumberFormatException exception){

parent.topPanel.statusPanel.showMessage("inputNumError");

}

catch(NullPointerException e)

{

System.out.println("NullPointerException caught");

}

}

else{

parent.topPanel.statusPanel.showMessage("changeCapacity");

}

}

// delete link



deleteLink = true;

}

else{

parent.topPanel.statusPanel.showMessage("linkDelete");

}

}

// change trunk parameter



try {

String inputTrunkParameter =

JOptionPane.showInputDialog("Enter New Link Trunk Parameter");

if (inputTrunkParameter != null && !inputTrunkParameter.equals("")){

int newTrunkParameter = Integer.parseInt(inputTrunkParameter);

linkTrunkParameter[currentNode1][currentNode2] = newTrunkParameter;


}

else{


}

}



}


{


}

}

else{

parent.topPanel.statusPanel.showMessage("changeTrunkParameter");

}

}

93

// change call rate



try {

String inputCallRate = JOptionPane.showInputDialog("Enter New

Link Call Rate");

if (inputCallRate != null && !inputCallRate.equals("")){

int newCallRate = Integer.parseInt(inputCallRate);

linkCallRate[currentNode1][currentNode2] = newCallRate;


}

else{


}

}



}


{


}

}

else{

parent.topPanel.statusPanel.showMessage("changeCallRate");

}

}

// change call duration



try {

String inputCallDuration = JOptionPane.showInputDialog("Enter New

Link Call Duration");

if (inputCallDuration != null && !inputCallDuration.equals("")){

int newCallDuration = Integer.parseInt(inputCallDuration);

linkCallDuration[currentNode1][currentNode2] = newCallDuration;


}

else{


}

}



}


{


}

}

else{

parent.topPanel.statusPanel.showMessage("changeCallDuration");

}

}

repaint();

94

}

return true;

}

public boolean mouseUp(Event evt, int x, int y){

if (!locked){

// delete node

if (deleteNode){

nodeDelete();

deleteNode = false;

}

// create link

else if (newLink){

newLink = false;



if (currentNode1 != currentNode2){

if (capacity[currentNode1][currentNode2] == 0){

createLink(currentNode1, currentNode2, Globals.linkCapacity,

Globals.trunkParameter, Globals.avgNumCalls,

Globals.avgCallLength);

}

else{

parent.topPanel.statusPanel.showMessage("linkOverlap");

}

}

}

else{

parent.topPanel.statusPanel.showMessage("createLink");

}

}

// delete link

else if (deleteLink){

linkDelete();

deleteLink = false;

}

repaint();

}

return true;

}

public boolean mouseDrag(Event evt, int x, int y){

// create link

if (!locked){

if (newLink){

currentPoint = new Point(x,y);

repaint();

}

}

return true;

}

// create link method. Sets the data for the link and screen position

public void createLink(int node1, int node2, int c, int t, int cr, int cd){

// Set the link data

capacity[node1][node2] = c;

currentCapacity[node1][node2] = 0;

linkTrunkParameter[node1][node2] = t;

linkCallRate[node1][node2] = cr;

linkCallDuration[node1][node2] = cd;

95

int dx;

int dy;

float dir_x;

float dir_y;

float l;

// calculate link length and direction

dx = node[node2].x-node[node1].x;

dy = node[node2].y-node[node1].y;

l = (float)( Math.sqrt((float)(dx*dx + dy*dy)));

dir_x = dx/l;

dir_y = dy/l;

// get the start and end point positions of the link

linkStartPoint[node1][node2] = new Point((int)(node[node1].x-5*dir_y),

(int)(node[node1].y + 5*dir_x));

linkEndPoint[node1][node2] = new Point((int)(node[node2].x-5*dir_y),

(int)(node[node2].y+ 5*dir_x));

// Calculate the position of the link capacity point

linkCapacityPoint[node1][node2] = new Point((linkStartPoint[node1][node2].x +

linkEndPoint[node1][node2].x)/2, 0);

linkCapacityPoint[node1][node2].y = ((linkStartPoint[node1][node2].y +

linkEndPoint[node1][node2].y)/2);

// increment the number of links in the network

Globals.numLinks++;


}

// settings for the display of the link

public void drawLink(Graphics g, int i, int j){

g.setColor(Color.BLACK);

g.drawLine(linkStartPoint[i][j].x, linkStartPoint[i][j].y,linkEndPoint[i][j].x,

linkEndPoint[i][j].y);

String strPointValue = "";

// if the current capacity matches the maximum link capacity, display

// the link node as red. Otherwise display in appropriate colour

// according to current view.

if (currentCapacity[i][j] == capacity[i][j]){

g.setColor(Color.RED);

if (Globals.viewSelectedIndex == 0){

strPointValue = "" + capacity[i][j];

}

else if (Globals.viewSelectedIndex == 1){

strPointValue = "" + linkTrunkParameter[i][j];

}


strPointValue = "" + linkCallRate[i][j];

}


strPointValue = "" + linkCallDuration[i][j];

}

}

else{

if (Globals.viewSelectedIndex == 0){

g.setColor(Color.BLUE);

strPointValue = "" + capacity[i][j];

}


g.setColor(Color.YELLOW);

strPointValue = "" + linkTrunkParameter[i][j];

}


96

g.setColor(Color.GREEN);

strPointValue = "" + linkCallRate[i][j];

}


g.setColor(Color.WHITE);

strPointValue = "" + linkCallDuration[i][j];

}

}

g.fillOval(linkCapacityPoint[i][j].x-5, linkCapacityPoint[i][j].y-5, 10, 10);

// write the link data in the appropriate place

if ((linkStartPoint[i][j].x <= linkEndPoint[i][j].x) &&

(linkStartPoint[i][j].y > linkEndPoint[i][j].y)){

g.drawString(strPointValue, linkCapacityPoint[i][j].x + 5,

linkCapacityPoint[i][j].y);

}

else if ((linkStartPoint[i][j].x < linkEndPoint[i][j].x) &&

(linkStartPoint[i][j].y <= linkEndPoint[i][j].y)){

g.drawString(strPointValue, linkCapacityPoint[i][j].x - 4 -

fmetrics.stringWidth(strPointValue), linkCapacityPoint[i][j].y + 9);

}

else if ((linkStartPoint[i][j].x > linkEndPoint[i][j].x) &&

(linkStartPoint[i][j].y >= linkEndPoint[i][j].y)){

g.drawString(strPointValue, linkCapacityPoint[i][j].x + 5, linkCapacityPoint[i][j].y);

}

else if ((linkStartPoint[i][j].x >= linkEndPoint[i][j].x) &&

(linkStartPoint[i][j].y < linkEndPoint[i][j].y)){

g.drawString(strPointValue, linkCapacityPoint[i][j].x - 4 -

fmetrics.stringWidth(strPointValue), linkCapacityPoint[i][j].y + 9);

}

}

// method to delete a node.

public void nodeDelete(){

node[currentNode1]= new Point(-100,-100);

for (int i=0; i<numNodes; i++){

if ((capacity[currentNode1][i] > 0) || (capacity[i][currentNode1] > 0)){

capacity[currentNode1][i] = 0;

capacity[i][currentNode1] = 0;

currentCapacity[currentNode1][i] = 0;

currentCapacity[i][currentNode1] = 0;

linkTrunkParameter[currentNode1][i] = 0;

linkTrunkParameter[i][currentNode1] = 0;

linkCallRate[i][currentNode1] = 0;

linkCallRate[currentNode1][i] = 0;

linkCallDuration[i][currentNode1] = 0;

linkCallDuration[currentNode1][i] = 0;

Globals.numLinks--;

}

}

emptySlot++;


}

// method to delete a link

public void linkDelete(){

capacity[currentNode1][currentNode2] = 0;

currentCapacity[currentNode1][currentNode2] = 0;

linkTrunkParameter[currentNode1][currentNode2] = 0;

linkCallRate[currentNode1][currentNode2] = 0;

linkCallDuration[currentNode1][currentNode2] = 0;

Globals.numLinks--;


}

97

// set the current capacity of the links back to 0.

public void clearCurrentCapacity(){



currentCapacity[i][j]=0;

}

}

}

// set all the simulation link data back to 0.

public void clearLinkData(){



callsStarted[i][j] = 0;

directCalls[i][j] = 0;

indirectCalls[i][j] = 0;

callsLost[i][j] = 0;

percentCallsLost[i][j] = 0;

}

}

}

// check if node has been clicked on

public boolean nodeClicked(int x, int y, int distance){


if ((x-node[i].x)*(x-node[i].x) + (y-node[i].y)*(y-node[i].y) < distance*distance){

nodeHit = i;

return true;

}

}

return false;

}

// check if link node has been clicked on

public boolean capacityPointClicked(int x, int y, int distance){


for (int j=0; j<numNodes; j++){

if ((capacity[i][j] > 0) && (Math.pow(x-linkCapacityPoint[i][j].x,2))

+ Math.pow(y-linkCapacityPoint[i][j].y,2) < Math.pow(distance, 2)){

currentNode1 = i;

currentNode2 = j;

return true;

}

}

}

return false;

}

// draw an example network on screen

public void drawExample(){

int width;

int height;

// remove any existing network

clear();

// get the application dimensions

width = this.size().width/10;

height = this.size().height/12;

if (Globals.networkSize == 0){

98

// small network

numNodes = 5;

node[0] = new Point(width*5, height*2);



node[3] = new Point(width*4 , height*10);


if (Globals.completeNetwork == 0){

// complete network


for(int j=0; j<numNodes; j++){

if (i != j){

if (Globals.symmetry == 0){

createLink(i,j, Globals.linkCapacity, Globals.trunkParameter,

Globals.avgNumCalls, Globals.avgCallLength);

}

else if (Globals.symmetry == 1){

int cap = numberGenerator.nextInt(451) + 50;

int trunk = numberGenerator.nextInt(11);

int cRate = numberGenerator.nextInt(251) + 50;

int cLength = numberGenerator.nextInt(4) + 1;

createLink(i, j, cap, trunk, cRate, cLength);

}

}

}

}

}

else if (Globals.completeNetwork == 1){

// non-complete network


// symmetric network

createLink(0,1, Globals.linkCapacity, Globals.trunkParameter,


createLink(0,4,Globals.linkCapacity, Globals.trunkParameter,




























}


// asymmetric network

99

createLink(0,1, numberGenerator.nextInt(451) + 50, numberGenerator.nextInt(11),

numberGenerator.nextInt(251) + 50, numberGenerator.nextInt(4) + 1);





























}

}

}

else if (Globals.networkSize == 1){

// large network

numNodes = 8;










// complete network



if (i != j){




}


int cap = numberGenerator.nextInt(451) + 50;

int trunk = numberGenerator.nextInt(11);

int cRate = numberGenerator.nextInt(251) + 50;

int cLength = numberGenerator.nextInt(4) + 1;

createLink(i, j, cap, trunk, cRate, cLength);

}

}

}

}

}

else if (Globals.completeNetwork == 1){

// non-complete network

100



if (i != j){

int k = numberGenerator.nextInt(5);

if ((k == 0) || (k == 1) || (k == 2)){


// symmetric network



}


// asymmetric network

createLink(i,j, numberGenerator.nextInt(451) + 50,

numberGenerator.nextInt(11), numberGenerator.nextInt(251) + 50,

numberGenerator.nextInt(4) + 1);

}

}

}

}

}

}

}

repaint();

}


public void runSimulation(){

Globals.running = true;



if (capacity[i][j] > 0){

if (Globals.algorithmSelectedIndex == 2){

assignTandemNode(i, j);

}

startCalls(i, j);

}

}

}

}

// start new calls on a link

public void startCalls(int i, int j){

final int node1 = i;

final int node2 = j;

class CallThread extends Thread{

public void run()

{

try{

int wait;

int arrivalTime = 0;

int maxTime = Globals.runDuration*60000;

int lambda = linkCallRate[node1][node2];

while(Globals.running == true){

// get the wait time between new calls starting

wait = (int)(getWaitTime(lambda)*60000);

// get the time the new call will start

arrivalTime = arrivalTime + wait;

101

// put the thread to sleep for the length of the wait time

sleep(wait);

// Stop any calls starting after the run duration time

if (arrivalTime >= maxTime){

break;

}

// check if simulation is still running

if (Globals.running == true){

// call is started and attempt to connect the call

parent.informationPanel.lblNumCallsValue.setText(Integer.toString

(Globals.callsStarted));

connectCall(node1, node2, arrivalTime);

Globals.callsStarted++;

callsStarted[node1][node2]++;

}

}

}

catch (InterruptedException exception)

{

System.out.println("Exception Caught");

}

}

}

Thread call = new CallThread();

call.start();

}

// attempt to connect a new call

public void connectCall(int i, int j, int arrTime){

final int node1 = i;

final int node2 = j;

final int arrivalTime = arrTime;

final int session = Globals.session;

class ConnectThread extends Thread{

public void run(){

int callDuration;

int lambda = linkCallDuration[node1][node2];

try{

// check if current capacity on link is less than the

// maximum capacity of the link

if (currentCapacity[node1][node2] < capacity[node1][node2]){

// connect the call

connectedCall(node1, node2);

directCalls[node1][node2]++;

currentCapacity[node1][node2]++;

// Get the duration of the call

callDuration = (int)(getWaitTime(lambda)*60000);

// put the call thread to sleep for the duration of

// the call

sleep(callDuration);

// check if the call thread belongs to the right

// simulation session

if (session == Globals.session){

// call has ended. Reduce the current

// capacity on the link

102

currentCapacity[node1][node2]--;

}

else{

// terminate the thread

stop();

}

}

else{

// no algorithm selected

if (Globals.algorithmSelectedIndex == 0){

lostCall(node1, node2);

}

// trunk reservation algorithm selected

else if (Globals.algorithmSelectedIndex == 1){

// run the trunk reservation algorithm

if (runTrunkAlgorithm(node1, node2)){

// connect the call


indirectCalls[node1][node2]++;



// put the call thread to sleep for the duration

// of the call








}

else{


stop();

}

}

else{

// call has been lost from the network

lostCall(node1,node2);

}

}

// sticky random routing algorithm selected

else if (Globals.algorithmSelectedIndex == 2){

// run the sticky routing algorithm

if (runStickyRoutingAlgorithm(node1, node2)){

// connect the call


indirectCalls[node1][node2]++;



// put the call thread to sleep for the duration

// of the call








}

else{

103


stop();

}

}

else{

// call has been lost from the network

lostCall(node1, node2);

}

}

}

// repaint the canvas

if (Globals.running){

repaint();

}

}

catch(InterruptedException exception){

System.out.println("Exception Caught");

}

}

}

Thread call = new ConnectThread();

call.start();

}

// trunk reservation algorithm

public boolean runTrunkAlgorithm(int i, int j){

int routeNodes[] = new int[numNodes];

int arrayIndex = 0;

int routedNode;

// find all the possible nodes to route by

for (int k=0; k<numNodes; k++){

if (node[k].x >0){

if ((k != i) && (k != j)){

if ((capacity[i][k] > 0) && (capacity[k][j]) > 0){

routeNodes[arrayIndex] = k;

arrayIndex++;

}

}

}

}

if (arrayIndex > 0){

int r = numberGenerator.nextInt(arrayIndex);

boolean sufficientCapacity1 = false;


// randomly select a node from the set of possible route nodes

routedNode = routeNodes[r];

// check if there is sufficient capacity on the links of requested route

if (capacity[i][routedNode] > 0){

if (currentCapacity[i][routedNode] < (capacity[i][routedNode] -

linkTrunkParameter[i][routedNode])){

sufficientCapacity1 = true;

}

}

if (capacity[routedNode][j] > 0){

if (currentCapacity[routedNode][j] < (capacity[routedNode][j] -

linkTrunkParameter[j][routedNode])){


}

}

if ((sufficientCapacity1 == true) && (sufficientCapacity2 == true)){

currentCapacity[i][routedNode]++;

104

currentCapacity[routedNode][j]++;

return true;

}

else{

return false;

}

}

else{

return false;

}

}

// sticky random routing algorithm

public boolean runStickyRoutingAlgorithm(int i, int j){



// node to route by is assigned tandem node of link

int routedNode = tandemNode[i][j];

// check if there is sufficient capacity on the links of requested route

if (capacity[i][routedNode] > 0){

if (currentCapacity[i][routedNode] < (capacity[i][routedNode] -

linkTrunkParameter[i][routedNode])){


}

}

if (capacity[routedNode][j] > 0){

if (currentCapacity[routedNode][j] < (capacity[routedNode][j] -

linkTrunkParameter[routedNode][j])){


}

}

if ((sufficientCapacity1 == true) && (sufficientCapacity2 == true)){

currentCapacity[i][routedNode]++;

currentCapacity[routedNode][j]++;

return true;

}

else{

// Reselect the tandem node

reAssignTandemNode(i, j, routedNode);

return false;

}

}

// assign a tandem node to a link for sticky routing algorithm

public void assignTandemNode(int i, int j){

int node1 = i;

int node2 = j;


int arrayIndex = 0;

// find all possible nodes to use as tandem node


if (node[k].x >0){

if ((k != node1) && (k != j)){

if ((capacity[node1][k] > 0) && (capacity[k][node2] > 0)){


arrayIndex++;

}

}

}

105

}



// randomly select a node from the set of possible nodes as a tandem node

tandemNode[node1][node2] = routeNodes[r];

}

}

// reassign tandem node for a link for sticky routing algorithm

public void reAssignTandemNode(int i, int j, int rNode){

int node1 = i;

int node2 = j;

int routedNode = rNode;


int arrayIndex = 0;

// find all possible nodes to use as tandem node


if (node[k].x >0){

if ((k != node1) && (k != node2) && (k != routedNode)){

if ((capacity[node1][k] > 0) && (capacity[k][node2] > 0)){


arrayIndex++;

}

}

}

}



// randomly select a node from the set of possible nodes as a tandem node

tandemNode[node1][node2] = routeNodes[r];

}

}

// call is connected on requested route. Update the necessary information

public void connectedCall(int node1, int node2){

double percentLostCalls;


Globals.callsConnected++;

parent.informationPanel.lblNumCallsConnectValue.setText(Integer.toString

(Globals.callsConnected));

percentLostCalls = (((double)(Globals.callsLost)/(double)(Globals.callsStarted))*100);

percentCallsLost[node1][node2] = (((double)(callsLost[node1][node2])/

(double)(callsStarted[node1][node2]))*100);

parent.informationPanel.lblPercentCallsLostValue.setText(twoDP.format

(percentLostCalls) + "%");

}

// call is lost from the network. Update the necessary information.

public void lostCall(int node1, int node2){

double percentLostCalls;


Globals.callsLost++;

callsLost[node1][node2]++;

parent.informationPanel.lblNumCallsLostValue.setText(Integer.toString(Globals.callsLost));

percentLostCalls = (((double)(Globals.callsLost)/(double)(Globals.callsStarted))*100);

percentCallsLost[node1][node2] = (((double)(callsLost[node1][node2])/

106

(double)(callsStarted[node1][node2]))*100);

parent.informationPanel.lblPercentCallsLostValue.setText(twoDP.format(percentLostCalls)

+ "%");

}

public void run() {

}

// calculate the wait time between call events

float getWaitTime(float lambda) {

float waitTime = (float)(-Math.log(numberGenerator.nextFloat())/lambda );

return waitTime;

}

// convert intergers to characters



return ""+c;

}

public void paint(Graphics g) {


g.setFont(roman);

// draw the links

if (newLink){

g.drawLine(node[currentNode1].x, node[currentNode1].y, currentPoint.x,

currentPoint.y);

}



if (capacity[i][j] > 0){

drawLink(g, i, j);

}

}

}


// draw the nodes


if (node[i].x >0){

g.fillOval(node[i].x-NODERADIUS, node[i].y-NODERADIUS, NODESIZE, NODESIZE);

}

}

g.setFont(new Font("TimesRoman", Font.BOLD, 12));

// draw the node labels


if (node[i].x >0){


g.drawString(intToString(i), node[i].x-3, node[i].y-14);

}

}

}

}

/**

* class for displaying the settings window.

*/

class SettingsFrame extends JFrame{

// Default values for settings

final int MAXNODES = Globals.maximumNodes;

107

final int TRUNK_PARAMETER = Globals.trunkParameter;

final int LINK_CAPACITY = Globals.linkCapacity;

final int RUN_DURATION = Globals.runDuration;

final int AVG_CALLS = Globals.avgNumCalls;

final int AVG_CALL_LENGTH = Globals.avgCallLength;

final boolean SOUND = Globals.sound;

final int SYMMETRIC = Globals.symmetry;

final int COMPLETE_NETWORK = Globals.completeNetwork;

final int NETWORK_SIZE = Globals.networkSize;

// textboxes for user input

JTextField txtMaxNodes = new JTextField();

JTextField txtTrunk = new JTextField();

JTextField txtLinkCapacity = new JTextField();

JTextField txtRunDuration = new JTextField();

JTextField txtAvgNumCalls = new JTextField();

JTextField txtAvgCallLength = new JTextField();

JCheckBox chkSound = new JCheckBox();

// radio buttons for example network

JRadioButton symmetric = new JRadioButton();

JRadioButton nonSymmetric = new JRadioButton();

JRadioButton complete = new JRadioButton();

JRadioButton nonComplete = new JRadioButton();

JRadioButton small = new JRadioButton();

JRadioButton large = new JRadioButton();

// settings buttons

Button btnDefault = new Button("Default");

Button btnOK = new Button("OK");

Button btnCancel = new Button("Cancel");

String errMessage = "";

SettingsFrame(){

createSettingsPanel();

pack();

}

public void createSettingsPanel(){

JPanel setPanel = createSettingParametersPanel();

JPanel btnPanel = createButtonPanel();

JPanel settingsPanel = new JPanel();

settingsPanel.setLayout(new GridLayout(1,1));

settingsPanel.setBorder(BorderFactory.createTitledBorder("Settings"));

settingsPanel.add(setPanel);

JPanel fPanel = createExamplePanel();

getContentPane().add(settingsPanel, BorderLayout.NORTH);

getContentPane().add(btnPanel, BorderLayout.SOUTH);

getContentPane().add(fPanel, BorderLayout.CENTER);

}

// settings for the network parameters

public JPanel createSettingParametersPanel(){



JLabel lblMaxNodes = new JLabel("Maximum Number of Nodes: ");

panel.add(lblMaxNodes);

txtMaxNodes.setText(Integer.toString(MAXNODES));

panel.add(txtMaxNodes);

JLabel lblLinkCapacity = new JLabel("Default Link Capacity Value: ");

panel.add(lblLinkCapacity);

108

txtLinkCapacity.setText(Integer.toString(LINK_CAPACITY));

panel.add(txtLinkCapacity);

JLabel lblTrunk = new JLabel("Default Link Trunk Reservation Parameter: ");

panel.add(lblTrunk);

txtTrunk.setText(Integer.toString(TRUNK_PARAMETER));

panel.add(txtTrunk);

JLabel lblRunDuration = new JLabel("Simulator Run Duration (mins): ");

panel.add(lblRunDuration);

txtRunDuration.setText(Integer.toString(RUN_DURATION));

panel.add(txtRunDuration);

JLabel lbltxtAvgNumCalls = new JLabel("Default Link Avg. Number of Calls per min: ");

panel.add(lbltxtAvgNumCalls);

txtAvgNumCalls.setText(Integer.toString(AVG_CALLS));

panel.add(txtAvgNumCalls);

JLabel lblAvgCallLength = new JLabel("Default Link Avg. Length of a Call (mins):");

panel.add(lblAvgCallLength);

txtAvgCallLength.setText(Integer.toString(AVG_CALL_LENGTH));

panel.add(txtAvgCallLength);

JLabel lblSound = new JLabel("Sound:");

panel.add(lblSound);

chkSound.setSelected(Globals.sound);

panel.add(chkSound);

return panel;

}

// settings for the example network

public JPanel createExamplePanel(){


panel.setBorder(BorderFactory.createTitledBorder("Example Settings"));


symmetric.setText("Symmetric");

nonSymmetric.setText("Non-Symmetric");


symmetric.setSelected(true);

}

else{

nonSymmetric.setSelected(true);

}

complete.setText("Complete");

nonComplete.setText("Non-Complete");


complete.setSelected(true);

}

else{

nonComplete.setSelected(true);

}

small.setText("Small Network");

large.setText("Large Network");


small.setSelected(true);

}

else{

109

large.setSelected(true);

}

ButtonGroup group = new ButtonGroup();

group.add(symmetric);

group.add(nonSymmetric);

ButtonGroup group2 = new ButtonGroup();

group2.add(complete);

group2.add(nonComplete);

ButtonGroup group3 = new ButtonGroup();

group3.add(small);

group3.add(large);

panel.add(symmetric);

panel.add(nonSymmetric);

panel.add(complete);

panel.add(nonComplete);

panel.add(small);

panel.add(large);

return panel;

}

public JPanel createButtonPanel(){


panel.setLayout(new GridLayout(1,3, 10, 10));

panel.add(btnDefault);

panel.add(btnOK);

panel.add(btnCancel);

return panel;

}



if (((String)arg).equals("OK")){

if (validateSettings()){

Globals.maximumNodes = Integer.parseInt(txtMaxNodes.getText());

Globals.trunkParameter = Integer.parseInt(txtTrunk.getText());

Globals.linkCapacity = Integer.parseInt(txtLinkCapacity.getText());

Globals.runDuration = Integer.parseInt(txtRunDuration.getText());

Globals.avgNumCalls = Integer.parseInt(txtAvgNumCalls.getText());

Globals.avgCallLength = Integer.parseInt(txtAvgCallLength.getText());

Globals.sound = chkSound.isSelected();

if (symmetric.isSelected()){

Globals.symmetry = 0;

}

else if(nonSymmetric.isSelected()){

Globals.symmetry = 1;

}

if (complete.isSelected()){

Globals.completeNetwork = 0;

}

else if (nonComplete.isSelected()){

Globals.completeNetwork = 1;

}

if (small.isSelected()){

Globals.networkSize = 0;

}

else if (large.isSelected()){

Globals.networkSize = 1;

110

}

setVisible(false);

}

else{

JOptionPane.showMessageDialog(this, errMessage ,"Invalid Data",

JOptionPane.WARNING_MESSAGE);

}

}

if (((String)arg).equals("Cancel")){

txtMaxNodes.setText(Integer.toString(Globals.maximumNodes));

txtTrunk.setText(Integer.toString(Globals.trunkParameter));

txtLinkCapacity.setText(Integer.toString(Globals.linkCapacity));

txtRunDuration.setText(Integer.toString(Globals.runDuration));

txtAvgNumCalls.setText(Integer.toString(Globals.avgNumCalls));

chkSound.setSelected(Globals.sound);



}

else{

nonSymmetric.setSelected(true);

}



}

else{

nonComplete.setSelected(true);

}

if (Globals.networkSize == 0){


}

else{

large.setSelected(true);

}

setVisible(false);

}

if (((String)arg).equals("Default")){

int result = JOptionPane.showConfirmDialog(this, "Are you sure you

want to change the settings back to the default values?",

"Set to Default",JOptionPane.YES_NO_OPTION);

if (result == 0){

txtMaxNodes.setText(Integer.toString(MAXNODES));

txtTrunk.setText(Integer.toString(TRUNK_PARAMETER));

txtLinkCapacity.setText(Integer.toString(LINK_CAPACITY));

txtRunDuration.setText(Integer.toString(RUN_DURATION));

txtAvgNumCalls.setText(Integer.toString(AVG_CALLS));

chkSound.setSelected(SOUND);




Globals.maximumNodes = MAXNODES;

Globals.trunkParameter = TRUNK_PARAMETER;

Globals.linkCapacity = LINK_CAPACITY;

Globals.runDuration = RUN_DURATION;

Globals.avgNumCalls = AVG_CALLS;

Globals.sound = SOUND;

Globals.symmetry = SYMMETRIC;

Globals.completeNetwork = COMPLETE_NETWORK;

Globals.networkSize = NETWORK_SIZE;

}

}

}

return true;

}

111

// validation of user input

public boolean validateSettings(){

if (hasNumber(txtMaxNodes.getText()) == false){

errMessage = "The maximum node field must contain a number";

return false;

}

if (txtMaxNodes.getText().equals("")){

errMessage = "The maximum node field must not be empty";

return false;

}

if (Integer.parseInt(txtMaxNodes.getText()) > 50){

errMessage = "The maximum number of nodes must be less than 50";

return false;

}

if (Integer.parseInt(txtMaxNodes.getText()) < 2){

errMessage = "The maximum number of nodes must be greater than 2";

return false;

}

if (hasNumber(txtLinkCapacity.getText()) == false){

errMessage = "The Default Link Capacity Value must contain a number";

return false;

}

if (txtLinkCapacity.getText().equals("")){

errMessage = "The Default Link Capacity Value must not be empty";

return false;

}

if (hasNumber(txtTrunk.getText()) == false){

errMessage = "The trunk reservation parameter must contain a number";

return false;

}

if (txtTrunk.getText().equals("")){

errMessage = "The trunk reservation parameter must not be empty";

return false;

}

if (hasNumber(txtRunDuration.getText()) == false){

errMessage = "The run duration must contain a number";

return false;

}

if (txtRunDuration.getText().equals("")){

errMessage = "The run duration must not be empty";

return false;

}

if (hasNumber(txtAvgNumCalls.getText()) == false){

errMessage = "The average number of calls per minute must contain a number";

return false;

}

if (txtAvgNumCalls.getText().equals("")){

errMessage = "The average number of calls per minute must not be empty";

return false;

}

return true;

}

public boolean hasNumber(String s){

for (int j = 0;j < s.length();j++) {

if (!Character.isDigit(s.charAt(j))) {

return false;

112

}

}

return true;

}

}

/**

* class for the timer. Works out time remaining and time elapsed in the simulation.

*/

class TimerCount implements ActionListener{

private int countdownSecs;

private int seconds = 1;

ActionButtonPanel parent;

public TimerCount(int initialCount, ActionButtonPanel myParent){

countdownSecs = initialCount - 1;

parent = myParent;

}

public void actionPerformed(ActionEvent e) {

if (countdownSecs >= 0){

// display the timer details

parent.parent.topParent.bottomPanel.runInfoPanel.lblActualTimeElapsed.setText(seconds

+ " Secs");

parent.parent.topParent.bottomPanel.runInfoPanel.lblActualTimeRemaining.setText

(countdownSecs + " Secs");

}

else{


}

// set the timer counters

countdownSecs--;

seconds++;

}

}

113

Appendix B

Experimental Plan

Key: C=Capacity, CR=Call Rate, TP= Trunk Parameter,CL=Call Length, RD=Run Duration

Experiment 1

Exp. No. Procedure Completed?1 Create 2 nodes & 1 link. Set C=100, CR=100, CL=1, RD=2. Run 12 times.2 Create 2 nodes & 1 link. Set C=110, CR=100, CL=1, RD=2. Run 12 times.3 Create 2 nodes & 1 link. Set C=110, CR=110, CL=1, RD=2. Run 12 times.4 Create 2 nodes & 1 link. Set C=110, CR=120, CL=1, RD=2. Run 12 times.5 Create 2 nodes & 1 link. Set C=110, CR=130, CL=1, RD=2. Run 12 times.

Experiment 2

Exp. No. Procedure Completed?6 Create 3 nodes & connect all nodes completely.

Set TP=0, C=100, CR=130, CL=1, RD=2. Run 2 times.7 Create 3 nodes & connect all nodes completely.







Set TP=20, C=100, CR=130, CL=1, RD=2. Run 2 times.

114




































115
































116

Experiment 3

Exp. No. Procedure Completed?78 Set Example Network to Complete, Symmetric, Small.

Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = None. Run 4 times.

79 Set Example Network to Complete, Symmetric, Small.Set TP=0, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

80 Set Example Network to Complete, Symmetric, Small.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

81 Set Example Network to Complete, Symmetric, Small.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 4 times.

82 Set Example Network to Non-Complete, Symmetric, Small.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = None. Run 4 times.

83 Set Example Network to Non-Complete, Symmetric, Small.Set TP=0, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

84 Set Example Network to Non-Complete, Symmetric, Small.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

85 Set Example Network to Non-Complete, Symmetric, Small.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 4 times.

86 Set Example Network to Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.

87 Set Example Network to Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 2 times.

88 Set Example Network to Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.







95 Set Example Network to Non-Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.

96 Set Example Network to Non-Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 2 times.

97 Set Example Network to Non-Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.

117

Exp. No. Procedure Completed?98 Set Example Network to Non-Complete, Asymmetric, Small.

Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.



101 Set Example Network to Non-Complete, Asymmetric, Small.Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.



Experiment 4

Exp. No. Procedure Completed?104 Set Example Network to Complete, Symmetric, Large.

Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = None. Run 4 times.

105 Set Example Network to Complete, Symmetric, Large.Set TP=0, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

106 Set Example Network to Complete, Symmetric, Large.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

107 Set Example Network to Complete, Symmetric, Large.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 4 times.

108 Set Example Network to Non-Complete, Symmetric, Large.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = None. Run 4 times.

109 Set Example Network to Non-Complete, Symmetric, Large.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 4 times.

110 Set Example Network to Non-Complete, Symmetric, Large.Set TP=5, C=100, CR=110, CL=1, RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 4 times.

111 Set Example Network to Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.

112 Set Example Network to Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 2 times.

113 Set Example Network to Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.



116 Set Example Network to Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.



118

Exp. No. Procedure Completed?119 Set Example Network to Complete, Asymmetric, Large.

Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.

120 Set Example Network to Non-Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = None. Run 2 times.

121 Set Example Network to Non-Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = Trunk Reservation. Run 2 times.

122 Set Example Network to Non-Complete, Asymmetric, Large.Set RD=2. Create Example Network.Set Algorithm = Sticky Routing. Run 2 times.







119

Appendix C

Results

C.1 Experiment 1

Capacity = 100, Call Rate = 100

Run No. Calls Started Calls Lost % of Calls Lost1 216 0 02 206 0 03 224 7 3.124 186 0 05 208 0 06 199 0 07 238 9 3.788 177 0 09 220 4 1.8210 206 0 011 214 0 012 195 0 0


Run No. Calls Started Calls Lost % of Calls Lost1 184 0 02 189 0 03 225 0 04 198 0 05 189 0 06 198 0 07 177 0 08 190 0 09 210 0 010 206 0 011 195 0 012 192 0 0


Run No. Calls Started Calls Lost % of Calls Lost1 217 0 02 208 0 03 204 0 04 206 4 1.945 208 0 06 189 0 07 242 5 2.078 213 4 1.889 203 0 010 221 0 011 206 0 012 248 21 8.47


120

Run No. Calls Started Calls Lost % of Calls Lost1 273 25 9.162 214 0 03 240 3 1.254 241 7 2.905 230 0 06 201 0 07 252 24 9.528 224 0 09 217 8 3.6910 232 17 7.3311 259 9 3.4712 236 0 0


Run No. Calls Started Calls Lost % of Calls Lost1 243 14 5.762 245 3 1.223 244 0 04 227 2 0.885 268 45 16.796 256 17 6.647 267 26 9.748 262 32 12.219 256 15 5.8610 269 21 7.8111 285 30 10.5312 246 0 0

C.2 Experiment 2

Call Rate = 130, Nodes = 3

Trunk Parameter = 0, Run No. = 1

Total Network Data:

Calls Started Calls Connected Calls Lost % of Calls Lost1573 1338 235 14.93

Link Data:

Node Node Capacity Call Calls Direct Indirect Calls % offrom to Length Started Calls Calls Lost Calls LostA B 100 1 251 205 7 39 15.60A C 100 1 259 211 7 41 15.89B A 100 1 255 206 9 40 15.75B C 100 1 284 214 10 60 21.20C A 100 1 259 216 13 30 11.63C B 100 1 265 219 21 25 9.47


Total Network Data:


Link Data:


121


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


122


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:

Node Node Capacity Call Calls Direct Indirect Calls % offrom to Length Started Calls Calls Lost Calls LostA B 100 1 231 218 0 13 5.63A C 100 1 242 217 0 25 10.33B A 100 1 263 251 0 12 4.56B C 100 1 266 233 5 28 10.53C A 100 1 268 238 5 25 9.33C B 100 1 250 249 1 0 0


Total Network Data:


Link Data:

Node Node Capacity Call Calls Direct Indirect Calls % offrom to Length Started Calls Calls Lost Calls LostA B 100 1 269 243 0 26 9.70A C 100 1 265 242 0 23 8.71B A 100 1 273 259 2 12 4.41B C 100 1 274 238 0 36 13.19C A 100 1 246 246 0 0 0C B 100 1 247 240 0 7 2.85

123


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:

Node Node Capacity Call Calls Direct Indirect Calls % offrom to Length Started Calls Calls Lost Calls LostA B 100 1 236 205 0 31 13.14A C 100 1 266 246 4 16 6.02B A 100 1 230 230 0 0 0B C 100 1 232 228 0 4 1.72C A 100 1 260 226 0 34 13.08C B 100 1 266 234 3 29 10.90

124


Total Network Data:


Link Data:



Total Network Data:


Link Data:




Total Network Data:


Link Data:

Node Node Capacity Call Calls Direct Indirect Calls % offrom to Length Started Calls Calls Lost Calls Lost

A B 100 1 264 227 10 27 10.23A C 100 1 263 230 14 19 7.22A D 100 1 248 225 6 17 6.85B A 100 1 277 224 22 31 11.19B C 100 1 239 204 7 28 11.72B D 100 1 260 213 16 31 11.92C A 100 1 263 212 13 38 14.45C B 100 1 246 209 9 28 11.38C D 100 1 277 227 13 37 13.36D A 100 1 283 210 23 50 17.67D B 100 1 266 219 24 23 8.65D C 100 1 231 195 9 27 11.69


Total Network Data:


Link Data:

125




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

126




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

127




Total Network Data:


Link Data:


A B 100 1 231 245 0 0 0A C 100 1 254 206 2 24 9.45A D 100 1 297 231 9 19 6.40B A 100 1 255 230 1 26 10.20B C 100 1 257 240 0 32 12.45B D 100 1 259 226 1 15 5.79C A 100 1 274 209 2 25 9.12C B 100 1 244 224 0 19 7.79C D 100 1 274 214 0 31 11.31D A 100 1 268 222 1 44 16.42D B 100 1 246 238 0 19 7.72D C 100 1 265 245 8 11 4.15


Total Network Data:


Link Data:




Total Network Data:


Link Data:

128




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

129




Total Network Data:


Link Data:




Total Network Data:


Link Data:





Total Network Data:


Link Data:

130


A B 100 1 242 210 11 21 8.68A C 100 1 264 224 9 31 11.74A D 100 1 259 226 9 24 9.27A E 100 1 244 214 9 21 8.61B A 100 1 269 225 15 29 10.78B C 100 1 255 219 6 30 11.76B D 100 1 263 221 11 31 11.79B E 100 1 268 217 12 39 14.55C A 100 1 246 196 13 37 15.04C B 100 1 276 226 18 32 11.59C D 100 1 248 208 13 27 10.89C E 100 1 288 227 21 40 13.89D A 100 1 264 214 14 36 13.64D B 100 1 255 224 6 25 9.80D C 100 1 277 218 21 38 13.72D E 100 1 225 193 8 24 10.67E A 100 1 260 221 9 30 11.54E B 100 1 229 213 6 30 12.05E C 100 1 252 200 10 42 16.67E D 100 1 259 216 18 25 9.65


Total Network Data:


Link Data:




Total Network Data:


Link Data:

131


A B 100 1 272 257 4 11 4.04A C 100 1 266 244 5 17 6.39A D 100 1 220 220 0 0 0A E 100 1 268 241 7 20 7.46B A 100 1 294 239 7 48 16.33B C 100 1 281 229 22 30 10.68B D 100 1 274 235 1 38 13.87B E 100 1 256 227 1 28 10.94C A 100 1 278 232 7 39 14.03C B 100 1 259 222 8 29 11.20C D 100 1 257 219 4 34 13.23C E 100 1 267 220 7 40 14.98D A 100 1 262 223 7 32 12.21D B 100 1 246 230 4 12 4.88D C 100 1 281 236 7 38 13.52D E 100 1 233 213 0 20 8.58E A 100 1 276 218 12 46 16.67E B 100 1 252 227 7 18 7.14E C 100 1 249 211 8 30 12.05E D 100 1 230 220 3 7 3.04


Total Network Data:


Link Data:




Total Network Data:


Link Data:

132




Total Network Data:


Link Data:




Total Network Data:


Link Data:

133




Total Network Data:


Link Data:




Total Network Data:


Link Data:

134




Total Network Data:


Link Data:




Total Network Data:


Link Data:

135


A B 100 1 243 232 0 11 4.53A C 100 1 223 223 0 0 0A D 100 1 287 260 0 27 9.41A E 100 1 266 252 1 13 4.89B A 100 1 287 273 1 13 4.53B C 100 1 269 239 1 29 10.78B D 100 1 276 236 0 40 14.49B E 100 1 238 223 0 14 6.30C A 100 1 272 233 1 38 13.97C B 100 1 250 223 0 27 10.80C D 100 1 274 227 1 46 16.79C E 100 1 286 256 5 25 8.74D A 100 1 245 220 0 25 10.20D B 100 1 244 237 1 6 2.46D C 100 1 268 229 11 18 6.72D E 100 1 266 233 8 25 9.40E A 100 1 278 239 0 39 14.03E B 100 1 262 249 0 13 4.96E C 100 1 222 209 1 12 5.41E D 100 1 277 259 0 18 6.50


Total Network Data:


Link Data:




Total Network Data:


Link Data:

136




Total Network Data:


Link Data:


A B 100 1 284 249 6 29 10.21A C 100 1 265 247 1 17 6.42A D 100 1 243 218 0 25 10.29A E 100 1 275 246 2 27 9.82B A 100 1 259 228 3 28 10.81B C 100 1 238 229 0 9 3.78B D 100 1 277 239 0 38 13.72B E 100 1 272 260 0 3 1.10C A 100 1 232 228 0 4 1.72C B 100 1 237 237 6 0 0C D 100 1 258 245 0 13 5.04C E 100 1 277 261 1 15 5.42D A 100 1 263 218 1 44 16.73D B 100 1 257 229 0 28 10.89D C 100 1 251 227 0 24 9.56D E 100 1 267 225 1 41 15.36E A 100 1 258 246 0 12 4.65E B 100 1 249 233 0 16 6.43E C 100 1 263 235 1 27 10.27E D 100 1 278 258 0 20 7.19


Total Network Data:


Link Data:

137


A B 100 1 259 234 0 25 9.65A C 100 1 266 247 0 19 7.14A D 100 1 297 268 3 26 8.75A E 100 1 246 240 0 6 2.44B A 100 1 272 256 0 16 5.88B C 100 1 241 210 0 31 12.86B D 100 1 263 239 0 24 9.13B E 100 1 256 224 0 32 12.50C A 100 1 234 234 0 0 0C B 100 1 287 224 0 63 21.95C D 100 1 262 246 0 16 6.11C E 100 1 264 237 0 27 10.23D A 100 1 289 234 0 55 19.03D B 100 1 240 223 0 17 7.08D C 100 1 259 242 0 17 6.56D E 100 1 292 241 0 51 17.47E A 100 1 281 234 0 47 16.73E B 100 1 287 257 0 30 10.45E C 100 1 258 236 0 22 8.53E D 100 1 260 242 0 18 6.92


Total Network Data:


Link Data:


A B 100 1 243 235 0 8 3.29A C 100 1 254 239 0 15 5.91A D 100 1 283 239 0 44 15.55A E 100 1 248 237 0 11 4.44B A 100 1 239 237 0 2 0.84B C 100 1 264 252 0 12 4.55B D 100 1 215 215 0 0 0B E 100 1 265 241 0 24 9.06C A 100 1 255 228 0 27 10.59C B 100 1 272 242 6 30 11.03C D 100 1 249 244 0 5 2.01C E 100 1 278 235 0 43 15.47D A 100 1 266 235 0 31 11.65D B 100 1 250 231 0 19 7.60D C 100 1 292 258 0 34 11.64D E 100 1 269 239 0 30 11.15E A 100 1 261 240 0 21 8.05E B 100 1 267 239 0 28 10.49E C 100 1 253 235 0 18 7.11E D 100 1 290 250 0 40 13.79



Total Network Data:


Link Data:


138


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


139


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


140


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


141


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:




Total Network Data:


Link Data:



142


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:



143


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:



144


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:



145


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:



146


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:



147



Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


148

Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

149




Total Network Data:


Link Data:




Total Network Data:


Link Data:

150




Total Network Data:


Link Data:




Total Network Data:


Link Data:

151




Total Network Data:


Link Data:




Total Network Data:


Link Data:

152




Total Network Data:


Link Data:




Total Network Data:


Link Data:

153




Total Network Data:


Link Data:




Total Network Data:


Link Data:

154




Total Network Data:


Link Data:





Total Network Data:


Link Data:


155


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


156


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


157


Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:



Total Network Data:


Link Data:


158


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:

159


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:

160


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:

161


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:

162


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:

163


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:





Total Network Data:

164


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

165




Total Network Data:


Link Data:




Total Network Data:


Link Data:

166




Total Network Data:


Link Data:




Total Network Data:


Link Data:

167




Total Network Data:


Link Data:




Total Network Data:


Link Data:

168




Total Network Data:


Link Data:




Total Network Data:


Link Data:

169




Total Network Data:


Link Data:




Total Network Data:


Link Data:

170




Total Network Data:


Link Data:




Total Network Data:


Link Data:

171




Total Network Data:


Link Data:



C.3 Experiment 3

Key: TP = Trunk Parameter, CR = Call Rate, CL = Calls Lost, CS = Calls Started

Complete & Symmetric Network

Algorithm = None:

Run No. = 1:

Total Network Data:


Link Data:

172

Node Node Cap’ty TP CR CL CS Direct Indirect Calls % offrom to Calls Calls Lost Calls Lost

A B 100 5 110 1 213 213 0 0 0A C 100 5 110 1 216 216 0 0 0A D 100 5 110 1 211 211 0 0 0A E 100 5 110 1 235 227 0 8 3.42B A 100 5 110 1 198 198 0 0 0B C 100 5 110 1 225 225 0 0 0B D 100 5 110 1 208 208 0 0 0B E 100 5 110 1 220 211 0 9 4.11C A 100 5 110 1 245 230 0 15 6.15C B 100 5 110 1 210 210 0 0 0C D 100 5 110 1 204 204 0 0 0C E 100 5 110 1 223 223 0 0 0D A 100 5 110 1 244 223 0 21 8.64D B 100 5 110 1 252 242 0 10 3.98D C 100 5 110 1 207 205 0 2 0.97D E 100 5 110 1 226 226 0 0 0E A 100 5 110 1 208 208 0 0 0E B 100 5 110 1 229 220 0 9 3.95E C 100 5 110 1 228 222 0 6 2.64E D 100 5 110 1 222 222 0 0 0

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 221 217 0 4 1.82A C 100 5 110 1 226 226 0 0 0A D 100 5 110 1 189 189 0 0 0A E 100 5 110 1 213 213 0 0 0B A 100 5 110 1 216 215 0 1 0.47B C 100 5 110 1 226 226 0 0 0B D 100 5 110 1 217 215 0 2 0.93B E 100 5 110 1 240 229 0 11 4.60C A 100 5 110 1 230 230 0 0 0C B 100 5 110 1 200 200 0 0 0C D 100 5 110 1 220 220 0 0 0C E 100 5 110 1 206 201 0 5 2.44D A 100 5 110 1 237 227 0 10 4.24D B 100 5 110 1 226 226 0 20 8.16D C 100 5 110 1 230 230 0 12 4.98D E 100 5 110 1 218 218 0 0 0E A 100 5 110 1 235 235 0 0 0E B 100 5 110 1 220 219 0 1 0.46E C 100 5 110 1 242 234 0 8 3.32E D 100 5 110 1 229 226 0 3 1.32

Run No. = 3:

Total Network Data:


Link Data:

173


A B 100 5 110 1 223 223 0 0 0A C 100 5 110 1 209 209 0 0 0A D 100 5 110 1 247 225 0 22 8.94A E 100 5 110 1 229 229 0 0 0B A 100 5 110 1 216 216 0 0 0B C 100 5 110 1 212 212 0 0 0B D 100 5 110 1 223 223 0 0 0B E 100 5 110 1 223 223 0 0 0C A 100 5 110 1 255 231 0 24 9.45C B 100 5 110 1 215 215 0 0 0C D 100 5 110 1 223 213 0 10 4.50C E 100 5 110 1 206 206 0 0 0D A 100 5 110 1 206 206 0 0 0D B 100 5 110 1 224 220 0 4 1.79D C 100 5 110 1 242 233 0 9 3.73D E 100 5 110 1 214 212 0 2 0.94E A 100 5 110 1 237 234 0 3 1.27E B 100 5 110 1 223 223 0 0 0E C 100 5 110 1 241 238 0 3 1.25E D 100 5 110 1 221 219 0 2 0.91

Run No. = 4:

Total Network Data:


Link Data:


A B 100 5 110 1 230 220 0 10 4.37A C 100 5 110 1 218 218 0 0 0A D 100 5 110 1 224 224 0 0 0A E 100 5 110 1 223 220 0 3 1.35B A 100 5 110 1 230 230 0 0 0B C 100 5 110 1 202 202 0 0 0B D 100 5 110 1 184 184 0 0 0B E 100 5 110 1 221 221 0 0 0C A 100 5 110 1 223 223 0 0 0C B 100 5 110 1 235 235 0 0 0C D 100 5 110 1 234 218 0 16 6.87C E 100 5 110 1 212 212 0 0 0D A 100 5 110 1 229 229 0 0 0D B 100 5 110 1 223 223 0 0 0D C 100 5 110 1 239 221 0 18 7.56D E 100 5 110 1 211 211 0 0 0E A 100 5 110 1 213 213 0 0 0E B 100 5 110 1 229 212 0 17 7.46E C 100 5 110 1 230 220 0 10 4.37E D 100 5 110 1 216 214 0 2 0.93

Algorithm = Trunk Reservation (Parameter=0):

Run No. = 1:

Total Network Data:


Link Data:

174


A B 100 0 110 1 239 227 5 7 2.93A C 100 0 110 1 241 227 6 8 3.32A D 100 0 110 1 206 204 0 2 0.97A E 100 0 110 1 211 199 6 6 2.84B A 100 0 110 1 108 208 0 0 0B C 100 0 110 1 193 189 2 2 1.04B D 100 0 110 1 206 206 0 0 0B E 100 0 110 1 237 223 14 0 0C A 100 0 110 1 220 209 11 0 0C B 100 0 110 1 222 218 2 2 0.90C D 100 0 110 1 212 212 0 0 0C E 100 0 110 1 216 208 6 2 0.93D A 100 0 110 1 204 198 1 5 2.45D B 100 0 110 1 218 195 16 7 3.21D C 100 0 110 1 229 203 15 11 4.80D E 100 0 110 1 209 207 0 2 0.96E A 100 0 110 1 214 206 6 2 0.93E B 100 0 110 1 226 223 1 2 0.88E C 100 0 110 1 216 203 3 10 4.63E D 100 0 110 1 228 222 6 0 0

Run No. = 2:

Total Network Data:


Link Data:


A B 100 0 110 1 231 215 4 12 5.22A C 100 0 110 1 228 219 4 5 2.20A D 100 0 110 1 224 203 11 10 4.48A E 100 0 110 1 254 239 10 5 1.98B A 100 0 110 1 197 194 1 2 1.02B C 100 0 110 1 213 197 11 5 2.36B D 100 0 110 1 209 204 1 4 1.92B E 100 0 110 1 229 220 5 4 1.75C A 100 0 110 1 209 209 0 0 0C B 100 0 110 1 218 205 5 8 3.69C D 100 0 110 1 229 220 9 0 0C E 100 0 110 1 202 202 0 0 0D A 100 0 110 1 247 244 3 0 0D B 100 0 110 1 205 205 0 0 0D C 100 0 110 1 200 200 0 0 0D E 100 0 110 1 220 219 0 1 0.46E A 100 0 110 1 219 213 5 1 0.46E B 100 0 110 1 231 217 8 6 2.61E C 100 0 110 1 222 214 5 3 1.36E D 100 0 110 1 222 214 6 2 0.90

Run No. = 3:

Total Network Data:


Link Data:

175


A B 100 0 110 1 236 222 13 1 0.43A C 100 0 110 1 209 209 0 0 0A D 100 0 110 1 211 210 1 0 0A E 100 0 110 1 217 216 0 1 0.46B A 100 0 110 1 229 203 17 9 3.95B C 100 0 110 1 213 212 0 1 0.47B D 100 0 110 1 208 208 0 0 0B E 100 0 110 1 238 238 0 0 0C A 100 0 110 1 219 213 2 4 1.83C B 100 0 110 1 206 206 0 0 0C D 100 0 110 1 217 217 0 0 0C E 100 0 110 1 224 221 2 1 0.45D A 100 0 110 1 225 216 5 4 1.79D B 100 0 110 1 230 226 0 4 1.75D C 100 0 110 1 208 201 3 4 1.93D E 100 0 110 1 243 235 3 5 2.07E A 100 0 110 1 212 206 1 5 2.36E B 100 0 110 1 210 210 0 0 0E C 100 0 110 1 207 205 2 0 0E D 100 0 110 1 218 218 0 0 0

Run No. = 4:

Total Network Data:


Link Data:


A B 100 0 110 1 228 220 7 1 0.44A C 100 0 110 1 233 232 1 0 0A D 100 0 110 1 199 199 0 0 0A E 100 0 110 1 226 226 0 0 0B A 100 0 110 1 223 198 13 12 5.41B C 100 0 110 1 209 197 7 5 2.40B D 100 0 110 1 252 226 19 7 2.79B E 100 0 110 1 213 205 4 4 1.89C A 100 0 110 1 246 217 26 3 1.22C B 100 0 110 1 202 202 0 0 0C D 100 0 110 1 253 238 12 3 1.19C E 100 0 110 1 187 187 0 0 0D A 100 0 110 1 198 187 9 2 1.02D B 100 0 110 1 240 235 5 0 0D C 100 0 110 1 194 194 0 0 0D E 100 0 110 1 230 230 0 0 0E A 100 0 110 1 256 241 13 2 0.78E B 100 0 110 1 236 234 0 2 0.85E C 100 0 110 1 202 199 2 1 0.50E D 100 0 110 1 226 220 1 5 2.21


Run No. = 1:

Total Network Data:


Link Data:

176


A B 100 5 110 1 207 207 0 0 0A C 100 5 110 1 224 223 0 1 0.45A D 100 5 110 1 221 213 2 6 2.73A E 100 5 110 1 240 231 5 4 1.67B A 100 5 110 1 185 185 0 0 0B C 100 5 110 1 256 241 8 7 2.75B D 100 5 110 1 214 212 0 2 0.94B E 100 5 110 1 214 214 0 0 0C A 100 5 110 1 214 214 0 0 0C B 100 5 110 1 202 200 0 2 1C D 100 5 110 1 223 220 2 1 0.45C E 100 5 110 1 213 213 0 0 0D A 100 5 110 1 232 131 0 1 0.43D B 100 5 110 1 234 131 0 3 1.29D C 100 5 110 1 233 231 0 2 0.86D E 100 5 110 1 235 222 1 12 5.13E A 100 5 110 1 231 225 6 0 0E B 100 5 110 1 213 213 0 0 0E C 100 5 110 1 214 214 0 0 0E D 100 5 110 1 217 217 0 0 0

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 201 201 0 0 0A C 100 5 110 1 218 218 0 0 0A D 100 5 110 1 236 214 8 14 5.96A E 100 5 110 1 210 210 0 0 0B A 100 5 110 1 125 215 2 8 3.57B C 100 5 110 1 218 218 0 0 0B D 100 5 110 1 241 219 7 15 6.25B E 100 5 110 1 226 220 4 2 0.89C A 100 5 110 1 221 217 0 4 1.82C B 100 5 110 1 232 232 0 0 0C D 100 5 110 1 214 212 0 2 0.94C E 100 5 110 1 230 223 2 5 2.18D A 100 5 110 1 227 126 0 1 0.44D B 100 5 110 1 224 224 0 0 0D C 100 5 110 1 246 237 2 7 2.86D E 100 5 110 1 214 214 0 0 0E A 100 5 110 1 209 209 0 0 0E B 100 5 110 1 190 190 0 0 0E C 100 5 110 1 218 218 0 0 0E D 100 5 110 1 213 213 0 0 0

Run No. = 3:

Total Network Data:


Link Data:

177


A B 100 5 110 1 219 213 0 6 2.75A C 100 5 110 1 234 227 4 3 1.29A D 100 5 110 1 207 207 0 0 0A E 100 5 110 1 259 249 3 7 2.71B A 100 5 110 1 208 199 2 7 3.38B C 100 5 110 1 243 236 3 4 1.65B D 100 5 110 1 213 213 0 0 0B E 100 5 110 1 223 218 2 3 1.35C A 100 5 110 1 257 245 6 6 2.34C B 100 5 110 1 219 219 0 0 0C D 100 5 110 1 220 210 8 2 0.91C E 100 5 110 1 191 191 0 0 0D A 100 5 110 1 197 189 0 8 4.08D B 100 5 110 1 230 217 5 8 3.49D C 100 5 110 1 218 215 0 3 1.38D E 100 5 110 1 244 244 0 0 0E A 100 5 110 1 196 196 0 0 0E B 100 5 110 1 240 234 3 3 1.26E C 100 5 110 1 229 226 1 2 0.87E D 100 5 110 1 225 225 0 0 0

Run No. = 4:

Total Network Data:


Link Data:


A B 100 5 110 1 226 224 0 2 0.89A C 100 5 110 1 213 213 0 0 0A D 100 5 110 1 202 202 0 0 0A E 100 5 110 1 239 235 2 2 0.84B A 100 5 110 1 116 216 0 0 0B C 100 5 110 1 216 212 0 4 1.86B D 100 5 110 1 233 230 2 1 0.43B E 100 5 110 1 248 224 7 17 6.88C A 100 5 110 1 250 236 5 9 3.61C B 100 5 110 1 214 214 0 0 0C D 100 5 110 1 214 210 1 3 1.41C E 100 5 110 1 210 210 0 0 0D A 100 5 110 1 225 223 0 2 0.89D B 100 5 110 1 207 207 0 0 0D C 100 5 110 1 245 225 9 11 4.51D E 100 5 110 1 233 223 1 9 3.88E A 100 5 110 1 223 219 3 1 0.45E B 100 5 110 1 216 216 0 0 0E C 100 5 110 1 243 241 0 2 0.83E D 100 5 110 1 218 216 1 1 0.46

Algorithm = Stick Random Routing :

Run No. = 1:

Total Network Data:


Link Data:

178


A B 100 5 110 1 218 215 2 1 0.46A C 100 5 110 1 207 207 0 0 0A D 100 5 110 1 222 221 0 1 0.45A E 100 5 110 1 228 228 0 0 0B A 100 5 110 1 217 217 0 0 0B C 100 5 110 1 210 210 0 0 0B D 100 5 110 1 230 221 0 9 3.93B E 100 5 110 1 227 214 1 12 5.31C A 100 5 110 1 224 224 0 0 0C B 100 5 110 1 185 185 0 0 0C D 100 5 110 1 230 222 5 3 1.31C E 100 5 110 1 186 186 0 0 0D A 100 5 110 1 234 222 6 6 2.58D B 100 5 110 1 215 215 0 0 0D C 100 5 110 1 209 205 0 4 1.92D E 100 5 110 1 197 197 0 0 0E A 100 5 110 1 230 230 0 0 0E B 100 5 110 1 217 217 0 0 0E C 100 5 110 1 240 230 7 3 1.26E D 100 5 110 1 233 229 0 4 1.72

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 234 234 0 0 0A C 100 5 110 1 252 240 11 1 0.40A D 100 5 110 1 238 217 3 18 7.59A E 100 5 110 1 231 229 0 2 0.87B A 100 5 110 1 209 209 0 0 0B C 100 5 110 1 194 194 0 0 0B D 100 5 110 1 217 212 1 4 1.85B E 100 5 110 1 230 230 0 0 0C A 100 5 110 1 231 217 5 9 3.91C B 100 5 110 1 235 231 0 4 1.71C D 100 5 110 1 217 215 1 1 0.46C E 100 5 110 1 231 229 2 0 0D A 100 5 110 1 231 225 4 2 0.87D B 100 5 110 1 198 198 0 0 0D C 100 5 110 1 211 211 0 0 0D E 100 5 110 1 222 222 0 0 0E A 100 5 110 1 237 237 0 0 0E B 100 5 110 1 229 219 0 10 4.39E C 100 5 110 1 214 214 0 0 0E D 100 5 110 1 204 203 1 0 0

Run No. = 3:

Total Network Data:


Link Data:

179


A B 100 5 110 1 192 192 0 0 0A C 100 5 110 1 218 209 0 9 4.15A D 100 5 110 1 241 228 10 3 1.25A E 100 5 110 1 223 215 6 2 0.90B A 100 5 110 1 222 213 8 1 0.45B C 100 5 110 1 220 220 0 0 0B D 100 5 110 1 211 205 4 2 0.95B E 100 5 110 1 218 218 0 0 0C A 100 5 110 1 186 186 0 0 0C B 100 5 110 1 193 193 0 0 0C D 100 5 110 1 223 219 3 1 0.45C E 100 5 110 1 221 221 0 0 0D A 100 5 110 1 217 217 0 0 0D B 100 5 110 1 211 211 0 0 0D C 100 5 110 1 212 212 0 0 0D E 100 5 110 1 221 221 0 0 0E A 100 5 110 1 211 211 0 0 0E B 100 5 110 1 213 213 0 0 0E C 100 5 110 1 229 226 0 3 1.32E D 100 5 110 1 226 226 0 0 0

Run No. = 4:

Total Network Data:


Link Data:


A B 100 5 110 1 238 236 2 0 0A C 100 5 110 1 216 216 0 0 0A D 100 5 110 1 236 236 0 0 0A E 100 5 110 1 204 204 0 0 0B A 100 5 110 1 220 218 0 2 0.91B C 100 5 110 1 237 237 0 0 0B D 100 5 110 1 200 200 0 0 0B E 100 5 110 1 235 235 0 0 0C A 100 5 110 1 233 233 0 0 0C B 100 5 110 1 209 209 0 0 0C D 100 5 110 1 226 222 3 1 0.44C E 100 5 110 1 190 190 0 0 0D A 100 5 110 1 245 228 17 0 0D B 100 5 110 1 211 211 0 0 0D C 100 5 110 1 204 204 0 0 0D E 100 5 110 1 202 202 0 0 0E A 100 5 110 1 202 202 0 0 0E B 100 5 110 1 207 207 0 0 0E C 100 5 110 1 216 212 4 0 0E D 100 5 110 1 240 237 2 1 0.42

Non-Complete & Symmetric Network

Algorithm = None :

Run No. = 1:

Total Network Data:


Link Data:

180


A B 100 5 110 1 214 214 0 0 0A E 100 5 110 1 215 215 0 0 0B A 100 5 110 1 205 205 0 0 0B C 100 5 110 1 216 216 0 0 0B E 100 5 110 1 226 226 0 0 0C B 100 5 110 1 225 225 0 0 0C D 100 5 110 1 199 199 0 0 0C E 100 5 110 1 221 221 0 0 0D A 100 5 110 1 209 209 0 3 1.42D B 100 5 110 1 219 219 0 11 4.80D C 100 5 110 1 226 226 0 18 7.41D E 100 5 110 1 215 215 0 0 0E A 100 5 110 1 210 210 0 4 1.88E B 100 5 110 1 221 221 0 0 0E D 100 5 110 1 232 232 0 20 7.94

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 227 225 0 2 0.88A E 100 5 110 1 199 199 0 0 0B A 100 5 110 1 197 197 0 0 0B C 100 5 110 1 232 232 0 0 0B E 100 5 110 1 228 228 0 0 0C B 100 5 110 1 218 218 0 0 0C D 100 5 110 1 195 195 0 0 0C E 100 5 110 1 243 243 0 0 0D A 100 5 110 1 232 218 0 14 6.06D B 100 5 110 1 233 220 0 13 5.60D C 100 5 110 1 227 227 0 0 0D E 100 5 110 1 214 214 0 0 0E A 100 5 110 1 224 212 0 12 5.38E B 100 5 110 1 214 214 0 0 0E D 100 5 110 1 211 211 0 0 0

Run No. = 3:

Total Network Data:


Link Data:


A B 100 5 110 1 187 187 0 0 0A E 100 5 110 1 214 214 0 0 0B A 100 5 110 1 220 220 0 0 0B C 100 5 110 1 207 207 0 0 0B E 100 5 110 1 237 222 0 15 6.36C B 100 5 110 1 209 209 0 0 0C D 100 5 110 1 209 209 0 0 0C E 100 5 110 1 224 217 0 7 3.14D A 100 5 110 1 204 204 0 0 0D B 100 5 110 1 241 231 0 10 4.17D C 100 5 110 1 218 218 0 0 0D E 100 5 110 1 222 221 0 1 0.45E A 100 5 110 1 229 222 0 7 3.07E B 100 5 110 1 229 229 0 0 0E D 100 5 110 1 246 230 0 16 6.53

181

Run No. = 4:

Total Network Data:


Link Data:


A B 100 5 110 1 217 217 0 0 0A E 100 5 110 1 243 232 0 11 4.53B A 100 5 110 1 232 221 0 11 4.74B C 100 5 110 1 230 230 0 0 0B E 100 5 110 1 210 210 0 0 0C B 100 5 110 1 218 212 0 6 2.75C D 100 5 110 1 209 209 0 0 0C E 100 5 110 1 216 216 0 0 0D A 100 5 110 1 195 195 0 0 0D B 100 5 110 1 208 208 0 0 0D C 100 5 110 1 239 239 0 0 0D E 100 5 110 1 230 218 0 12 5.22E A 100 5 110 1 211 211 0 0 0E B 100 5 110 1 210 208 0 2 0.95E D 100 5 110 1 217 217 0 0 0

Algorithm = Trunk Reservation (Parameter=0) :

Run No. = 1:

Total Network Data:

Calls Started Calls Connected Calls Lost % of Calls Lost3234 3234 0 0

Link Data:


A B 100 0 110 1 212 205 7 0 0A E 100 0 110 1 214 212 2 0 0B A 100 0 110 1 221 218 3 0 0B C 100 0 110 1 215 215 0 0 0B E 100 0 110 1 210 210 0 0 0C B 100 0 110 1 215 211 4 0 0C D 100 0 110 1 219 215 4 0 0C E 100 0 110 1 192 192 0 0 0D A 100 0 110 1 237 237 0 0 0D B 100 0 110 1 189 189 0 0 0D C 100 0 110 1 234 228 6 0 0D E 100 0 110 1 210 210 0 0 0E A 100 0 110 1 214 214 0 0 0E B 100 0 110 1 242 242 0 0 0E D 100 0 110 1 210 210 0 0 0

Run No. = 2:

Total Network Data:


Link Data:

182


A B 100 0 110 1 237 216 11 10 4.24A E 100 0 110 1 218 209 5 4 1.84B A 100 0 110 1 228 225 3 0 0B C 100 0 110 1 200 200 0 0 0B E 100 0 110 1 223 222 1 0 0C B 100 0 110 1 217 210 5 2 0.93C D 100 0 110 1 213 213 0 0 0C E 100 0 110 1 223 223 0 0 0D A 100 0 110 1 223 214 6 3 1.35D B 100 0 110 1 208 194 9 5 2.42D C 100 0 110 1 205 205 0 0 0D E 100 0 110 1 218 218 0 0 0E A 100 0 110 1 230 229 1 0 0E B 100 0 110 1 232 212 10 10 4.33E D 100 0 110 1 203 203 0 0 0

Run No. = 3:

Total Network Data:


Link Data:


A B 100 0 110 1 217 217 0 0 0A E 100 0 110 1 213 213 0 0 0B A 100 0 110 1 225 225 0 0 0B C 100 0 110 1 204 204 0 0 0B E 100 0 110 1 217 215 2 0 0C B 100 0 110 1 236 224 9 3 1.27C D 100 0 110 1 200 200 0 0 0C E 100 0 110 1 210 202 3 5 2.38D A 100 0 110 1 239 223 5 11 4.60D B 100 0 110 1 233 210 12 11 4.72D C 100 0 110 1 226 217 5 4 1.77D E 100 0 110 1 236 218 10 8 3.39E A 100 0 110 1 224 224 0 0 0E B 100 0 110 1 199 199 0 0 0E D 100 0 110 1 220 219 0 1 0.45

Run No. = 4:

Total Network Data:


Link Data:


A B 100 0 110 1 242 242 0 0 0A E 100 0 110 1 213 210 3 0 0B A 100 0 110 1 192 192 0 0 0B C 100 0 110 1 216 216 0 0 0B E 100 0 110 1 227 223 4 0 0C B 100 0 110 1 209 209 0 0 0C D 100 0 110 1 211 211 0 0 0C E 100 0 110 1 206 206 0 0 0D A 100 0 110 1 232 211 12 9 3.90D B 100 0 110 1 206 198 7 1 0.49D C 100 0 110 1 212 212 0 0 0D E 100 0 110 1 247 235 11 1 0.41E A 100 0 110 1 219 214 5 0 0E B 100 0 110 1 208 208 0 0 0E D 100 0 110 1 215 215 0 0 0

183

Algorithm = Trunk Reservation (Parameter=5) :

Run No. = 1:

Total Network Data:


Link Data:


A B 100 5 110 1 202 202 0 0 0A E 100 5 110 1 210 210 0 0 0B A 100 5 110 1 214 214 0 0 0B C 100 5 110 1 225 219 0 6 2.68B E 100 5 110 1 212 212 0 0 0C B 100 5 110 1 225 225 0 0 0C D 100 5 110 1 209 209 0 0 0C E 100 5 110 1 209 209 0 0 0D A 100 5 110 1 231 218 5 8 3.48D B 100 5 110 1 177 177 0 0 0D C 100 5 110 1 211 211 0 0 0D E 100 5 110 1 223 216 6 1 0.45E A 100 5 110 1 230 230 0 0 0E B 100 5 110 1 218 218 0 0 0E D 100 5 110 1 219 215 0 4 1.83

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 227 227 0 0 0A E 100 5 110 1 217 217 0 0 0B A 100 5 110 1 219 219 0 0 0B C 100 5 110 1 240 229 0 11 4.58B E 100 5 110 1 232 229 1 2 0.86C B 100 5 110 1 220 220 0 0 0C D 100 5 110 1 237 237 0 0 0C E 100 5 110 1 215 212 2 1 0.47D A 100 5 110 1 235 234 1 0 0D B 100 5 110 1 192 192 0 0 0D C 100 5 110 1 220 220 0 0 0D E 100 5 110 1 202 202 0 0 0E A 100 5 110 1 237 221 16 0 0E B 100 5 110 1 214 213 1 0 0E D 100 5 110 1 210 210 0 0 0

Run No. = 3:

Total Network Data:


Link Data:

184


A B 100 5 110 1 216 213 0 3 1.39A E 100 5 110 1 220 220 0 0 0B A 100 5 110 1 205 205 0 0 0B C 100 5 110 1 196 196 0 0 0B E 100 5 110 1 219 217 0 2 0.91C B 100 5 110 1 211 211 0 0 0C D 100 5 110 1 204 204 0 0 0C E 100 5 110 1 223 218 0 5 2.24D A 100 5 110 1 250 247 3 0 0D B 100 5 110 1 215 215 0 0 0D C 100 5 110 1 216 216 0 0 0D E 100 5 110 1 221 221 0 0 0E A 100 5 110 1 226 226 0 0 0E B 100 5 110 1 224 222 2 0 0E D 100 5 110 1 228 228 0 0 0

Run No. = 4:

Total Network Data:


Link Data:


A B 100 5 110 1 220 219 1 0 0A E 100 5 110 1 212 203 0 9 4.25B A 100 5 110 1 207 207 0 0 0B C 100 5 110 1 237 237 0 0 0B E 100 5 110 1 228 226 0 2 0.88C B 100 5 110 1 211 211 0 0 0C D 100 5 110 1 228 222 0 6 2.63C E 100 5 110 1 210 206 0 4 1.90D A 100 5 110 1 236 232 3 1 0.42D B 100 5 110 1 199 199 0 0 0D C 100 5 110 1 197 197 0 0 0D E 100 5 110 1 227 227 0 0 0E A 100 5 110 1 226 226 0 0 0E B 100 5 110 1 226 220 2 4 1.77E D 100 5 110 1 228 228 0 0 0

Algorithm = Sticky Random Routing :

Run No. = 1:

Total Network Data:


Link Data:


A B 100 5 110 1 239 233 6 0 0A E 100 5 110 1 212 212 0 0 0B A 100 5 110 1 244 241 2 1 0.41B C 100 5 110 1 214 214 0 0 0B E 100 5 110 1 229 227 0 2 0.87C B 100 5 110 1 243 234 4 5 2.06C D 100 5 110 1 228 226 0 2 0.88C E 100 5 110 1 229 218 2 9 3.93D A 100 5 110 1 227 227 0 0 0D B 100 5 110 1 220 220 0 0 0D C 100 5 110 1 244 244 0 0 0D E 100 5 110 1 208 208 0 0 0E A 100 5 110 1 206 206 0 0 0E B 100 5 110 1 233 233 0 0 0E D 100 5 110 1 213 213 0 0 0

185

Run No. = 2:

Total Network Data:


Link Data:


A B 100 5 110 1 225 210 7 8 3.57A E 100 5 110 1 241 241 0 0 0B A 100 5 110 1 222 219 1 2 0.90B C 100 5 110 1 228 210 0 18 7.93B E 100 5 110 1 217 217 0 0 0C B 100 5 110 1 199 199 0 0 0C D 100 5 110 1 236 236 0 0 0C E 100 5 110 1 209 209 0 0 0D A 100 5 110 1 235 233 1 1 0.43D B 100 5 110 1 256 245 6 5 1,95D C 100 5 110 1 218 205 0 13 5.99D E 100 5 110 1 232 224 0 8 3.46E A 100 5 110 1 209 209 0 0 0E B 100 5 110 1 205 205 0 0 0E D 100 5 110 1 216 211 0 5 2.33

Run No. = 1:

Total Network Data:


Link Data:


A B 100 5 110 1 235 234 1 0 0A E 100 5 110 1 210 210 0 0 0B A 100 5 110 1 225 225 0 0 0B C 100 5 110 1 212 212 0 0 0B E 100 5 110 1 239 239 0 0 0C B 100 5 110 1 238 238 0 0 0C D 100 5 110 1 222 222 0 0 0C E 100 5 110 1 226 226 0 0 0D A 100 5 110 1 242 240 0 2 0.83D B 100 5 110 1 223 219 3 1 0.45D C 100 5 110 1 224 218 5 1 0.45D E 100 5 110 1 217 217 0 0 0E A 100 5 110 1 220 225 5 0 0E B 100 5 110 1 212 212 0 0 0E D 100 5 110 1 222 212 0 10 4.52

Run No. = 4:

Total Network Data:


Link Data:

186


A B 100 5 110 1 247 233 11 3 1.22A E 100 5 110 1 206 195 8 3 1.46B A 100 5 110 1 191 191 2 0 0B C 100 5 110 1 236 231 0 5 2.13B E 100 5 110 1 202 202 0 0 0C B 100 5 110 1 239 232 3 4 1.68C D 100 5 110 1 208 208 0 0 0C E 100 5 110 1 209 209 0 0 0D A 100 5 110 1 218 218 0 0 0D B 100 5 110 1 218 215 2 1 0.46D C 100 5 110 1 209 209 0 0 0D E 100 5 110 1 201 201 0 0 0E A 100 5 110 1 229 221 2 6 2.63E B 100 5 110 1 220 202 8 10 4.57E D 100 5 110 1 220 209 0 11 5.02

Complete & Asymmetric Network

Network 1:

Algorithm = none, Run no=1:

Total Network Data:


Link Data:


A B 348 2 232 3 494 94 0 0 0A C 221 2 91 1 180 180 0 0 0A D 162 5 228 4 491 491 0 0 0A E 95 2 178 4 335 335 0 0 0B A 403 5 138 2 280 280 0 0 0B C 414 7 91 1 176 176 0 0 0B D 369 1 184 2 398 398 0 0 0B E 132 6 299 2 613 521 0 92 15.01C A 465 7 58 2 133 133 0 0 0C B 464 1 72 3 149 149 0 0 0C D 130 1 136 4 265 265 0 0 0C E 251 2 216 4 390 390 0 0 0D A 61 7 269 1 513 177 0 336 65.50D B 154 0 197 2 410 410 0 0 0D C 225 2 275 3 546 546 0 0 0D E 53 1 180 2 340 223 0 117 34.41E A 173 1 261 2 561 561 0 0 0E B 395 0 218 4 442 442 0 0 0E C 499 2 80 3 160 160 0 0 0E D 292 7 290 1 558 558 0 0 0

Algorithm = none, Run no.=2:

Total Network Data:


Link Data:

187


A B 348 2 232 3 444 444 0 0 0A C 221 2 91 1 168 168 0 0 0A D 162 5 228 4 445 445 0 0 0A E 95 2 178 4 344 344 0 0 0B A 403 5 138 2 286 286 0 0 0B C 414 7 91 1 178 178 0 0 0B D 369 1 184 2 357 357 0 0 0B E 132 6 299 2 625 561 0 64 10.24C A 465 7 58 2 109 109 0 0 0C B 464 1 72 3 147 147 0 0 0C D 130 1 136 4 279 279 0 0 0C E 251 2 216 4 434 434 0 0 0D A 61 7 269 1 550 161 0 389 70.73D B 154 0 197 2 358 358 0 0 0D C 225 2 275 3 549 549 0 0 0D E 53 1 180 2 384 259 0 125 32.55E A 173 1 261 2 507 507 0 0 0E B 395 0 218 4 447 447 0 0 0E C 499 2 80 3 155 155 0 0 0E D 292 7 290 1 558 558 0 0 0

Algorithm = Trunk Reservation, Run no.=1:

Total Network Data:


Link Data:


A B 348 2 232 3 488 488 0 0 0A C 221 2 91 1 167 167 0 0 0A D 162 5 228 4 463 463 0 0 0A E 95 2 178 4 387 387 0 0 0B A 403 5 138 2 265 265 0 0 0B C 414 7 91 1 161 161 0 0 0B D 369 1 184 2 392 392 0 0 0B E 132 6 299 2 571 528 28 15 2.63C A 465 7 58 2 122 122 0 0 0C B 464 1 72 3 137 137 0 0 0C D 130 1 136 4 270 270 0 0 0C E 251 2 216 4 421 421 0 0 0D A 61 7 269 1 495 322 141 32 6.48D B 154 0 197 2 377 337 24 16 4.24D C 225 2 275 3 526 526 0 0 0D E 53 1 180 2 359 283 48 28 7.80E A 173 1 261 2 527 527 0 0 0E B 395 0 218 4 458 458 0 0 0E C 499 2 80 3 156 156 0 0 0E D 292 7 290 1 587 587 0 0 0


Total Network Data:


Link Data:

188


A B 348 2 232 3 479 479 0 0 0A C 221 2 91 1 193 193 0 0 0A D 162 5 228 4 426 426 0 0 0A E 95 2 178 4 367 367 0 0 0B A 403 5 138 2 298 298 0 0 0B C 414 7 91 1 186 186 0 0 0B D 369 1 184 2 355 355 0 0 0B E 132 6 299 2 621 548 51 22 3.55C A 465 7 58 2 96 96 0 0 0C B 464 1 72 3 151 151 0 0 0C D 130 1 136 4 259 259 0 0 0C E 251 2 216 4 398 398 0 0 0D A 61 7 269 1 476 299 131 46 9.68D B 154 0 197 2 398 338 32 28 7.05D C 225 2 275 3 559 559 0 0 0D E 53 1 180 2 346 251 55 40 11.59E A 173 1 261 2 528 528 0 0 0E B 395 0 218 4 403 403 0 0 0E C 499 2 80 3 159 159 0 0 0E D 292 7 290 1 590 590 0 0 0

Algorithm = Sticky Random Routing, Run no.=1:

Total Network Data:


Link Data:


A B 348 2 232 3 507 507 0 0 0A C 221 2 91 1 172 172 0 0 0A D 162 5 228 4 454 454 0 0 0A E 95 2 178 4 353 353 0 0 0B A 403 5 138 2 279 279 0 0 0B C 414 7 91 1 169 169 0 0 0B D 369 1 184 2 390 390 0 0 0B E 132 6 299 2 580 568 12 64 0C A 465 7 58 2 124 124 0 0 0C B 464 1 72 3 143 143 0 0 0C D 130 1 136 4 263 263 0 0 0C E 251 2 216 4 419 419 0 0 0D A 61 7 269 1 537 380 156 1 0.19D B 154 0 197 2 385 382 3 0 0D C 225 2 275 3 551 515 29 7 1.27D E 53 1 180 2 382 315 56 11 2.88E A 173 1 261 2 558 558 0 0 0E B 395 0 218 4 410 410 0 0 0E C 499 2 80 3 158 158 0 0 0E D 292 7 290 1 531 531 0 0 0


Total Network Data:


Link Data:

189


A B 348 2 232 3 419 419 0 0 0A C 221 2 91 1 183 183 0 0 0A D 162 5 228 4 446 446 0 0 0A E 95 2 178 4 353 353 0 0 0B A 403 5 138 2 307 307 0 0 0B C 414 7 91 1 156 156 0 0 0B D 369 1 184 2 364 364 0 0 0B E 132 6 299 2 592 526 65 1 0.17C A 465 7 58 2 105 105 0 0 0C B 464 1 72 3 150 150 0 0 0C D 130 1 136 4 296 296 0 0 0C E 251 2 216 4 429 429 0 0 0D A 61 7 269 1 543 367 168 8 1.48D B 154 0 197 2 369 365 1 3 0.82D C 225 2 275 3 519 502 14 3 0.58D E 53 1 180 2 377 319 45 13 3.46E A 173 1 261 2 491 491 0 0 0E B 395 0 218 4 444 444 0 0 0E C 499 2 80 3 181 181 0 0 0E D 292 7 290 1 621 621 0 0 0

Network 2:

Algorithm = None, Run no.=1:

Total Network Data:


Link Data:


A B 494 2 218 2 425 425 0 0 0A C 308 2 75 4 147 147 0 0 0A D 149 9 166 1 334 333 0 1 0.30A E 398 0 155 4 348 348 0 0 0B A 169 7 122 3 255 255 0 0 0B C 94 5 161 1 363 251 0 112 30.94B D 186 9 85 3 179 179 0 0 0B E 435 1 66 2 104 104 0 0 0C A 321 0 118 3 242 242 0 0 0C B 228 3 81 2 179 179 0 0 0C D 436 5 103 3 198 198 0 0 0C E 114 1 273 2 536 515 0 21 3.93D A 63 5 130 2 274 250 0 24 8.79D B 410 9 87 4 158 158 0 0 0D C 416 5 175 3 357 357 0 0 0D E 132 2 214 1 421 358 0 63 15.00E A 360 6 292 4 614 614 0 0 0E B 142 6 267 4 501 501 0 0 0E C 171 2 276 4 552 552 0 0 0E D 358 7 174 3 341 341 0 0 0


Total Network Data:


Link Data:

190


A B 494 2 218 2 437 437 0 0 0A C 308 2 75 4 151 151 0 0 0A D 149 9 166 1 321 321 0 0 0A E 398 0 155 4 265 265 0 0 0B A 169 7 122 3 263 263 0 0 0B C 94 5 161 1 305 252 0 53 17.43B D 186 9 85 3 183 183 0 0 0B E 435 1 66 2 141 141 0 0 0C A 321 0 118 3 232 232 0 0 0C B 228 3 81 2 158 158 0 0 0C D 436 5 103 3 217 217 0 0 0C E 114 1 273 2 510 484 0 26 5.11D A 63 5 130 2 270 253 0 17 6.32D B 410 9 87 4 204 204 0 0 0D C 416 5 175 3 344 344 0 0 0D E 132 2 214 1 427 349 0 78 18.27E A 360 6 292 4 570 570 0 0 0E B 142 6 267 4 550 550 0 0 0E C 171 2 276 4 553 553 0 0 0E D 358 7 174 3 344 344 0 0 0


Total Network Data:


Link Data:


A B 494 2 218 2 460 460 0 0 0A C 308 2 75 4 156 156 0 0 0A D 149 9 166 1 370 364 6 0 0A E 398 0 155 4 316 316 0 0 0B A 169 7 122 3 238 238 0 0 0B C 94 5 161 1 307 270 37 0 0B D 186 9 85 3 180 180 0 0 0B E 435 1 66 2 120 120 0 0 0C A 321 0 118 3 219 219 0 0 0C B 228 3 81 2 150 150 0 0 0C D 436 5 103 3 203 203 0 0 0C E 114 1 273 2 549 490 42 17 3.10D A 63 5 130 2 267 257 8 2 0.75D B 410 9 87 4 174 174 0 0 0D C 416 5 175 3 337 337 0 0 0D E 132 2 214 1 430 370 36 24 5.58E A 360 6 292 4 596 596 0 0 0E B 142 6 267 4 517 517 0 0 0E C 171 2 276 4 573 573 0 0 0E D 358 7 174 3 341 341 0 0 0


Total Network Data:


Link Data:

191


A B 494 2 218 2 444 444 0 0 0A C 308 2 75 4 155 155 0 0 0A D 149 9 166 1 315 315 0 0 0A E 398 0 155 4 308 308 0 0 0B A 169 7 122 3 232 232 0 0 0B C 94 5 161 1 306 261 45 0 0B D 186 9 85 3 161 161 0 0 0B E 435 1 66 2 135 135 0 0 0C A 321 0 118 3 217 217 0 0 0C B 228 3 81 2 161 161 0 0 0C D 436 5 103 3 202 202 0 0 0C E 114 1 273 2 490 460 19 11 2.25D A 63 5 130 2 240 230 5 5 2.09D B 410 9 87 4 169 169 0 0 0D C 416 5 175 3 368 368 0 0 0D E 132 2 214 1 448 377 50 21 4.70E A 360 6 292 4 582 582 0 0 0E B 142 6 267 4 547 547 0 0 0E C 171 2 276 4 542 542 0 0 0E D 358 7 174 3 353 353 0 0 0


Total Network Data:


Link Data:


A B 494 2 218 2 414 414 0 0 0A C 308 2 75 4 155 155 0 0 0A D 149 9 166 1 338 335 3 0 0A E 398 0 155 4 341 341 0 0 0B A 169 7 122 3 257 257 0 0 0B C 94 5 161 1 340 288 52 0 0B D 186 9 85 3 164 164 0 0 0B E 435 1 66 2 139 139 0 0 0C A 321 0 118 3 235 235 0 0 0C B 228 3 81 2 164 164 0 0 0C D 436 5 103 3 228 228 0 0 0C E 114 1 273 2 550 521 29 0 0D A 63 5 130 2 265 251 14 0 0D B 410 9 87 4 175 175 0 0 0D C 416 5 175 3 368 368 0 0 0D E 132 2 214 1 466 396 68 2 0.43E A 360 6 292 4 548 648 0 0 0E B 142 6 267 4 518 518 0 0 0E C 171 2 276 4 571 571 0 0 0E D 358 7 174 3 336 336 0 0 0


Total Network Data:


Link Data:

192


A B 494 2 218 2 400 400 0 0 0A C 308 2 75 4 144 144 0 0 0A D 149 9 166 1 349 336 13 0 0A E 398 0 155 4 305 305 0 0 0B A 169 7 122 3 233 233 0 0 0B C 94 5 161 1 299 259 40 0 0B D 186 9 85 3 163 163 0 0 0B E 435 1 66 2 117 117 0 0 0C A 321 0 118 3 242 242 0 0 0C B 228 3 81 2 195 195 0 0 0C D 436 5 103 3 202 202 0 0 0C E 114 1 273 2 530 504 26 0 0D A 63 5 130 2 258 252 5 1 0.39D B 410 9 87 4 181 181 0 0 0D C 416 5 175 3 303 303 0 0 0D E 132 2 214 1 425 380 43 2 0.47E A 360 6 292 4 652 652 0 0 0E B 142 6 267 4 518 518 0 0 0E C 171 2 276 4 530 530 0 0 0E D 358 7 174 3 388 388 0 0 0

Network 3:


Total Network Data:


Link Data:


A B 213 4 193 4 380 380 0 0 0A C 357 3 117 3 249 249 0 0 0A D 215 4 144 3 286 286 0 0 0A E 84 2 191 3 366 366 0 0 0B A 205 7 177 2 342 342 0 0 0B C 71 5 298 1 595 205 0 390 65.66B D 190 6 66 3 127 127 0 0 0B E 165 10 194 3 398 398 0 0 0C A 209 1 273 2 543 543 0 0 0C B 135 5 283 1 540 351 0 189 35.06C D 355 4 189 2 365 365 0 0 0C E 262 2 228 2 452 452 0 0 0D A 459 4 217 4 429 429 0 1 0D B 356 4 227 2 425 425 0 0 0D C 173 0 135 2 252 252 0 0 0D E 97 10 151 4 291 291 0 2 0E A 53 0 113 3 244 244 0 0 0E B 325 9 266 1 555 555 0 0 0E C 178 2 268 3 543 543 0 0 0E D 392 6 156 1 307 307 0 0 0


Total Network Data:


Link Data:

193


A B 213 4 193 4 362 362 0 0 0A C 357 3 117 3 242 242 0 0 0A D 215 4 144 3 284 284 0 0 0A E 84 2 191 3 394 394 0 0 0B A 205 7 177 2 348 348 0 0 0B C 71 5 298 1 609 198 0 411 67.49B D 190 6 66 3 127 127 0 0 0B E 165 10 194 3 415 415 0 0 0C A 209 1 273 2 521 521 0 0 0C B 135 5 283 1 555 363 0 192 34.59C D 355 4 189 2 407 307 0 0 0C E 262 2 228 2 444 444 0 0 0D A 459 4 217 4 445 445 0 1 0D B 356 4 227 2 467 467 0 0 0D C 173 0 135 2 275 275 0 0 0D E 97 10 151 4 265 265 0 0 0E A 53 0 113 3 242 241 0 1 0.41E B 325 9 266 1 516 516 0 0 0E C 178 2 268 3 527 527 0 0 0E D 392 6 156 1 320 320 0 0 0


Total Network Data:


Link Data:


A B 213 4 193 4 361 361 0 0 0A C 357 3 117 3 237 237 0 0 0A D 215 4 144 3 292 292 0 0 0A E 84 2 191 3 364 364 0 0 0B A 205 7 177 2 376 376 0 0 0B C 71 5 298 1 615 398 215 2 0.33B D 190 6 66 3 141 141 0 0 0B E 165 10 194 3 370 370 0 0 0C A 209 1 273 2 494 494 0 0 0C B 135 5 283 1 541 421 120 0 0C D 355 4 189 2 408 408 0 0 0C E 262 2 228 2 466 466 0 0 0D A 459 4 217 4 445 445 0 0 0D B 356 4 227 2 438 438 0 0 0D C 173 0 135 2 249 249 0 0 0D E 97 10 151 4 291 291 0 0 0E A 53 0 113 3 242 242 0 0 0E B 325 9 266 1 547 547 0 0 0E C 178 2 268 3 569 567 1 1 0.18E D 392 6 156 1 293 293 0 0 0


Total Network Data:


Link Data:

194


A B 213 4 193 4 402 402 0 0 0A C 357 3 117 3 235 235 0 0 0A D 215 4 144 3 276 276 0 0 0A E 84 2 191 3 381 381 0 0 0B A 205 7 177 2 341 341 0 0 0B C 71 5 298 1 631 449 182 0 0B D 190 6 66 3 124 124 0 0 0B E 165 10 194 3 400 400 0 0 0C A 209 1 273 2 558 558 0 0 0C B 135 5 283 1 529 437 92 0 0C D 355 4 189 2 374 374 0 0 0C E 262 2 228 2 447 447 0 0 0D A 459 4 217 4 437 437 0 0 0D B 356 4 227 2 485 485 0 0 0D C 173 0 135 2 289 289 0 0 0D E 97 10 151 4 299 299 0 0 0E A 53 0 113 3 249 249 0 0 0E B 325 9 266 1 521 521 0 0 0E C 178 2 268 3 551 551 0 0 0E D 392 6 156 1 328 328 0 0 0


Total Network Data:


Link Data:


A B 213 4 193 4 402 402 0 0 0A C 357 3 117 3 227 227 0 0 0A D 215 4 144 3 287 287 0 0 0A E 84 2 191 3 368 368 0 0 0B A 205 7 177 2 372 372 0 0 0B C 71 5 298 1 545 360 184 0 0B D 190 6 66 3 126 126 0 0 0B E 165 10 194 3 382 382 0 0 0C A 209 1 273 2 505 505 0 0 0C B 135 5 283 1 576 462 113 1 0.17C D 355 4 189 2 389 389 0 0 0C E 262 2 228 2 477 477 0 0 0D A 459 4 217 4 470 470 0 0 0D B 356 4 227 2 459 459 0 0 0D C 173 0 135 2 276 254 21 1 0.26D E 97 10 151 4 276 276 0 0 0E A 53 0 113 3 257 257 0 0 0E B 325 9 266 1 539 511 28 0 0E C 178 2 268 3 527 527 0 0 0E D 392 6 156 1 374 374 0 0 0


Total Network Data:


Link Data:

195


A B 213 4 193 4 386 386 0 0 0A C 357 3 117 3 259 259 0 0 0A D 215 4 144 3 270 270 0 0 0A E 84 2 191 3 379 378 1 0 0B A 205 7 177 2 339 339 0 0 0B C 71 5 298 1 595 406 188 1 0.17B D 190 6 66 3 154 154 0 0 0B E 165 10 194 3 371 371 0 0 0C A 209 1 273 2 530 530 0 0 0C B 135 5 283 1 549 453 96 0 0C D 355 4 189 2 388 388 0 0 0C E 262 2 228 2 433 433 0 0 0D A 459 4 217 4 427 427 0 0 0D B 356 4 227 2 454 454 0 0 0D C 173 0 135 2 268 268 0 0 0D E 97 10 151 4 293 293 0 0 0E A 53 0 113 3 246 246 0 0 0E B 325 9 266 1 518 518 0 0 0E C 178 2 268 3 582 570 11 1 0.17E D 392 6 156 1 296 296 0 0 0

Non-Complete & Asymmetric Network

Network 1:


Total Network Data:


Link Data:


A B 162 1 103 4 206 206 0 0 0A E 78 3 291 3 587 511 0 76 12.97B A 456 5 284 4 501 501 0 0 0B C 427 2 197 4 394 394 0 0 0B E 75 2 115 3 241 241 0 0 0C B 65 0 140 4 279 279 0 0 0C D 153 0 89 4 182 182 0 0 0C E 128 8 73 3 139 139 0 0 0D A 465 6 141 4 318 318 0 0 0D B 453 6 281 1 535 535 96 0 0D C 157 6 106 1 217 217 0 0 0D E 297 4 235 4 447 447 0 0 0E A 489 3 264 2 504 504 0 0 0E B 499 10 126 4 275 275 0 0 0E D 180 7 219 1 415 410 0 5 1.20


Total Network Data:


Link Data:

196




Total Network Data:


Link Data:




Total Network Data:


Link Data:


A B 162 1 103 4 220 220 0 0 0A E 78 3 291 3 580 544 36 0 0B A 456 5 284 4 565 565 0 0 0B C 427 2 197 4 389 389 0 0 0B E 75 2 115 3 220 220 0 0 0C B 65 0 140 4 284 284 0 0 0C D 153 0 89 4 176 176 0 0 0C E 128 8 73 3 165 165 0 0 0D A 465 6 141 4 261 261 0 0 0D B 453 6 281 1 519 519 0 0 0D C 157 6 106 1 205 205 0 0 0D E 297 4 235 4 446 446 0 0 0E A 489 3 264 2 533 533 0 0 0E B 499 10 126 4 235 235 0 0 0E D 180 7 219 1 452 417 0 35 7.74

197


Total Network Data:


Link Data:


A B 162 1 103 4 219 219 0 0 0A E 78 3 291 3 543 517 26 0 0B A 456 5 284 4 540 540 0 0 0B C 427 2 197 4 389 389 0 0 0B E 75 2 115 3 220 220 0 0 0C B 65 0 140 4 284 284 0 0 0C D 153 0 89 4 195 195 0 0 0C E 128 8 73 3 124 124 0 0 0D A 465 6 141 4 254 254 0 0 0D B 453 6 281 1 545 145 0 0 0D C 157 6 106 1 222 222 0 0 0D E 297 4 235 4 466 466 0 0 0E A 489 3 264 2 552 552 0 0 0E B 499 10 126 4 254 254 0 0 0E D 180 7 219 1 403 403 0 0 0


Total Network Data:


Link Data:


A B 162 1 103 4 224 224 0 0 0A E 78 3 291 3 551 518 33 0 0B A 456 5 284 4 574 574 0 0 0B C 427 2 197 4 390 390 0 0 0B E 75 2 115 3 192 192 0 0 0C B 65 0 140 4 280 280 0 0 0C D 153 0 89 4 169 169 0 0 0C E 128 8 73 3 143 143 0 0 0D A 465 6 141 4 286 286 0 0 0D B 453 6 281 1 576 176 0 0 0D C 157 6 106 1 225 225 0 0 0D E 297 4 235 4 449 449 0 0 0E A 489 3 264 2 472 472 0 0 0E B 499 10 126 4 221 221 0 0 0E D 180 7 219 1 426 420 0 6 1.41

Network 2:


Total Network Data:


Link Data:

198


A B 489 7 71 1 139 139 0 0 0A E 72 4 141 3 296 296 0 0 0B A 448 10 239 1 478 478 0 0 0B C 286 1 119 3 226 226 0 0 0B E 59 0 287 2 549 252 0 297 54.10C B 418 9 106 3 217 217 0 0 0C D 51 5 55 3 126 126 0 0 0C E 90 1 182 3 369 369 0 0 0D A 177 4 256 4 512 512 0 0 0D B 320 10 243 1 499 499 0 0 0D C 286 9 286 3 528 528 0 0 0D E 245 3 244 3 512 512 0 0 0E A 76 9 203 3 387 387 0 0 0E B 475 6 170 4 308 308 0 0 0E D 179 1 120 4 233 233 0 0 0


Total Network Data:


Link Data:


A B 489 7 71 1 160 160 0 0 0A E 72 4 141 3 255 255 0 0 0B A 448 10 239 1 437 437 0 0 0B C 286 1 119 3 227 227 0 0 0B E 59 0 287 2 595 295 0 300 50.42C B 418 9 106 3 193 193 0 0 0C D 51 5 55 3 109 109 0 0 0C E 90 1 182 3 340 340 0 0 0D A 177 4 256 4 505 505 0 0 0D B 320 10 243 1 453 453 0 0 0D C 286 9 286 3 533 533 0 0 0D E 245 3 244 3 496 496 0 0 0E A 76 9 203 3 372 372 0 0 0E B 475 6 170 4 352 352 0 0 0E D 179 1 120 4 221 221 0 0 0


Total Network Data:


Link Data:


A B 489 7 71 1 136 136 0 0 0A E 72 4 141 3 308 276 3 29 9.45B A 448 10 239 1 488 488 0 0 0B C 286 1 119 3 224 224 0 0 0B E 59 0 287 2 579 448 74 57 9.86C B 418 9 106 3 214 214 0 0 0C D 51 5 55 3 108 108 0 0 0C E 90 1 182 3 345 312 19 14 4.07D A 177 4 256 4 587 587 0 0 0D B 320 10 243 1 457 457 0 0 0D C 286 9 286 3 549 549 0 0 0D E 245 3 244 3 491 491 0 0 0E A 76 9 203 3 388 387 1 0 0E B 475 6 170 4 338 338 0 0 0E D 179 1 120 4 253 253 0 0 0

199


Total Network Data:


Link Data:




Total Network Data:


Link Data:




Total Network Data:


Link Data:

200


A B 489 7 71 1 132 132 0 0 0A E 72 4 141 3 260 258 6 2 0.77B A 448 10 239 1 449 449 0 0 0B C 286 1 119 3 222 222 0 0 0B E 59 0 287 2 564 466 90 8 1.42C B 418 9 106 3 206 206 0 0 0C D 51 5 55 3 105 102 0 2 0.95C E 90 1 182 3 368 326 40 2 0.54D A 177 4 256 4 510 510 0 0 0D B 320 10 243 1 445 445 0 0 0D C 286 9 286 3 559 559 0 0 0D E 245 3 244 3 476 476 0 0 0E A 76 9 203 3 413 405 8 0 0E B 475 6 170 4 305 305 0 0 0E D 179 1 120 4 246 246 0 0 0

Network 3:


Total Network Data:


Link Data:


A B 141 3 265 1 492 353 0 139 28.25A E 410 3 177 1 347 347 0 0 0B A 54 1 118 3 274 274 0 0 0B C 219 2 63 4 135 135 0 0 0B E 487 4 53 2 108 108 0 0 0C B 498 9 119 1 218 218 0 0 0C D 347 0 254 1 456 456 0 0 0C E 311 3 209 4 388 388 0 0 0D A 127 9 174 1 348 317 0 31 8.93D B 81 10 102 2 207 207 0 0 0D C 108 7 136 1 270 243 0 27 10.04D E 416 10 288 3 519 519 0 0 0E A 444 0 254 3 505 505 0 0 0E B 135 10 247 2 455 455 0 0 0E D 229 6 123 2 242 242 0 0 0


Total Network Data:


Link Data:


A B 141 3 265 1 496 366 0 130 26.21A E 410 3 177 1 333 333 0 0 0B A 54 1 118 3 206 206 0 0 0B C 219 2 63 4 135 135 0 0 0B E 487 4 53 2 118 118 0 0 0C B 498 9 119 1 239 239 0 0 0C D 347 0 254 1 472 472 0 0 0C E 311 3 209 4 395 395 0 0 0D A 127 9 174 1 325 313 0 12 3.69D B 81 10 102 2 206 206 0 0 0D C 108 7 136 1 301 265 0 36 11.96D E 416 10 288 3 538 538 0 0 0E A 444 0 254 3 493 493 0 0 0E B 135 10 247 2 503 500 0 3 0.60E D 229 6 123 2 245 245 0 0 0

201


Total Network Data:


Link Data:




Total Network Data:


Link Data:


A B 141 3 265 1 499 409 32 58 11.62A E 410 3 177 1 350 350 0 0 0B A 54 1 118 3 222 222 0 0 0B C 219 2 63 4 122 122 0 0 0B E 487 4 53 2 96 96 0 0 0C B 498 9 119 1 236 236 0 0 0C D 347 0 254 1 487 487 0 0 0C E 311 3 209 4 428 428 0 0 0D A 127 9 174 1 354 321 29 4 1.13D B 81 10 102 2 184 184 0 0 0D C 108 7 136 1 232 232 0 27 0D E 416 10 288 3 521 521 0 0 0E A 444 0 254 3 434 434 0 0 0E B 135 10 247 2 491 455 18 18 3.67E D 229 6 123 2 207 207 0 0 0


Total Network Data:


Link Data:

202




Total Network Data:


Link Data:


A B 141 3 265 1 490 401 43 146 9.39A E 410 3 177 1 309 309 0 0 0B A 54 1 118 3 203 203 0 0 0B C 219 2 63 4 140 140 0 0 0B E 487 4 53 2 128 128 0 0 0C B 498 9 119 1 237 237 0 0 0C D 347 0 254 1 478 478 0 0 0C E 311 3 209 4 374 374 0 0 0D A 127 9 174 1 334 322 12 0 0D B 81 10 102 2 194 191 2 1 0.53D C 108 7 136 1 230 230 0 0 0D E 416 10 288 3 535 535 0 0 0E A 444 0 254 3 486 486 0 0 0E B 135 10 247 2 445 407 31 7 1.58E D 229 6 123 2 249 249 0 0 0

C.4 Experiment 4

Complete & Symmetric Network

Algorithm = None:

Run No. = 1:

Total Network Data:


Link Data:

Node from: A, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 226, Direct

Calls: 226, Indirect Calls: 0, Calls Lost: 0, % Calls Lost: 0.00

Node from: A, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 204, Direct


Node from: A, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 219, Direct


Node from: A, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 213, Direct


Node from: A, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 252, Direct


Node from: A, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 221, Direct


Node from: A, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 228, Direct


Node from: B, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 209, Direct

203


Node from: B, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 212, Direct


Node from: B, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 221, Direct


Node from: B, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 210, Direct


Node from: B, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 191, Direct


Node from: B, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 216, Direct


Node from: B, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 214, Direct


Node from: C, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 226, Direct


Node from: C, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 207, Direct


Node from: C, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 190, Direct


Node from: C, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 199, Direct


Node from: C, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 237, Direct


Node from: C, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 203, Direct


Node from: C, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 245, Direct


Node from: D, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 222, Direct


Node from: D, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 232, Direct


Node from: D, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 245, Direct


Node from: D, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 186, Direct


Node from: D, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 240, Direct


Node from: D, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 238, Direct


Node from: D, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 191, Direct


Node from: E, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 202, Direct


Node from: E, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 187, Direct


Node from: E, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 214, Direct


Node from: E, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 232, Direct


Node from: E, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 238, Direct


Node from: E, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 207, Direct


Node from: E, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 214, Direct


Node from: F, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 200, Direct


Node from: F, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 241, Direct


Node from: F, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 233, Direct


Node from: F, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 213, Direct


Node from: F, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 223, Direct


Node from: F, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 218, Direct


Node from: F, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 200, Direct


Node from: G, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 223, Direct


Node from: G, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 213, Direct


Node from: G, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 235, Direct


Node from: G, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 188, Direct


Node from: G, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 219, Direct


Node from: G, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 255, Direct


Node from: G, Node to: H, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 250, Direct


Node from: H, Node to: A, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 220, Direct


Node from: H, Node to: B, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 255, Direct


Node from: H, Node to: C, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 196, Direct


Node from: H, Node to: D, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 213, Direct


Node from: H, Node to: E, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 219, Direct


Node from: H, Node to: F, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 197, Direct


Node from: H, Node to: G, Capacity: 100, Trunk Parameter: 5, Call Rate: 110, Call Length: 1, Calls Started: 239, Direct


204

Run No. = 2:

Total Network Data:


Link Data:























































































205



























Run No. = 3:

Total Network Data:


Link Data:




























































206






















































Run No. = 3:

Total Network Data:


Link Data:

































207


















































































Run No. = 1:

Total Network Data:


Link Data:



208


































































































209














Run No. = 2:

Total Network Data:


Link Data:









































































210









































Run No. = 3:

Total Network Data:


Link Data:














































211




































































Run No. = 4:

Total Network Data:


Link Data:



















212
































































































213

Run No. = 1:

Total Network Data:


Link Data:






















































































214




























Run No. = 2:

Total Network Data:


Link Data:



























































215























































Run No. = 3:

Total Network Data:


Link Data:































216



















































































Run No. = 4:

Total Network Data:


Link Data:




217


































































































218













Algorithm = Sticky Random Routing:

Run No. = 1:

Total Network Data:


Link Data:







































































219











































Run No. = 2:

Total Network Data:


Link Data:












































220






































































Run No. = 3:

Total Network Data:


Link Data:

















221

































































































222

Run No. = 4:

Total Network Data:


Link Data:























































































223



























Complete & Asymmetric Network

Algorithm = None:

Run No. = 1:

Total Network Data:


Link Data:






















































224














Run No. = 2:

Total Network Data:


Link Data:



































































Run No. = 3:

Total Network Data:

225


Link Data:



































































Run No. = 3:

Total Network Data:


Link Data:














226























































Run No. = 1:

Total Network Data:


Link Data:






























227






































Run No. = 2:

Total Network Data:


Link Data:

















































228



















Run No. = 3:

Total Network Data:


Link Data:



































































229

Run No. = 4:

Total Network Data:


Link Data:



































































Algorithm = Sticky Random Routing:

Run No. = 1:

Total Network Data:


Link Data:






230






























































Run No. = 2:

Total Network Data:


Link Data:

























231











































Run No. = 3:

Total Network Data:


Link Data:












































232
























Run No. = 3:

Total Network Data:


Link Data:































































233





Complete & Asymmetric Network Network 1:

Algorithm = None, Run No. = 1:

Total Network Data:


Link Data:















































































234




































Total Network Data:


Link Data:




















































235






























































Algorithm = Trunk Reservation, Run No. = 1:

Total Network Data:


Link Data:

























236


























































































Total Network Data:


237

Link Data:

































































































238

















Algorithm = Sticky Random Routing, Run No. = 1:

Total Network Data:


Link Data:






































































239













































Total Network Data:


Link Data:











































240







































































Network 2:


Total Network Data:


Link Data:













241


































































































242





Total Network Data:


Link Data:


















































































243

































Total Network Data:


Link Data:























































244




























































Total Network Data:


Link Data:




























245























































































Total Network Data:


Link Data:

246


































































































247

















Total Network Data:


Link Data:







































































248











































Network 3:


Total Network Data:


Link Data:









































249










































































Total Network Data:


Link Data:














250

































































































251





Total Network Data:


Link Data:



















































































252
































Total Network Data:


Link Data:























































253




























































Total Network Data:


Link Data:




























254























































































Total Network Data:


Link Data:

255


































































































256
















Non-Complete & Asymmetric Network

Network 1:


Total Network Data:


Link Data:

































































257






Total Network Data:

Calls Started Calls Connected Calls Lost % of Calls Lost11035,10247,788,7.14

Link Data:





































































Algorithm = Trunk Reservation Parameter, Run No. = 1:

Total Network Data:


Link Data:

258





































































Algorithm = Trunk Reservation Parameter, Run No. = 2:

Total Network Data:


Link Data:


















259





















































Total Network Data:


Link Data:



































260




































Total Network Data:


Link Data:




















































261


















Network 2:


Total Network Data:


Link Data:

































































262


Total Network Data:


Link Data:


































































Total Network Data:


Link Data:











263
























































Total Network Data:


Link Data:
































264



































Total Network Data:


Link Data:





















































265














Total Network Data:


Link Data:

































































Network 3:


Total Network Data:

266


Link Data:






























































Total Network Data:


Link Data:




















267











































Total Network Data:


Link Data:













































268


















Total Network Data:


Link Data:






























































Total Network Data:


269

Link Data:






























































Total Network Data:


Link Data:
























270






































271

Simulation of Telephone Exchanges to Compare Diﬁerent...

Documents

Transcript of Simulation of Telephone Exchanges to Compare Diﬁerent...