Urbiftock: An experiment in Dynamic Group Management in Pervasive Social Applications

Andoni Lombide Carreton, Dries Harnie, Elisa Gonzalez Boix, Christophe Scholliers,

Tom Van Cutsem, and Wolfgang De Meuter

Software Languages Lab Vrije Universiteit Brussel

Brussels, Belgium {alombide,dharnie,egonzale,c!scholl,tvcutsem,wdmeuter}@vub.ac.be

Abstract-Pervasive social applications are applications that enable end users to interact and share information on the move. In these applications, the concept of a user group plays a central role as it models the user's social networks. Most pervasive social applications today model these user groups as simple lists of users that have to be manually managed by the user to re8ect the changes in a frequently changing context. Managing user groups in current frameworks is complicated because of three main reasons. There is a lack of abstractions (i) to discover users on the move, (ii) to organize these users in composable context-aware user groups, and (iii) to manage the communication between the users and groups of users.

Our research focuses on providing proper abstractions to deal with the specific characteristics of user groups in pervasive social applications. In this paper we describe Urbijlock, a framework which aids the programmer in managing the complexity of implementing such dynamic user groups. Fur­thermore, we describe a messaging system called Guanotes which has been developed by means of our framework and exploits dynamic user groups to enable context-aware message propagation among mobile users.

I. INTRODUCTION

In the last few years social networking applications such

as Facebook, MySpace and Flickr, have gained tremendous

popularity. Thanks to those sites users can easily create

and share information worldwide (e.g. photos, videos, what

they did over the weekend, etc.). However, nowadays social

networking applications are still more a reporting tool of

social events than a tool used to engage in social interactions,

because they are poorly integrated in the physical world.

With the increasing popularity of mobile ad hoc networks,

a brand new form of social networking is emerging by

means of pervasive social applications [1], [2]: applications

that enable spontaneous interactions of people by means

of handheld devices (such as their cell phones). Mobile ad

hoc networks are formed by collocating several handheld

devices equipped with wireless communication. These net­

works have two important properties [3]: devices need to

collaborate without relying on infrastructure and they can

lose connectivity when their owners move about. Pervasive

social applications exploit such a collocation of a number

978-1-4244-5328-3/10/$26.00 ©201O IEEE 250

of mobile devices in the immediate vicinity to enable social

interaction on the move. In pervasive social applications, user groups form a central

concept for reasoning about the user's social networks.

Although some middleware platforms have been recently

developed especially for pervasive social applications [4],

[5], [1], we observe that there is a lack of high-level

abstractions to interact with groups of users. 1Ypically, user

groups are exposed as simple lists of users or devices.

The system provides a number of predefined user groups

(e.g. "the world" or "my direct contacts" in MyNet [5]).

End users can also create and manage groups by explicitly

adding or removing users. However, if the connectivity of

the social network varies, these changes usually have to be

manually reflected by the end user. For example, a user that

defines a group of "classmates" of hislher Dutch course

needs to manually update it every academic year. Due to

the above mentioned nature of mobile ad hoc networks,

pervasive social applications call for a more dynamic group

management system. Since people move about constantly,

changes to groups will happen a lot more frequently. For

example, the addition or removal of a user to a group could

be automatically derived based on information provided in

the user profile, e.g. "attending Dutch course", or their

physical location (as users move about with their devices).

This paper describes Urbiflock: a framework that aids

programmers in developing pervasive social applications by

providing infrastructure for discovering people in a mobile

ad hoc network based on intensional descriptions, organizing

these people in compos able user groups that are automati­

cally synchronized with changes in the environment, and,

finally, enabling communication between them. The rest of

this paper is organised as follows: in Section II we define a

few necessary properties for user groups in pervasive social

applications. In Section III we show the architecture of our

framework and explain how users can manage user groups in

Urbiflock. Finally, in Section IV, we describe an application

built on top of the Urbiflock framework called Guanotes. This application demonstrates how Urbiflock communicates

with peers in a mobile ad hoc setting.

II. REPRESENTING USER GROUPS IN PERVASIVE SOCIAL

ApPLICATIONS IN A MOBILE ENVIRONMENT

The concept of user groups arises in pervasive social

applications as an abstraction to reason about users' social

networks. Part of our work in Urbiflock revolves around

experimenting with different kinds of user groups. The

simplest type of user groups are the so called buddy lists, i.e. list of friends or acquaintances of a user. Other examples

