CoAP communication with the mobile phone sensors over the IPv6

CoAP communication with the mobile phone sensors over the IPv6 Tomislav Dimcic *, Dejan Drajic *, Srdjan Krco * * Ericsson d.o.o., Belgrade, Serbia toma.dimcic@gmail.com, dejan.d.drajic@gmail.com, srdjan.krco@ericsson.com Abstract In this paper a few implementations were presented in order to show the importance of the IPv6 usage for IoT and possibilities that IPv6 offer. It is done in order to overcome addressing and routing limitations of IPv4 based mobile networks and WiFi. Two set-ups are presented. In the first one, smartphone is used as end point that could be accessed directly through the IPv6 address. Second set-up shows how smartphone could be used as a half-gateway for non IP devices, and provides access to the devices that use Bluetooth or Infrared communication with smartphone. I. INTRODUCTION Every smartphone has a number of embedded sensors, like GPS, microphone, speaker, camera, light, etc. If the data from the phones sensors could be accessed from the internet they could be combined and used for forming the bigger picture about the environment. For example, data gathered from many different sound sensors on phones could provide information about the noise level in the different parts of the city to form the noise level map. Having in view that there are so many smartphones in the world the potential is huge. Problem occurs while trying to get the data from the phone. Phone, while on the IPv4 mobile network, does not have a static IP address and every time when the phone is switched off and on, it obtains new IP address from the network. On the other hand, if the phone is on the WiFi, through the IPv4 network, port forwarding on the local router must be provided. These problems are the reason why it is not practical as well as possible to implement any server on the phone that could be accessed from the internet. Google developed and offered service for notification system. In order to enable this function, the constant communication with their service needed to be open, which has a large influence on the phone battery consumption [1]. A promising solution for this problem is usage of the IPv6 network. IPv6 addressing system enables every IoT (Internet of Things) device to have a unique IP address which facilitates implementation by avoiding port forwarding. In this paper some practical implementations are presented in order to show the importance of the IPv6 for IoT and possibilities that IPv6 offers. In observed cases a mobile device can have its own sensors (embedded) or different sensors can be connected wirelessly, for example via Bluetooth, when mobile phone acts as halfgateway for sensors from devices that do not support IPv6 protocol, allowing them to be accessible via IPv6 network. Communication with mobile phones is done over CoAP protocol, while Digcovery system is used for the service discovery. Work presented in this paper is done in the scope of the EU FP7 IoT6 research project which aims at researching and exploiting the potential of IPv6 to develop a service oriented architecture overcoming the current IoT fragmentation [2]. Within the project various ways to integrate an IPv6-based IoT into mobile phone networks enabling mobile devices to provide access to smart objects as well as to use mobile devices as sensors/actuators are explored. The paper is organized as follows: after introduction, in Section II CoAP protocol and Digcovery system are explained. Section III covers test case with Mobile Phones with its own sensors, while in Section IV half gateway implementation is presented. In Section V conclusions and future work are given. II. COAP PROTOCOL AND DIGCOVERY CoAP (Constrained Application Protocol) is proposed by the CoRE (Constrained RESTful Environments) working group in order to optimize the use of the RESTful web service architecture in the constrained nodes and networks [3]. CoAP is an application layer protocol designed to lower the complexity for the constrained networks but, also, to enable communication over the existing internet infrastructure. Existing protocols on application layer that operates in requestresponse model are not good match for low-power, resource constrained devices. CoAP is a light-weight application protocol based on UDP that supports multicast requests, cashing and REST web services between the end-points, and is seen as a future protocol for IoT. The lack of reliability of the UDP is compensated by using other methods that provide confirmation of received messages. It is designed for low-powered devices and it fulfills the IoT requirements [4]. CoAP is still work in progress of the IETF CoRE Working Group [5]. It is intended to be used as the HTTP-replacement for smart objects that are connected to the Internet [6]. One of the requirements for CoAP design is resource, service and end point discovery. As suggested in CoRE Resource Directory draft [7], a good solution is usage of Resource Directory for storing descriptions and resource discovering. There are also other solutions. IETF Page 388 of 478

