Experimental Study
This
section introduces an experimental study we have conducted in order to
assess the effectiveness of our proposed musical services. We carried
out several experiments (about 4000) consisting in the download of
either a set of MP3-type songs or a set of different karaoke clips,
according to the selected service. During the experimentation of the
song-on-demand distribution service, four different replicated Web
servers were exploited at the Internet side as song repositories, which
were dispersed throughout the world; for the mobile karaoke service, we
used three different replica servers that were located within a
metropolitan scenario.
The communication between the IS and the mobile client
was simulated by means of an UMTS simulator which was able to produce
the transmission delay time of each frame at the UMTS radio link layer.
Detailed information concerning the experimental models we adopted for
our experiments are discussed in the following sections.
24.4.1 UMTS Simulation Model
Currently, no real measurements of UMTS wireless
data are available; hence, in our experiments the communication between
the IS system (on the Internet side) and the mobile client application
was carried out through a simulated UMTS network (running the
background traffic class). To this aim, a UMTS simulator provided by
the Fondazione Marconi (an Italian public foundation for wireless
computing) was exploited. The UMTS network simulator we used was able
to return Wireless Network Transmission Time (WNTT) values after
simulations, i.e., the time spent to download musical resources, as
computed at the UMTS radio link control (RLC) layer.
The simulated transmission of an IP packet over an air interface is illustrated in Figure 24.7.
The RLC layer received a PDCP frame composed of an IP data packet to
which various headers were added for each different level of the
protocol stack (indeed, the PDCP layer was not simulated, for the sake
of simplicity).
We conducted experiments with IP packets of different
sizes (160, 480, and 960 bytes) coming from the Internet. The resulting
PDCP frames were then segmented into RLC data blocks, each of which was
36 bytes. The result of this segmentation activity at the RLC level was
that 5, 15, and 30 RLC data blocks were needed to transmit IP packets
with the dimensions of 160, 480, and 960 bytes, respectively. In
summary, if the transmission slot was available, 10, 30, and 60
milliseconds were needed to transmit over the air interface IP packets
with the dimensions of 160, 480, and 960 bytes, respectively. It goes
without saying that the obtained WNTT values depended on some
operational parameters, such as the amount of traffic present in the
simulated cell, the number of active clients and their speeds. WNTT
measurements included the time spent for possible retransmissions at
the RLC level.
The main problem that derives from adopting an approach
where simulated results for RLC frames (traveling over the wireless
link) are combined with the real measurements obtained for the TCP
segments (traveling over the wired Internet) is that segment errors and
resulting retransmissions at the TCP level are not taken into account.
To circumvent this problem, our experiments included
the possible retransmission time delays incurred at the TCP level
obtained by exploiting an external delay management mechanism. This
external delay management mechanism was designed to take into account
the typical TCP error recovery method based on received ACKs. Simply
put, the delay mechanism compared the WNTT values obtained through the
UMTS simulation against the time out values computed by TCP. If the
simulated WNTT value was larger than the correspondent TCP time out
value, then a retransmission must have occurred at the TCP level. In
such a case, the WNTT value of that particular TCP segment was
augmented by an additional value chosen as equal to the next WNTT value
extracted from the set of the UMTS-based simulated values.
Consequently, the TCP time out value was updated as follows: If a
retransmission at the TCP level was detected according to the method
mentioned previously, then the subsequent TCP time out value was
calculated as the double of the previously computed value. If no
retransmission at the TCP level was detected, then the traditional
adaptive formula for the calculation of the TCP timeout value, as
proposed by Jacobson, was followed. [20]
The next section
presents the two different measurement architectures (along with
obtained results) we adopted on the Internet side to evaluate the
song-on-demand distribution service and the mobile karaoke service we
have implemented.
24.4.2 Song-on-Demand: Measurement Architecture and Results
To evaluate the efficacy of the song-on-demand
distribution service we have developed, we used four different Web
servers, geographically distributed over the Internet, providing the
same set of 40 different songs. The four replica servers were located
in Finland, Japan, the United States, and New Zealand (see Figure 24.8).
Our designed intermediate system, located in Bologna, Italy, was
running over a Pentium 3 machine (667 MHz, 254 MB RAM) equipped with
the Windows 2000 Server operating system. The UMTS device, on which the
client of our application was running, was emulated by means of a
Pentium 2 computer (266 MHz, 128 MB RAM) equipped with the Windows CE
operating system.
In order to provide the reader with an approximate idea
of the transmission times experienced over the considered Internet
links, it is worth mentioning that the round trip times (RTTs),
obtained with the ping routine, between the client and the four servers
measured 70 (Finland), 393 (Japan), 145 (United States) and 491 (New
Zealand) milliseconds. As far as the downloading process is concerned,
we took two basic assumptions:
-
MP3 file dimension: In our experiments we used 40
different MP3-based songs, whose corresponding file dimension ranged
from 3 to 5 MB, which corresponds to the average file dimension of the
songs maintained in the Napster system.
-
Number of downloads activities: Our software
application provides support to two different types of song download
services, the first consisting of downloading a single song, the other
consisting of downloading a complete
set of songs (song compilation). To evaluate the performance of our
system under both circumstances, we conducted the following experiments:
-
A set of independently replicated experiments consisting in the download of single songs.
-
A set of independently replicated experiments,
with each one consisting of the download of a set of songs. The number
of songs for each compilation ranged in the set of 3, 5, and 10. These
three values were chosen based on the consideration that the average
disk capacity of typical MP3 players never exceeds 50 MB.
For the sake of brevity, in this chapter we only report
the results obtained for the download of single songs. If interested,
you may refer to the work of Roccetti and cowokers [21], [22] for further details on the results we obtained when song compilations were downloaded.
In the following, we report on a large set of results
obtained during many experimental trials based on the previously
mentioned models.
In particular, we begin by presenting the measurements
we obtained for our wireless application on the Internet side. In
essence, Wireline Network Transmission Time
(WLNTT) values refer to the time spent over the wired Internet links to
download a requested song from the replicated Web servers toward the IS
on the Internet side. These measurements have been compared with those
that may be obtained by downloading the same MP3-based song with a
standard HTTP GET method. The first row of Table 24.1
reports those results for MP3 files whose size is 5 MB. The second row
shows the average WLNTT percentage improvement obtained by our system
that exploits the previously mentioned C2LD mechanism, with
respect to the standard HTTP protocol. As shown in the table, our
system obtains an average percentage improvement over the fastest HTTP
replica, which is equal to 32 percent.
Table 24.1: Song-On-Demand WLNTT Results
| |
|
C2LD (4 Servers) |
HTTP |
| |
|
Finland |
USA |
Japan |
New Zealand |
|
Download time (seconds) |
32.547 |
47.889 |
122.191 |
248.740 |
624.195 |
|
C2LD improvement (percent) |
— |
32 |
73.4 |
86.9 |
94.7 |
As already mentioned, Wireless Network Transmission
Time (WNTT) values refer to the time spent for downloading songs to the
mobile devices through the wireless links. (It is worth remembering
that these values have been obtained through UMTS simulations.) Figures 24.9 and 24.10 show the WNTT values for 5 MB- and 3 MB-sized songs, depending on the following traffic parameters:
-
The speed at which users move throughout the cell (expressed in km/h)
-
The additional traffic in the cell (expressed via Erlang values)
In addition, it is worth noting that the WNTT
values we have plotted have been obtained by averaging all the
experiments conducted with IP packets of different dimensions (i.e.,
160, 480, and 960 bytes). The main considerations that derive from an
analysis of the results presented in Figures 24.9 and 24.10
are (1) the larger the traffic in the cell (and the users' speed), the
larger the corresponding WNTT values, and (2) the best WNTT result may
be obtained when the mobile device is completely still. (In such a
case, a data rate of about 12 KBps may be obtained.) Additionally, it
is worth noting the impact that the download time values, obtained on
the Internet side, have on the total time requested to download songs
on UMTS terminals. The obtained average download delays on the Internet
side (about 33 seconds) seem to be quite irrelevant if compared with
the WNTT values that have been experienced on the wireless links
(ranging from 250 to 1325 seconds, i.e., from about 4 to 22 minutes).
This optimal result on the Internet side is probably due to the use of
the adopted Web replication technology along with the use of our
distribution mechanism (C2LD). Note that if we try to
download songs from a single Web server (such as the New Zealand Web
server) with the standard HTTP, this can lead to an increase of the
WLNTT value by about 600 seconds (10 minutes).
24.4.3 Mobile Karaoke: Measurement Architecture and Results
To evaluate the efficacy of the mobile karaoke
distribution service we have implemented, three different Web replica
servers were used. They all maintained the same set of karaoke clips,
along with the associated multimedia resources. As shown in the small
picture of Figure 24.8,
out of these three Web servers, two were located on the same LAN at the
Department of Computer Science of the University of Bologna (a 100-Mbps
Ethernet). The third server and the IS system were deployed on a
different 100-Mbps Ethernet LAN, located at a remote site of the
University of Bologna (the Computer Science Laboratory of Cesena). The
two LANs were approximately 10 hops each from other, interconnected
through a 34-Mbps link. The
IS application was running over a Pentium 3 machine (800 MHz, 512 MB
RAM) equipped with the Windows 2000 Professional operating system.
Finally, the client side of our mobile application was emulated on a
Pentium 3 machine (667 MHz, 512 MB RAM) equipped with the Microsoft
Pocket PC operating system emulator. (It is worth mentioning that the
round trip times, obtained with the ping routine, between the emulated
client and the three Web servers measured about 10 milliseconds on
average.)
As far as the downloading process is concerned, we took the following basic assumptions:
-
SMIL files: We used SMIL files with dimensions
ranging from 3 to 4 kb. SMIL files of such dimensions are typically
large enough to specify complete karaoke clips.
-
Multimedia resources: SMIL files were used which
typically pointed to two different multimedia objects: (1) a WMA
(Windows Media Audio) file, and (2) a WMV (Windows Media Video) file.
For audio files, we used a set of WMA files with dimensions ranging
from approximately 1.5 to 2.0 MB, corresponding to songs sampled at 64
kbps (and lasting approximately from 3.5 to 4 minutes). For video
files, we used WMV video clips lasting approximately 30 seconds, with a
quality needing a data rate of 190 kbps, thus yielding file dimensions
ranging from 750 to 850 kb. As previously explained, the execution of
audio and video resources were synchronized (along with textual
information) by using SMIL commands. In the case when an audio file had
a duration longer than the video file, the execution of the video file
was scheduled to be repeated through the conclusion of the music file.
As far as the obtained results are concerned, the first
consideration is the time spent over the wired links to download
karaoke clips from the replicated Web servers toward the IS (i.e.,
WLNTT results). Those WLNTT results amounted to quite small values.
Indeed, 0.2 seconds on average were needed to download the SMIL files,
while 5/6 seconds on average were measured to download the
corresponding multimedia objects.
Much-larger values were measured for the WNTT results
experienced over the wireless link. As in the case of simple song
distribution, those measurements were taken depending on the two
traffic parameters: (1) the speed at which users moved through the
cell, and (2) the additional traffic in the cell.
The WNTT values needed for delivering SMIL files to the
mobile device were as much as 1 second on average. Instead, as the
example in Figure 24.11
shows, the WNTT values are reported that were measured to deliver over
the wireless link the multimedia resources of two different karaoke
clips, respectively: "Losing My Religion" by REM (hereinafter referred
to as song 1) and "A Little Respect" by Wheatus (hereinafter referred
to as song 2). In particular, song 1 was comprised of a WMA audio file
of 2.15 MB and a WMV video file of 765 kb; song 2 was comprised of a
WMA audio file of 1.6 MB and a WMV video file of 850 kb. Figure 24.11 presents three different graphs for each song, with each graph plotted for a different Erlang value.
In each graph, the WNTT values needed to deliver the audio and the
video files are presented separately, through two different curves.
Each curve varies depending on the user speed. (Again, it is worth
noting that the WNTT values we plotted were obtained by averaging all
the experiments conducted with IP packets of different dimensions.)
As in the case of simple song distribution, it is easy
to notice that (1) as the traffic in the cell increases, the
corresponding WNTT values increase, and (2) the lowest WNTT results may
be obtained when the mobile device is still. In addition, the karaoke
clip for song 1 was available at the handheld device after an average
time interval ranging from about 3.5 to 9.5 minutes (220 to 570
seconds), while the karaoke clip for song 2 was delivered to the UMTS
device after an average time interval ranging from about 3 to 8 minutes
(180 to 490 seconds).
To conclude this section, it is worth noting that
the WNTT results obtained for the mobile karaoke service appear to be
better than those obtained with the song distribution service due to
the fact that in the case of mobile karaoke multimedia resources of
smaller size were exploited in the field trials. (Further details on
the field trials conducted for the mobile karaoke service may be found
in Roccetti et al. [23])
Sections
