BLUEMUSIC:
A MULTICHANNEL ARCHITECTURE FOR MUSIC DISTRIBUTION
Marco Furini
Department of Computer Science, University of Piemonte Orientale, Alessandria, Italy
Keywords:
Content Distribution, Digital Music, Incentive Mechanism, Bluetoothing.
Abstract:
Despite the increasing number of e-music downloads and the large use of mobile devices, the mobile music
market is slowly taking off. Prices seem to be the main burden: compared to the wired environment, a song is
twice or three times more expensive. Furthermore, mobile network transfer data rate causes the download time
to be very long. In this paper we propose Bluemusic, a multi channel architecture that couples the usage of
the mobile phone network with the free-of-charge communication technologies provided in cellphones (e.g.,
bluetooth or Wi-Fi) to distribute music in the mobile environment. To protect digital contents, Bluemusic is
provided with a security mechanism that prevents illegal contents distribution. An evaluation of our approach
shows that Bluemusic can be helpful to the expansion of the mobile music market.
1 INTRODUCTION
Only few years ago the music industry was hesitant
to enter into the digital market, as the digital sce-
nario was usually associated with piracy and with il-
legal music sharing; Today things are different and
the download music is a successful scenario for dif-
ferent reasons: i) low prices (around one dollar); ii)
high speed residential Net access (e.g., DSL) with flat
rate plans and iii) large availability of cool portable
devices (e.g., Ipod).
The digital music market is seen as an interest-
ing opportunity for mobile operators: mobile-phone
companies are becoming an important player in the
emusic market with the releasing of multimedia cell-
phones (e.g., the Nokia N90 series or the announced
iPhone from Apple); cellular operators are consider-
ing the distribution of emusic an important applica-
tion for their 3G networks. The remarkable revenues
of the ringtones market, which recently reached $4.1
billions worldwide and the increasing number of mo-
bile phone subscribers, convinced the mobile industry
to be part of the mobile music market.
A great take off was expected, but the initial re-
sults show that people keep on buying songs from res-
idential Net access and avoid using the mobile phone
network for songs downloading. This is not surpris-
ing if we consider that a song is much more expensive
if downloaded from the mobile phone network.
In this paper we propose Bluemusic, a multi-
channel architecture designed to distribute digital mu-
sic in the mobile scenario. Bluemusic aims at reduc-
ing the price paid by a mobile customer for down-
loading the song directly to his/her device. It couples
the usage of the mobile phone network with the usage
of the free-of-charge bluetooth (or Wi-Fi) technology
available in many cellphones. It is provided with a se-
curity mechanism that protects the digital content by
requiring a license to play out the song. The idea is
to to limit the usage of the expensive mobile phone
network. To stimulate users music distribution, Blue-
music has an incentive mechanism that mitigates the
user selfish behavior.
The evaluation of Bluemusic investigates the se-
curity features and the performance (in term of down-
loading time) and results show that our multichannel
approach bring benefits, not only to customers, but
also to music stores and to mobile phone operators.
The remainder of this paper is organized as fol-
lows: In section 2 we present the Bluemusic archi-
tecture and its evaluation is presented in Section 3.
Conclusions are drawn in Section 4.
358
Furini M. (2007).
BLUEMUSIC: A MULTICHANNEL ARCHITECTURE FOR MUSIC DISTRIBUTION.
In Proceedings of the Second International Conference on Signal Processing and Multimedia Applications, pages 348-351
DOI: 10.5220/0002133703480351
Copyright
c
SciTePress
Bluemusic
client
Bluemusic
server
Mobile-phone
network
Song/licenserequest
download
payment
Network
Song
distribution
Figure 1: Bluemusic multichannel architecture: The mobile
phone network distribution is coupled with direct client-to-
client distribution.
2 THE BLUEMUSIC
ARCHITECTURE
In this section we describe Bluemusic, a multi-
channel architecture to distribute emusic in a mobile
scenario. It is composed of a Bluemusic server and of
Blumusic clients (Bserver and Bclient, for short). The
idea, depicted in Fig. 1, is to minimize the usage of
the expensive cellphone network by coupling it with
another, free-of-charge, channel.
Bluemusic Server. A BServer is in charge of prepar-
ing and releasing the song to a BClient that requests
it. The BServer uses the mobile phone network to
communicate with BClients. For security reasons, as
we better show in the following, the song is released
in the form of an encrypted media file along with an
encrypted license file.
Bluemusic Client. A BClient is a mobile de-
vice that can access a cellphone network and is
equipped with a free-of-charge communication tech-
nology (e.g., bluetooth and/or Wi-Fi); it can re-
quest/download songs/licenses through a BServer and
can directly communicate with other BClients using a
free-of-charge technology. A BClient has a BPlayer,
a software released to handle all the Bluemusic oper-
ations (song acquisition, distribution, sharing).
In the following we present details of the phases
necessary to participate, to acquire and to distribute
songs in our multi-channel proposal.
2.1 Bluemusic Sign-up Procedure
The sign-up registration procedure is required to
gather BClient information: the unique user identifier
(UID) and the the device identifier (DID). Once the
registration procedure has been done, the BServer re-
leases the BPlayer for the BClient; Once the BPlayer
has been installed, the BClient can acquire licenses,
distribute and play out songs.
Furthermore, during this sign-up procedure, the
private key is generated and delivered to the BClient,
which will store it into the device repository keys.
Song
License
Song
Encryptedaudiowithkey a
Clear
audiodata
30secs
a
SongID|Rigth|HV|UserID|Wkey
watermarkedwithkeywkey
Private/public
encryption
Symmetric
encryption
Figure 2: Two separate files are produced for any song. To
decrypt the song file, the license file must be decrypted.
2.2 Song Acquisition
A BClient can acquire a song directly from the
BServer. When contacted, the BServer prepares the
song and delivers it to the BClient using the cellphone
network. As shown in Figure 2, the song is released
with two separate files: the media data (encrypted
with symmetric key) and the license information data
(encrypted with private/public keys). Note that the us-
age of the symmetric key allows BClients to share the
media file.
The BServer first generates the α encryption key
and then encrypts the media file (or a portion of it).
To decrypt the media file, the BClient has to know the
α key. For this reason, the α key is hidden insidethe
media file. The key is hidden using a watermarking
technique that spreads out the hidden content without
compromising the media content (Cheng et al., 2002).
In particular, the key is spread out using another key,
the so-called watermarking key (WKey), which will
be available to the BClient with the license file.
The license file contains information related to
the rights acquired (e.g., the right of playing out the
song), the song identifier, the UID, the watermark key
(WKey) for decrypting the song file, the hash value of
the song file (HV) for verifying the song integrity.
This approach ensures that a license file can be
decrypted only by the device for which it has been
released, causing the sharing of the license file to be
a useless operation. Conversely, the media data file is
not bound to the device, and hence it can be shared.
2.3 Song Distribution
Bluemusic is a multi-channel distribution architecture
that allows BClients to share files with other BClients.
We recall here that the media file can be played out
only if its license is acquired and that license sharing
is useless, as a license file is bounded both to the song
and to the BClient device.
The distribution procedure is managed by the
BPlayer software, which uses the free-of-charge com-
munication technology to look-up for other BClients.
The discovered BClients can be contacted. When
BLUEMUSIC: A MULTICHANNEL ARCHITECTURE FOR MUSIC DISTRIBUTION
359
contacted, the BClient receives information about the
song (e.g., Song ID, Song Title, Song author) and
checks the user’s preferences to authorize/deny the
downloading of the incoming song. This is done to
avoid the downloading of unwanted songs.
The benefits of this BClient distribution it to re-
duce the price paid by a user to get a song on his/her
mobile device. In fact, only the small license file
passes through the cellphone network, while the me-
dia file is obtained through a free-of-charge technol-
ogy. Needless to say, the more people will share
their song, the more chances a user has to receive
the preferred song over his devices. Users coopera-
tion is thus essential for the success of the Bluemusic
approach. To this aim, Bluemusic is provided with
a payment-based incentive mechanism that attach a
small additional financial cost to the license price,
so that it can be partially or totally recouped by re-
distributing the song (Furini and Montangero, 2006).
2.4 License Acquisition
To play out a song received by another BClient, it is
necessary to acquire the corresponding license file. To
this aim, the BServer has to be contacted. License
acquisition is done in a transparent way as it happens
today with DRMs like Microsoft DRM 10.
Since the license is bounded to the song and to the
BClient, the BClient has to communicate the follow-
ing information: the song ID, the user ID, the device
ID and the song file hash function (HV). Upon the re-
ception of these information, the BServer first checks
the song integrity in order to avoid the possibility that
a malicious user may transfer a fake or different song
with respect to the one described by the Song ID iden-
tifier. If the integrity check succeeded, the BServer
sends to the BClient some song information (Song Ti-
tle, Song Author, and price) and asks for a YES/NO
reply. If the client agrees on buying the license, the
license file is generated by the BServer (as depicted
in Figure 2) and is sent back to the BClient (payment
is not investigate in this paper). The BClient, using its
private key, can decrypt the license file, unlocks and
plays out the media file.
2.5 Song Playout
To play out a song, the BPlayer needs to decrypt both
the media file and the license file. The license file is
the first one that has to be decrypted as it contains in-
formation necessary to decrypt the song file. Since
the license file in encrypted with the public key, the
BPlayer retrieves the private key from the repository
and decrypts the license file. Note that the private key
Time(sec)
940
Bandwidth(kbps)
50
25
75
188 376
564
752
Figure 3: Experienced data transfer rate obtained while
downloading a 4MB song using a GPRS cellular network.
has to be secret to the user in order to avoid key shar-
ing. This can be achieved with hardware or software
solution (Bar-El and Weiss, 2004).
Once decrypted, the license provides the follow-
ing information: Song ID, Rights acquired, User ID,
the watermark key (WKey) and the hash value of
the song file (HV). Before playing the song out, the
BPlayer checks for the song integrity. To this aim it
computes the hash value of the media file and com-
pares it with the retrieved value HV. If the integrity
check fails, the play out cannot begin; if it succeed,
the BPlayer uses the retrieve Wkey to retrieve the α
key and uses this key to unlock the song file. From
now one, the BPlayer can begin the song play out.
3 BLUEMUSIC EVALUATION
In this section we evaluate our multi-channel proposal
by investigating: i) downloading time; ii) impulsive
buying and iii) security issues.
3.1 Downloading Time
Bluemusic allows using both the mobile phone net-
work (e.g., GPRS, EDGE and UMTS) and the free-
of-charge technology (e.g., Bluetooth or Wi-Fi) pro-
vided with current cellphones.
In the following we investigate the time necessary
to download a 4MB song using the different technolo-
gies. Experiments are done using devices with differ-
ent devices (Nokia N90, Nokia 6230, Motorola V3
and Siemens S55), two different cellphone network
providers (TIM and Wind) and in different day time.
GPRS Downloading. Results from downloading
songs very similar to the situation depicted in Figure
3, where it can be noted that the real transfer rate only
occasionally goes above 50kbps (against the theoreti-
cal 170kbps). With such transfer rate the time neces-
sary to download a 4 MB song is around 940 seconds.
SIGMAP 2007 - International Conference on Signal Processing and Multimedia Applications
360
150
200
250
300
350
400
1 21 41 61 81 101 121
Time (sec)
Data Transfer Rate (kbps)
Bluetooth 1.1
Bluetooth 2.0
Figure 4: Download of a 4MB song using Bluetooth.
EDGE Downloading. A similar difference from
theory to practice has been found using the EDGE
technology: instead of the theoretical data transmis-
sion rate of 384 kpbs, the experienced data transfer
rate was around 82 kbps, which leads to a download-
ing time of 390 seconds to get a 4MB song.
UMTS Downloading. The UMTS data transfer
rate experienced using showed an average download
rate of 312Kbps (a max of 440kbps was reached),
which leads to a downloading time of 102 secs to get
a 4MB song. Again the actual transfer rate is far from
the theoretical one (144kbps, 384kbps or 2Mbps de-
pending on the usage (vehicular, pedestrian or fixed).
Bluetooth Downloading. Figure 4 summarizes
the results, which show that the bluetooth 1.1 allows
transmitting a 4MB song in 132 seconds with a data
transfer rate that is around 250kbps, and the blue-
tooth 2.0 needs 91 seconds with a data transfer rate
around 350 kbps. Note that the connection setup time
is not shown and hence one second should be added
to the downloading time due to connection set-up time
(Frank Kargl and Weber, 2002).
Wi-Fi Downloading. The conducted experiments
with a Nokia N90 showed that a 4MB song can be
downloaded in around 5 seconds.
3.2 Impulsive Buying
An important characteristic of Bluemusic is that it
stimulates unplanned purchases (Cobb and Hoyer,
1986), as it enables consumers to acquire a license
song immediately after the reception of song. In fact,
the music is considered an experience good, and when
a customer receives a song through the free-of-charge
communication technology, it is stimulated to buy it.
3.3 Security Analysis
Content protection is an essential feature for any dig-
ital distribution and in the following we analyze pos-
sible Bluemusic security concerns.
It is to note that the so-called Digital Right Man-
agement schemes admits no final and strong solu-
tion, since security rests on code obscurity. However,
DRM systems are nowadays the only mechanisms
used against piracy and that a mobile device can be
used to build a more secure DRM (T.S.Messerges and
E.A.Dabbish, 2003). Another security concern is re-
lated to the use of watermarking techniques: (Schon-
berg and Kirovski, 2004) claims that secure finger-
printing is not possible with current technologies, but
(He and Hu, 2004) are more optimistic.
4 CONCLUSIONS
This paper presented Bluemusic, a multi-channel dis-
tribution architecture designed to distribute digital
music in a mobile scenario. Bluemusic is coupled
with a security mechanism that ensures that a shared
song can be played out only upon license acquisition.
The evaluation of our proposal showed that a multi-
channel approach is worth using as it reduces both the
download time and the mobile phone data traffic.
REFERENCES
Bar-El, H. and Weiss, Y. (2004). Drm on open platforms?
it may be possible after all. In Proceedings of the 2nd
IEE Secure Mobile Communications Forum.
Cheng, S., Yu, H., and Xiong, Z. (2002). Enhanced spread
spectrum watermarking of mpeg-2 aac audio. In Pro-
ceedings of the IEEE Int. Conf. on Acoustics, Speech,
and Signal Processing, pages 3728–3731.
Cobb, C. J. and Hoyer, W. D. (1986). Planned versus
impulse purchase behavior. Journal of Retailing,
62:384–409.
Frank Kargl, Stefan Ribhegge, S. S. and Weber, M. (2002).
Bluetooth-based ad-hoc networks for voice trasmis-
sion. In Proceedings of HICSS. IEEE Press.
Furini, M. and Montangero, M. (2006). The use of incen-
tive mechanisms in multi-channel mobile music dis-
tribution. In Proceedings of the IEEE AXMEDIS In-
ternational Conference. IEEE Press.
He, S. and Hu, M. (2004). Performance study of ecc-based
collusion-resistant multimedia fingerprinting. In Pro-
ceedings of the 38th CISS, pages 827–832.
Schonberg, D. and Kirovski, D. (2004). Fingerprinting and
forensic analysis of multimedia. In Proceedings of
ACM Multimedia, pages 788–795.
T.S.Messerges and E.A.Dabbish (2003). Digital rights man-
agement in a 3G mobile phone and beyond. In Pro-
ceedings of DRM. ACM Society.
BLUEMUSIC: A MULTICHANNEL ARCHITECTURE FOR MUSIC DISTRIBUTION
361