Experimenting opportunistic networks with

WiFi Direct

Marco Conti, Franca Delmastro, Giovanni Minutiello, Roberta Paris

Institute of Informatics and Telematics (IIT)

National Research Council of Italy, Pisa

Email: firstname.lastname@iit.cnr.it

Abstract—WiFi Direct introduces new opportunities to de-ploy real opportunistic networks through users’ mobile devices.However, its original specification does not take into accountall the parameters that can emerge from an opportunisticnetwork scenario, not only in terms of technical requirements(e.g., available resources and connectivities) but also of userscharacteristics and profiles, which can heavily influence thesystem’s performances and devices’ interactions. In this workwe investigate the feasibility of creating opportunistic networkson top of WiFi Direct framework by analyzing the protocol’sperformances in real scenarios with a variable number ofmobile devices. Experimental results show the times requiredto form a group of variable size and the best configurationsto support opportunistic networking operations and upper layerapplications.

Index Terms—WiFi Direct, P2P, opportunistic networks, mo-bile social networks

I. INTRODUCTION

Opportunistic networks represent the natural evolution of

mobile ad hoc networks (MANETs), overtaking limitations

and constraints of this paradigm related to the continuous

update of highly dynamic network topologies. Opportunistic

networks takes advantage of the human mobility and the

consequent network dynamism by defining new opportunities

of communication generated by the occasional encounter of

users and their personal devices. In this scenario, when two

users and devices come into contact, they can exploit direct

communications to exchange contents, to offer services, to

share resources and also to forward messages, even towards

other users/devices not currently in contact [1]. In this sce-

nario, available Internet connection represents just another

communication opportunity.

Initial solutions to really implement ad hoc (and subse-

quently opportunistic) networks relied on WiFi ad-hoc mode

that was painful to set up (designed for expert users only)

and supported data transfer speeds at most around 11 Mbps.

In addition, devices configured to communicate in ad-hoc

mode were not able to concurrently manage an infrastructured

communication (e.g., AP connections) keeping the two worlds,

ad-hoc and Internet-connectivity, completely separated. WiFi

Alliance [2], by introducing Wi-Fi Direct technology and the

related software protocol, practically overtakes these limitation

This paper has been partially funded by Regione Toscana under the projectSmartHealthyENV (POR-CREO FESR 2007-2013) and by Registro .it underthe project CAPP-Collective Awareness Participatory Platform.

by supporting both peer-to-peer and AP communications,

promising a much easier set up and management by upper-

layer applications, and regular Wi-Fi speeds up to 250 Mbps.

However, the original specifications of WiFi Direct does not

take into account all the parameters that can emerge from

an opportunistic network scenario. Here, the system has to

deal with both devices’ and users’ requirements, considering

not only technical specifications (e.g., available resources

and connectivities) but also personal users’ profiles that can

derived from multiple information (e.g., habits, interests, user-

generated contents, mobility, cooperative aptitude). To this

aim, the complexity of the network management increases

while offering even more efficient and personalized services.

Specifically, we move the attention from the standard notion

of network of devices to the emerging concept of network of

people, in which the users, their contents and needs are the

core of the system. This follows the current trends of social

networking applications in which users needs to exchange in-

formation anywhere and anytime, always requiring an Internet

connectivity. Through opportunistic communications we can

further extend this paradigm and its application scenarios by

exploiting the physical interaction’s opportunities among per-

sonal devices generated by the users’ mobility, not requiring

any pre-existent social relationships among the involved users

and not necessarily requiring an Internet connectivity. This

new paradigm is known as Mobile Social Networks [3].

Currently, a few works in literature presented real imple-

mentations of opportunistic networks. [4] presented WiFi-Opp,

an opportunistic networking setup based on the AP mode of

mobile users’ devices and evaluated its performances through

simulations based on real human mobility traces. We applied

a similar approach in [5], [6] through real experiments but

we experienced issues related to real users’ mobility and

intermittent connectivity events. To the best of our knowledge,

this is the first work on real experiments on the use of

