1. Wireless Sensor Networks Using Android Virtual Devices and Near Field
Communication Peer-To-Peer Emulation
Doug Serfass, Kenji Yoshigoe
Department of Computer Science
University of Arkansas at Little Rock
Little Rock, AR, USA
djserfass,kxyoshigoe@ualr.edu
Abstract—Several new Android smartphones support Near
Field Communication (NFC). The Android SDK provides an
NFC API that can be used to develop NFC applications
that conduct peer-to-peer (P2P) data exchange. The Android
emulator does not support P2P communication between instances of the Android Virtual Device (AVD). In addition to
this constraint, P2P experimentation on actual smartphones is
difficult due to limited NFC support. To fill the gap created
by this minimal support, we propose the JavaMail NFC
API (JNFC). JNFC uses the JavaMail API to emulate the
functionality of the Android NFC P2P API. To evaluate the
performance of JNFC, we created the DroidWSN Wireless
Sensor Network (WSN) model and implemented it as an
Android application. We design and conduct an experiment
for our DroidWSN model to measure the execution time of
our Android application WSN on AVDs. We compare our
simulation results against those from a similar experiment that
measured the execution time of a WSN composed of Sun SPOT
wireless devices. While the execution time of our DroidWSN
model is slower, we assert that our design is more simple and
flexible than that of our comparison study. We conclude that
this benefit and the factors of JNFC cost (it is open source),
the quality and quantity of Android smartphone sensors, and
imminent Android smartphone support for NFC P2P, combine
to make JNFC and the Android AVD a platform for NFC and
WSN research. Our study also emphasizes the need for Google
to create Android NFC P2P and sensor emulation APIs.
smartphones, the AVD does not support most of these same
sensors. Android developers must solve this problem through
sensor emulation. For example, the camera can be emulated
using a camera preview API [2].
We created JNFC by using the JavaMail API [3] to
emulate the functionality of the Android NFC P2P API [4].
The purpose of this study is to prove that JNFC and the
Android AVD are a platform for NFC and WSN research.
To facilitate our proof, we divise our DroidWSN model
and implement it as an Android application. Our Android
application also emulates using the NFC reader as a sensor
to read a simulated NFC tag. We use our Android application
to evaluate the performance of JNFC and compare our
simulation results against a similar study.
This paper consists of the following sections: Section 2 is
recent related work on WSN in the context of smartphones,
NFC and emulation.; Section 3 is a brief description of
Android NFC P2P.; Section 4 describes our implementation of JNFC.; Section 5 details our evaluation of JNFC
consisting of our DroidWSN model and AVD experiment
and simulation result.; Section 6 is our conclusions and
suggestions for future research.
Keywords-near field communication; p2p; wireless sensor
network
II. R ELATED W ORK
I. I NTRODUCTION
Google’s selection of Java has made it easy for developers
to create Android applications. Google also provides the
Android Development Tools (ADT), a custom plugin for the
Eclipse IDE. From inside Eclipse, the ADT gives developers
access to the AVD, an emulator configuration that models
an actual device (smartphone) by defining hardware and
software options to be emulated by the Android Emulator.
The Android APIs are composed of numerous packages
and classes that facilitate developer access to the features of
any Android model smartphone. These features include an
extensive collection of sensors. Android NFC [1], although
not classified as a sensor, can be loosely defined as a sensor
in that it reads NFC tags. While the Android APIs provide
such rich access to Android sensors on Android model
978-1-4673-1375-9/12/$31.00 ©2012 IEEE
Zhang et al. [5] presented uSink, a cross platform, smartphone based, mobile sink for WSNs. uSink is composed
of a Zigbee uSD card, the Zigbee uSD SDK, uSinkWare
smartphone middleware and two smartphone applications
based on uSinkWare, uSniffer and uController. The authors
experimental results show that a smartphone can be used as
a mobile sink.
Lin et al. [6] created Dandelion, a framework for developing wireless body sensor applications on smartphones.
Dandelion provides: a platform-agnostic programming abstraction for in-sensor data processing, called senselet; transparent integration of senselets and smartphone code; and
platform-independent development and distribution of senselets. Their study significantly reduces the development time
required to program wireless body sensors.
Ali et al. [7] presented an extension simulation module for
the NFC Interface and Protocol (NFCIP-1) over the Network

