Meeting the Costs of Delivery

If we improve any of these quality metrics—frame rate, resolution, color depth—cost
of delivery increases. The issue is whether tariff premiums can increase faster than the
cost of delivery (see Figure 14.4). It is also difficult to calculate the real cost of delivery.
If we are working with conversational services, we can assume there is no buffering,
and there is a direct interrelationship between the application bit rate and radio and
network bandwidth occupation.
However, interactive, streamed, and background all use buffering. Do we also cost in
buffer occupancy as a part of the delivery cost budget? Consider: Auser has a 10-Mbyte
file to send. He is given the choice of sending the file in 5 seconds, 5 minutes, or 50 minutes.
Now this could mean either the file takes 5 seconds, 5 minutes, or 50 minutes
to send, or the network could guarantee that the file would be sent within 5 seconds,
5 minutes, or 50 minutes; that is, the network can make the decision to use a high bandwidth
channel for a short period of time or a low bandwidth channel for a long period of
time, as long as the overall time taken meets the user’s agreed time limit.
The tighter the time constraint, the more priority needs to be given to the traffic
stream and, implicitly, the more it will cost to send. However, sending the file more
slowly occupies buffer bandwidth. If this buffer bandwidth is memory bandwidth the
customer has paid for (that is, buffer bandwidth in the handset), then it might be
argued that this bandwidth has a nil cost to the operator (unless he decided to subsidize
handsets with extra memory, in which case, it would be a real cost).
You might also argue that sending the file in 5 seconds rather than 5 minutes actually
uses less network resource and therefore costs less. From a user’s perspective,
faster probably represents higher value, but if some users pay for the 5-minute service
and get the 5-second service, because the network had instant bandwidth available,
then the user paying a premium price for the 5-second service will be upset. Also, the
elapsed session time (that is, the promised delivery time and the actual delivery time)
needs to be monitored and measured by the network to provide the basis for
a time = quality, time = money based billing metric.
Going back to time-based billing might be regarded as a backward step. Billing by
the number of bits sent is now a well-established principle. Figure 14.5 shows the way
a session might progress. The handset is supported in a steady-state condition of
“always on” connectivity. Charges are based on the volume of data transmitted. For
much of the time, no data is transmitted, so no charges are incurred. The offered traffic
loading from the session is spasmodic and the file size exchanges are usually small—a
few kilobytes, for example.
However, as color handsets have become available (typically with 65,000-color displays),
and as CCD or CMOS imaging have been introduced, file size has become
larger. As file sizes increase, it makes sense to give the user the option of send or receive
at a faster or slower rate. The application provides a fast load or slow load option. The
user pays a premium for priority.

Here we have argued that we can charge more for sending something sooner (not
necessarily faster in terms of bit rate, but sooner in terms of elapsed time). The time
saving comes from not using buffering. We have also argued that it has cost us less to
send! Buffer bandwidth is expensive bandwidth and becomes more expensive as
offered traffic becomes more bursty.
We are trying to get away from the “always on, sometimes sending” model to a
“sometimes on, always sending model.” When a session is in progress, we want to
increase the data duty cycle. 349