WiFi Direct for opportunistic networks based on Android

implementation and by using a variable number of nodes. [7]

presented preliminary experimental results considering only

on a two-nodes configuration and by using laptops with a

customized implementation of WiFi Direct framework. In

order to compare our experimental results with those presented

in [7], we reproduce the same configuration with our nodes as

explained in Section III. In addition, we evaluate the protocol

performances in different configurations involving up to six

978-1-4799-0543-0/13/$31.00 ©2013 IEEE

nodes as detailed in Sections IV and V. However, before

analyzing the experimental results, we present a technical

overview of the protocol and its Android implementation in

Section II. Conclusions and future works are then presented

in Section VI.

II. WIFI DIRECT OVERVIEW

WiFi Direct, initially called Wi-Fi P2P, is currently the

reference standard to support device-to-device (D2D) com-

munications on WiFi channels. It exploits the same physical

wireless interface to support both standard wireless commu-

nications and D2D, defining one virtual interface for each

protocol. WiFi Direct relies on the concept of group. Devices

that want to establish D2D communications must organize

in groups assuming the roles of Group Owner (GO) and/or

Client. A device can assume both roles only in case it has

more wireless physical interfaces or it implements time sharing

techniques on the same interface. A GO is an ”AP-like” entity

that provides BSS functionalities to the associated clients, both

legacy (i.e., supporting standard 802.11 wireless access) and

P2P. Legacy clients can communicate only with the GO by

exploiting it as WLAN access, while P2P clients are also

able to establish client-to-client communications. The roles are

dynamically defined by implementing a two-phase protocol

(i.e., Device Discovery and Group Formation); the life of

the group and related communications are strictly connected

to the GO’s behaviour. When a group is established, WiFi

Direct implements a set of operations to manage the group

and devices’ interactions supporting also power management

mechanisms as specified in [2]. In this paper we focus only

on the Device Discovery and Group Formation procedures in

order to investigate the feasibility of creating opportunistic

networks on top of WiFi Direct and to analyze the protocol’s

performances in real scenarios involving a variable number of

mobile devices.

A. Device Discovery and Group Formation

The first step in the definition of a WiFi Direct group is

represented by the Device Discovery procedure. It consists of

two phases: Scan and Find. During the Scan phase each device

collects information about the surrounding devices by scanning

all the supported wireless channels (specified by IEEE 802.11

standard). Considering that P2P devices uses only Social

Channels (i.e., 1, 6, and 11 in the 2.4GHz band) to operate

through WiFi Direct, the Scan phase allows them to discover

also potential legacy clients operating on different channels.

The Scan phase has a predefined duration and is followed

by the Find phase, in which P2P devices alternate Search

and Listen states on the Social Channels for randomized time

periods. In this phase a device in the Search state sends

Probe Request messages in order to discover other devices

concurrently in the Listen state on the same channel. When

a device receives a Probe Request on a specific channel, it

replies with a Probe Response on the same channel, including

information to identify itself and the group it belongs to (if

the device is the GO). The convergence of two devices on the

same channel is guaranteed by the random periods in which

each device stays in the Listen state (generally between 100

and 300 ms) [2].

The Device Discovery procedure is followed by the Group

Formation in which the devices define the GO and establish

their first connection. WiFi Direct defines three different

procedures for a P2P group formation: (i) standard, in case

there is a GO negotiation through a three-way handshake,

(ii) autonomous, in case a node elects itself as GO and

announces its presence to the others through beacon messages,

(iii) persistent, in case the involved nodes already participated

in the same group and are able to rebuild it starting from

their local information (in this case there is an Invitation

procedure to join the group)1. Once the GO is identified,

the protocol implements an authentication procedure based on

WiFi Protected Setup (WPS) in order to establish a secure

wireless connection mainly based on a PIN code exchange

[2]. Then, there is the devices’ address configuration phase

in which nodes receive an IP address assigned by a DHCP

server running on the GO. It is worth noting that, in case of a

persistent group, the involved nodes are already authenticated