2. Simulator ns-2. Their simulation module plays an important
role in the study of the NFC protocol by enabling evaluation
of proposed solutions without implementation. The implemented module is efficient as it is proven that simulated
results differ from measured values by an approximate value
of 12% for data transfer and 8% for throughput.
III. A NDROID NFC P2P
Android NFC P2P [8] is available in Android 2.3.3
(API level 10). To transmit a message over NFC, a
smartphone must support this API level and be NFCcompliant. To receive a message over NFC, a smartphone
must be NFC-compliant and support this API level and
the com.android.npp NDEF push protocol. All Android
applications must include a class that extends the android.app.Activity class. Methods of the Activity class are
overridden in order to implement NFC P2P.
We name the smartphone transmitting an NFC message
the TransmitSmartphone and the smartphone receiving an
NFC message the ReceiveSmartphone. To initiate NFC P2P,
the ReceiveSmartphone starts the application that contains
the ReceiveActivity class, the TransmitSmartphone waits
until the ReceiveSmartphone application is running and,
finally, the TransmitSmartphone starts the application that
contains the TransmitActivity class. If the TransmitSmartphone is running and the TransmitSmartphone and the
ReceiveSmartphone are closer than 4cm, then NFC P2P will
occur. Figure 1 shows the Android NFC P2P process.
method of the android.nfc.NfcAdapter class. This method
will set up a listener for the Intent being filtered such that
when the listener detects an Intent matching the IntentFilter
(in our case, an NFC Message), the listener will call the
ReceiveActivity class onNewIntent method.
An NFC message is an instance of the class android.nfc.NdefMessage. The constructor for NdefMessage
has one argument, an android.nfc.NdefRecord array. An
NdefRecord is created from a String and is used to populate
the zero index element of an NdefRecord array. The onResume method is called when the TransmitActivity class starts
to interact with a user. After an NFC message is created,
the enableForegroundNdefPush method of the NfcAdapter
class is called to push (transmit) the NFC message to the
ReceiveSmartphone.
After the NFC Message is transmitted from the TransmitSmartphone to the ReceiveSmartphone, the ReceiveActivity class onNewIntent method is called. This method
retrieves the extended data (the NFC message) from the
Intent and returns an array of android.os.Parcelable objects,
which are cast into an NdefMessage array. At this point,
the ReceiveActivity class onNewIntent method has received
and parsed the NFC Message. Android NFC P2P is complete. The ReceiveSmartphone application that contains the
ReceiveActivity class may now use the NFC message as
dictated by the application.
IV. JNFC
JNFC is a package that uses the JavaMail API, specifically, javamail-android [3], a JavaMail port for Android,
to emulate the functionality of the Android NFC P2P API.
Source information, in the form of an NFC message created
from a String, is attached to an email message. The email
message is sent to an email inbox. The email inbox is read,
the sent email is located and the NFC message attachment is
downloaded. The original String is reconstructed from the
downloaded NFC message attachment. The algorithm for
JNFC is shown in Figure 2 and the class diagram in Figure 3.
Figure 1: Android NFC P2P Sequence Diagram
An android.content.Intent class is an abstract description
of an operation to be performed. The ReceiveSmartphone anticipates receiving an NFC message in the future and sets up
an Intent to detect this event. The Intent is initialized in the
ReceiveActivity class onCreate method. After initialization,
the Intent is passed in the ReceiveActivity class onResume
method as an argument to the enableForegroundDispatch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package jnfc;
define m, r : NFCmessage;
define n, s : String;
define p, q : Mail;
initially m, n, p, q, r, s = null;
n := "hello, world";
m := new NFCMessage();
p := new Mail();
m.setText(n);
p.setAttachment(m);
p.send();
q := new Mail();
r := q.getAttachment();
s := r.getText();
show(s); // display "hello, world"
Figure 2: JNFC Algorithm