include user groups representing social aspects such as the

users sharing a particular feature (e.g. "speaks Spanish"), or

a particular interest (e.g. "likes badminton"). Pervasive social

applications are intended to be used by mobile devices in

mobile ad hoc networks, so another important type of user

groups is organized by people that are physically collocated.

Examples of such user groups are the "nearby users" (i.e.

users that are located within a geometrical distance), but also

users one has previously met at a certain location such as the

campus bar, etc. In order to represent such diverse types of

user groups in pervasive social applications, we distill four

requirements for user groups that need to be supported by

the underlying system.

1) Semantic-based User Groups: In pervasive social ap­

plications, it is important to be able to address the set of

users in proximity. Adopting the definition of proximity as

the perception of being close to somebody or something,

one can discern two different notions of proximity [6]. First,

users can be in physical proximity defined by, for example,

the Bluetooth communication range of their cellular phones.

Secondly, proximity can be defined with more abstract terms

based on, for example, the user's social links (i.e. being

friends, friends of friends, etc.) or user's social preferences.

2) Dynamic User Groups: In social applications, user

groups are typically defined by the end user explicitly adding

and removing group participants (e.g. "add as a friend").

In pervasive social applications, user groups are exposed

to a higher rate of changes in their composition. This is

because mobile ad hoc networks are formed by collocated

mobile devices. Since mobile devices only have a limited

connectivity (because the communication range of wireless

technology is limited) and users carry these devices as they

move about, the contents of social networks change accord­

ingly. For example, the "nearby users" group in Urbiflock

fluctuates arbitrarily as users appear and disappear at a

particular location.

3) Composite User Groups: Most pervasive social mid­

dleware consider groups as a static concept, i.e. an enu­

meration of users or devices. In many situations this is not

sufficient for defining user groups. For example, one could

compose a user group defined by a physical distance with

a user-defined one to create a user group of people in the

neighborhood who like to drink Belgian beers. Therefore, it

should be possible to construct user groups as a composition

of a number of simpler user groups.

251

4) Subjective Definition of User Groups: Every user

should be able to define their own group of users. Due to the

openness of pervasive social applications, it is not realistic

to assume that all users will use the same criteria. Instead,

users will use their own (subjective) terms to describe the

composition of user groups. For example, one could define

the group of "nearby users" by those users who are in

the same room while somebody else could define it by

those users who are in the same building or city. Therefore,

user groups cannot be defined as a globally shared concept.

Rather, different definitions for a same user group should be

able to coexist in the system.

III. URBIFLOCK

Pervasive social applications enable spontaneous interac­

tions of people using new technologies such as wireless net­

works and mobile devices. To facilitate the development of

this kind of applications, we present Urbiflock: a distributed

object-oriented framework for the development of pervasive

social applications. The aim of the Urbiflock framework is

to provide programmers with the necessary infrastructure

to deal with the highly dynamic environment to which

pervasive social networking applications running on mobile

devices interacting via a wireless network are exposed. In

particular, Urbiflock aims to give programmers expressive

abstractions to organize and manage dynamic user groups.

We have implemented Urbiflock on top of the Am­

bientTalk language [3], an object-oriented scripting lan­

guage specially designed for mobile ad hoc networks.

AmbientTalk's actor-based, event-driven concurrency model

makes it highly suitable for developing applications running

on mobile devices. Devices running AmbientTalk can dis­

cover each other on the network, which provides the low­

level support for allowing users to discover other users in a

dynamically demarcated network. In addition, AmbientTalk

is embedded in Java which allows us to reuse all existing

Java execution platforms and libraries (e.g. virtual machines,

GUI components, encryption libraries, etc.).

In Urbiflock, users (called flockrs) can meet other users

and interact with them, for example by sending each other

messages. Flockrs have a profile with information about their

identity which can be browsed by other flockrs. Users of

the Urbiflock framework can create groups of flockrs by

specifying a set of criteria that user profiles must meet. These

groups are then made available to the applications running

on top of the framework.

A. Urbijlock Architecture

The architecture of the Urbiflock framework (shown in

Figure 1) is divided into three layers: applications, Urb­

iflock core, and Urbiflock infrastructure. The application

layer includes several core applications which are currently

available in the framework such as group and profile editors.

There are also some user applications such as I rate you

(IRBU) which allows users to ask proximate users to rate