and they can directly exchange the wireless keys reducing the

WPS phase duration.

WiFi Direct specifications [2] describe in detail the behavior

of the protocol in case of two nodes establishing a P2P group

in the three different ways, but the complexity increases with

the number of nodes and the group size. In addition, the

system’s performances related to the execution of the previous

procedures are strictly related to the implementation of the

protocol and to its interaction with the operating system and

the upper layer applications.

To better investigate the possibility of implementing a real

opportunistic network with users’ mobile devices, in this

paper we experimentally validate Android 4.2 implementation

of WiFi Direct by deploying a real testbed with Google

Galaxy Nexus smartphones. We start from a two nodes group

formation, analyzing the three different procedures. Then, we

analyze a case in which three nodes simultaneously try to

connect to each other to create a group and, eventually, a case

of incremental join of a group involving up to six devices.

The main target of this work is to experimentally set up an

opportunistic network without neither modifying the internal

operating system drivers or requiring an explicit interaction

from the user. In fact, in previous versions of Android it was

not possible to establish D2D communications without rooting

the device and forcing the use of ad-hoc communications [8].

With the introduction of WiFi Direct, opportunistic commu-

nications can become a reality even though several work is

needed to analyze the protocol performances in case of nodes’

mobility and high churn rates (as general characteristics of

opportunistic networks). This last investigation is currently a

work-in-progress.

1Details on the execution of the three different procedures will be providedin Section III.

B. Android and WiFi Direct

Android provides Wi-Fi Direct APIs (also known as

WiFiP2P) [9] to mobile applications as a high-level access

to networking operations internally managed by WiFi Di-

rect framework that, in case of Android/Linux OS, is the

wpa supplicant process [10]. The process maintains also a

local configuration file (p2p supplicant.conf) in which it stores

the local device’s configuration parameters and information

about possible persistent groups. In case the local node is a

GO, it includes also the list of peers participating to the same

group. WiFiP2P APIs allows mobile applications to:

• discover, request information, and connect to other peers;

• be notified of the success or failure of the previous

operations in terms of local interactions between the

application and the framework;

• register intents that notify the application of specific

events detected by the framework through networking op-

erations (e.g., a dropped connection or a newly discovered

peer).

It is worth noting that WiFi Direct communications gen-

erally request the user’s authorization through a PushButton

mechanism during a Provision Discovery procedure that fol-

lows the device discovery phase. In order to allow the real

implementation of opportunistic networks in which the device

could experience high frequency connection’s attempts and

consequent user’s authorization requests, it would be useful

to allow mobile applications to avoid this procedure, at least

for the nodes running the same application, requiring a general

authorized consent by the user (just once). However, this is not

possible by using standard WiFiP2P APIs, while it can be done

by exploiting some procedures implemented as Android hid-

den APIs. Applications can invoke hidden APIs through Java

reflection or customized SDK. However, their implementation

is not fully guaranteed since they are not officially released

[11]. Applications can benefit from the use of hidden APIs

also for other operations, like the request to remove a persistent

group from the wpa supplicant configuration file, or to recover

the information related to a group identifier to execute specific

operations. In this way, the application developer has a greater

control on the group’s management operations that can be

really useful, for example, in case of forwarding protocols

implementation.

In order to validate Android 4.2 implementation of WiFi

Direct, according to the general description provided by of-

ficial specifications, we decided to analyze both application

level messages and those exchanged at the network level. To

this aim, we used Google Galaxy Nexus smartphones as nodes

participating in the group formation, and three laptops, with

wireless cards in monitor mode, as sniffers. In this way, we

were able to observe all the packets sent on the network on

each Social Channel (especially for the discovery phase). In

the next sections we present the performance results obtained

through real experiments with two, three and six smartphones.

In the first case we focus on the analysis of device discovery