3. To map this algorithm onto the code depicted in Figure 1,
we created the JNFC NfcAdapter class and several helper
classes. Our JNFC NfcAdapter class emulates the Google
classes NfcAdapter and android.app.Activity by implementing the methods enableForegroundNdefPush and onNewIntent. These Google methods are what allow the AVD (if
NFC were supported) or a smartphone (if it supports NFC)
to initiate P2P communication via NFC.
V. JNFC P ERFORMANCE E VALUATION
To evaluate JNFC performance, we used JNFC as the
foundation of our DroidWSN model. We designed a simulation experiment for DroidWSN and executed our simulation
on the AVD. We compared our experimental result with data
from a similar experiment conducted on an actual WSN.
A. DroidWSN Model
Our DroidWSN model uses JNFC (as the PHY protocol
layer) to simulate a multi-hop WSN. DroidWSN is also
our Android application and its Activity class is DroidWSNActivity. We use the name DroidWSN in the following
discussion to refer to both our model and our Android
application. DroidWSN source information, in the form
of an NFC message read from a simulated NFC tag, is
conveyed to a sink and, from the sink, to the Internet in the
form of a destination email inbox. The distributed algorithm
for DroidWSN is shown in Figure 5 and the class diagram
in Figure 6.
Figure 3: JNFC Class Diagram
The JNFC NfcAdapter class enableForegroundNdefPush
and onNewIntent methods may be utilized from any location
in an Android application that requires NFC P2P. When
actual NFC P2P is supported on the AVD or smartphone,
a developer will replace the JNFC API with the NFC P2P
API. Figure 4 shows how to use the JNFC NfcAdapter class.
NfcAdapter na = new NfcAdapter();
na.enableForegroundNdefPush("hello, world");
String s = na.onNewIntent();
1
2
3
4
5
6
7
8
9
10
11
12
13
program droidwsn;
define m : NFCmessage;
define n : String;
initially m, n = null;
do read NFC tag → m:=parse(NFC tag data)
2 m = null ∧ sink → n := parse(m)
2 m = null ∧ ¬sink → m to (i,j)
2 ¬empty (i,j) → receive m
2 receive m ∧ sink → n := parse(m)
2 receive m ∧ ¬sink → m to (j,k)
2 n = null → n to (sink,Internet)
2 nothing to do → sleep
od
Figure 4: Use of JNFC NfcAdapter Class
Figure 5: DroidWSN Distributed Algorithm
The enableForegroundNdefPush method and a Mail class
implement lines 6 through 11 of the JNFC algorithm. The
NFC message m in the JNFC algorithm is actually an
instance of the NdefMessage class. An NdefMessage object
is not serializable and cannot be used as an email attachment.
As a result, we convert the NdefMessage object to a byte
array and use the MIME Content-Type of application/xjava-serialized-object to attach the NdefMessage object to
an email message.
The onNewIntent method implements lines 12 through 14
of the JNFC algorithm. onNewIntent calls a Mail method,
which loops over an array of email messages from an email
inbox until it finds the email created and sent by the enableForegroundNdefPush method. When an email message with
a subject of “jnfc” is found, the Multipart content (the NFC
message attachment) of this email message is downloaded
as a ByteArrayOutputStream and converted to a byte array.
The byte array is used to construct an NdefMessage. The
NdefRecord and TextRecord [9] classes are used to get the
“hello, world” String from the NdefMessage.
The guard on line 5 is true after reading a simulated NFC
tag. We use an Intent from the NFC Demo [9] application
to generate this event. An intent-filter is added to the
AndroidManifest.xml (to allow the application to receive
the Intent) and code is used to create and start the Intent.
We use the singleTop launchMode to force the Activity
startActivity method to route the intent through a call to
the Activity onNewIntent method. The onNewIntent method
calls the resolveIntent method to parse the NFC tag data
to an NFCMessage (an NdefMessage array). These two
methods implement the action on line 5.
After the guard on line 5 has been enabled, m is not null
and one of the guards on lines 6 or 7 is true. If the node is
a sink, the guard on line 6 is true and m is parsed to the
String n, which from [9] is “Some random english text.” If
the node is not a sink, the guard on line 7 is true and node i
sends m to node j over channel (i,j). If the guard on line 6
was enabled, n is not null and the guard on line 11 is true.
The sink node sends n to the Internet (a destination email
inbox) over channel (sink,Internet).

