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: rstname.lastname@iit.cnr.it
AbstractWiFi Direct introduces new opportunities to de-
ploy real opportunistic networks through users mobile devices.
However, its original specication 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 proles, which can heavily inuence the
systems performances and devices interactions. In this work
we investigate the feasibility of creating opportunistic networks
on top of WiFi Direct framework by analyzing the protocols
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 congurations
to support opportunistic networking operations and upper layer
applications.
Index TermsWiFi 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 dening 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 congured 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.
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 specications 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 specications (e.g., available resources
and connectivities) but also personal users proles 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 efcient and personalized services.
Specically, 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 interactions 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 rst 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 conguration 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 conguration with our nodes as
explained in Section III. In addition, we evaluate the protocol
performances in different congurations 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, dening 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 dened 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 GOs 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 specied 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 protocols
performances in real scenarios involving a variable number of
mobile devices.
A. Device Discovery and Group Formation
The rst step in the denition 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 (specied 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 predened 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 specic 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 dene the GO and establish
their rst connection. WiFi Direct denes 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 identied,
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 conguration 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 specications [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
systems 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 conguration le (p2p supplicant.conf) in which it stores
the local devices conguration 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 notied 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 specic
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 users 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 connections attempts and
consequent users 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
reection or customized SDK. However, their implementation
is not fully guaranteed since they are not ofcially released
[11]. Applications can benet from the use of hidden APIs
also for other operations, like the request to remove a persistent
group from the wpa supplicant conguration le, or to recover
the information related to a group identier to execute specic
operations. In this way, the application developer has a greater
control on the groups 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-
cial specications, 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 rst case we focus on the analysis of device discovery
and group formation phases in the three different settings (i.e.,
Device A
wpa_s app
wifiP2PManager.
discoverPeers()
discovery
P2P-Device-Found B
Device B
wpa_s app
wifiP2PManager.
discoverPeers()
P2P-Device-Found A
wifiP2PManager.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 specic
events, like the simultaneous request to create a group and the
incremental join of a group, in order to evaluate the protocols
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 noties
the application with a P2P Device Found event and the
application can invoke the function to extract the nodes
information necessary to execute a connection. The connection
request is followed by a Provision Discovery phase (to require
the users 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 (prexed
roles) can invoke the creation of the group. In the Invitation
Request/Response messages the nodes specify a conguration
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 dont 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 conguration
of the autonomous mode in which the discovery is limited to
the Scan phase. Instead, persistent and standard congurations
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 les, 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 conguration (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 inuenced 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
conguration 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 conguring
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 clients 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 conguration (especially in the discovery phase,
with a difference of about 2s), while in the standard and
persistent congurations we experienced higher times only
Device A
app
wifiP2PManager.
discoverPeers()
discovery
P2P-Device-Found B
Device B
wpa_s app
wifiP2PManager.
discoverPeers()
P2P-Device-Found A
wifiP2PManager.connect(B)
discovery
wifiP2PManager.connect(A)
wps wps
dhcp dhcp
negotiation
with B
negotiation
with A
Device C
wpa_s app
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 conguration
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 nd each other and start the GO negotiation phase
in the standard conguration. In the meanwhile, C nds
one of the other two nodes and tries to connect to it. The
protocols 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 4
2
. Let
us assume that A is always elected as GO, we identied the
following situations including a single optimal case (without
errors):
2
The gure shows the type of error occurred, the percentage of occurrences,
average time to complete the group (including the discovery phase) and 95%
condence 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
autonomous
persistent
standard
(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
autonomous
persistent
standard
(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
autonomous
persistent
standard
(c) Cdf Discovery and Group Formation
Fig. 2.
A-B negotiation phase is successfully completed and C
discovers A as GO. Cs 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 noties 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 rst 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 notications of
discovered nodes. In this case C discovers B as the rst node
available and tries to connect to it before being notied of the
GOs presence. In those cases, the join operation can require
up to 2min to complete.
These experiments show the applications performances in
0
20
40
60
80
100
120
140
N
o

f
a
i
l
u
r
e
G
F
F
P
D
F
R
e
q
u
e
s
t
n
e
w
d
i
s
c
o
v
e
r
y
(
c
)
G
O
-
N
e
g
-
F
a
i
l
D
o
u
b
l
e
e
r
r
o
r
D
e
v
i
c
e
l
o
s
t
s
e
c
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 congurations reect 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/B
C
D
E
F
(a) Cdf Single node groups 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 GOs 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 notication 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 notied
by the framework), we select the rst available neighbor as
connections 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
connections timeout expiration. Also other nodes experience
some failure in the join procedure but always managed with a
rapid notication (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 ve 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 reect 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 rst work in
this direction since opportunistic networks are characterized by
several dynamic parameters that must be taken into account
and that can highly inuence 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: data
forwarding in disconnected mobile ad hoc networks, Communications
Magazine, IEEE, vol. 44, no. 11, pp. 134141, 2006.
[2] Wi alliance: Wi direct specications. [Online]. Available:
http://www.wi-.org/discover-and-learn/wi--direct
[3] M. Conti and M. Kumar, Opportunities in opportunistic computing,
Computer, vol. 43, no. 1, pp. 4250, 2010.
[4] S. Trifunovic, B. Distl, D. Schatzmann, and F. Legendre, Wi-opp:
ad-hoc-less opportunistic networking, in Proceedings of the 6th ACM
workshop on Challenged networks. ACM, 2011, pp. 3742.
[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 wi 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] Wi direct android apis. [Online]. Available:
http://developer.android.com/guide/topics/connectivity/wip2p.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 demystied, in Proceedings of the 18th ACM conference
on Computer and communications security. ACM, 2011, pp. 627638.