and group formation phases in the three different settings (i.e.,

Device A

wpa_sapp

wifiP2PManager.

discoverPeers()

discovery

P2P-Device-Found B

Device B

wpa_sapp

wifiP2PManager.

discoverPeers()

P2P-Device-Found AwifiP2PManager.connect(B)

discovery

wifiP2PManager.connect(A)

Provision Discovery Request

Provision Discovery Response

wps wps

dhcp dhcp

Go Negotiation Request

Go Negotiation Response

Go Negotiation Confirmation

Beacon

Become Go

Connected (GO) Connected (CLIENT)

Fig. 1. Standard Group Formation

standard, autonomous and persitent), comparing the obtained

results with those presented in [7]. Then, by increasing the

number of nodes, we analyze the protocol reactions to specific

events, like the simultaneous request to create a group and the

incremental join of a group, in order to evaluate the protocol’s

time response and the reaction to possible errors.

III. TWO-NODES EXPERIMENTAL RESULTS

Let us consider two devices, A and B. Figure 1 shows

a sequence diagram explaining the main interactions be-

tween an Android app and wpa supplicant process running

on the two nodes in order to discover each other and to

establish a P2P group based on the standard procedure.

To start a device discovery procedure, the application must

call WiFiP2PManager.DiscoverPeers() that requests

wpa supplicant to start the Scan and Find phases. The dis-

covery remains active until a connection is initiated or a

group is formed, otherwise it is stopped automatically after

120s (timeout introduced by the Android implementation).

Every time a new node is discovered, wpa supplicant notifies

the application with a ”P2P Device Found” event and the

application can invoke the function to extract the node’s

information necessary to execute a connection. The connection

request is followed by a Provision Discovery phase (to require

the user’s authorization) and the negotiation procedure.

In case of autonomous mode, the discovery is limited to

the Scan phase and the negotiation is completely removed

since the GO simply announces its presence through Bea-

con messages on the Social channels. Instead, in case of

a persistent group formation, the nodes execute the device

discovery followed by an Invitation procedure (instead of

GO negotiation) in which both a client or a GO (prefixed

roles) can invoke the creation of the group. In the Invitation

Request/Response messages the nodes specify a configuration

timeout as the interval of time needed by each device to be

ready for establishing the group after receiving a successful

Invitation response. The introduction of this additional time

should reduce the probability of a join failure. In addition, in a

persistent group formation, since the nodes already know each

other, they don’t require the execution of the authentication

phase and the WPS phase is limited to the keys’ exchange.

Figures 2 (a) and (b) show the cumulative distribution

function (cdf) of times required for the discovery and group

formation phases obtained by 250 experiments for each of the

three different procedures. Each plot represents the average of

the times experienced by the two nodes. We can note that in

the autonomous case each node spends about 1s to discover the

other in all the experiments. This is related to the configuration

of the autonomous mode in which the discovery is limited to

the Scan phase. Instead, persistent and standard configurations

experience discovery times in the range [1.48s, 15.35s] and

[1.5s, 15.9s], respectively. This is due to the random duration

of the Find phase in which the two nodes must converge on

the same channel and receive the probe messages.

By analyzing the group formation procedures, we can note

that the autonomous case maintains a large distance from the

other two cases by experiencing 3s to form the group in the

92% of the experiments, and an additional delay of 5s in the

last 8%. Looking at wpa supplicant log files, we discovered

that in those cases an error occurred during the WPS phase

and the process introduces a delay of 5s before re-starting

the WPS procedure. The same error has been experienced

in the standard configuration (in 9.5% of cases) requiring an

average time of 12.26s to form the group. However, there are

additional cases with higher times (3.5%), not influenced by

WPS errors, but presenting delays in other phases: (i) during

the GO negotiation phase due to a message loss, (ii) during the

addressing phase due to a delay in the DHCP server response.

Considering that the discovery and group formation procedures

are independent in their execution, we can note in Figure 2 (c)

that in the worst cases a standard group formation can require

about 23s to successfully complete.

A surprising result arises from the evaluation of the per-

sistent group formation. In this case we expect to experience

lower times to form the group with respect to the standard

configuration by reducing the WPS phase, but this never