4. Figure 6: DroidWSN Class Diagram
The enableForegroundNdefPush method was modified to
allow for node identifiers and sink nodes. If the node is a
sink, the email subject is set to a String consisting of “jnfc”,
“sink” and the date and time, for example, “jnfc|sink|4 9 21
20:46:02 GMT+00:00 2011”. If the node is not a sink, the
email subject is set to a String consisting of “jnfc”, the node
identifier and the date and time, for example, “jnfc|2|4 9 21
18:32:03 GMT+00:00 2011”. The latter subject will be used
by the action on line 8 and the next node in the hop to receive
the next m from channel (i,j).
If channel (i,j) is not empty, the guard on line 8 is true
and m is received from channel (i,j). One of the guards on
lines 9 or 10 is now true. If the receiving node j is a sink,
the guard on line 9 is true and m is parsed to the String n.
If the receiving node is not a sink, the guard on line 10 is
true and node j sends m to node k over channel (j,k). If the
guard on line 9 was enabled, n is not null and the guard on
line 11 is true. The sink node sends n to the Internet (a
destination email inbox) over channel (sink,Internet).
The onNewIntent method was modified to allow for
the previous node, node identifiers and sink nodes. The
onNewIntent method calls two Mail methods which contain
logic to get and delete m from the appropriate channel. After
these methods return to the onNewIntent method, the action
on line 8 is complete and m is received from channel (i,j).
To simulate a sensor node transceiver, we implemented
the infinite do loop on line 5 and the guard and action on
line 12. This code is the MAC protocol layer of DroidWSN
and its operation is depicted in Figure 7.
A portion of our MAC protocol layer is fixed assignment
Time Division Multiple Access (TDMA) [10]. In the fixed
assignment class of protocols, available resources are divided between nodes such that the resource assignment is
long term and each node can use its resources exclusively
without the risk of collisions. TDMA requires tight time
synchronization between nodes to avoid overlapping of signals in adjacent time slots. In JNFC, transmit “signals” are
simulated by email send and receive “signals” by email read,
delete and send. We added Transmit and ReceiveTransmit
inner classes to our DroidWSNActivity class to implement
these actions. Transmit is called after a sensor event occurs
Figure 7: DroidWSN Transmit (top, no TDMA) and ReceiveTransmit (bottom, TDMA) Sequence Diagram of MAC
Protocol Layer
(a simulated NFC tag read).
Both the Transmit and ReceiveTransmit classes extend
the android.os.AsyncTask class. AsyncTask is a computation
that runs on a background thread and whose result is
published on the UI thread. All potentially slow running operations in an Android application such as network (email),
file and database access should be executed from a class that
extends AsyncTask.
The Transmit class performs a simple, asynchronous activity (email send) and does not use TDMA. The ReceiveTransmit class encapsulates a more complex sequence of
activities consisting of one or two (email read, delete, send)
depending on if the node is not a sink (one) or a sink (two).
If the node is a sink, the second (email read, delete, send)
is required to transmit data from the child of a child of
the sink to the Internet. ReceiveTransmit uses TDMA and is
called from the class member field mUpdateTimeTask. mUpdateTimeTask, a timer, is an implementation of the interface
java.lang.Runnable and is called from the android.os.Handler
class postDelayed method as adapted from [11].
The mUpdateTimeTask class run method obtains the
“wall” clock time (as set by the phone network) from the
class android.os.SystemClock currentTimeMillis method.
Using this time ensures that all of the nodes in our WSN
are synchronized. The last line of the mUpdateTimeTask run
method calls the Handler method postAtTime to cause mUpdateTimeTask to be added to the message queue, to be run at

