The Distribution and Management of Memory

As we will see in later chapters, you can build a completely new business model on
storage, particularly distributed storage. Distributed storage may even have the benefit
of being supplied and paid for by your subscribers. Storage bandwidth does however
incur management overheads. We need a memory real-time operating system to
go with the DSP real-time operating system (RTOS) and microcontroller RTOS .
Memory has to be managed at a micro and macro level. At the micro level, we have
to distribute memory in a handset close to the point of consumption—next to the DSP
and next to the microcontroller—and then optimize the partitioning of the memory to
match the tasks being undertaken.
At the macro level, we need to decide how much memory we should put in the subscriber
product and how much in the network and where. The choice is extended by
the provision of Web-based storage. The example in Table 6.5 is from Xdrive Technology’s
Web site and shows a number of options for accessing Webbased
virtual storage.

For wireless devices, this is one option for extending the apparent storage capability
of the device but with the proviso that quite a lot of processor power (battery bandwidth)
will be needed to recover files from storage and quite a lot of RF transmit power
(also battery bandwidth) will be needed to send files to storage. Remember that over
the radio physical layer, we are not particularly short of delivery bandwidth, but we
are short of power. This tends to mean that it is better to have storage in the subscriber
device rather than in the network (or in the case of Xdrive, in a network the other side
of the access network).
We are also introducing delay because of the need to use the radio physical layer to
download or upload files. Additional delays may be introduced by the network/networks
between the subscriber and the storage. Finally, the remote storage itself will
have a latency (delay and delay variability), which will be a consequence of the loading
on the server.
Virtual storage solutions define quality of service in terms of access delay, security,
and policy management. For example, Amazon identifies customers in terms of their
spending power and spending habits. This information can be stored as a cookie in
your computer. When you access the Amazon site you get privileged access to the
server if you have been identified as a big spender—a process known as virtual resource
management.
The ability to store complex content either in the subscriber appliance or the network
so that either the subscriber or the network can choose when to send or exchange
files also helps smooth out some of the peak loading experience in a network.
The ability to shift loading, for instance, from the daytime to nighttime is dependent
on the ability to store information that is not delay-sensitive. It is also dependent on having
application layer software that is sufficiently intelligent to make and take the decision
to store or send, which probably means the ability to negotiate with the network.
We are assuming that the 3G handset will be encouraging subscribers to create their
own content. If the local storage in the subscriber device becomes full, the subscriber
will want to send the file for remote storage. It would be more efficient for the network
if this were done at night. It could also be lower cost for the user. This is only an extension
of existing pricing policies, where lower cost calls can be made in the evening.

Virtual archiving, however, requires some mechanism for establishing image ownership.
We cover authentication and encryption in a later chapter, but for now, we just
need to know that we must be able to identify and sign complex content so that we can
prove that we own or at least produced the content prior to archiving. Note that we
might want to realize value from our stored images. We might also expect image value
to appreciate over a number of years. Providing authentication and encrypting files in
long-term virtual storage is a tricky proposition. What happens if we lose our authentication
key? We cannot access our files, and even if we can, we cannot decrypt them.
In 1986, the BBC spent several million pounds creating a Domesday project file. It
was the 900th anniversary of the establishment of the Domesday Book— the systematic
recording of taxable assets by William the Conqueror. The BBC decided to create a
new Domesday Book that would provide a snapshot of life in 1986 and could be available
for study 900 years later (just as the Domesday Book can be read today). Sixteen
years later the BBC discovered they had lost the source code used to store and manage
the files, and the software engineer involved had long ago left the corporation. The file
is at time of writing completely unreadable. This highlights the fact that electronic
media storage is far from dependable as a mechanism for long-term storage. (Needless
to say, after 900 years, the Domesday records—on parchment—remain in good shape.)
The Digital Preservation Coalition has a useful handbook on this topic, produced in
association with the British Library and available on www.dpconline.org.
The point about virtual storage and the purpose of digital storage is to earn money
from people who wish to store material and then retrieve material at some later date.
Once we have addressed the issues of long-term key management and long-term digital
storage stability and accessibility, the potential exists for realizing value from
image redistribution.
Some would argue that the network in the transaction is purely a dumb delivery
machine and needs to have no involvement in storage provision. This is the basis for
peer-to-peer networking in which files are exchanged directly, between users without any network interaction—the jargon word used is disintermediation. Network operators
generally do not want to be disintermediated. Napster was an early example of a company
who effectively disintermediated music distributors by setting up peer-to-peer
exchange of MPEG-3 audio files. Unfortunately, they used a central server to log
exchanges. The records from the central server could be subpoenaed, and Napster (as
a free exchange mechanism) was effectively shut down. Napster Mark IIs have
appeared, and also Aimster and Mesh, who avoid the use of a centralized server. These
companies provide a peer-to-peer exchange product, which at time of writing, appears
relatively robust to malign intervention.

Summary
We are putting into people’s hands products that can physically capture substantial
amounts of simultaneous audio and video bandwidth in four distinct ways, as shown
in Table 6.6. We can add additional text and information (via a keyboard) and can digitally
sign complex content prior to sending or storing the information. The complex
control can either be stored in the device, in the network, or on the other side of the network
(for example, a peer-to-peer exchange).
The job of the application software in the user’s handset is to manage this complex
content. This includes managing the storage requirements of the user or the user’s
device or both. The software has to have sufficient intelligence to know when
subscriber-resident, device-resident storage is about to run out and provide the option
to use virtual storage resources. Virtual storage resources, however, present some fairly
unique authentication issues.
In a traditional voice phone call, network software (using SS7 signaling) sets up a
call, maintains the call, and clears down the call. The call is then billed. In a multimedia
exchange, network software (which we describe in Part IV) sets up a session, manages
the session, and clears down the session. When virtual archiving is involved, the session
might last 1000 years or more! It is uncertain whether any electronic storage media
would be sufficiently stable, either in hardware or software terms, to provide this kind
of life span.

More prosaically, we are reliant on our application software to try and convince our
subscriber to spend more money with us. A simple exchange (SMS or voice) needs to
be upgraded into a complex exchange of time-sensitive rich media files. This includes
bringing multiple participants into a session. It is the job of the software in the handset
to increase session persistency, session complexity, and session value.
In 2000/2001, Sony started a global advertising campaign called “Go Create.”
Essentially, Sony is trying to change the consumer appliance into a creative appliance.
(The consumer electronics industry becomes the creative electronics industry.) Consumption
is a passive (and ultimately lackluster) pastime. When we create something,
such as a media file, our natural inclination is to share our creation with other people—
a sort of egocentric rather than network-centric value proposition.
All this suggests the need for an integrated storage management and delivery management
real-time operating system. In wireless, this RTOS needs to take into account
the qualities (for example, inconsistencies) of the radio channel. In a wireless IP network,
the RTOS needs to take into account the qualities (for example, delay and delay
variability) of the IP network.
In Chapter 20, “Network Software Evolution,” we discuss Sun’s Java-based storage
network operating system, called Jiro. Such an operating system needs to interact with
the OS in the subscriber handset. In other words, we need to integrate radio bandwidth,
network bandwidth, and storage bandwidth performance in order to deliver a
consistent and predictable end-to-end user experience. This is a subject that we will
revisit in substantial detail. 167