happens. In fact, even though in all the experiments the

invitation procedure successfully completes, the client initially

fails to join the group. This is due to the immediate tentative

of the client to connect to the GO while it is still configuring

the group (GO spends around 600ms to start the P2P group

session and to send the group ID on the network, essential

information for the client to join the group). In this case,

wpa supplicant delays the subsequent client’s tentative of

exactly 5s. This problem could be solved by setting the

appropriate timeout for the client before trying to join the

group after the invitation procedure (currently set to 200ms).

Comparing all the results with those presented in [7], we

can note that we always experienced lower times in the

autonomous configuration (especially in the discovery phase,

with a difference of about 2s), while in the standard and

persistent configurations we experienced higher times only

Device A

app

wifiP2PManager.discoverPeers()

discovery

P2P-Device-Found B

Device B

wpa_sapp

wifiP2PManager.discoverPeers()

P2P-Device-Found AwifiP2PManager.connect(B)

discovery

wifiP2PManager.connect(A)

wps wps

dhcp dhcp

negotiationwith B

negotiationwith A

Device C

wpa_sapp

wifiP2PManager.discoverPeers()

P2P-Device-Found B

discovery

P2P-Device-Found B

Connection Failed

discovery

wifiP2PManager.connect(B)

wifiP2PManager.connect(B)

P2P-GO-NEG-FAILURE|GROUP-FORM-FAILURE|P2P-DEVICE-LOST

wpa_s

Connected (GO) Connected (CLIENT)

Beacon

Fig. 3. Three nodes Group Formation.

in 20% of cases due to the implementation issues described

above. In any case, we can summarize that the autonomous

mode has the best performances to complete a group formation

of two nodes. However, in a highly dynamic environment such

as opportunistic networks, the a priori selection of a GO should

include the analysis of several parameters in order to guarantee

a minimum network stability. The autonomous configuration

is suitable indeed for an incremental group formation as we

can observe in the last set of experiments.

IV. THREE NODES: SIMULTANEOUS GROUP FORMATION

REQUEST

In these experiments three devices simultaneously try to

build up a WiFi Direct group. Since the group formation is a

procedure involving only two nodes, the request of the third

one is rejected with different error messages and consequent

different delays to form the entire group. Figure 3 shows the

sequence diagram of the operations executed by the Android

application and related wpa supplicant process on the three

nodes.

All the nodes start the discovery phase simultaneously. A

and B find each other and start the GO negotiation phase

in the standard configuration. In the meanwhile, C finds

one of the other two nodes and tries to connect to it. The

protocol’s reaction to this event differs depending on several

parameters: (i) the time in which C starts the connection

operation with respect to the status of the other two nodes

(i.e., GO negotiation completed or not, group formed or not),

(ii) if C selects the GO or the client as destination of the

connection request. We ran 30 experiments and we are able to

distinguish among 7 different cases as shown in Figure 42. Let

us assume that A is always elected as GO, we identified the

following situations including a single optimal case (without

errors):

2The figure shows the type of error occurred, the percentage of occurrences,average time to complete the group (including the discovery phase) and 95%confidence intervals.

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12 14 16

P(X

<t)

t - sec

autonomouspersistentstandard

(a) Cdf Discovery

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30

P(X

<t)

t - sec

autonomouspersistentstandard

(b) Cdf Group Formation

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30

P(X

<t)

t - sec

autonomouspersistentstandard

(c) Cdf Discovery and Group Formation

Fig. 2.

• A-B negotiation phase is successfully completed and C

discovers A as GO. C’s connection request represents a

request to join an autonomous group, but when A receives

the request it is still completing the WPS phase with B.

A immediately sends a Group Formation Failure (GFF)

to C that starts a new discovery phase and successfully

join the group. In this case, C requires on average 12.3s

to complete the operation (13% of cases).

• C tries to connect to B, client of the original group.

In this case it receives a Provision Discovery Failure

(PDF) 8s after the connection request and starts a new

discovery phase in which it receives a beacon message

from A (GO). At this point it is able to join the group.