them on a certain subject, and Guanotes which is explained

in Section IV. The Urbiflock core layer is composed of

four important concepts: flockrs, user groups, user profiles

and the TOTAM framework for communication with a

group. The infrastructure layer consists of three low-level

abstractions on which the framework core is based: a RETE

engine that determines the contents of user groups and the

service discovery and communication APIs to discover and

communicate with nearby applications.

1) Flockr: A flockr represents a user in the framework. A

flockr has exactly one profile and he can create and belong

to multiple groups. In addition, a flockr can have multiple

installed applications. Other applications can query a flockr

for information about the user or about the applications

installed on the device.

2) User Groups: As we have stated before, user groups

are an important concept in pervasive social applications:

they represent the social networks a user belongs to. More­

over, the definition of these social networks can vary from

user to user. The Urbiflock framework manages user groups,

taking into account the properties in section II. We will

discuss dynamic user group management in detail in the

next section.

3) User Profile: In order to support semantic-based user

groups, the Urbiflock framework requires access to informa­

tion associated with the user. Profiles in Urbiflock represent

the user identity (e.g. name, gender, hobbies, etc.). They

are highly extensible and besides a number of mandatory

fields, flockrs can add as many custom fields as they like. For

example, users can add a field with their year of graduation

and use it to create a group of flockrs who graduated in the

same year. The framework also makes it easy to add new

types of fields (e.g. hobbies or eye color).

4) TOTAM Infrastructure: To enable interactivity in per­

vasive social applications, a good communication abstraction

should enable flockrs to communicate with each other with­

out being connected at the same time, while maintaining pri­

vacy. Due to the dynamics of pervasive social applications,

not everyone in a user group is directly reachable using a

wireless link.

To this end we have designed a dedicated communication

abstraction called Tuples on the Ambient (TOTAM) [7].

TOT AM is a tuple-based middleware which allows flockrs to

communicate with other flockrs belonging to the same group

by exchanging tuples. The framework allows the tuple itself

to determine whether a flockr is in its scope before it is

physically exchanged between two flockrs.

5) Applications: Applications need to be explicitly added

to a flockr before they can be used. From then on the user

sees the application in a launch screen (similar to the Home

screen on the Apple iPhone). Running applications have

controlled access to flockr information via the framework

such as the flockr profile. This is a common functionality

252

I

URBIFLOCK

Urbiflock's Applications

User Applications {Guano!es, IRBU, ... ) II

Core Applications {GroupEditor, Profile Editor,

Urbiflock's Core

B II TOTAM

User Group

I User Profile

Urbiflock's Infrastructure

)1

I I I

I RETE

II Discovery API II Communications

I Engine {WiR, Bluetooth, RFID .. . ) API

AmbientTalk Virtual Machine

JVM

Figure I. Urbiflock architecture

found in pervasive social applications. In addition, Urbiflock

applications have access to the groups defined by the user

and the list of flockrs who have installed the same applica­

tion on their devices.

B. User Group Management in Urbiflock

As stated in section II, user groups are a central concept

in pervasive social applications. In these kinds of appli­

cations, user groups need to be semantic-based, dynamic,

and composable with other user groups. Furthermore, each

user will have a different set of definitions for user groups,

corresponding to individual social networks. Part of the work

in Urbiflock revolves around experimenting with different

ways of managing user groups.

Urbiflock provides two predefined user groups:

friends Group and nearbyGroup. The first group is a buddy

list which works like regular buddy lists in other social

network applications. It is always present and it is the only

group that requires user intervention to maintain. The other

predefined user group, nearbyGroup, tracks other flockrs

that are in wireless communication range of the device

Urbiflock is running on. W henever another user moves in

or out of range, nearbyGroup is updated to reflect this.

Additionally, users can create their own user groups in

two different ways:

1) User groups based on profile information: A first way

for the user to create user groups is to filter on profile

information. As mentioned in the previous section, each

flockr has an associated user profile, which is essentially a

list of key-value pairs. This user profile has a few mandatory

fields (like username, first name, last name, etc.) but users

are free to add new fields. The framework also allows users

to add their own types of fields in addition to the standard

types of fields (string, number, date, enumeration, etc.).

Figure 2 shows the profile viewer: the "Interests" field is

an example of such a user-defined type.

o

sex I Male

Profile Viewer

lastname I Lombide Carreton

