The economics of prime time

Common Topics

Recent Articles

Utilisation figures from an ISP: The X-axis represents time (by hour), the Y-axis utilisation in mbits/s. Click to enlarge for traffic details.

In the above chart, only those users active on the service at A would actually drive an increased cost to the ISP. Usage at B and even a small amount at C would not cost the ISP a penny more. Even usage at A doesn't drive additional costs unless it triggers a step change in the backhaul capacity.

The most common way of dealing with this costing problem is to ignore it and say that everyone bears an equal share of the cost. This though is clearly unfair to the vast majority and there are some stats that I want to bring in here as an aside, which however serve to illustrate the point.

According to research by Ellacoya, five per cent of broadband users generated 45.3 per cent of traffic - while 40 per cent of users account for only 3.8 per cent of traffic. This tallies with earlier research which indicates that 10 per cent of users account for 65 per cent of traffic.

In South Korea and Japan, four per cent of users make up 75 per cent of traffic demand according to the Telco 2.0 blog. This is clearly a concentration of usage into the hands of fewer people.

As infrastructure capability grows, so the ability for a small number of individuals to dominate increases.

We need to use a method to allocate costs that balances these two extremes. On one extreme, having a situation where if you use the service for all but the peak period, you are not charged. On the other extreme we would allocate the same cost to all users regardless of the likelihood that a heavy user will be using the network at peak times more often than a light user. Contention ratios fall into the latter category and are misleading as a result.

Instead we use a 'busy hour assumption', which allows the model to take into account how users aggregate onto the shared infrastructure by taking a wider view of the peak window. Using this approach, the operator assumes how many busy hours there are to be in a week, and shares the cost equally between the number of hours. The operator then adds up how much busy hour usage a customer builds up, and allocates that cost to them. The outline is far from perfect, but it at least provides a model within which most users can be allocated a share of the cost, while taking into account the fact that usage off-peak is de-facto free.

Modelling this way allows for applications to be differentiated into those that are very likely to occur during the peak window (TV), against those that occur at off peak times (patches and backups).

We base our assumption on 100 Mbps backhaul costing £1,000 per Month. Ie a cost of £10 per Mbps which is close to reality and makes the numbers easier to walk through. In our models we use 45 'busy hours' per week (Monday to Friday, 6pm to 11pm and 10am to 10pm at weekends), where internet use is concentrated. We assume that usage in these 45 hours is equal so we get a fairly low cost per hour but a wide window to forecast user behaviour. Remember that 1mbits-hour is about 450MB. So let's multiply the number of busy hours (45) in a month by number of weeks in a month (4.3) to give busy hours per month.

So you have 1 Mbps costing £10, which you are using for 195 hours per month. This gives you a cost per Mbps Hour of £0.05168 - or about 5p. 1 Mbps used for 1 hour delivers 450 Megabytes, so to get a cost per Gigabyte you take your cost per Mbps Hour and divide by 0.45. 0.05168 / 0.45 = 0.1148, so 1 Gigabyte would cost you around 11.5p Let's say Joe Bloggs is using 2GB of data a month. His cost is therefore £0.23 per month.

So what? £0.23 per month is not going to break the service provider, but consider a month's IP TV viewing. The BARB website shows this to be around 25 hours per week, fluctuating with the season and the weather.

Using the same model, if Joe Bloggs watches 25 hours of 1080p HD TV per week, he's using 448 GB of data a month. That is going to cost the service provider £51.45. Tying this back to our previous research, we stated that the cost of a two-hour, 1080p programme (a 9GB file) would be £1.07 for the backhaul. 45 busy hours results in a monthly cost of £1.03. The difference between this and the £1.07 is in the rounding.

Last year's estimated circuit cost was £12,462 per year, which we rounded in the walk through to £1,000 per month to make the numbers simpler. Re-run the equation with your backhaul circuit set back to £1,038.50 a month and you get back to £1.07.

(Of course if you have a smaller peak window, the cost goes up and vice-versa. This is the weakness of our forecast model, because if you overestimate the number of busy hours and find that your demand is very peaky you could find your costs escalating rapidly. There is a whole article in itself on peak to mean, but I will save that for another day.)

The Cost of Prime Time

In summary, the cost of delivering an hour of peak time HD TV over IP can be calculated according to the variables you choose. But what doesn't change with these assumptions is the view that the economics of HD TV over IP simply does not work. The two scenarios show our results if we use the standard 45 busy hours. The more extreme example shows a heavier concentration of peak viewing into 21 hours a week (three hours per day, say 7pm to 10pm.)

Regardless of the assumptions, we arrive at figures way in excess of what can be achieved over a broadcast platform, albeit with associated restrictions on the service. There may be niches in which such a premium for the functionality would be acceptable, but unless something changes in the way that the whole thing is organised and built, these traffic costs will mean that ISPs need to throttle demand in some way

That is The Broadband Incentive Problem. ®

Jeremy Penston is managing director of The IP Development Network founded in 2005. He was previously responsible for the strategic planning and product management of the full range of Internet and Telco products from Dial, through Broadband, Dedicated Access, Hosting,Security, Voice and VoIP services at several companies including Pipex.. A longer version of this article originally appeared on the ipdev.net blog.