Smart Waste Management using Internet of Things Architecture

Smart Waste Management using Internet of Things Architecture Alexandru Costin AVRAM Department of Economic Informatics and Cybernetics The Bucharest University of Economic Studies ROMANIA alexanderavram@gmail.com Abstract: This paper showcases a potential design for an Internet of Things gateway that can be used to provide a framework for a Smart Waste Management System. The advantage that this solution gives to the problem of collecting data, processing it and outputting the result action is provided by the protocols used, adapted from technology that has proven itself mature. Protocols like IPv6, HTTP, SSL are synonymous today with the Internet and adapting them to the nature of the embedded computing in the Internet of Things can build upon previous experience. Key-Words: IoT Internet of Things, CoAP, REST, 6LOWPAN, RPL 1. Introduction The Internet of Things concept has arrived to provide a helping hand in connecting different types of devices or things, extracting data from them and perform an action in context with the data read. A potential Smart Waste Management system needs a way to detect which of its trash cans has a bigger load and a way to process this info. The result of this action will be a path sent to the fleets of cars that will take in account the most optimal route to conserve different resources (time, carbon dioxide emissions etc.)[1]. In this article I propose a model of an IoT Gateway that allows through different protocols and devices a way to get the necessary data. 2. Overview of System Advances in low-power wireless communication have allowed IPv6 to be adapted to the embedded world with the 6lowpan translation layer and 802.15.4e as a MAC layer and RPL as a routing protocol. An IoT Gateway sits between an Ipv4/Ipv6 network and a 6lowpan IoT sensor network. The Gateway acts as a router and either transfers messages transparently or acts as a proxy, translating the messages. A brief overview of elements in the network: IoT Nodes / Smart Objects is an embedded device capable of collection sensor data and transmitting it IoT Gateway is an embedded device that acts as a router between sensors/wan networks and is capable of sending data forward to a datacenter to be processed. The Gateway may also establish a feedback loop in order to further interact with the system [1]. Examples of Smart Objects can be Contiki Devices, Nivis Smart Objects, Waspmote sensor boards, while a Raspberry Pi with a Smart Object transceiver can fulfil the role of an IoT Gateway. The IoT Gateway should expose a REST interface to the outside network while using COAP over UDP over 6lowpan on the wireless sensor network side. REST is a software style architecture for communicating information about constructs through simple HTTP messages like GET, PUT, DELETE and POST. Like HTTP it has a client server.architecture and the concept of resource which is identified by a URI. By exposing the REST interface, the IoT Gateway can provide benefits like proxying requests and resource caching as an optimization of 30

