2012 2nd Baltic Congress on Future Internet Communications
Interconnecting IPv6 Wireless Sensors with an Android Smartphone in the Future Internet Philipp Schleiss, Nikolaj Tørring, Søren Aagaard Mikkelsen, and Rune Hylsberg Jacobsen Aarhus University School of Engineering, Aarhus University, Finlandsgade 22, 8200 Aarhus N, Denmark Email:
[email protected], {20101581,20100881,rhj}@iha.dk
Interconnecting smart objects and smartphones is a natural step forward for the Future Internet. The application domains, in which one would like to interconnect a smartphone with smart objects, are manifold. These include, but are not limited to, home automation control [7], wireless sensor networks [8], mobile health [9], and military applications [10]. This paper reports on a possible setup for enabling IPv6 on Android devices independently of the Internet service provider. The setup permits the end-user to access networked objects addressable through the IPv6 protocol anywhere the mobile device can connect to the Internet. The proposed mechanism is applied to an Android smartphone and is used to integrate wireless sensor data from an IPv6 over Low power Wireless Personal Area Network (6LoWPAN) in the Internet of Things [11].
Abstract—To fulfill the vision of the Future Internet a ubiquitous deployment of IPv6 is a necessity. The work presented in this paper combines networking technologies and mobile software application development to support interworking of mobile devices and smart objects. We report on the implementation of an Android IPv6 smartphone that interworks with Web-enabled wireless sensors in the Internet of Things. This includes a possible network setup for IPv4/IPv6 interworking by using a public tunnel broker service. The demonstrated solution is universal, since the Android device can be connected to any IP network, even where a Network Address Translation (NAT) device is deployed. Index Terms—Android, IPv6, 6LoWPAN, Internet of Things, mobile applications.
I. I NTRODUCTION The Internet of Things predicts a world in which a vast number of physical objects, the so-called smart objects, communicate over the Internet [1], [2]. In such a scenario, the Internet Protocol (IP) and the end-to-end architecture of the Internet is a natural candidate for building a global network out of things. Furthermore, enabling technologies such as lowpower wireless communication allow smart objects to form networks based on open standards and protocols [3], [4]. This permits the Internet to penetrate into the real world of physical objects. A widespread deployment of IPv6 is a key to the success of smart object networks. IPv6 has several advantages compared to IPv4 such as a larger address space, better header format, provision for extensions, and security features. Despite these benefits, there is still a lack of end-to-end IPv6 support for mobile devices to access the Internet of Things; and, although nowadays end-users have IPv6-ready computers, the adoption of IPv6 in the Internet is still low [5]. An explosive growth in the usage of mobile devices has given end-users constant and geographically independent Internet access. Newer smartphones are equipped with sophisticated operating systems (OS), like Android, which provide the end-user with a broad spectrum of possible applications. Furthermore, software development for smartphones has been enriched by frameworks that allow rapid and diverse application development [6]. As a result, a great number of innovative mobile applications have emerged and today there is a strong community support for mobile application development on the Internet.
978-1-4673-1671-2/12/$31.00 ©2012 IEEE
II. BACKGROUND For the seamless and efficient networking of smart objects with a smartphone, a number of key technologies must be evoked. These technologies are outlined below. A. Android Android is a Linux based open source operating system for smart mobile devices [6], [12]. It is based on a modified Linux kernel optimized for mobile devices. Due to these optimizations, it is not possible to run any Linux application on the device which makes the work with Android OS somewhat more technically challenging compared to working with a fullfeatured Linux distribution. IPv6 support has been available for Wi-Fi connections since version 2.1 of the Android OS. However, IPv6 is not typically supported for mobile networks e.g., GPRS and UMTS due to the lack of necessary functionality in the radio chipsets. To gain full access to the underlying Linux OS of the smartphone a rooting process must be applied. This process exploits some security vulnerability and allows the developer to execute arbitrary native applications directly in Linux. The process can be assisted by freely available rooting applications. However, the preinstalled Linux kernel has limited functionality due to memory constraints and therefore lacks otherwise typical OS applications. In the industry, smartphone manufacturers build and adjust the Android source code to achieve full software-hardware compatibility. This customization process can also be realized
14
by a third party to for example equip older smartphone models with newer versions of the OS. Distributed, customized versions of Android can then be installed on smartphones to access new functionality. This installation process is commonly denoted as flashing a custom ROM. With Android it is further possible to develop applications in the Java programming language and to compile the application to a special executable format for the Dalvik Java virtual machine (JVM) [6], [12]. The Java application development is supported through the use of an Android Software Development Kit (SDK) which integrates into an existing Integrated Development Environment (IDE) such as Eclipse. The SDK provides an emulation of the mobile device for faster debugging cycles. Apart from the SDK, the development tool package contains the Android Debug Bridge (ADB) that enables communication with the smartphone. The ADB also allows access to the command line interface of the mobile device which is useful for executing non-Java-based applications. The ADB may also be used to transfer files to and from the device.
tunnel, that is the tunnel broker endpoint, as the default gateway. Since AYIYA works from behind NATs (unless there is a very restrictive firewall in place), anybody should be able to get ubiquitous IPv6 connectivity by using this mechanism. III. I MPLEMENTATION The steps needed to demonstrate a universal IPv6 interworking solution for an Android smartphone with wireless sensor nodes on the Internet of Things are outlined below and details can be found at the project home page (www.comsyslab.dk/projects/v6Android.html). A. System design The system architecture consists of smart objects with embedded HTTP-based Web servers. An Android smartphone runs a dual-stack and a specially designed mobile application is used to communicate with the smart object over IPv6. In this particular implementation a wireless temperature sensor node based on the TelosB mote platform was used [17]. The node connects to a base station using the IEEE 802.15.4 radio standard. Temperature data is recorded in a comma separated value (CSV) file format and it can be retrieved by using RESTful Web services [2]. Due to the limited IPv6 support in the mobile operator networks, a universal solution that is independent of the IPv6 support from the chipset and the service provider, should be designed. The Android OS is therefore equipped with an AICCU implementation, enabling IPv6 connectivity over an IPv4 infrastructure. Fig. 1 shows the network setup. The Android smartphone connects to the IPv6 Internet by using tunneling to the SixXS tunnel broker. A temperature sensor node uses 6LoWPAN to connect to the Internet and end-to-end communication is established between the Android smartphone and the sensor node. The sensor node is further registered with the mashup application Pachube (www.pachube.com). Requests from Pachube have to traverse through the tunnel broker due to the lack of IPv6 support at Pachube. A purpose-built mobile application interacts with the same temperature sensor node. It displays the sensed temperature data on the Android smartphone as a textual representation. The pulling of data is accomplished by using Web services, i.e., by using the HTTP protocol over the IPv6. The application is designed to handle interchangeable configurations through an XML configuration file located on the SD memory card of the smartphone. This configuration file can be manipulated by other software to provide a simple and easy configuration possibility. The application design uses the Model-ViewController (MVC) software pattern to allow a separation of responsibility. More specifically, design decisions for the data model are independent of the user interface. The controller component handles the coupling between the view and the model, making the software, as a whole, more flexible and maintainable.
B. 6LoWPAN Due to the memory limitations, processing power and energy constraints of smart objects that use IEEE 802.15.4 radios, it is not feasible to implement a full-blown IPv6 solution. The 6LoWPAN adaption layer enriches low power radios such as IEEE 802.15.4 with IPv6 [2], [11]. The protocol is based on an open, long-lived (more that 4 years) and reliable IETF standard [13]. It has a transparent Internet integration that complies with the IPv6 standard and supports the end-toend architecture of the Internet. The 6LoWPAN adaption layer introduces fragmentation and protocol header compression to adapt to the small packet size of IEEE 802.15.4 networks. C. IPv6 in IPv4 tunneling Tunneling is a well-established transition mechanism that enables connectivity between dual-stack devices, allowing IPv6 devices to transit networks that only support IPv4 [14]. Basically, IPv6 packets are encapsulated in IPv4 packets between dual-stack devices on the Internet. Complications can arise when the devices are only equipped with private IPv4 addresses which are enforced by the use of Network Address Translation (NAT) mechanisms for communication over the Internet. Hence, the mobile device will be dynamically assigned an IPv4 address that lacks global uniqueness. Somewhat unfortunately, this is the most common way of attaching mobile devices to the Internet today. In this case a special IPv6 tunneling protocol, like Anything in Anything (AYIYA), can be used to circumvent the issues related to lack of native IPv6 connectivity and NAT mechanisms [15]. The AYIYA protocol is integrated into the Automatic IPv6 Connectivity Configuration Utility (AICCU) tunnel broker software using the services provided by, for example, the SixXS [16] tunnel broker. Essentially, AICCU sets up a virtual network interface in the OS, which is assigned a global IPv6 address, and it uses the corresponding endpoint of an AYIYA
15
pattern is well-suited for this application and it is implemented by the use of decoupled packages. The model package contains classes for representing the accessible sensor nodes and their configuration. The XML configuration file that is loaded by the controller defines the instantiation of the model structure. For the temperature sensor node, the payload can be limited to a maximum of 8 bytes when using the CSV file format. The controller extends the HTTP client functionality provided by the Java framework to allow the establishment of an HTTP connection to any URL. An HTTP request is issued when the user presses the query button in the application. As soon as the result is retrieved from the server, the graphical user interface is triggered to update the content. The application design is independent of the version of IP protocol as long as a valid URL is provided. The controller implements functionality to parse the received data in the chosen format and to transform it into instances of the data model in use. The application integrates into the Android OS through the normal installation process for the smartphone. Fig. 2 shows the display of the temperature-sensing application on the Android smartphone. The actual sensor nodes to be read is determined by the selection item and the refresh button activates the retrieval of the sensor data. In the design, attention has to be paid when modifying data represented by the graphical user interface from another thread, which can lead to unpredictable concurrent access; hence updates to the user interface have to be indirectly triggered. This implies that the availability of changed data can only be signaled to the user interface. Thereafter, the thread managing the user interface must update the graphical representation.
Fig. 1. Network setup with Internet of Things enabled wireless sensors accessible from an Android smartphone.
B. Sensor node design The TelosB sensor nodes run a light-weight OS that is optimized for network sensor applications [18]. The software for the sensor node is based on the TCPEcho sample program which is distributed together with the TinyOS software. The program was modified to sample the temperature sensor when the existing timer is fired every 1.30 minutes and stored it as a global variable. When an HTTP-GET request method is received, the program will convert the latest measurement to Celsius and deliver the result. To satisfy the Pachube data format, the HTTP header was modified to report the contenttype as CSV format. C. System integration
D. System verification
1) Automatic tunneling: To execute AICCU and thus obtain global IPv6 connectivity, some steps are necessary. First, the user interaction on an Android device is not permitted to trigger the execution of applications which require root privileges. Hence, access to the command line interface on the Android smartphone has to be established through the ADB. Secondly, the TUN kernel extension that is needed to establish a tunnel through the AICCU protocol layer is not, by default, supported in Android 2.1 that ships with the HTC Hero smartphone. To circumvent this problem, a custom build of Android 4.0 was flashed to the ROM of the HTC Hero smartphone and the smartphone boot loader entries where adjusted. To add further functionality for easier configuration and network support the Busybox software was installed, providing useful program utilities in a single executable [19]. AICCU for Android smartphones is available through a customized compiled executable. The software can be configured and started either via the ADB or by a third party application, allowing access to the console by using the keyboard of the smartphone. 2) Android application: The mobile application is developed in the Java programming language with the combined use of the Eclipse IDE and the Android SDK. The MVC software
In order to verify the system, a number of function tests were conducted. In the first stage, the application on the Android device was tested as a stand-alone and in the second stage, the attachment to a wireless sensor node on the Internet of Things was verified. Application tests during the software development phase were mainly conducted through the IDE. The Android SDK provides an emulation service to run, debug and test applications targeted for Android devices through the Eclipse IDE. The Android OS emulator can access the same networking functionality as the underlying host OS including IPv6 connectivity. Due to a bug in the underlying implementation, issues with IPv6 arose when using an Android 2.1 emulator. The Android 4.0 emulator was therefore used instead. Further complications hindered the emulator from using the correct IPv6 route, which could only be resolved through remote debugging directly on the HTC Hero smartphone. To conduct a representative test in the emulated environment, a Web server was installed on the development computer. The Web server offered access to a CSV file. The debugging of the Android application was based on the Web server, which was accessed through the global IPv6 address.
16
Fig. 2. Display of the Android temperature-sensing application for reporting sensor data over IPv6.
Fig. 3. A graph display from Pachube, which had pulled data from our sensor in 24 hours
To test the integration of the wireless sensor node with the Internet, it was registered on the mashup application Pachube. Data was pulled from the sensor over the Internet every 15 minutes. The pull approach was chosen as this allows for more energy conservation. The API key for Pachube in the push-method increases the number of packets for every request, since the header would be at least 100 bytes; thus packets have to be fragmented when transfered over an IEEE 802.15.4 network.
for the smartphone. This is comparable to a Linux-based laptop connected to the Internet in the same way. For the Linux laptop the measurements resulted in an average RTT of 34.7 ms ± 1.3 ms. The tests used UDP packets of 56 bytes of payload and 20 samples were used in each experiment. The slightly shorter RTT of the Linux laptop is attributed to its powerful CPU (2.53 GHz) compared to that of the Android smartphone (528 MHz).
IV. E XPERIMENTS AND R ESULTS
After being able to establish a stable IPv6 Internet access, the remote temperature-sensing application was started. The first attempt to contact the sensor node was successful. Temperature data could be pulled on demand and subsequently displayed on the smartphone display. Likewise, Pachube could successfully pull temperature data from the same sensor node. As an example Fig. 3 shows the temperature trace from the sensor node as presented on Pachube. One issue experienced with Pachube was its inability to directly connect to a feed using IPv6. To circumvent this, an IPv6-IPv4 translation service provided by SixXS was used. To use this service, the sensor nodes’ IPv6 address needed to be associated with a DNS AAAA record. Subsequently, Web page content could be translated between the IPv6 and the IPv4 Internet. This solution cannot scale to the Internet of Things, but worked for this particular experiment.
C. Application
The experimentation was separated into two stages. First the IPv6 connectivity had to be established and tested. Thereafter, another implementation and installation cycle was run and the functionality of the entire system was tested. A. Environment and IPv6 connectivity The temperature sensor node was connected wirelessly to the IPv6 Internet through a 6LoWPAN (IEEE 802.15.4) base station acting as a router. The sensor node offers an HTTP interface which returns the measured temperature. The data was fitted into a single 6LoWPAN packet thus allowing the network to conserve energy. The Android smartphone was located in a different building connected to a Wi-Fi access point. This access point obtained a private IPv4 address from the local area network and could access the Internet through a NAT device. To verify IPv6 connectivity, the AICCU software was first deactivated on the mobile device and, as expected, the entered IPv6 address could not be contacted. After starting the AICCU software, the same test was repeated and a ping message was sent to a valid IPv6 destination. This resulted in a response being received. To verify the IPv6 connectivity in more detail, a trace route command was issued and the result was analyzed. A domain name server (DNS) capable of supplying IPv6 addresses was set up to test the name resolution. After configuring the DNS server address, a ping request for the URL ipv6.google.com could successfully be issued.
D. Smartphone gateway node The interconnection of a mobile device with smart objects over an IPv6 infrastructure enables sensor networks to become mobile by using the smartphone as a gateway. In order to explore this idea, a mobile gateway prototype device has been built in the laboratory [9]. Fig. 4 shows the prototype. The prototype was made of a custom-built IEEE 802.15.4 sensor node that was attached to the back of an Android smartphone (HTC Nexus One). A serial connection was used between the sensor node and the smartphone. By using such gateway devices is is possible to connect wireless sensor networks to the Internet of Things and to allow these networks to become mobile.
B. Performance To assess the IPv6 stack performance of the Android smartphone, the round-trip-time (RTT) was measured. For a single IPv6 hop, tunneled through IPv4 via a Wi-Fi access point, an average RTT of 35.7 ms ± 1.3 ms was measured
V. D ISCUSSION Today there is a large, ongoing effort to, and community support for, building mobile applications for the Android
17
phone gateway prototype. R EFERENCES [1] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,” Computer Networks, vol. 54, no. 15, pp. 2787–2805, 10/28 2010. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2010.05.010 [2] J.-P. Vasseur and A. Dunkels, Interconnecting Smart Objects with IP The Next Internet. Morgan Kaufmann, 2010. [3] F. L. Piccolo, D. Battaglino, L. Bracciale, M. D. Filippo, A. Bragagnini, M. S. Turolla, and N. B. Melazzi, “Towards fully ip-enabled ieee 802.15.4 lr-wpans,” in 6th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Workshops (SECON), june 2009, p. 1. [Online]. Available: http://dx.doi.org/10.1109/SAHCNW.2009.5172967 [4] K. Mayer and W. Fritsche, “Ip-enabled wireless sensor networks and their integration into the internet,” in Proceedings of the first international conference on Integrated internet ad hoc and sensor networks (InterSense ’06). New York, NY, USA: ACM, 2006, p. 5. [5] L. Colitti, S. Gunderson, E. Kline, and T. Refice, Evaluating IPv6 Adoption in the Internet, ser. Passive and Active Measurement. Springer Berlin / Heidelberg, 2010, vol. 6032, pp. 141–150. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-12334-4 15; [6] Google, “Android developers,” accessed January 2012. [Online]. Available: http://developer.android.com/index.html [7] B. M. Dorge and T. Scheffler, “Using ipv6 and 6lowpan for home automation networks,” in IEEE International Conference on Consumer Electronics (ICCE), 2011, pp. 44–47. [Online]. Available: http://dx.doi.org/10.1109/ICCE-Berlin.2011.6031865 [8] N. Moreira, M. Venda, C. Silva, L. Marcelino, and A. Pereira, “@sensor - mobile application to monitor a wsn,” in 6th Iberian Conference on Information Systems and Technologies (CISTI), 2011, pp. 1–6. [9] R. H. Jacobsen, F. O. Hansen, J. K. Madsen, H. Karstoft, P. H. Mikkelsen, T. A. Skogberg, E. S. Rasmussen, C. Andersen, M. Alrøe, and T. S. Toftegaard, “A modular platform for wireless body area network research an real-life experiments.” International Journal On Advances in Networks and Services, vol. 4, no. 3&4, 2011. [10] V. Kaul, C. Makaya, S. Das, D. Shur, and S. Samtani, “On the adaptation of commercial smartphones to tactical environments,” in Military Communications Conference (MILCOM), 2011, pp. 2205–2210. [11] J. W. Hui and D. E. Culler, “Ipv6 in low-power wireless networks,” Proceedings of the IEEE, vol. 98, no. 11, pp. 1865–1878, 2010. [12] K. Paul and T. K. Kundu, “Android on mobile devices: An energy perspective,” in IEEE 10th International Conference on Computer and Information Technology (CIT), 2010, pp. 2421–2426. [13] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, “Transmission of ipv6 packets over ieee 802.15.4 networks,” sep 2007. [Online]. Available: http://www.ietf.org/rfc/rfc4944.txt, [14] E. Nordmark and R. Gilligan, “Basic transition mechanisms for ipv6 hosts and routers,” oct 2005. [Online]. Available: http://www.ietf.org/rfc/rfc4213.txt [15] J. Massar, “Ayiya: Anything in anything,” expired Internet Draft. [Online]. Available: http://tools.ietf.org/html/draft-massar-v6ops-ayiya02 [16] “Aiccu reference site,” retrieved January 2012. [Online]. Available: http://www.sixxs.net/tools/aiccu/ [17] Memsic-Crossbow, “Telosb mote platform,” Tech. Rep., data sheet. [Online]. Available: http://www.memsic.com/support/documentation/wireless-sensornetworks/category/7-datasheets.html?download=152%3Atelosb; [18] “Tinyos documentation wiki,” retrieved January 2012. [Online]. Available: http://docs.tinyos.net/tinywiki/index.php/Main Page [19] N. Wells, “Busybox: A swiss army knife for linux,” Linux J., vol. 2000, no. 78es, oct 2000. [Online]. Available: http://dl.acm.org/citation.cfm?id=364412.364422 [20] J. Zhang, C. Chen, J. Ma, N. He, and Y. Ren, “usink: Smartphonebased mobile sink for wireless sensor networks,” in IEEE Consumer Communications and Networking Conference (CCNC), 2011, pp. 90– 95. [21] R. Silva, P. Carvalho, P. Sousa, and P. Neves, “Enabling heterogeneous mobility in android devices,” Mob.Netw.Appl., vol. 16, no. 4, pp. 518– 528, aug 2011. [Online]. Available: http://dx.doi.org/10.1007/s11036011-0322-6
Fig. 4. An IEEE 802.15.4 extended smartphone prototype device used as a mobile gateway device.
smartphone. Many applications for smartphones make use of communication interfaces such as Wi-Fi, GPRS, and UMTS that come with the smartphones and the smartphones are most frequently being used as an Internet host. More recently, Android devices have been used as networking devices, for example, in ad hoc networks and as gateways [10] and data collection points (sink nodes) in wireless sensor networks [8], [20]. However, until now, only sporadic demonstrations of universal IPv6 support with Android have been reported. To truly enrich the Internet of Things with mobile devices versatile mobility mechanisms are needed to provide roaming between access technologies e.g., Wi-Fi, WiMAX, and UMTS/LTE. Consequently, mobility-aware solutions for Android need to be designed. One possible design was proposed by Silva et al. [21]. The research team proposed a solution to achieve heterogeneous mobility of Android-based systems. They also studied the handover delay between 3G and Wi-Fi. In the proposed setup a native IPv6 network was assumed. It is expected that much more research will be disseminated in this area in the near future. VI. C ONCLUSIONS The Future Internet will be largely heterogeneous, ranging from high-end computers with high-bandwidth connections to energy-constrained embedded devices communicating over lossy wireless links. The work presented in this paper demonstrates a possible solution for accessing IPv6 smart objects in the Internet of Things with a newer Android smartphone over a heterogeneous network infrastructure. The proposed solution includes the interworking of IPv6 over low-power wireless links, as well as over IPv4 networks, by using an automatic tunneling mechanism based on AYIYA. It was observed that connecting an Android smartphone to the IPv6 Internet requires a complex integration effort and that the process cannot yet be fully automated. To enhance the overall user experience with IPv6 internetworking on a smartphone, improved IPv6 support must be offered from mobile network providers, as well as the vendors of GPRS/UMTS radio chipsets. It is believed that this is essential to the success of future mobile IPv6 applications in the Internet of Things. ACKNOWLEDGEMENTS We would like to thank Esben S. Rasmussen and Claus Andersen for their work on the IEEE 802.15.4-enabled smart-
18