considers DNS-SD (Domain Name System Service Discovery) [8] as the service discovery mechanism. Protocols like ZigBee [9] and SLP (Service Location Protocol) [10] are also working on the service discovering systems and they offer their solutions. Digcovery is global discovery platform. This platform is used to locate the different domains and the wide deployed directories with the different resources. It is based on DNS (dig command in Linux OS). Digcovery is public and accessible from anyplace through digcovery.net. Digcovery allows the delegation of each domain to the end-user and/or service provider through digrectories [11]. Digcovery is introduced as a service discovery system on the IoT6 project [12]. It has a CoAP interface build-in in order to enable communication with the constrained devices on the network edge. On low power devices it is too complicated or impossible to implement DNS protocol, and usage of a CoAP for discovery enables development of more distributed systems. It allows end devices to discover services that it needs. In this paper we study the access to the mobile phone sensors over the internet, through the IPv6 network. A smartphone application is responsible for registering phone s sensors into a Digcovery directory. Another device (a laptop in this test case) searches the directory for the required service (see Section III). After receiving the required description, a client application on the laptop communicates with the phone and collects measurements from the sensors on the phone. In addition, access and communication to the external device connected via Bluetooth with the phone is presented (Section IV). III. MOBILE PHONE WITH ITS OWN SENSORS In this test setup an Android based smartphone was used for implementation of the IPv6 CoAP server, a Raspberry Pi [13] was acting as an IPv6 border router and finally a laptop as an IPv6 client (Fig. 1.). if there is no support in the ISP. Within this mechanism IPv6 address is carried by the IPv4 network to the Freenet6 server, where the communication translates completely to the IPv6 network. On Freenet6, a single, permanent IPv6 address and a DNS name are assigned to each user, making their device reachable from anywhere on the IPv6 internet. The Raspberry Pi was set with a Freenet6 client, which enables IPv6 communication. The client keeps the IPv4 tunnel constantly open with the Freenet6 server. Beside that the client is in charge to get the static IPv6 address from the Freenet6 server. Freenet6 has a unique IPv6 address for every account created on its site. Raspberry Pi is basically a Linux machine and therefore it could be set to be a router for the local network enabling internet access to the local devices. Since Raspberry Pi already has a tunneling mechanism that provides IPv6, it is converted to be a Wi-Fi hot spot for the IPv6 network. In this way IPv6 enabled devices could get the IPv6 address through the Raspberry. A full /56 prefix is assigned to a Raspberry, enabling the distribution of IPv6 connectivity to an entire network. A static IPv6 address, accessible from the web is assigned to the Raspberry Pi. Raspberry Pi acts as a border router for the IPv6 network and enables the smartphone to get its IPv6 address. To enable that, a DHCP server is built on the Raspberry which assigns unique IPv6 address to every device that tries to connect with it. The IP address assigned to the smartphone is the following: 2001:5c0:1504:b800:50d0:f101:83cc:b8b4 Since this is a REST CoAP server there are several available interfaces: /sensor, /sensor/gps, / sensor/light, etc. After boot, in order to enable service discovery (Fig. 2), the smartphone s CoAP server registers its available resources and services on the Digcovery, by sending the following PUT requests: and coap://[2001:720:1710:10::1000]:5683/dig?ep=sensors&pr oto=coap&port=5683&d=example.com &lat=25&long=45&z=belgrade, coap://[2001:720:1710:10::1000]:5683/dig?ep=gps&proto =coap&port=5683&d=example.com &lat=25&long=45&z=belgrade, Figure 1. Test set-up, IPv6 communication between laptop and CoAP Server on the Android In order to be able to route communication in a proper way ISP (Internet Service Provider) needs to have a support for IPv6. Because ISP s in Serbia don t support IPv6 addressing system, a tunneling system was used provided by Gogo6 [14] with its Freenet6 Tunnel Broker [15]. A tunneling mechanism enables IPv6 network even Figure 2. Communication flow getting the list of available sensors from the Android phone Page 389 of 478