Journal of Mobile, Embedded and Distributed Systems, vol. VII, no. 1, 2015 ISSN 2067 4074 traffic, since WSNs can be very constrained environments. [2] Working together with REST is the CoAP layer that provides the way of accessing sensor data. CoAP is an application that is mapped over UDP and can expose resources through URIs. CoAP servers should be run on SmartObjects which can expose that like so: format of URI <Ipv6>:<PORT>/sensors/waste. CoAP can also be secured by using HTTPS or in highly constrained devices with DTLS. The IoT Gateway can translate a REST request into a CoAP request which in turn will arrive at the SmartObject [3]. What makes CoAP ideal for embedded devices is its binary packet structure that facilitates easy parsing for machines. One important thing to take in to account is the use of UDP to clamp down on overhead which leads to an asynchronous nature, a feature which application builders need to be aware of. To paint an obvious picture, each trashcan will be fitted with an IoT Sensor. An IoT Gateway will be mounted in the neighborhood which allows visibility and connectivity to all IoT sensors in that area. The Gateway will collect the data, store and/or forward it by Ethernet/GPRS/WiFi to the back-end for further processing. Trashcans can also have RFID tags which can be read by the garbage collecting cars. 3. The IoT Gateway The IoT Gateway is an important element, being a bridge between two networks that strive to implement the same protocols. The IoT Gateway I propose uses the Raspberry Pi embedded, which is an ARM SoC with 512 MB of RAM and enough computing power to run the Linux OS. As a WAN interface the Raspberry Pi can be connected the RJ-45 Ethernet, Wi-Fi and also GPRS. For a WSN interface, the Pi exposes a SPI interface which can be used to interconnect it with Smart Object transceiver. To coordinate the WSN, the RPL protocol is used. RPL is an IPv6 routing protocol for low power and lossy networks. These networks have strong constraints and its nodes often operate on battery power [3]. As such special precautions need to be taken: low number of changes in the structure of the network so less work is done and less power is consumed by the node; support of multipoint messaging and special broadcast behavior to make sure that the network is not overrun and remains operational. The transceiver is the Root Node in the RPL tree structure. The advantage of this solution is that it can be implemented very fast by using a Contiki OS-capable device as the RPL border router (the actual router between 6lowpan and fullfledged Ipv6). The disadvantage is the fact that the device will probably have a lot less RAM than the Pi, which means that it can only hold a much smaller routing table. The obvious improvement is moving the Root Node to the Raspberry Pi and using the SmartObject only as a bridge (another device) to the WSN. This improvement is outside the scope of this article. Contiki is an open-source OS for Smart Objects which contains a free Ipv6 6lowpan stack (RPL capable) combined with CoAP draft 13 implementation [4]. 3.1 Cooja Simulator To demonstrate this concept we use the Cooja Simulator for Linux, software launched by the creators of the Contiki OS. Cooja is capable of simulating entire WSN (location, transmitting parameters, delay, loss) and to emulate real Contiki devices. The rpl-border-router process (emulated device) can be exposed to the Linux host through a TUN interface which simulates the SPI on the Raspberry Pi. This TUN interface has an IPv6 address and is the gateway for the Ipv6 6lowpan network of the WSN [5]. The Cooja-run processes will thus be divided into two categories: 31

Rpl-border-router: this is the gateway between the two networks; it holds the Ipv6 routing table of the WSN. CoAP server: a REST style server which will expose our needed sensor date by the following URI: <Ipv6>:<COAP_PORT>:/sensors/ waste. A COAP get request to this URI will return a string with the value of the sensor. The full flow will be detailer later in this article. Figure 1. Cooja-run processes. 3.2 Node-RED Node-RED is advertised as a visual way to wire The Internet of Things. It is a tool created by IBM which greatly simplifies the way to create and describe different flows between HW, online services and APIs [6]. With Node-RED we can create a glue between REST on the IoT Gateway side and CoAP at the Smart Objects side. By creating such flows we can use the IoT as a proxy for requests to the IoT sensors. At minimum two flows need to be created to easily support sensor data access. The first flow describes a way for the user to get the device list from the IoT Gateway. A HTTP GET interface is created at the URI http://device-list with the Node-RED URL to be used as a proxy. The Gateway will respond to this request with a JSON array of the device IPv6 addresses of all IoT sensors. This is done by querying a web-server on the rpl-borderrouter node which holds the Ipv6 addresses, parsing the HTML file for the addresses and returning them to the user through a response node. The request and parsing is done by a function node in the Node-RED flow. The second flow describes a way for the user to get the actual sensor data from a specific device. The IoT exposes a RESTlike interface to the user through a HTTP GET node. It will await requests at the /sensors/waste?device=<ipv6> URI. This URI is in a form of a query where <Ipv6> is the Ipv6 address of the requested device. After parsing the required address the flow interconnects with a system node which is capable of running any Linux command/process. In this case it runs the coap-client of the libcoap library with the necessary parameters to reach the /sensors/waste URI at the CoAP server of the specified device. The coap-client will send the request directly to the TUN interface exposed by the Cooja Simulator or that of another process on the Raspberry Pi (the Root process for the RPL tree). The coapclient receives a response through the same interfaces and passes it along to the the following node in the Node-RED flow. This next node is a function node that packages the value in a JSON message which will then be sent back to the user through the HTTP Response node. 32

