06 May 2011

Best practice – by definition – constantly evolves, and so do training methods.

Lately we have had some feedback to the effect that the ready-built scenario model for our WiMAX-DSL training course was too much too soon, and that it would be easier to start with something simpler, in order to gain the basic principles before rushing on to something (the current model) which showcases STEM’s power more comprehensively.

Therefore, a number of ‘blank sheet’ exercises, designed to foster an early intuition for the STEM paradigm, have been improvised in recent training assignments, and are now being drafted into our regular training guide. To avoid any preconceptions and distractions, these exercises are based intentionally on topics outside of telecoms, albeit communications in the transport sense.

Imagine a school with *n* pupils, *x*% of which live far enough away to
require transport by a school bus with a maximum capacity of 50 seats (not including
the driver). How many buses do you need, and if the school population is growing,
when might you need to buy an extra bus?

This is the archetypal STEM problem which could be represented as simply one service element (how many children need rides?) and one resource element (how many children per bus?). However, we will choose to structure this more conventionally with a market segment element for the school population in case we decide to model the provision of school lunches to a different subset later. (We will assume that reasonable routes to school can be found to fill the buses as efficiently as possible. The harder problem of multiple buses driving simultaneously to multiple schools is examined later).

Taking *n* as 300 and *x* as 30, then you would create a STEM model like
this, and it would immediately calculate that 2 buses are required:

If the population was growing at 5% p.a., then STEM would ‘install’ the next bus after 3 years. If each bus has an operational lifetime of ten years, costs EUR60,000 to buy, EUR4800 p.a. to maintain and EUR5000 p.a. to operate, then STEM would also tell you the cost of subsidising the service. (You might want to model the driver too.)

Consider a local education authority with responsibility for 10 schools, with a total population of 3000 (and the same 30% requiring a bus to school). Simply bumping up the numbers won’t do, as you would conclude that 18 (= 900/50) fully-occupied buses would suffice; whereas any one school in the original example would actually have had ten seats spare across two buses. We would prefer not to run the model ten times to get (close to) the right result. Cue the location element, a concise way to express the fact that demand is distributed in more than one place. As a general rule, geography has two impacts:

- it ensures that every school with children has at least one bus (consider what you might calculate if the total population was only 300 across 10 schools, back to requiring a total of 90 seats); and
- it ensures that a suitable allowance is made for those unoccupied seats at each separate school.

Remember also that there will be a natural variance in bus-ride numbers (or in spare seats, depending on how you look at it), making it unlikely that you would achieve 90% occupancy on every school bus.

In the STEM model, plug in a location element, with sites set to 10 schools, and
linked to the resource with distribution set to Monte Carlo^{1}, and then
look at the results.

Not only do we get back to (at least) two buses (ten spare seats) per school, but in fact we find we need 23 buses at the start. Some of the schools have sufficiently more than 90 pupils to require another bus (and more will exceed 100 pupils than might fall below 50). Then plug in the 5% p.a. growth and watch the results.

The next logical step in this progression is to use template replication to model the actual school numbers, one by one, and we will do this live at the User Group in October. For now, we turn our attention from per-customer dimensioning (implicit in the common school arrival time) to traffic loading in terms of actual concurrent usage. For this aspect we imagine a fleet of taxis.

Imagine a town with a population of 10,000 and, for the sake of argument, all town dwellers using the taxi service for an average of 30 minutes per week, with no particular bias between weekdays and the weekend. If 20% of the daily taxi demand fell in the morning rush hour, then how many taxis would you need to provide a good service?

Again, this is a classic STEM service description, where you could have a market segment element of 10,000 people and a service with 30 × 365/7 ‘Taxi Minutes’ per person to calculate the ‘rush-hour traffic’ in ‘Taxi Erlangs’. In plain English, this would mean how many simultaneous taxi journeys on average during the busiest hour? (For simplicity, assume all taxis are occupied by a single person.)

Naturally one would expect some variance amid the usage during that busy hour, and
therefore STEM is pre-programmed with an Erlang B function to calculate how many
taxis you would need (average plus some overhead) to achieve a better than *x*%
probability of all taxis being taken when you need one (‘blocking’).
Create a transformation, change the type to Erlang B, and choose a Grade of Service
(GoS) of 1% (0.01).

You could expand this to cover say 15 similar but quite separate towns by bumping up the numbers. With an effective capacity of 1 passenger you would not need to worry about spare seats. However, it would still be the case that a taxi in town A would not be available to give a ride in town B. So the averaging effect to achieve the 1% GoS should consider only a population of 10,000 per town, not 150,000 all together balancing some of the peaks. Fortunately the Erlang B transformation allows you to specify a number of sites (inferred from a location element) to capture this disaggregated overhead effect.

As a further exercise, you might like to turn this into a template in order to model several categories, say of big, medium and tiny towns.

These simple exercises are an effective way to gain a quick grasp of fundamental STEM calculations and illustrate the generality of the methodology which may be applied to many other sectors outside telecommunications.

^{1} If you don’t know what the Monte Carlo distribution is (not the
same as a Monte Carlo walk), then you would probably benefit from one of our training
courses, or at least to join the audience participation at the User Group.

© Implied Logic Limited