STEM newsletter

Voice and data services compared

30 October 2004

STEM 7.0 introduces a variant to the profile of a service which allows for a data service to be described directly in terms of its nominal bandwidth requirement, and then for the effective peak traffic and annual traffic volume to be derived as calculated quantities. This new Peak Driven option contrasts with the established Volume Driven methodology for voice services, which derives busy-hour traffic from annual call minutes via an assumed daily traffic distribution.

Voice minutes and GPRS data

An abstract mathematical model is always easier to understand in the context of a specific example, and we shall consider two typical services provided to 1000 mobile subscribers.

Voice and GPRS data services for mobile subscribers

For both the services shown, we assume the same subscriber base, growing from 1000 (to keep the numbers simple). The number of connections for each service is calculated from a penetration assumption, which we can take as a constant 1.0 for the voice service, on the basis that all mobile subscribers regard voice as the primary handset application.

Firstly, we shall review the established traffic model for the voice service. We start with an assumed Annual Traffic per Connection, typically measured in Call Minutes. From the service provider’s perspective, this metric may be readily calculated from average billing records; for an individual subscriber, this is easily imagined as typical daily minutes multiplied by 365, or perhaps 250 for a business customer. Again, to keep the numbers simple, we shall assume 20 × 250 = 5000 Call Minutes. (Usually we would segment the subscriber base to differentiate between different calling behaviour and tariff plans.)

Thus the annual volume of minutes for the total subscriber base is 1000 × 5000 = 5 million Call Minutes. Revenue is driven by three tariffs: Connection Tariff (× New Subscribers), Rental Tariff (× average Subscribers over a period) and Usage Tariff (× Traffic Volume, calculated from average connections).

For dimensioning purposes, we need to estimate the busy-hour traffic, and this calculation takes into account assumptions for the number of Busy Days per Year and Proportion of Traffic in the Busy Hour, as well as the necessary Annual to Busy-Hour Unit Ratio in order to convert from minutes to hours. We have already assumed 250 days in the year, so with the default of 20% traffic in the busy hour, this gives us 5,000,000 / 250 × 0.2 / 60 ≈ 67 Erlangs. (Typically this needs to be fed through an Erlang B Transformation to calculate the number of circuits required to achieve a desired grade-of-service, allowing for the number of Sites over which this traffic is distributed.)

Subscribers, annual traffic and busy-hour traffic for voice

In contrast, the calculation for the GPRS data service will be Peak Driven, and we shall assume that there is a Penetration of 10% of all voice subscribers, i.e. 100 subscribers for GPRS. We start with an assumed Nominal Bandwidth per Connection, say 56kbits/s, together with a Contention Ratio which defines the effective load for dimensioning purposes. In practice this ratio may be derived from additional parameters stored in User Data. For example, we might assume that at most 20% of GPRS users will be active at any one time, even in the busy hour, and that each user’s ‘duty cycle’ might only keep the connection busy for 10% of the time.

This implies a Contention Ratio of 50, and thus a peak traffic load for all subscribers of 100 × 56kbits/s / 50 = 112kbits/s in the busy hour.

Assuming a similar distribution of traffic as for the voice service, i.e. Proportion of Traffic in Busy Hour = 0.2 over 250 Busy Days per Year, and measuring annual volume in MBytes, we would set Annual to Busy-Hour Unit Ratio = 3600 × 1000 / 8 / 2 30 ≈ 0.00042 (seconds per hour; kbits to bytes; bytes to GBytes), and then STEM will calculate the annual volume of data as 112 × 250 / 0.2 × 0.00042 ≈ 58.8 GBytes.

Subscribers, annual volume and peak rate for GPRS

The actual inputs as entered for the two services in STEM are compared below.

Achieving greater realism

The example above is deliberately contrived to keep the arithmetic simple, and also glosses over a couple of issues.

Multiple contention ratios

Firstly, the definition of a contention ratio depends very much on context. Within a single UMTS cell, a lower contention ratio may be necessary to allow for the fact that one or two subscribers may significantly tip the average if they happen to connect simultaneously. In contrast, the greater numbers of subscribers aggregating traffic in the core network means that the variance in demand will be lower there. Thus a higher contention ratio may be used in the core network.

The Contention Ratio defined within the service element should relate to the edge of the network; further efficiencies should be factored in, e.g. with a Multiplier Transformation.

Quality of service (QoS) and ‘proper’ bandwidth aggregation

If a network carries multiple packet-switched services, then simply adding contended bit-rates may overstate the required capacity by overlooking the extent to which a low-priority service may exploit dimensioning headroom provided for a higher-priority service.

VoIP traffic can be considered as having a very short window of opportunity (< 50ms) for useful delivery, whereas HTTP traffic from Web browsing may cope with up to (say) 500ms delay, and email SMTP traffic up to (say) 60s. Accordingly, with appropriate measures of tolerance for delay, tolerance of loss of capacity and mean traffic levels for these different services, it may be possible to quantify how much HTTP traffic can be carried in the ‘headroom’ provided for peaks in VoIP traffic, and similarly, some of the SMTP traffic may ‘piggy-back’ on the other two services. This will result in a leaner dimensioning model than simply adding contended bit rates.

We invite comments on these ideas, which we hope to develop in further extensions to the input parameters for service demand in a future release of STEM.

       Buy SSL

© Implied Logic Limited