5. a specific time, in our case 1000ms from the current time.
The end result of this code is that the mUpdateTimeTask
class run method gets called once a second.
The mUpdateTimeTask class run method checks to see if
the seconds after the minute are equal to the TDMA slot time
assigned to a node. The slot time is equal to the node number
multiplied by 5. This calculation divides every minute into
11 slots. For example, if the node number is 3, its slot time
to handle a request and/or process a receive and transmit is
from 15-19 seconds after the minute, inclusive.
As shown in the bottom portion of Figure 7, during
a receive and transmit, the NfcAdapter class performs a
read (getNdefMessageAttachment) followed by a delete
(deleteMessage). If the node is a sink, then in succession the
guards on lines 9 and 11 are enabled. The sink node sends
(send method call) n (the String read from a simulated NFC
tag by another node several hops in the past) to the Internet
(a destination email inbox) over channel (sink,Internet). If
the node is not a sink, then the guard on line 10 is enabled
and node j sends (enableForegroundNdefPush method call)
m (the NFCMessage received by node j) to node k over
channel (j,k).
Selecting “Transmit Receive State” [12] from our application menu activates the transceiver as described above.
Selecting “Sleep State” switches the transceiver off. This
action would actually result in less energy being used by a
smartphone battery as the DroidWSN application remains in
the foreground without executing any application code.
This algorithm collects all available data from the nodes
and transfers it to a central off network computing facility.
This leads to high response accuracy as all processing
is done off the network. It also leads to complete data
reusability as all datum are transferred off the network and
can be stored in full resolution. The negative effect of this
approach is a high data transfer cost. The Request and
ReceiveTransmit classes execute methods (called from our
timer) implement the central data optimized algorithm as
shown in Figure 9.
// 1-4 from Request().execute();
Mail p = new Mail();
1
boolean request = p.receiveRequest(
node,sink);
p.deleteRequest(request,node,sink);
2
p.forwardRequest(request, node);
if(request)
3,4
retrieveLocalDataAndSendToParent();
5
ReceiveTransmit().execute();
Figure 9: DroidWSN Implementation of Central Data Optimized Algorithm (Line Numbers Refer to Figure 8)
The small and large deep network topologies are shown
in Figure 10. The numbers represent nodes and are Sun
SPOT wireless devices in our comparison platform and
AVDs in our study. The base stations are an iBook G4
and an email inbox in our comparison and JNFC/DroidWSN
studies, respectively. The arrows represent the direction of
data flow. Request flow is in the opposite direction.
B. Experiment
Our simulation experiment was designed to compare the
performance of JNFC using our DroidWSN model and
Android application against an actual WSN. We created
multiple instances of the AVD and adapted our simulation
experiment from the analytical study conducted by Gaber
et al. [13]. The authors created a WSN using Sun SPOT
wireless sensor nodes connected to an iBook G4 base station.
Our simulation results are compared against this platform
and our simulation experiment utilizes an algorithm and
network topologies from this study.
The central data optimized algorithm is shown in Figure 8.
This algorithm is very similar to our distributed algorithm
for DroidWSN as shown in Figure 5. For our simulation experiment, we consider these two algorithms to be equivalent.
1 Receive request from parent node
2 FOR EACH child node
Forward request to child
3 Retrieve local data
4 Send local data to parent node
5 FOR EACH child node
Receive response value
Send response value to parent node
Figure 8: Central Data Optimized Algorithm
1 → 2 → 3(Sink) → BaseStation
1 → 2 → 3 → 4 → 5 → 6(Sink) → BaseStation
Figure 10: Small (top) and Large (bottom) Deep Network
Topologies
This experiment (and our comparison study) measure the
execution time of a WSN. Execution time is defined as the
time between query dissemination and the time when the
last message containing response data arrives at the base
station. Local and response data in our comparison study is
an integer. Local data in our study is an NFC message and
response data is a String. Our clock started when we sent a
query message to a sink node and ended when we received
a response data message from all nodes.
For WSN size of 1,2,...,6, we ran our DroidWSN implementation on the AVD 5 times and calculated the average.
Our AVD used Android 3.2 (API level 13). Our desktop
computer used Windows Vista with an Intel Core 2 Duo
CPU @2.67 GHz and 2GB RAM.
C. Simulation Result
Figure 11 shows the result of our experiment. This result
demonstrates that, for both node types, as the number of

