Data Usage Forecast

As mentioned, we need to address the various categories of data users and
forecast for each user type and the amount of data throughput. We also
need to forecast where the throughput begins and ends. If for example a
given user has Web browsing service plus operator provided e-mail, then a certain amount of traffic will terminate on an e-mail server within the operator’s
network, while a certain amount of traffic will be sent to and from the
Internet. The dimensioning of the interfaces to the e-mail system and to the
Internet will depend on the amount of traffic related to those services.
Moreover, the e-mail system will need to be dimensioned to meet requirements
for total number of users, total storage, and total traffic in and out.
For each type of user and data service, we perform a similar analysis to
determine busy-hour usage.We assume, for example, a certain amount of
usage during work days and a certain percentage in the busy hour. From
this we calculate the average throughput per user and per type of service in
the busy hour. This throughput should be calculated in bps, and the
uplink/downlink split should be specified. For most services, we will find
that the downlink traffic is far greater than the uplink traffic with an 80
percent/20 percent split being common. Once we have determined the busyhour
usage, we need to add some buffer to allow for burstiness or peaks
within the busy hour. The amount of buffer to be added will depend on the
amount of build-ahead factored into the network design. If for example
there is already a build-ahead of 12 months, then the system will be purposely
over dimensioned at the beginning, in which case a further buffer
would be wasteful. On the other hand, if little build-ahead has been factored
in, then a 25 percent buffer for data traffic peaks could well be appropriate.
It should be noted that the busy hour for voice traffic and the busy hour
for data traffic might not coincide. Given that for many network technologies,
different core network nodes are used for voice and data, whether the
two busy hours happen to be the same will often not be an issue for network
node dimensioning. For example, in 3GPP Release 1999, voice traffic is handled
by an MSC and data traffic by an SGSN. Similarly, in CDMA 2000,
voice traffic is handled by an MSC and data traffic is handled by a PDSN.
Therefore, for dimensioning of an SGSN or PDSN, whether the voice busy
hour is coincident with the data busy hour is of no consequence.
The same cannot be said for the access network, however. Nor can the
same necessarily be said for the backbone transport network. On the access
network, for example, the capacity of a BSC or Radio Network Controller
(RNC) will be determined both by the voice usage and the data usage. In the
core network backbone, we may wish to use VoIP (such as with 3GPP
Release 4), in which case the backbone network will carry both voice and
packet data, in which the issue of coincident busy hours is important. Until
experience tells us otherwise, it is wise to assume the worst case—that is,
that the voice busy hour and data busy hour are coincident. 415