Wireless sensor networks using android virtual devices and near field

1,247 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,247
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Wireless sensor networks using android virtual devices and near field

  1. 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. 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. 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. 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. 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. 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

×