|
Project Introduction
SPEED would like to expand its business by entering the Fibre Internet Provision market by developing a new Fibre‐Optic Network (Fibre Network).
SPEED is currently in the early planning stage of this investment. The development of fully detailed plan will take place in the following months. At this stage, SPEED must make high‐level decisions regarding the network designs to be implemented. To that end, they would like an analysis of how to best design their new Fibre network on the basis of the description laid out in the rest of this document. They have commissioned you to analyse their problem by developing and solving appropriate
Mathematical Programming models and reporting back with an analysis of your findings.
It has been decided that the analysis would be based on the London region only, which has been divided into 20 zones. The general problem involves deciding on an optimal network design that can serve the internet traffic demand across all zones subject to a number of other technical design specifications. The problem and deliverables are described in detail in the following sections.
Fibre‐Optic Network Design
SPEED is building a new network for Fibre internet data traffic, which is expected to increase dramatically in the future. Estimates for future demand for data traffic (traffic is defined as the amount of data communicated per second) in each zone is available (see Appendix). The demand for data traffic is expressed in Gigabits per second (Gbps), i.e. the
Gigabits of data that will need to be transmitted/communicated to each zone every second. SPEED wants to ensure that the network design to be implemented can handle these demand estimates. The estimates given here relate to total demand for data‐traffic to and from a zone.
Thus, the analysis can disregard data‐traffic direction and should consider the traffic totals only.
SPEED is an end‐user internet service provider. It will purchase, from ‘wholesale’ internet providers, certain amounts of traffic processing capacity in seven separate internet exchanges located in London. It can then use these capacities to cover future internet traffic demand estimates across all 20 zones in London. The demand in zones is served by the exchanges in which capacity has been purchased, by connecting each London zone (by Fibre‐Optic ‘Links’) to one exchange.
The available traffic processing capacity at each of the exchanges is available as a ‘batch’. The following batches of traffic processing capacities are available for purchase in London’s seven internet exchanges: 600Gbps in each of the exchanges 1, 3 and 4 and 500 Gbps in each of the remaining exchanges 2, 5, 6 and 7. Only a single batch can be bought in each exchange. Further, SPEED cannot buy portions of any batch capacities: i.e. either it buys one (and only one) entire batch of capacity at an exchange or no capacity at that exchange.
Zones can be connected to exchanges via building Fibre‐Optic links. Although the connection between zones and exchanges involves several cables of different lengths, the analysis should be based on the average distance of the cables connecting a given exchange with a given zone. This is referred to as the average distance of a potential zone‐to‐exchange link. Data on average zone‐to‐exchange distances is provided in the Appendix.
Therefore, SPEED needs to determine: (a) which batches of available capacities in exchanges to buy and (b) which zones should be allocated to each of the exchanges in which processing capacity has been purchased (i.e. whether to connect a zone and an exchange via fibre optic cables).
The network design should adhere to a number of specifications which are as follows:
Allocating a zone to an exchange is not allowed if the distance between them is more than given distance threshold which is: 20Km for exchanges 1, 2, 3 and 25Kms for exchanges 4, 5, 6, 7.
It is not possible to apportion a zone’s Fibre data traffic across several exchanges. Instead, each zone must be allocated to a unique exchange (and obviously no zone can be allocated to an exchange in which no capacity has been purchased).
The total traffic routed to any of the exchanges must not exceed the available processing capacity (batch) purchased at that exchange.
For network reliability reasons, SPEED wants to purchase batches in at least three exchanges.
Due to regulations regarding network use, SPEED is required to allocate at least four zones to each of the exchanges in which traffic processing capacity has been purchased.
To avoid very uneven routing distribution, no exchange is allowed to process more than 40% of total data traffic demand across all zones.
SPEED has not yet decided firmly on the objective that will determine the optimal network design. It has been agreed, however, that it is important that customer experience and network reliability are ensured to a great extent. To that end, it is considering the following two objectives: (1) to maximise the minimum speed offered to end‐users; (2) to minimise the maximum proportional utilisation of purchased capacity across exchanges. These objectives are described in more detail below.
(1) Each exchange is characterised by an ideal speed that an exchange can ‘offer’ to a user in an ideal network communications setting. This is calculated to be equal to 0.20Gbps for exchanges 1 ,3, 4 and 0.25Gbps for exchanges 2, 5, 6, 7. In practice, no user can ever be offered these ideal speeds by any of the exchanges. On average, it is estimated that the “target Fibre speed” that any exchange can offer to any zone reduces proportionally to average distance between them. In particular, the reduction is equal to 0.005Gbps per km. For example, if the average distance between one of the exchanges and a zone allocated to it is 20km and the exchange’s ideal speed is 0.25Gbps, then, on average, the target speed offered to users in that zone (which will have to be entirely served by that exchange as described earlier) will be equal to 0.25‐0.005*20 = 0.15Gbps.
(2) The total amount of traffic allocated to an exchange (i.e. the sum of the data traffic demand across all zones allocated to the exchange), is referred to as the utilisation of that exchange. Dividing each exchange’s utilisation by the size of its traffic processing capacity (the batch Gbps capacity) gives the “proportional utilisation” of processing capacity for that exchange. To ensure network reliability, but also to account for future increases in demand, SPEED may consider minimising the maximum “proportional utilisation” across exchanges.
SPEED would like you to develop, solve and analyse models by considering the above two metrics in three separate scenarios for the objective to be used, for which it wants to know the optimal answers relating to minimum Fibre target speeds across all zones and maximum proportional utilisations across all exchanges:
Scenario 1: Maximise the minimum “target Fibre speed” across all zones (as described in (1) above).
Scenario 2: Minimise the maximum “proportional utilisation” across exchanges (as described in (2) above).
Scenario 3: Minimise the maximum “proportional utilisation” across exchanges, with the added restriction that minimum “target Fibre speed” achieved has to be at least 70% of the optimal “target Fibre speed” determined in scenario 1.
SPEED has commissioned you to provide a set of answers for optimal network designs corresponding to each of the above scenarios. However, it would be interested in any additional analysis which you may apply to the problems, e.g. possibly (but not necessarily or limited to) how the network design may cope with #p#分页标题#e#
increases in future demand.
Deliverables and Report Contents
SPEED wants you to develop Mathematical Programming models for their problem and use AIMMS to implement and solve these MP models. It also expects that you will then analyse and discuss your findings on the basis of the questions outlined in the previous sections but also including your insights on any other issues which you identify as relevant. You must deliver to SPEED a Project Report containing your analysis and suggestions but also detailing the modelling that you have undertaken.
The Project report should consist of the following (explained below in more detail):
(a) An Executive Summary (as short as possible), discussing your main findings.
(b) A concise Management Report discussing all of your findings.
(c) A number of Technical Appendices, detailed below.
(d) An electronic copy, on a CD or DVD, of all of the AIMMS files that you develop as well as any additional computer files used (if any).
(a) The Executive Summary is intended for SPEED’s executive board. This should be completely free of any mathematical terms and discussion of modelling technicalities. It should provide separate answers to each of the questions raised by SPEED in the specification of the three scenarios given above. They are expecting a list of alternative network designs from which they may potentially choose. These alternative designs should be described only in terms of high‐level information: for example, they need to know about the optimal values in each scenario but not necessarily about the optimal allocation of zones to exchanges.
(b) In the Management Report, which is intended for SPEED’s ‘second‐tier’ managers, you should concisely discuss all of your findings and analysis in more detail. This should be independent of the Executive Summary (i.e. self‐contained). Ideally, the Management Report will avoid the use of unnecessary mathematics, technical terms and discussion of modelling technicalities.
(c) The technical appendices will be read by SPEED’s operations managers and network engineers. The following separate Appendices should be included:
i.
An appendix detailing the development of the MP models, where all entities of your models are defined and their development is explained in detail.
ii.
An appendix containing short algebraic statements for each of your MP models, in MP formulation format.
iii.
A description of the relationship (correspondence) between the entities of your mathematical models and their AIMMS implementations.
iv.
An appendix containing listings for all of your AIMMS models (i.e. a printout of all the associated AIMMS files).
v.
Possibly, any other technical information that you think would be helpful in understanding your MP models and their AIMMS implementations.
vi.
If you include additional files (other than the contents of the AIMMS model files) then you must include in your report another appendix detailing the purpose of each additional file.
|
 |
|||
| 网站地图 |