The other end of the communication link is embodied in an IPv6 Client installed on a laptop. Similar to the Raspberry Pi, the laptop obtained an IPv6 address through the Freenet6 Tunnel Broker and is able to make a request over IPv6. In order to read available services on the phone, the IPv6 client sends a GET request to the Digcovery server: coap://[2001:720:1710:10::1000]:5683/dig?qt=2&ep=sensors, Digcovery responds with a description of those services: [{"name":"coap.sensors","port":5683,"addr":"2001:5c0:1504:b800 :50d0:f101:83cc:b8b4","values":[{"value":"25@45","nameField": "geo"},{"value":"belgrade","namefield":"gps"}],"gps":"belgrade ","loc":[45.0,25.0],"domainname":"example.com"}, {"name":"coap.gps","port":5683,"addr":"2001:5c0:1504:b800:50d 0:f101:83cc:b8b4","values":[{"value":"25@45","nameField":"geo "},{"value":"belgrade","namefield":"gps"}],"gps":"belgrade","lo c":[45.0,25.0],"domainname":"example.com"}] The descriptions of both services are being sent because they are registered from one domain. After receiving this message, the IPv6 CoAP client installed on the laptop sends a GET request to the following address: coap://[2001:5c0:1504:b800:50d0:f101:83cc:b8b4]:5683/sensors/ The request is tunneled through the Freenet6 over the Internet to the Raspberry Pi, which than transmits the request to its final destination, a smartphone. Because the smartphone listens on the 5683 port, it gets the request, processes it and sends back a response to the laptop through the same communication channel (Fig. 2.). The response holds information about the available sensors on the phone (Table 1.): TABLE I. LIST OF AVAILABLE SENSORS devices via the Internet, it is crucial to show how these devices could have an internet access over the IPv6 network. The role of half-gateway is to communicate through IPv6 but still to be able to connect to a device via Bluetooth or Infrared. The mobile phone performs registration of these devices in Digcovery or a Resource Directory thus allowing their discovery and obtaining measurements. In the full gateway implementation additionally protocol adaptations, security and privacy aspects should be supported, what is not investigated in this paper. In this setup an Android phone, with CoAP Server implemented, is used as IPv6 half-gateway for the Bluetooth enabled device MindWave [16]. The MindWave device is able to read brain wave activity and to send raw measurements to the smartphone. As in the first test case, Raspberry Pi is set as the Border Router for IPv6 and got its IPv6 address with the Freenet6 client which enables the IPv6 communication. On Freenet6, a single, permanent IPv6 address and a DNS name are assigned to each user, making their device (PC, laptop) or any other device reachable from anywhere on the IPv6 internet. The IP address on the phone is the following: 2001:5c0:1504:b800:71bc:54c0:eee3:3b83 The MindWave device is able to read brain wave activity and to send raw measurements to the smartphone. A connection between the MindWave and the smartphone is established using Bluetooth. An application installed on the phone communicates over the IPv6 network, reads and process the EEG (Electro Encephalograph) data from the MindWave (and interpret it as the level of attention and meditation) and it has a CoAP server that waits for the request from the internet. The server listens the port 5683. This setup enables access to the Bluetooth device via IPv6 network. This is a list of available sensors: KR3DM 3-axis Accelerometer AK8973 3-axis Magnetic field sensor GP2A Light sensor GP2A Proximity sensor K3G Gyroscope sensor Rotation Vector Sensor Gravity Sensor Linear Acceleration Sensor Orientation Sensor Corrected Gyroscope Sensor GPS For example, if the request is sent to the: coap://[2001:5c0:1504:b800:50d0:f101:83cc:b8b4]:5683/sensor/gps, the response is the current location of the phone. Similar to this, the measurements from all sensors can be read. IV. HALF GATEWAY IMPLEMENTATION In this test case mobile phone acts as a half-gateway for sensors from devices that don t support IPv6 protocol [10]. These devices are connected to the phone via Bluetooth, Infrared, etc. Since IoT means connected Figure 3. IPv6 communication between laptop and MindWave device using Android phone as a gateway After running the IPv6 EEG CoAP Server Application on the phone (Fig. 3.), it sends the registration data to the Digcovery: coap://[2001:5c0:1504:b800:71bc:54c0:eee3:3b83]:5683/di g?ep=attention&proto=coap&port=5683&d=example.com &lat=25&long=45&z=belgrade Page 390 of 478

