How should a metro network operator calculate the true cost of providing bandwidth services? Simple answers relating cost to distance are easy to estimate, but do they make commercial sense? How should the relative expense of one route compared to another feed through to the customer? A demand-driven cost and dimensioning model will help determine these issues.
Context
This model considers a simple urban backbone ring consisting of five nodes (named A to E) connected in a loop, with an additional cross-ring trunk. Customers can purchase E1 services between any two nodes on the ring. Nodes A-D are commissioned in Q1 2001, whereas Node E and trunks D-E and C-E are commissioned three months later, in Q2 2001.
Infrastructure
The three main parts of the network infrastructure are the nodes, the trunks, and the network management system (common to all nodes and trunks).
- Nodes - A node consists essentially of a router. The routers are dimensioned according to the traffic they switch - in this case, E1s. On the access side, an aggregate card multiplexes the E1s onto STM-1s, so they can plug into an STM-1 port on the router. On the
ring side, the circuits are transported at the STM-1 level, and can plug straight into the router's STM-1 ports.
- Trunks - The trunk STM-1s, the only resources that make up the trunks, are circuits on the fibres that connect each pair of nodes. The model uses an average cost per STM-1, varying by trunk to allow for distance.
- Common - The network management system is common to the whole network. It has a capacity of 1000 STM-1 ports, and is driven by all the STM-1s in the network.
The framework is readily extensible to model alternative technologies, such as optical switching.
Mapping services onto paths
The table below defines the paths the traffic takes. Some services may consist of more than one path (e.g. service B-C consists of three paths), in which case the proportion of traffic that is carried on each path is defined. In the table, the endpoints are marked in bold. These paths are used to map the traffic onto the nodes and the trunks.
|
Service |
Proportion of traffic on used path(s) |
| A–B |
A–B (100%) |
| A–C |
A–C (100%) |
| A–D |
A–B + B–D (90%);
A–C + C–D(10%) |
| A–E |
A–B + B–D + D–E (50%);
A–C + C–E (50%) |
| B–C (Q1 2001, before Node E is deployed) |
A–B + A–C (60%);
B–D + C–D (40%) |
| B–C (Q2 2001 onwards) |
A–B + A–C (60%);
B–D + C–D (30%);
B–D + D–E + C–E (10%) |
} |
B–D (40%); C–D (30%); D–E + C–E (10%) |
|
B–D |
B–D (100%) |
|
B–E |
B–D + D–E (100%) |
|
C–D |
C–D (100%) |
|
C–E |
C–E (100%) |
|
D–E |
D–E (100%) |
Modelling the nodes
The model's service elements, which represent the E1 services, drive a basic node template (see illustration). When the model is run, this node template is replicated for all five nodes, and when combined with the node-specific inputs (in this case, the node access traffic and node ring traffic), produces results specific to each node.
To calculate the traffic at each node, the traffic from each service is mapped on to the nodes they use. The endpoints of each service are used to generate a node access traffic matrix (the access circuits at each node), and the trunk mappings from the table above are used to generate a node ring traffic matrix (the ring circuits at each node). The node ring traffic matrix is shown below and reflects the fact that traffic which transits a node requires both 'in' and 'out' capacity. The implementation of this matrix in STEM, using the node template's variant data inputs, is shown below.
| Service |
Node A |
Node B |
Node C |
Node D |
Node E |
| A–B |
100% |
100% |
|
|
|
| A–C |
100% |
|
100% |
|
|
| A–D |
100% |
180% (2×90%) |
20% (2×10%) |
100% |
|
| A–E |
100% |
100% |
100% (2×50%) |
100% (2×50%) |
100% |
| B-C (Q1 2001) |
120% (2×60%) |
100% |
100% |
80% (2×40%) |
0% |
| B-C (Q2 2001 onwards) |
120% (2×60%) |
100% |
100% |
80% (40%+ 30%+10%) |
20% (2×10%) |
| B–D |
|
100% |
|
100% |
|
| B–E |
|
100% |
|
200% (2 x 100%) |
100% |
| C–D |
|
|
100% |
100% |
|
| C–E |
|
|
100% |
|
100% |
| D–E |
|
|
|
100% |
100% |
The data is linked to multiplier transformations which take a proportion of each service's traffic and sum it to give the total traffic for each node, and thus drive the nodes' traffic-dependent resources. Note that the Network Management resource is not replicated for each node and so is not part of the template.
Modelling the trunks
The principle behind modelling the trunks is the same as modelling the nodes, except that it is a lot simpler. A Trunks template is defined so that the elements are replicated for each trunk (see illustration below).
Replication and cost allocation
For anyone costing a metro network, although the basic network components may be largely identical in structure for each node and trunk, they must be modelled individually to capture the different traffic flows. Traditional cost models either aggregate over the entire network, or must be manually repeated for each node and trunk in order to obtain individual installation and cost results.
The Analysys framework makes it easier to structure the problem, and is robust with respect to future refinements because it exploits the powerful new template replication feature of STEM 6.2. This allows the nodes and trunks of a network to be modelled individually, based on a common template structure, without each copy having to be built – and maintained – by hand. The complexity of the actual structure is encapsulated within the instructions for replication. The operator can then readily determine the appropriate shares of the costs of each node and trunk for individual routes.
A run-time copy of this model can be downloaded on request to run on your desktop, complete with comprehensive documentation. This model can be viewed in conjunction with our standard demonstration package. Outputs can be regenerated for a limited range of inputs; prices are available on request for a fully functional model.