firstname IAndoni

username ! andoni

I ( remove)

I ( remove)

birthdate 'Ill 1 I 1984 ( remove)

Interests ( Badminton �: I ( remove)

( Add Field ) Ok

Figure 2. Editing profiles in Urbiflock

The user can create an intensional description of a user

group by enumerating a set of constraints. The Urbiflock

framework will use these constraints in combination with

user profiles to define the members of that group.

2) Composing groups: The second way a user can create

a group in Urbiflock is to compose it out of other groups. A

group based around a shared interest (e.g. badminton) is very

useful, but it is often desirable to send a message to only

those players who are currently nearby, to organize a match

for example. Only having a specialized nearbyBacimintonGroup

clearly is not sufficient: sometimes the user wants to address

all badminton players, for example to set up a tournament.

The number of possible combinations grows exponentially

with the number of available groups to choose from.

Urbiflock allows the user to define a nearbyBadmintonGroup

which contains players both nearby and interested in bad­

minton, by composing it from the badmintonGroup and

the nearbyGroup. The implementation of Urbiflock al­

lows composing groups using the basic Boolean opera­

tors (and, or, not). Figure 3 illustrates the creation of the

nearbyBadmintonGroup.

"" '" User Croup Editor

Name: My badminton team

IS!'l Is friend 0

Is nearby 0

