STEM newsletter

The Monte Carlo distribution for real

01 January 2008

Network business models should take account of geographical realities such as varying customer densities and backhaul costs, but typically data is only available at an aggregate level in the early stages of business planning. This refresher article illustrates how STEM can make a realistic allowance for slack equipment capacity across a distributed network, how it can perform a site-by-site calculation when the data becomes available without your head exploding, and how the overall results typically compare.

Matching installed equipment capacity to total subscriber demand

To illustrate this article, we are going to look at the business model for a new ISP which aims to deploy its own DSLAMs across multiple exchange sites under one of the now common local-loop unbundling (LLU) regimes. Although the full business model would consider a detailed service portfolio in order to forecast the aggregation of voice and data traffic, we are just going to focus on the number of required ports on a DSLAM at any given site.

The business model will run for five years from 2008–12, and STEM will generate the results in quarters throughout. For the prototype site, we assume an addressable market of 5000 households, and model penetration as an S-curve increasing towards a saturation of 25% market share, i.e. around 1250 subscribers by Q4 2012.

We assume that the new operator will buy and deploy equipment capacity in units of full shelves of 480 ports (= 20 cards per shelf × 24 ports per card), and that a single DSLAM can accommodate up to four shelves = 1920 ports.

This results in an initial deployment of one shelf for service launch in Q1 2008, and then the second and third shelves being added as the demand increases. How quickly this happens depends on the overall subscriber growth rate. STEM matches the installed equipment capacity to the total demand from subscribers automatically. Notice the blue line on the chart below showing the slack capacity, which varies in the range 0–497 ports, peaking immediately after the installation of a new shelf.

Service demand and installed equipment capacity

Usually we would use a maximum utilisation constraint to cause the second shelf to be installed before 100% utilisation of the first shelf is achieved, matching what the operator’s technical staff would do in practice. However, this is equivalent to working with a smaller unit capacity, and the issue is disregarded in this model to keep things simple.

Allowing for slack equipment capacity across a distributed network

Of course, modelling demand at just one site is not very challenging: the complexity arises from varying characteristics across multiple sites, and the interconnections between them. Now we will extend the model to consider nine sites as a clear illustration of principles which could be applied equally well to 90 sites. In fact the point of this article is to show how you can readily calculate perfectly ‘good enough’ results for an unlimited number of sites without having to model them individually. STEM’s built-in deployment feature allows you to express the fact that a single demand is spread over one or more physically separate sites: in this case, local exchange sites in different towns.

The initial model was already structured to link the size of the market to the number of sites, by combining a formula in the Market element with an assumption for the average number of households per site. So increasing the number of sites from one to nine will automatically increase the addressable market to 45 000. However, without an awareness of the geography, STEM would only install one DSLAM at service launch, and would only ever install a maximum of 497 free ports. Instead, each site requires its own DSLAM and, at any point in time, there will be up to 497 free ports at each site.

Used and installed equipment capacities

The deployment feature provides this awareness, and offers various alternative distribution models for the spread of demand across those sites. The most generally useful is the so-called Extended Monte Carlo distribution, which guarantees at least one unit per site, and assumes an average of half a unit of slack capacity (240 ports) at each site (even though the numbers will vary per site in practice). If you think about it, this is a reasonable assumption in the absence of much more detailed data, and captures a significant overhead cost (compared to the minimum installation) which is sometimes neglected in hasty business plans.

Extended Monte Carlo deployment

For both the DSL shelf and the DSLAM chassis itself, the evident effect is that additional units must be installed long before 100% utilisation is reached. This is because, across the sites in real life, there will be varying numbers of potential households and different penetration rates, and some sites will reach 100% penetration long before others do.

The remainder of this article demonstrates how you could progress to modelling the sites individually if the detailed data were available, and how the installation results compare.

Performing a manageable site-by-site calculation

Suppose we do have access to specific market size data on a per-site level, and possibly even different penetration growth curves. Although we could run the model over and over for each site in turn, this would not be very practical for a detailed scenario or sensitivity analysis, nor would it give you results for the network business as a whole.

This is why STEM provides a template replication feature which allows you to repeat the same model structure many times within one model without having to manually replicate any of the model structure. First you group the elements in question as a template, and then you identify the inputs within that template which should vary by site. STEM automatically creates a table with one row per input and one column per site, and allows you to just type in the varying values without repeating the entire calculation structure, ensuring consistency of calculation and results across all sites.

Template elements and variant data

Although manual replication is feasible with STEM’s intelligent copy-and-paste function, this approach is labour intensive, subject to user error, and does not help much if you want to add something to the calculation structure later. In contrast, template replication allows you to identify template elements which will then be replicated automatically whenever you re-run the model. This means that any new structure added to the template will be automatically propagated across all sites.

Detailed and consistent results are generated for each individual site, as well as for the network as whole. When you proceed to add scenarios or sensitivities, you are guaranteed that these will impact equally on all sites. The further you go with this sort of analysis, the harder it gets to keep everything consistent in a spreadsheet, whereas STEM is purpose-built with this kind of process automation in mind.

Template elements and variant data

Comparing the overall results with linear or normal demand distribution

The simplest use of this approach is to use a linear range of market sizes for the various sites varying in the range 3000–7000 inclusive in steps of 500:

Linear and normal demand distributions

Or if we want to be more sophisticated, we can use an approximately normal distribution, so that more of the sites are clustered towards the mean. This is an interesting exercise in Excel (and in fact the numbers shown above are linked directly from Excel into STEM), but as you will see from the charts below, it makes very little difference to the overall results – no more than the impact of timing at the site level.

Comparison with explicit linear and normal distributions

So the impact on the results of doing a very precise, site-level model is rather slight compared to the significant difference between the ‘minimum’ results and those factoring in the deployment, at least for the DSL shelf element. (The DSLAM results deviate more because the utilisation is still critically low.)

STEM 7.1 consistently prompts you to consider equipment deployment, as it is listed as a key feature in the top section of the Resource icon menu, and this is because it can be such an important (and sometimes dominant) factor when dimensioning a network.

© Implied Logic Limited