Air Interface Dimensioning

The most straightforward way to
determine the required GPRS air interface capacity is to estimate the
amount of data traffic (in terms of bits/second) that a given cell will be
required to handle in the busy hour. This can be done by estimating the
number of GPRS users in the cell and estimating the usage requirements
of those users (which will be linked to handset capabilities and the commercial
agreements between users and the network operator). From this
demand estimate, we can estimate an average GPRS throughput requirement
in the busy hour. In order to allow for usage spikes within the busy
hour, it is appropriate to add an overhead of 20 to 30 percent. From this,
we can then determine the number of channels that are needed to support
that load. For example, using CS-2, a single timeslot can carry about 10
Kbps of user data.

This approach, however, does not account for the fact that a given cell
will most likely be used to support both GPRS data traffic and GSM voice
traffic. When a cell’s resources are shared between GPRS and GSM, it is
quite inefficient to independently determine GPRS and GSM resource
requirements (based on some blocking criteria) and simply add the two
together. To do so would result in over-dimensioning of the cell. The reason
for this is because voice traffic follows an Erlang distribution, which
requires that there be more channels in a cell than are used, on average, by
the voice traffic.

If, for example, we have a cell with three RF carriers and a total of 22
TCHs (one TCH for BCCH and one TCH for SDCCH/8), then at 2-percent
blocking, the 22 TCHs can carry approximately 15 Erlangs. In other words,
at any given instant, we can expect 15 of the 22 TCHs to be occupied with
voice traffic, leaving seven channels available. This is not to say that voice
traffic will never use more than 15 TCHs during the busy hour—just that
there will be an average of seven TCHs available during this time. These
seven TCHs can be used for GPRS traffic. At CS-2, this corresponds to a
gross data rate on the air interface of over 90 Kbps for GPRS traffic and a
usable rate of about 70 Kbps. Thus, we can accommodate an average of 70
Kbps of GPRS traffic in the cell during the busy hour without increasing
the number of RF channels. Whether this will be sufficient to accommodate the needs of the GPRS users (including any buffer for usage spikes) is
dependent upon what those needs happen to be. If it is insufficient, then
more RF capacity will need to be added. This RF capacity can be dedicated
for GPRS or can be shared between GSM and GPRS. For that matter, any
cell that supports both GSM and GPRS can be configured so that all
resources are shared or that certain resources are reserved for one service
or the other with any remaining resources shared.
This approach whereby inefficiently used GSM capacity is used by GPRS
does not necessarily tell the whole story of RF dimensioning. First, the
approach assumes that the GSM network is correctly dimensioned for voice
to begin with, which may not be the case in heavily loaded cells. Secondly,
what we have described implies an assumption that may not be true in
reality—the assumption that the GPRS busy hour and the GSM busy hour
coincide. If they do not coincide, then the approach described above will err
on the conservative side.

As of this writing, relatively few GPRS networks have been deployed
(when compared with the number of GSM networks) and relatively few
GPRS subscribers exist. Therefore, there is not a great deal of real-world
experience to draw upon. This is unfortunate as it means that real-world
rules of thumb have not yet been developed. On the other hand, it is fortunate
that we have not had to deal with a sudden explosion in the number of
GPRS subscribers. As the number of subscribers grows, we will be able to
monitor traffic patterns to see which types of transactions subscribers
require, the typical file sizes, burstiness, and so on. Such monitoring will
enable trending so that RF dimensioning decisions can be made in advance
of subscriber demands.