Lets define the set of peers as:
{1}i P i M ,=,..., (1)
where M is the number of the peers currently online in the peer-to-peer network. That means they can be located and accessed with the sufficient bandwidth. Since the peers (Wi-Fi walkman) and users exist in pairs, we will use the term peer and user interchangeablely.
The music content in the network is defined as a set of items, denoted by the set I . Each item has a specific physical location, i.e.
,{{1}{1}}i j i I I i M j N =|=,...,;=,..., (2)
where N i is the number of items physically located in the local storage device by the peer P i .
User retrieves music content regarding to his/her own interests. In a particular time, user may have one particular interest/intent. The interest can be obtained either explicitly or implicitly. For instance, it could be explicitly obtained by asking users to rate items. Alternatively, this can also be implicitly indicated by the music items that the user is playing. In our Wi-Fi walkman, we use user’s music play-list to indicate the user’s music interest:
Formally, we use a vector ,{},{1}{1}i j q q i V v i M j N ==,...,;=,..., to represent the play-list of the user q P , where the element ,1i j q v =, if user q P played the item ,i j I ,
otherwise ,0i j q v =.
{{1}}q V V q M =|=,...,
,{), {1}{1}i j q q i V v i M j N ==,...,;=,..., (3)
We would like to note that generally the interest of the user will change over time. It is in fact depends on the current context. Therefore, the play-list (representing the current users’ interest) should ideally be dependent on the time also, i.e. ()q q V V t →.
We utilize a time window to forget the old music items users have played, as shown in Fig. 2. By doing so, system can more focus on the current user’s interest.
Fig. 2 Time window for forgetting. 3.2 Personalized Recommendation
In order to automatically recommend the appropriate music regarding to the user’s current interest (indicated by the play-list q V ), we denote a distance measurement between a music item and the play-list as ,(,)i j q d I
V to measure the likeness of the item ,i j I to the play-list q V . If d is smaller than a threshold D , the system will
recommend item ,i j I
to user q V . The list of recommendations for user q V is expressed
as follows:
,,Rec {|(, ) & } ,
{1}{1}
i j i j q q i I I d I V D i q i M j N =∈<≠=,...,;=,..., (4)
Play sequence
The current recommender system is implemented by using the collaborative filtering technique. Collaborative filtering utilizes the correlations (commonalities) between users on the basis of their ratings (i.e. the play-lists of users) to predict and recommend music items which have the highest correlations to the user’s preference (user’s current play-list).
The accuracy of the collaborative filtering directly relies on the number of users, who provide their ratings. In mobile networks, the density of peers may vary strongly depending on the local situation. (For instance, on the bus, there are only a dozen of people while in the airport there are thousands of peoples. Depending on the current density of peers, we perform recommendation by two different approaches, namely the flooding model and the client/server model.
Flooding Model
When the density of peers is large (i.e. thousands of users) and the play-lists from those users are enough to obtain a good recommendation, we use the flooding approach to find the correlations between users.
By using the correlation [12], the similarity between two play-lists q V and p V is calculated as follows:
(,)q p Sim V V = (5) ,1
i N M i j q q M i j i i v v N
=∑∑∑
where q v is the mean rating of the user q V .
The distance measurement between a music item ,i j I and a play-list from user q P can be calculated [12,13] as the weighted average rating. This is shown as follows:
,,,(,),(,)(,)()q p i j i j p q p q p q q sim V V T d I V v k
sim V V v v ?>=+?∑ (6)
where k is the constant value. In the flooding model, the play-list of the user is broadcasted to all its neighbors in order to determine the recommendation for that user. The neighboring peers check the similarity (using in Eq.(5)) between the received play-list and their own play-list. They decrease the TTL (Time to Live) field of the broadcasted play-list and then pass it to their neighboring peers again until the TTL count reaches 0. If one of the neighboring peers possesses that the similarity between its play-list and the broadcasted play-list is higher than T , the items in the play-list (including the locations) are sent back to the initial peer that posed the query. Finally all items received
by the querying peer are ranked according to the distance measurement (Eq.(6)) and consequently the top-N ranked items are recommended to the user.
Client/Server Model
When the density of the peers is small and consequently the play-lists (rating) from those users are not enough to obtain a good recommendation, we have to access a predefined rating database and use the database to calculate the recommendation. In this model, we assume the peer has a chance to access a server which has a rating database. The rating database stores the play-list of the users in the networks.
Fig.3 illustrates the procedure of obtaining the recommended play-list. In order to reduce the computational complexity, we apply the item-based recommendation algorithm proposed in [14] in the server part to calculate the recommendations.
In item-based recommendation, each music item can be represented by who has played it. More frequently, each item ,i j I can be represented by a vector ,i j U , where its element ,1q i
j u = if the item ,i j I has been played by the peer q P .
Item-based recommendation is then performed by exploring the correlations between the items rather than the correlations between users. Recommendations are created by finding items that are similar to other items that the user according to:
,',',',',','(,)(,)()()
i j i j i j i j i j i j Freq I I sim I I Freq I Freq I =× (7)
where ,()i j Freq I is the number of times that item ,i j I is in any of the play-lists. ,','(,)i j i j Freq I I is the number of times that item ,i j I and ','i j I are in the same play-list.
Due to the fact that the item-to-item matrix is relatively static, it is possible to compute this matrix offline. This extremely reduces the computational demands.
3.3 Demonstration Implementation
The Wi-Fi walkman demonstration is implemented on the Sharp Zaurus PDA by using C++, as shown in Fig. 1. It is running on an ad-hoc wireless network. It features audio playback, audio storage, audio recommendation, and ad-hoc wireless connectivity for audio exchange.
The Wi-Fi walkman itself contains an audio agent, a transport agent, and a wireless interface shown in Fig. 3. The audio agent is responsible for communication with the recommendation services, managing the MP3 files on the storage devices (e.g. a fresh card), and selecting which MP3 to play. The transport agent uses the wireless ad-hoc network to communicate with other transport agents and share the music files. Due to the dynamic nature of an ad-hoc network, the transport agents must keep track of the other walkmans around them. The standard 802.11 functionality is to transfer TCP/IP packets.
The enhanced ad-hoc wireless interface also informs the transport agent of new
Fig. 3 Illustration of the Wi-Fi Walkman in client/server model