\..:( s..::.: ex'--_--'-'-' '-__ '-' '-__ --'-:...Jl 0

L( l..::.: nte.::.re::.: s.:.:.ts_.:...:..J ,--_..:.::..;l (Badminton : 10

�========�+========�) Save )

Figure 3. Composing a group from others

253

Figure 3 shows how the user can create composite user

groups in Urbiflock. When creating a user group, the user

is first prompted to enter a name. This name is local to

the user's device: another user might also create a group

called "My badminton team", but it can address a totally

different set of people. The user can then use the button

marked '+' to add either constraints on profiles, or compose

with another group. In this screenshot we see that the user

has checked both the "is friend" and "is nearby" checkboxes;

these signify that members of the user group should also

belong to the friendsGroup and nearbyGroup, respectively. The

second part of the screenshot shows how the user can set

constraints on a group. The drop-down boxes show, from left

to right: the field being inspected, the comparator being used,

and the value being compared to. The available comparators

are defined by the field type. For example, number fields can

be compared with "smaller than", "equal", "greater than",

etc. comparators.

With the abstractions for programming pervasive social

applications that Urbiflock provides, users can keep track

of other flockrs in their environment and classify them in

groups according to criteria based on their user profile.

However, communication in a pervasive social application is

a non-trivial issue: as users and their devices walk in and out

of wireless range, the number of available communication

partners fluctuates.

IV. GUANOTES: URBIFLOCK AT WORK

Inspired by the "Wall" plug-in of Facebook where people

can post notes on somebody else's wall, Guanotes allows

flockrs to post notes to any flockr present in their surround­

ings or belonging to a particular group. This allows users to

define a target group of note receivers in addition to target

individuals (as done in the "Wall" plug-in). For example,

one could imagine sending price reductions only to people

who have their birthday while the reduction is active. This

information is retrieved by collecting this information from

the flockrs' profiles and is used to update the corresponding

groups, which can be used by different applications, such as

the Guanotes application.

A guanote consists of a message and a receiver list (a

group of flockrs or just one). Guanotes keeps track of the

connected flockrs which are running the application. Devices

running the Guanotes application communicate with each

other (by means of the TOTAM framework) to interchange

the guanotes they carry. A guanote is propagated to another

device only if a flockr belongs to the receiver list. A guanote

is thus propagated through the network hopping from device

to device in order to ensure that it gets received by all

the targeted flockrs. In order to avoid flooding the network,

TOTAM ensures that only flockrs belonging to the receiver

list are used as routers (so that only potential targeted flockrs

carry guanotes).

, , ,

\ \

Halla I I

I I

/ /

---- /

Figure 4. Ouanotes usage scenario in Urbiflock

Figure 4 illustrates the propagation of a guanote in a

campus-based scenario. It shows six ftockrs connected in

Urbiftock and running the Guanotes application. The com­

munication range of their devices is depicted with a dotted

line while the colored dot on their devices denotes the gender

of the ftockr (white for girls, black for males, and grey with

stripes if the gender is not set in the ftockr's profile). In

particular, the figure 4 shows how a "hallo" guanote is sent

by Elisa to the nearbyMaleGroup (previously defined as all

nearby male ftockrs). This guanote is transitively propagated

until all connected ftockrs belonging to the nearbyMaleFlock

are reached. The guanote is not propagated to ftockrs that

do not adhere to the definition of nearbyMaleFlock. In this

scenario, the guanote should be propagated to Stijn and

then to Wolf. Elisa's device is in communication range of

two devices (Sara and Stijn), but since the guanote is only

meant for nearby male ftockrs, it is only propagated to Stijn.

Similarly, Stijn's device is nearby to Elisa, Wolf and Sara,

but it only propagates the guanote to Wolf. It is important

to note that Wolf receives the "hallo" guanote without being

in direct communication range of Elisa's device.

Figure 5 shows the Urbiftock GUI of Elisa's device during

the process of creating the "hallo" guanote. In particular,

three different types of GUIs are displayed: at the top

the editors for the nearbyGroup and nearbyMaleGroup groups,

the middle shows Elisa's inbox (which contains a guanote

previously received from Sara) and the bottom part contains

the editor for creating new guanotes. The contents of the

two groups correspond with the scenario in Figure 4. The

guanote editor shows how Elisa can create the "hallo" guan­

ote by selecting the target group from a drop-down list and

writing text in the content section. As previously mentioned,

a guanote can also be sent to an explicit collection of ftockrs.

To this end, a user can enumerate the targeted ftockrs in the

receiver list. It is important to note that if the receiver is a

group, the composition of the group is recomputed at each

hop.

The Guanotes application described in this section demon-

254

• " '"' " Viewing user group NearbyGroup r "" ,.... ,.... Viewing user group nearbyMaleCroup

NearbvCrOUD nearbvMaleGrouD sara stijn stijn

"'"' r. elisa:: Guanotes Inbox

� ura: haJlo 11m. lIIybody I" for. drl"k?

( IA00

New )( elisa:: New Guanote

To. nearbyMaleGroup

t T

Delete ) I

.{ Friend,Group �B _______________ ...,.... NearbyGroup

hallo

� ______ _ S _ en_ d ________ �)C� ________ �D� i,c= ar� d ________ �

Figure 5. OUI of Elisa's Urbiflock

strates how Urbiftock enables indirect communication in per­

vasive social applications. The TOT AM framework delivers

messages to members of the user group without requiring the

whole user group to be visible to each individual member.

V. RELATED WORK

A number of middleware solutions targeting pervasive

social applications have been recently designed [4], [5],

[1]. The most relevant difference with Urbiftock are in

the way user groups are handled. MyNet [5] is a secure

platform which enables end-users to easily organize their

social networks. Unlike Urbiftock, user groups in MyNet

are represented as lists of users or devices. Three built-in

user groups are provided: "the world", "my direct contacts",

"my extended contacts" (i.e. users two social hops away).

Mokhtar et al. explore in [1] a number of social-based

matching algorithms to reason about user preferences and

their social links. In contrast to those approaches, Urbiftock

aims to be a platform for the rapid prototyping of per­

vasive social applications. In this regard, Urbiftock has a

stronger resemblance to BT Communities [4], a framework

aimed at the development of pervasive social applications

that communicate over Bluetooth. In this framework, the

Bluetooth connections (or the lack thereof) between different

devices denote the different communities. In addition to

physical notions of proximity based on wireless connectivity,

Urbiftock also allows groups to be based on profile attributes.

Some of the traditional social networking applications

also have a mobile counterpart (e.g. Facebook). However,

they assume that users have access to their centralized

infrastructure rather than exploiting the collocation of de­

vices to enable social interaction on the move. Such a

recently released application is Friendlee [8]: it uses social

network information (such as the most frequently called

people by a user) to rank user contacts. It also allows

contextual information (such as location-based information)

to be shared among friends. However, Friendlee does not

allow end-users to take advantage of this information to

manage their contact lists.

Cluestr [9] offers sophisticated contact recommendation

algorithms to allow users to efficiently retrieve a group

of mobile users. However, once this group is derived the

system does not update its content to reflect changes in the

environment. VENETA [10] is a contact recommendation

system that uses the friend-of-friend principle to discover

new potential mobile contacts in the neighborhood. Other

approaches exploit groups of proximate users in order to

route content more efficiently [2], [11]. These approaches are

orthogonal to groups: contact recommendation and content

routing between groups of users could be implemented on

top of Urbiflock and TOTAM.

VI. CONCLUSIONS AND FUTURE WORK

In this paper we presented Urbiflock: a framework which

aids in the rapid development of pervasive social applica­

tions that have to deal with the discovery of users in a

dynamically demarcated wireless network. Urbiflock also

provides abstractions for organizing users into user groups

that are automatically synchronized with their environment

and communicating with such dynamically changing groups

of users.

In future research we are going to explore the user

groups abstraction and generalize it for use in applications

other than pervasive social networks. We have tested our

current implementation on a number of HTCP3650 Touch

Cruise phones. For future tests, we are looking into porting

Urbiflock (and AmbientTalk1) to new platforms like Google

Android and the Apple iPhone. We also have concrete plans

to deploy Urbiflock on a campus-wide network at the Vrije

Universiteit Brussel; this will give us empirical data of how

well Urbiflock scales.

ACKNOWLEDGMENT

Elisa Gonzalez Boix and Dries Harnie are funded by the

prospective research for Brussels program of IWOIB-IRSIB.

Christophe Scholliers and Andoni Lombide Carreton are

funded by a doctoral scholarship of IWT-Vlaanderen. Tom

Van Cutsem is a postdoctoral fellow of FW O-Vlaanderen.

IThe Urbiftock framework is available together with the AmbientTalk language at http://code.google.com/p/ambienttalkl.

255

REFERENCES

[1] S. Ben Mokhtar and L. Capra, "From pervasive to social com­puting: Algorithms and deployments," in ACM International Conference on Pervasive Services (ICPS 09),2009.

[2] A. Meshhadi, S. Ben Mokhtar, and L. Capra, "Habit: Leverag­ing human mobility and social network for efficient content dissemination in manets," in Proceedings of the 1 Oth IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM09), 2009.