6. nodes in a deep network increases, there is a corresponding
increase in execution time. The increase in execution time
is acceptable, as it reflects the TDMA used in our ReceiveTransmit class, and is a result of an increase in both request
and data messages as the WSN size increases.
other models that are appropriate for implementation using
JNFC. Social networking is a reasonable candidate. We
would also like to observe the process involved in converting
a JNFC application to actual NFC P2P.
R EFERENCES
[1] International Organization for Standardization. ISO/IEC
18092:2004 Information technology – Telecommunications
and information exchange between systems – Near Field
Communication – Interface and Protocol (NFCIP-1) [Online].
Available: http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=38578
[2] T. Gibara. Obtaining a Live Camera Preview in Android [Online]. Available: http://www.tomgibara.com/android/
camera-source
[3] GNU GPL v2. javamail-android [Online]. Available: http:
//code.google.com/p/javamail-android/
Figure 11: Deep Network Execution Time
Our comparison study experimental platform is based on
the Squawk Java virtual machine [14] created by Simon et
al. Sun SPOT wireless devices use 802.15.4 for both the
PHY and MAC layers. This implementation provides robust
single-hop communication between Sun SPOTs with clear
channel checking, packet acknowledgement and retries. The
lowpan layer (above the MAC) provides the radiogram protocol. The radiogram protocol is used to create a dedicated,
direct connection between two Sun SPOTs for both sending
and receiving of datagrams. The DroidWSN MAC layer uses
TDMA. This scheme results in a slower execution time.
However, from an application perspective, DroidWSN is
more simple and flexible. Device address is not fixed and
is an integer from 1,2,...,11. The Sun SPOT device uses a
fixed IEEE (MAC) address combined with a port (channel)
number.
VI. C ONCLUSION
JNFC is open source and, as demonstrated by our DroidWSN model, facilitates simple and flexible application
design. JNFC is slower than the protocols used in our
comparison study. However, we feel that JNFC performance
in our experiment was reasonable, and that this makes
JNFC a suitable choice for research if performance is not
being studied. Other benefits of using JNFC for research
are associated with its integration into Android and the
features of this platform. Android smartphones support a
large number of high quality sensors. JNFC can be utilized
for WSN research in applications that interface with these
sensors.
In the near future, many Android smartphones will also
include NFC P2P. Until that time, JNFC is useful for creating
applications used to experiment with NFC P2P. We feel our
research should also encourage Google to develop Android
NFC P2P and sensor emulation APIs. Future work is to study
[4] Google. Near Field Communication | Android Developers
[Online]. Available: http://developer.android.com/guide/topics/
nfc/index.html
[5] J. Zhang et al., “uSink:Smartphone-based Mobile Sink For
Wireless Sensor Networks,” in 2011 IEEE Consumer Communications and Networking Conf., 2011 c IEEE. doi:
10.1109/CCNC.2011.5766639
[6] F. Lin et al., “A Framework for Transparently Programming Phone-Centered Wireless Body Sensor Applications for
Health,” in Proc. WH ’10 Wireless Health, 2010 c ACM. doi:
10.1145/1921081.1921091
[7] W. Ali et al., “Simulation of NFCIP-1 Protocol over NS-2,”
in 7th Int. Conf. on Informatics and Systems, 2010 c IEEE.
ISBN: 978-1-4244-5828-8
[8] Z. Mednieks et al. Programming Android. O’Reilly Media,
2011.
[9] Google. NFCDemo - NFC Demo | Android Developers
[Online]. Available: http://developer.android.com/resources/
samples/NFCDemo/index.html
[10] H. Karl and A. Willig. Protocols and Architectures for Wireless Sensor Networks. Wiley, 2007.
[11] Google. Updating the UI from a Timer | Android Developers [Online]. Available: http://developer.android.com/
resources/articles/timed-ui-updates.html
[12] V. Raghunathan et al., “Energy-Aware Wireless Microsensor Networks,” in IEEE Signal Processing Magazine, 2002
c IEEE. doi: 10.1109/79.985679
[13] M. Gaber et al., “An Analytical Study of Central and InNetwork Data Processing For Wireless Sensor Networks,”
in Information Processing Letters, Vol. 110, Iss. 2, 2009
c Springer. doi: 10.1016/j.ipl.2009.10.008
[14] D. Simon et al., “Java on the Bare Metal of Wireless Sensor
Devices: The Squawk Java Virtual Machine,” in 2nd Int.
Conf. on Virtual Execution Environments, 2006 c ACM. doi:
10.1145/1134760.1134773