In this case C experiences 16.1s on average to join

the group (20%). It is worth noting that, in general,

when a new group starts, all the participants remove

the other discovered devices from their internal lists,

maintaining only the group participants. Therefore, it can

happens that the third node successfully completes the

Provision Discovery phase with the GO and waits to be

accepted as member of the group, but since the other two

nodes already formed a group it is forced to start a new

discovery phase. This introduces a delay of about 60s to

complete the operation (7%).

• C sends a Negotiation Request to A while it is completing

the negotiation phase with B. In this case C receives a

P2P GO negotiation failure (GO-Neg-Fail) message from

A about 99s after the connection request. This happens

in 40% of the experiments, requiring on average 109s to

C to join the group.

• C does not receive any message after the connection

request. wpa supplicant notifies a Device Lost event,

which invokes a new discovery phase. This represents the

worst case, requiring on average 130s to join the group

(7%).

Finally, we also experienced a few cases in which C fails

twice in the join operation. The first failure due to one of

the previous cases and the second one trying to connect to

the client node even after the group has been formed. This

is mainly due to a delay in wpa supplicant notifications of

discovered nodes. In this case C discovers B as the first node

available and tries to connect to it before being notified of the

GO’s presence. In those cases, the join operation can require

up to 2min to complete.

These experiments show the application’s performances in

0

20

40

60

80

100

120

140

No fa

ilure

GFF

PD

F

Request

new

dis

covery

(c)

GO

-Neg-F

ail

Double

erro

r

Devic

elo

st

sec

3% 13% 20%

7%

40%10%

7%

Fig. 4. Times and errors during the three-nodes experiments.

Fig. 5. Six nodes: incremental join.

case of simultaneous requests from three nodes to create

a WiFi Direct group. Replicating the same experiments by

using four nodes, we could expect that nodes organize in two

different groups with the same probability that they discover

each other as two separate couples. Actually, we found that

the protocol is able to successfully form a single group in 90%

of cases with times in the range [86.5s, 275s].

These configurations reflect a possible situation in which

three/four friends meet in a location and their devices tries

to establish simultaneously an opportunistic network in order

to exchange contents. Even though this case is possible, it is

more likely that users and mobile devices start to discover

each other not really at the same time, but incrementally, with

variable delays in the joining procedure. To test the reaction

of the protocol to this situation we performed the following

set of experiments.

0

0.2

0.4

0.6

0.8

1

3 5 6 7 10 2 4 8 16 32 64 128

P(X

<t)

t - sec

A/BCDEF

(a) Cdf Single node group’s join.

0

0.2

0.4

0.6

0.8

1

10 12 14 22 8 16 32 64 128

P(X

<t)

t - sec

(A,B)(A,B,C)

(A,B,C,D)(A,B,C,D,E)

(A,B,C,D,E,F)

(b) Cdf Incremental group formation.

Fig. 6.

V. INCREMENTAL GROUP FORMATION

We set up a testbed with six Google Galaxy Nexus smart-

phones as shown in Figure 5. A and B start creating a standard

group, followed sequentially by nodes C, D, E and F that

directly request to join the group after receiving GO’s beacon

messages. We ran 30 experiments during which each join

request is delayed of 150s in order to allow the previous nodes

to complete their operations and to avoid error situations in

the group formation phase. Figure 6 (a) shows the cdf of the

times required by each node to complete its join procedure

as absolute time (i.e., starting from its discovery phase). The

line representing the higher times is related to the standard

group formation between A and B, which includes the GO

negotiation procedure. The other nodes measure less than 15s

to complete the procedure except for the last node (i.e., F)

which experiences additional delays in 13% of cases due to

repeated failures in the original join request. This is due to

the wpa supplicant notification of the list of discovered nodes

with separate ”P2P Device Found” events. Since the local

node cannot know a priori who is the GO (if not notified

by the framework), we select the first available neighbor as

connection’s destination in order to join the group. In this

case the local node experiences one of the error explained

in the previous section, introducing a variable delay in the

