24.4 An Experimental Study

24.4 An 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).

Figure 24.7: Segmentation of an IP packet into RLC data blocks.

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.

Figure 24.8: Web server replicas and clients (big picture— song-on-demand; small picture— mobile karaoke).

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:

1. 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.

2. 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 C²LD 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:

1. The speed at which users move throughout the cell (expressed in km/h)

2. The additional traffic in the cell (expressed via Erlang values)

Figure 24.9: Song-on-demand WNTT results for 5-MB-sized songs.

Figure 24.10: Song-on-demand WNTT results for 3-MB-sized songs.

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 (C²LD). 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:

1. 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.

2. 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.)

Figure 24.11: Mobile karaoke WNTT measurements for delivering song 1 (upper graphs) and song 2 (lower graphs).

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])

^[20]Jacobson, V., Berkeley TCP evolution from 4.3-Tahoe to 4.3-Reno2, in Proc. 18th Internet Engineering Task Force Meeting, University of British Columbia, Vancouver, 1990, 365.

^[21]Roccetti, M., Ghini, V., and Salomoni, P., Distributing music from IP networks to UMTS terminals: an experimental study, in Proc. 2002 SCS EUROMEDIA Conference, Roccetti, M., Ed., The Society for Modeling and Simulation International, Modena, 2002, 147–154.

^[22]Roccetti, M. et al., Bringing the wireless Internet to UMTS devices: a case study with music distribution, to appear in the International Journal of Multimedia Tools and Applications, Kluwer, 2003.

^[23]Roccetti, M. et al., MoKa: a wireless Internet application for delivering mobile karaoke on UMTS devices, in Proc. IASTED International Conference on Communications, Internet and Information Technology, M.H. Hamza, Ed., St. Thomas, VI, November 2002, pp. 346–351.