Journal of Mobile, Embedded and Distributed Systems, vol. VII, no. 1, 2015 ISSN 2067 4074 Figure 2. Node-RED flow. This flows provide the minimum framework for a user to interrogate the IoT sensor nodes and get the waste level from each trashcan sensor 3.3 Data processing in IoT Gateway While the exposed Node-RED interfaces can be used to connect the Gateway to cloud applications, the Gateway can also to do some back-end duty, collect data and store it in a database on the SD/HDD of the Linux IoT Gateway. As a proof of concept, a MySQL database will run on the gateway which will have tables for the devices and of course for sensor readings. To publish the data in the database, a Python multithreaded application was created to get the devicelist and interrogate each device periodically at random intervals between each thread. The threads interrogate the sensors through the interfaces of the IoT itself that were described above: the Node-Red interfaces and flows. This has the advantage of greatly simplifying the implementation. For example for http requests to the interface I use the pycurl module which is a wrapper over the libcurl C library. The database can then be interrogated by the user and calculation can be done on the readings. This has the advantage of caching the readings which can be a tremendous boost to communication stability because we no longer have to constantly query the device if multiple user require the data in the same immediate time-frame. For this get sensor flow will add a node that interrogates the MySQL database to see if a reading from the specified device was recently done (e.g. in the last 30 seconds). 4. Security Security in this IoT architecture is a multitier design. Layered security has proven itself to be a viable concept so applying it in this environment is a natural conclusion. Unwanted aspects that might be permissible without security would be 33

exposing sensor data to outside eyes. For example an attacker might deduce that a homeowner is on vacation because the waste level on his trashcan was constant for a long period of time. As such security is implement at almost every layer. As per the IEEE 802.15.4e drafts, the MAC layer frames can be encrypted with AES. This can offer protection against wireless sniffing attacks [7]. Keys can be pre-shared or use PANA for sharing of communication keys. CoAP data can be protected because the CoAP protocol offers bindings for DTLS (Datagram Transport Layer Security) which acts like a TLS for UDP datagrams. DTLS offers different cipher suites which can be used [1]. The REST interface can be protected by offering a HTTPS socket instead of just a HTTP one. SNMP can also be provided by using v3 of the protocol which offers encryption services. The IoT Gateway connection to the outside WAN can also be protected by either using a VPN service or making sure that communication occurs through a dedicated VLAN. 5. Improvements Several improvements can be made to this architecture. As specified before the rpl-border-router process should be moved from the transceiver to the Linux host to tap on the extra RAM and permit larger networks. Another improvement is to generate Node-RED flows that can permit connectivity of the Gateway to cloud services for IoT like Xively. Besides the REST interface, a SNMP interface can also be exposed to the user since MIB operations poses a great similarity to the GET/POST operations for REST. To facilitate expected behavior both interfaces will have to intersect in a common point. This can be created with a middleware layer that be exposed to both the REST/SNMP layers. As a usability feature, data can also be exposed through a web interface in the form of a portal. At first this can be stored locally on the IoT gateway and will only offer status and information about IoT devices connected to it. This can be then extended to offer functionality similar to cloud apps like Xively, essentially becoming a Network Operating Center for all the Waste Management System. 6. Conclusions An IoT infrastructure can greatly benefit a Waste Management System. Data can b easily accessed from IoT sensors both by human users through common interfaces like HTTP/SNMP, and also through backend High Performance Computing equipment which can periodically query the waste level, and through specific mathematical models can dynamically redirect the fleet of collecting cars. Acknowledgement Parts of this paper were presented at The 7th International Conference on Security for Information Technology and Communications (SECITC 2014), Bucharest, Romania, 12-13 June 2014. References [1] Cristian Toma, Marius Popa, IoT Internet of Things Architecture for Context Aware Sensors Data Processing in Waste Management Solution, 2014 [2] Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, Chapter 5, 2000 [3] Walter Colitti, Kris Steenhaut, Niccolo De Caro, Integrating Wireless Sensor Networks with the Web, 2011 [4] Contiki Team, www.contiki-os.org [5] Cooja and Contiki team, https://github.com/contiki-os/contiki/wiki/an- Introduction-to-Cooja [6] Node-RED team, http://nodered.org/, 2014 [7] P. Thubert, A. Brandy and other, IETF RFC 6550, RPL: IPv6 Routing Protocol for Low- Power and Lossy Networks, 2012 34