[3] T. Van Cutsem, S. Mostinckx, E. Gonzalez Boix, J. Dedecker, and W. De Meuter, "Ambienttalk: object-oriented event­driven programming in mobile ad hoc networks," in XXVI International Conference of the Chilean Computer Science Society (SCCC). IEEE Computer Society, 2007, pp. 3-12.

[4] R. Beale, "Supporting social interaction with smart phones," IEEE Pervasive Computing, vol. 4, no. 2, pp. 35-41,2005.

[5] D. N. Kalofonos, Z. Antoniou, F. D. Reynolds, M. Van-Kleek, J. Strauss, and P. Wisner, "Mynet: A platform for secure p2p personal and social networking services," IEEE Inter. Con! on Pervasive Computing and Communications (PerCom), pp. 135-146, 2008.

[6] V. Ratniro, J. Dedecker, E. Tanter, and P. Barron, "Exper­imenting with language support for proxitnity in ambient­oriented programming," LNCS, vol. 5049, pp. 259-283, 2008.

[7] C. Scholliers, E. Gonzalez Boix, and W. De Meuter, "Totam: Scoped tuples for the ambient," in 2th Workshop on Context­aware Adaptation Mechanisms for Pervasive and Ubiquitous Services (CAMPUS), vol. 19. EASST, 2009, pp. 19-34.

[8] A. Ankolekar, G. Szabo, Y. Luon, B. A. Huberman, D. Wilkinson, and F. Wu, "Friendlee: a mobile application for your social life," in Inter. Con! on Human-Computer In­teraction with Mobile Devices and Services (MobileHCI'09). ACM, 2009, pp. 1-4.

[9] R. Grob, M. Kuhn, R. Wattenhofer, and M. Wirz, "Cluestr: mobile social networking for enhanced group communica­tion," in Int. Conference on Supporting Group Work (GROUP '09). New York, NY, USA: ACM, 2009, pp. 81-90.

[10] M. Von Arb, M. Bader, M. Kuhn, and R. Wattenhofer, "Veneta: Serverless friend-of-friend detection in mobile social networking," in IEEE Inter. Conf. on Wireless and Mobile Computing, Networking and Communications (WiMOB'OB), 2008, pp. 184-189.

[11] E. Jaho and I. Stavrakakis, "Joint Interest- and Locality­A ware Content Dissetnination in Social Networks," in Sixth Annual IEEElIFIP Conference on Wireless On demand Net­work Systems and Services (WONS'09), 2009.