and coap://[2001:5c0:1504:b800:71bc:54c0:eee3:3b83]:5683/di g?ep=meditation&proto=coap&port=5683&d= example.com &lat=25&long=45&z=belgrade In order to read the data from the MindWave, IPv6 CoAP Client on the laptop sends GET request to the Android application that can handle the CoAP request and it is connected to the MindWave via Bluetooth: GET on coap://[ 2001:5c0:1504:b800:71bc:54c0:eee3:3b83]:5683/attention/ or GET on coap://[ 2001:5c0:1504:b800:71bc:54c0:eee3:3b83]:5683/meditation/ The request is tunneled through the Freenet6 over the Internet to the Raspberry, which than transmits the request to its final destination, Android phone. Phone listens the 5683 port, gets the request, process it and send back the response to the laptop through the same communication channel (Fig. 4.). The response holds information about current data gathered from the MindWave. enables every IoT device to have a unique address could be used. In this paper some implementations were presented in order to show the importance of the IPv6 for IoT and possibilities that IPv6 offer. Since in Serbia ISPs don t have a support for IPv6, tunneling mechanism is used to demonstrate proof of concept. Freenet6 Tunneling Broker enables carrying IPv6 address through the IPv4 channel which enables local networks IPv6 connectivity. To avoid having the tunneling mechanism for every device a Raspberry Pi device was set to work as a Border Router for IPv6. In this way any device could have IPv6 connectivity using WiFi through Raspberry Pi. Also, every device connected through this system has a unique IPv6 address. Two set-ups are presented. In the first one, smartphone is used as end point that could be accessed directly through the IPv6 address. Smartphone has a number of sensors and, if asked, it could response with readings from those sensors. The REST CoAP server is used so every sensor could be accessed independently. Second set-up shows how smartphone could be used as a halfgateway for non IP devices. In that way, access to the devices that use Bluetooth or infrared, is provided. In the future work we plan to compare IPv6 set-up that uses Digcovery system presented here, with the same setup where instead of the Digcovery IPv4 based Resource Directory will be used [7]. Preliminary results show that there is a major influence of the IPv6 tunneling mechanism on the communication speed, so it is necessary directly to use IPv6 access point in order to avoid tunneling delays and to perform real comparisons of IPv6 Digovery system and IPv4 based Resource Directory. Figure 4 Communication flow getting the attention or meditation level from the MindWave If the request was sent to the attention interface, the response holds information about current attention level, and if the request was sent to the meditation interface, the response holds information about current meditation level. These levels are relative values between 0 and 100. V. CONCLUSIONS AND FUTURE WORK In IPv4 based mobile networks, mobile phone does not have a static IP address, and every time the phone is switched off and on, it obtains new IP address from the network, while if the phone is on the WiFi, through the IPv4 network, port forwarding on the local router must be provided. It makes a problem to get sensors data from the smartphones. To avoid these problems IPv6 networks that ACKNOWLEDGMENT Main part of the research presented in this paper was undertaken in the context of European Project FP7 IoT6 project (STREP). The project has received funding from the European Community's Seventh Framework Programme under grant agreement n 288445. REFERENCES [1] http://www.androidhive.info/2012/10/android-push-notificationsusing-google-cloud-messaging-gcm-php-and-mysql/ [2] IoT6 D1.3 Updated version of IoT6 architecture & SOA specifications [3] Tomislav Dimčić, Srđan Krčo, Nenad Gligorić, CoAP (Constrained Application Protocol) implementation in M2M Environmental Monitoring System, 2nd International Conference on Information Society Technology, 2012 [4] Nenad Gligorić at al: CoAP over SMS Performance Evaluation for Machine to Machine Communication, 20th Telecommunications Forum (TELFOR), Special Session, 2012 [5] http://datatracker.ietf.org/wg/core/charter/ IETF CoRE Working Group [Last accessed April 2013] [6] Bergmann, O.; Hillmann, K.T.; Gerdes, S., "A CoAP-gateway for smart homes," Computing, Networking and Communications (ICNC), 2012 International Conference on, vol., no., pp.446-450, Jan. 30 2012-Feb. 2 2012. [7] http://tools.ietf.org/html/draft-ietf-core-resource-directory-01 Page 391 of 478

[8] S. Cheshire and M. Krochmal. DNS-Based Service Discovery. RFC 6763. ISSN: 2070-1721, Internet Engineering Task Force, February 2013. [9] Zigbee Specification. ZigBee Document 053474r17, January 2008. [10] E. Guttman, C. Perkins, J. Veizades and M. Day. Service Location Protocol, Version 2. IETF RFC2165, June 1999 [11] IoT6 D6.2 Ubiquitous access and mobile phone network interactions report [12] http://www.iot6.eu/ [13] http://www.raspberrypi.org/ [14] http://www.gogo6.com [15] http://www.gogo6.com/freenet6/tunnelbroker [16] http://www.neurosky.com Page 392 of 478