Network Factors

Let’s look at WAP as an example of the demerits of unnecessary and unneeded mediation.
Figure 8.4 describes some of the network components in a present GSM network
with a wireless LAN access point supporting Dynamic Host Configuration Protocol, or
DHCP (the ability to configure and reconfigure IPv4 addresses), a Web server, a router,
and a firewall. The radio bearers shown are either existing GSM, high-speed circuitswitched
data (HSCSD)—circuit-switched GSM but using multiple time slots per user
on the radio physical layer— or GPRS/EDGE.
The WAP gateway is then added. This takes all the rich content from the Web server
and strips out all the good bits—color graphics, video clips, or anything remotely difficult
to deal with. The castrated content is then sent on for forward delivery via a
billing system that makes sure users are billed for having their content destroyed. The
content is then moved out to the base station for delivery to the handset.

The problem with this is verification delay. There is not much point in standing in
front of a vending machine and having to wait for 2 minutes while your right to buy is
verified and sent to the machine. It is much easier and faster to put in some cash and
collect the can.
There is also a specification for a wireless datagram (WDP). Because the radio layer
is isochronous (packets arrive in the same order they were sent), you do not need individual
packet headers (whose role in life is to manage out-of-order packet delivery).
This reduces some of the Physical layer overhead, though whether this most likely
marginal gain is worth the additional processing involved is open to debate.
Work items listed for WAP include integration with MExE, including a standardized
approach to Java applet management, end-to-end compression encryption and
authentication standards, multicasting, and quality of service for multiple parallel
bearers. Some of the work items assume that existing IETF protocols are nonoptimum
for wireless network deployment and must be modified.
As with content, we would argue it is better to leave well enough alone. Don’t change
the protocols; sort out the network instead. Sorting out the network means finding an
effective way of matching the QoS requirements of the application to network quality of
service. This is made more complex because of the need to support multiple per-user
QoS streams and security contexts. QoS requirements may also change as a session progresses,
and network limitations may change as a session progresses.
As content and applications change then, it can be assumed new software will need to
be downloaded into base stations, handsets, and other parts of the network. Some hardware
reconfiguration may also be possible. Changing the network in response to changes
in the content form factor is infinitely preferable to changing the content in response to
network constraints. Reconfiguration does, however, imply the need to do device verification
and authentication of bit streams used to download change instructions.
The Software Defined Radio (SDR) Forum (www.sdrforum.org) is one body
addressing the security and authentication issues of remote reconfiguration.

Summary
In earlier chapters, we described how the radio physical layer was becoming more
flexible—able to adapt to rapid and relatively large changes in data rate. We described
also how multiple parallel channel streams can be supported, each with its own quality
of service properties. The idea is that the Physical layer can be responsive to the Application
layer. One of the jobs of the Application layer is to manage complex content—
the simultaneous delivery of wideband audio, image, and video products.
Traditionally, the wireless industry has striven to simplify complex content so it is
easier to send, both across a radio air interface and through a radio network. Simplifying
complex content reduces content value. It is better, therefore, to provide sufficient
adaptability over the radio and network interface to allow the network to adapt to the
content, rather than adapt the content to the network.

This means that handset hardware and software also needs to be adaptable and
have sufficient dynamic range (for example, display and display driver bandwidth
and audio bandwidth) to process wideband content (the rich media mix). In turn this
implies that a user or device has a certain right of access to a certain bandwidth quantity
and bandwidth quality, which then forms the basis of a quality of service profile
that includes access and policy rights.
Given that thousands of subscribers are simultaneously sending and receiving complex
content, it becomes necessary to police and regulate access rights to network
resources. As we will see in later chapters, network resources are a product of the
bandwidth available and the impact of traffic-shaping protocols on traffic flow and
traffic prioritization.
Radio resources can be regarded as part of the network resource. Radio resources
are allocated by the MAC layer (also known as the data link layer, or Layer 2). The
radio resources are provided by Layer 1—the Physical layer. MExE sets out to standardize
how the Application layer talks to the Physical layer via the intermediate layers.
This includes how hardware talks to hardware and how software talks to software
up and down the protocol stack.
The increasing diversity of device (handset) hardware and software form factor and
functionality creates a problem of device/application compatibility. Life would be
much easier (and more efficient) if a de facto dominant handset hardware and software
standard could emerge. This implies a common denominator handset hardware and
software platform that can talk via a common denominator network hardware and
software platform to other common denominator handset hardware/software platforms.
It is worthwhile to differentiate application compatibility and content compatibility.
Applications include content that might consist of audio, image, video, or data. Either
the application can state its bandwidth (quantity or quality) requirements or the content
can state its requirements (via the Application layer software). This is sometimes
described as declarative content—content that can declare its QoS needs. When this is
tied into an IP-routed network, the network is sometimes described as a content-driven
switched network.
An example of a content-driven switching standard is MEGACO—the media gateway
control standard (produced by the IETF), which addresses the remote control of
session-aware or connection aware devices (for instance, an ATM device). MEGACO
identifies the properties of streams entering or leaving the media gateway and the
properties of the termination device—buffer size, display, and any ephemeral, shortlived
attributes of the content that need to be accommodated including particular
session-based security contexts. MEGACO shares many of the same objectives as
MExE, and as we will see in later chapters, points the way to future content-driven
admission control topologies.
Many useful lessons have been learned from deploying protocols developed to
accommodate the radio physical layer. If these protocols take away rather than add to
content value, they fail in terms of user acceptance. At time of writing, the WAP form
is being disbanded and being subsumed into the Open Mobile Alliance (OMA), which
aims to build on work done to date on protocol optimization. 197