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 account
all the parameters that can emerge from an opportunistic
network scenario, not only in terms of technical requirements
(e.g., available resources and connectivities) but also of users
characteristics and profiles, which can heavily influence the
system’s performances and devices’ interactions. In this work
we investigate the feasibility of creating opportunistic networks
on top of WiFi Direct framework by analyzing the protocol’s
performances in real scenarios with a variable number of
mobile devices. Experimental results show the times required
to form a group of variable size and the best configurations
to support opportunistic networking operations and upper layer
applications.
Index Terms—WiFi Direct, P2P, opportunistic networks, mo-
bile social networks
I. I NTRODUCTION
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 project
SmartHealthyENV (POR-CREO FESR 2007-2013) and by Registro .it under
the project CAPP-Collective Awareness Participatory Platform.
978-1-4799-0543-0/13/$31.00 ©2013 IEEE
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
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. W I F I D IRECT 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.
1 Details on the execution of the three different procedures will be provided
in 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 Device B
app wpa_s app wpa_s
wifiP2PManager. wifiP2PManager.
discoverPeers() discoverPeers()
discovery
P2P-Device-Found B
discovery
wifiP2PManager.connect(B)
P2P-Device-Found A
wifiP2PManager.connect(A)
Provision Discovery Request
Provision Discovery Response
Go Negotiation Request
Go Negotiation Response
Go Negotiation Confirmation
Become Go
Beacon
wps wps
dhcp dhcp
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. T WO - NODES E XPERIMENTAL 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 Device A Device B Device C
should reduce the probability of a join failure. In addition, in a app wpa_s app wpa_s app wpa_s
persistent group formation, since the nodes already know each wifiP2PManager. wifiP2PManager. wifiP2PManager.
discoverPeers() discoverPeers() discoverPeers()
other, they don’t require the execution of the authentication
phase and the WPS phase is limited to the keys’ exchange. discovery
discovery
Figures 2 (a) and (b) show the cumulative distribution P2P-Device-Found B
P2P-Device-Found A
wifiP2PManager.connect(B) P2P-Device-Found B
function (cdf) of times required for the discovery and group wifiP2PManager.connect(A)
wifiP2PManager.connect(B) discovery

formation phases obtained by 250 experiments for each of the

negotiation negotiation
three different procedures. Each plot represents the average of with B with A

P2P-Device-Found B
the times experienced by the two nodes. We can note that in wifiP2PManager.connect(B)

wps wps
the autonomous case each node spends about 1s to discover the
other in all the experiments. This is related to the configuration dhcp dhcp

of the autonomous mode in which the discovery is limited to P2P-GO-NEG-FAILURE|

Connection Failed
the Scan phase. Instead, persistent and standard configurations GROUP-FORM-FAILURE|
P2P-DEVICE-LOST
Connected (GO) Connected (CLIENT)
experience discovery times in the range [1.48s, 15.35s] and Beacon
discovery

[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
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. T HREE 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):
2 The 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.
 1 1 1

0.8 0.8 0.8

P(X<t) 0.6 0.6 0.6

P(X<t)

P(X<t)
0.4 0.4 0.4

0.2 0.2 0.2

autonomous autonomous autonomous
persistent persistent persistent
standard standard standard
0 0 0
0 2 4 6 8 10 12 14 16 0 5 10 15 20 25 30 0 5 10 15 20 25 30
t - sec t - sec t - sec

(a) Cdf Discovery (b) Cdf Group Formation (c) Cdf Discovery and Group Formation
Fig. 2.

• A-B negotiation phase is successfully completed and C 7%

140
discovers A as GO. C’s connection request represents a 40%
10%
120
request to join an autonomous group, but when A receives
100
the request it is still completing the WPS phase with B. 7%
80

sec
A immediately sends a Group Formation Failure (GFF)
60
to C that starts a new discovery phase and successfully
40
join the group. In this case, C requires on average 12.3s 20
3% 13% 20%

to complete the operation (13% of cases). 0

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

newdiscovery
•

GO-Neg-Fail
No failure

Request

Double

Device
In this case it receives a Provision Discovery Failure

error
PDF
GFF

lost
(c)
(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.
Fig. 4. Times and errors during the three-nodes experiments.
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 Fig. 5. Six nodes: incremental join.
in 40% of the experiments, requiring on average 109s to
C to join the group.
• C does not receive any message after the connection case of simultaneous requests from three nodes to create
request. wpa supplicant notifies a Device Lost event, a WiFi Direct group. Replicating the same experiments by
which invokes a new discovery phase. This represents the using four nodes, we could expect that nodes organize in two
worst case, requiring on average 130s to join the group different groups with the same probability that they discover
(7%). each other as two separate couples. Actually, we found that
the protocol is able to successfully form a single group in 90%
Finally, we also experienced a few cases in which C fails of cases with times in the range [86.5s, 275s].
twice in the join operation. The first failure due to one of
These configurations reflect a possible situation in which
the previous cases and the second one trying to connect to
three/four friends meet in a location and their devices tries
the client node even after the group has been formed. This
to establish simultaneously an opportunistic network in order
is mainly due to a delay in wpa supplicant notifications of
to exchange contents. Even though this case is possible, it is
discovered nodes. In this case C discovers B as the first node
more likely that users and mobile devices start to discover
available and tries to connect to it before being notified of the
each other not really at the same time, but incrementally, with
GO’s presence. In those cases, the join operation can require
variable delays in the joining procedure. To test the reaction
up to 2min to complete.
of the protocol to this situation we performed the following
These experiments show the application’s performances in set of experiments.
 1 1
0.8
0.6
P(X<t)
0.4
0.2
0 0
2 3 4 5 6 7 8 10 16 32
t - sec
(a) Cdf Single node group’s join.
V. I NCREMENTAL 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.
0.8
0.6
P(X<t)
0.4
A/B (A,B)
C 0.2 (A,B,C)
D (A,B,C,D)
E (A,B,C,D,E)
F (A,B,C,D,E,F)
64 128 8 10 12 14 16 22 32 64 128
t - sec
(b) Cdf Incremental group formation.
Fig. 6.
VI. C ONCLUSION
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.
R EFERENCES
[1] L. Pelusi, A. Passarella, and M. Conti, “Opportunistic networking: data
forwarding in disconnected mobile ad hoc networks,” Communications
Magazine, 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 ACM
workshop 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 and
Multimedia Networks (WoWMoM), 2011. IEEE, 2011.
[6] V. Arnaboldi, M. Conti, F. Delmastro, G. Minutiello, L. Ricci,
“DroidOppPathFinder: A Context and Social-Aware Path Recommender
System Based on Opportunistic Sensing,” IEEE WoWMoM 2013 Demo
session.
[7] D. Camps-Mur, A. Garcia-Saavedra, and P. Serrano, “Device to device
communications with wifi direct: overview and experimentation,” IEEE
Wireless 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, “Android
permissions demystified,” in Proceedings of the 18th ACM conference
on Computer and communications security. ACM, 2011, pp. 627–638.