join procedure up to a maximum value of 120s in case of

connection’s timeout expiration. Also other nodes experience

some failure in the join procedure but always managed with a

rapid notification (e.g., 6s on average), making the new client

able to successfully conclude the operation with a limited

delay. Figure 6 (b) shows the cdf of times required to form

the incremental group. We can note that, up to five nodes,

the group formation has a similar cdf behaviour, translating

each case of about 5s, which is also the average time required

to complete the join of an autonomous group without errors.

Only in the last case we experience higher delays, reaching

the maximum time of 159s due to the same reasons explained

above. These results reflect the complexity of WiFi Direct to

manage a variable number of nodes joining the same group

and the need to introduce additional policies at the appli-

cation/middleware layer to manage additional constraints of

opportunistic networks like nodes’ mobility and heterogeneous

devices.

VI. CONCLUSION

Experimental analysis of WiFi Direct through real testbeds

allows us to analyze advantages and constraints of using this

protocol in order to actually deploy opportunistic networks on

a large scale. However, this represents only the first work in

this direction since opportunistic networks are characterized by

several dynamic parameters that must be taken into account

and that can highly influence the performances of this protocol.

To this aim, we are planning to integrate the support of

WiFi Direct protocol inside our middleware platform CAMEO

(Context-Aware Middleware for Opportunistic Networks) [5]

aimed at implementing context- and social-aware policies for

the smart management of users’/devices’ resources and the op-

timized dissemination and sharing of useful contents through

the Mobile Social Network (MSN) paradigm [3]. CAMEO

represents a common platform to develop MSN applications in

several applications domains, by exploiting multi-dimensional

context information related to the user, her devices and the

surrounding environment. In this scenario WiFi Direct can

pave the way for the large scale use of opportunistic networks

and MSN applications.REFERENCES

[1] L. Pelusi, A. Passarella, and M. Conti, “Opportunistic networking: dataforwarding in disconnected mobile ad hoc networks,” CommunicationsMagazine, IEEE, vol. 44, no. 11, pp. 134–141, 2006.

[2] “Wifi alliance: Wifi direct specifications.” [Online]. Available:http://www.wi-fi.org/discover-and-learn/wi-fi-direct

[3] M. Conti and M. Kumar, “Opportunities in opportunistic computing,”Computer, vol. 43, no. 1, pp. 42–50, 2010.

[4] S. Trifunovic, B. Distl, D. Schatzmann, and F. Legendre, “Wifi-opp:ad-hoc-less opportunistic networking,” in Proceedings of the 6th ACMworkshop on Challenged networks. ACM, 2011, pp. 37–42.

[5] V. Arnaboldi, M. Conti, and F. Delmastro, “Implementation of cameo:A context-aware middleware for opportunistic mobile social networks,”in IEEE International Symposium on World of Wireless, Mobile andMultimedia Networks (WoWMoM), 2011. IEEE, 2011.

[6] V. Arnaboldi, M. Conti, F. Delmastro, G. Minutiello, L. Ricci,“DroidOppPathFinder: A Context and Social-Aware Path RecommenderSystem Based on Opportunistic Sensing,” IEEE WoWMoM 2013 Demosession.

[7] D. Camps-Mur, A. Garcia-Saavedra, and P. Serrano, “Device to devicecommunications with wifi direct: overview and experimentation,” IEEEWireless Communications Magazine, 2012.

[8] [Online]. Available: http://android-developers.blogspot.it/2010/12/its-not-rooting-its-openness.html

[9] “Wifi direct android apis.” [Online]. Available:http://developer.android.com/guide/topics/connectivity/wifip2p.html

[10] wpa supplicant and WiFi P2P. [Online]. Available:https://android.googlesource.com/platform/external/wpa supplicant 8

[11] A. P. Felt, E. Chin, S. Hanna, D. Song, and D. Wagner, “Androidpermissions demystified,” in Proceedings of the 18th ACM conferenceon Computer and communications security. ACM, 2011, pp. 627–638.