Nalin Gupta Thesis

Aalto University

School of Science

Degree Programme of Computer Science and Engineering

Nalin Gupta

Management of Decentralized DHT BasedM2M Network

Masters ThesisEspoo, May 6, 2012

Supervisor: Professor Antti Yla-JaaskiAalto University School of Science, Finland

Instructor: Jouni Maenpaa M.Sc. (Tech.)Ericsson Research, Finland

Aalto UniversitySchool of ScienceDegree Programme of Computer Science and Engineering

ABSTRACT OFMASTERS THESIS

Author: Nalin Gupta

Title:Management of Decentralized DHT Based M2M Network

Date: May 6, 2012 Pages: 9+ 54

Professorship: Data Communication Software Code: T-110

Supervisor: Professor Antti Yla-JaaskiAalto University School of Science, Finland

Instructor: Jouni Maenpaa M.Sc. (Tech.)Ericsson Research, Finland

Machine-to-Machine (M2M) technology is evolving beyond the traditional teleme-try use-cases and becoming key enabler for innovative concepts like Internet-of-Things (IoT), leading to a whole new set of possible applications. Currently thereare 13 billion connected devices and it is envisioned that by the year 2020, thisnumber will reach 50 billion. We believe that the key to achieve this massive scal-ability is using peep-to-peer based decentralized architecture and interoperabilityusing open standards. Architecturally, the Internet is composed of a collectionof heterogeneous sub-networks; similarly, we believe that the next generation ofM2M networks would also consist of heterogeneous networks joined together usinggateways or proxies, giving a hierarchical architecture.

Hence, we are conducting research into decentralized hierarchical Machine-to-Machine (M2M) networks using Internet Engineering Task Force (IETF) andInstitute of Electrical and Electronics Engineers (IEEE) aligned protocols. Thedecentralization is achieved using Distributed Hash Table (DHT) based Peer-to-Peer (P2P) algorithms. The project involves studying the latest state-of-the-arttechnologies like IPv6 over Low power Wireless Personal Area Networks (6LoW-PAN), ZigBee, Constrained Application Protocol (CoAP), Distributed Hash Ta-ble (DHT), Smart-M3, and creating a prototype testbed platform of embeddedLinux and ZigBee devices to carry the experiments and analysis. The focus ofthis thesis is on how to manage this decentralized hierarchical M2M network us-ing Simple Network Management Protocol (SNMP). The central topics studiedare decentralized management, node discovery, resource discovery, node configu-ration, and proxy functionality.

Keywords: M2M, Decentralized, Network Management, SNMP, Proxy,DHT, IoT, Smart-M3, CoAP

Language: English

ii

Aalto-yliopistoPerustieteiden korkeakouluTietotekniikan tutkinto-ohjelma

DIPLOMITYONTIIVISTELMA

Tekija: Nalin Gupta

Tyon nimi:DHT-pohjaisen hajautetun M2M-verkon hallinta

Paivays: 6.5.2012 Sivumaara: 9+ 54

Professuuri: Tietoliikenneohjelmistot Koodi: T-110

Valvoja: Professori Antti Yla-JaaskiAalto-yliopisto, Perustieteiden korkeakoulu

Ohjaaja: Jouni Maenpaa M.Sc. (Tech.)Oy L M Ericsson Ab

Machine-to-Machine (M2M) -teknologioiden kaytto on laajenemassa perinteisistatelemetriasovelluksista uusille sovellusalueille. M2M-teknologiat mahdollistavatjoukon uusia innovatiivisia ratkaisuja kuten niin sanotun esineiden Internet -ekosysteemin. Nama ratkaisut puolestaan avaavat mahdollisuuksia uusien sovel-lusten luomiseen. Talla hetkella markkinoilla on 13 miljardia Internet-verkkoonkytkettya laitetta. Joidenkin arvioiden mukaan vuoteen 2020 mennessa naidenlaitteiden maara kasvaa jopa 50 miljardiin. Taman diplomityon lahtokohtanaon, etta keskeisia tekijoita nain skaalautuvan jarjestelman luomisessa ovat avoi-met standardit ja vertaisverkkoteknologioihin perustuvat hajautetut arkkiteh-tuurit. Internetin arkkitehtuuri koostuu joukosta aliverkkoja. Myos tassa diplo-mityossa lahtokohtana on hierarkkinen arkkitehtuuri, jossa yhdyskaytava- javalityspalvelimet liittavat yhteen joukon heterogeenisia M2M-verkkoja. Tahanajatukseen pohjautuen diplomityon tavoitteena on tutkia hajautettuja M2M-verkkoja, jotka perustuvat Internet Engineering Task Force (IETF) ja Institu-te of Electrical and Electronic Engineers (IEEE) -standardointiorganisaatioidenyhteyskaytantoihin. Tassa diplomityossa hajautetun arkkitehtuurin toteuttami-seen kaytetaan Distributed Hash Table (DHT) -ja vertaisverkkoalgoritmeja.Tyossa tutkitaan myos viimeisimpia teknologioita kuten IPv6 over Low powerWireless Personal Area Networks (6LoWPAN), ZigBee, Constrained Applica-tion Protocol (CoAP), DHT ja Smart-M3. Tyohon kuuluu myos prototyyp-pialustan kehittaminen. Tama alusta koostuu sulautetuista Linux- ja ZigBee-laitteista. Alustaa kaytetaan kokeiden suorittamiseen ja jarjestelman analysoin-tiin. Diplomityon keskeisena tavoitteena on tutkia kuinka hallita hierarkkistaja hajautettua M2M-verkkoa kayttaen Simple Network Management Protocol(SNMP) -protokollaa. Tyon keskeisimpia tutkimusaiheita ovat hajautettu ver-konhallinta, laitteiden loytaminen, resurssien loytaminen, laitteiden konfigurointija valityspalvelintoiminnallisuus.

Asiasanat: M2M, hajautettu, verkonhallinta, SNMP, valityspalvelin,DHT, esineiden Internet, Smart-M3, CoAP

Kieli: Englanti

iii

Acknowledgements

I would like to express my sincere gratitude to Professor Antti Yla-Jaaski forsupervising my thesis and supporting my studies without which this momentwould not have been possible.

I am deeply grateful to my instructors Jouni Maenpaa and Jani Hautakorpifor providing me with the opportunity to work in the prestigious EricssonResearch NomadicLab, and for their guidance, encouragement and kindnessthroughout the research work.

I would also like to thank my fellow students Jaime Jimenez and DaoyuanLi for their friendship and support during the thesis.

Espoo, May 6, 2012

Nalin Gupta

iv

Abbreviations and Acronyms

3G 3rd Generation Mobile Telecommunications6LoWPAN IPv6 over Low-power Wireless Personal Area

NetworksACK AcknowledgmentAPI Application Programming InterfaceAPS Application Support Sub-layerASN.1 Abstract Syntax Notation OneBSD Berkeley Software DistributionCoAP Constrained Application ProtocolCoRE Constrained RESTful Environments working groupDHT Distributed Hash TableDDNS Distributed Domain Name ServiceDNS Domain Name ServiceEABI Embedded Application Binary InterfaceGPRS General Packet Radio ServiceGPS Global Positioning SystemICT Information and Communication TechnologiesIDE Integrated Development EnvironmentIETF Internet Engineering Task ForceIoT Internet of ThingsIPC Inter-Process CommunicationJAR Java ARchiveJSON JavaScript Object NotationLR-WPAN Low-Rate Wireless Personal NetworkLoWPAN Low-power Wireless Personal NetworkLN Local Node, less powerful devices without DHT e.g.

ZigBee motesM2M Machine-to-MachineM2MCE Machine-to-Machine Communication EnablerMCN Monitoring and Controlling Node

v

MD5 Message-Digest algorithm 5MIB Managed Information BaseOID Object IDentifiersOSI Open Systems InterconnectionP2P Peer-to-PeerP2P4M2M Peer-to-Peer for M2M NetworkPAN Personal Area NetworkPDU Protocol Data UnitPN Proxy Node for interfacing LNs with WNQoS Quality of ServiceREST Representational State TransferRFID Radio-Frequency IDentificationRMI Remote Method InvocationRPC Remote Procedure CallRTT Round Trip TimeSIB Semantic Information BrokerSMI Structure of Management InformationSNMP Simple Network Management ProtocolUDP User Datagram ProtocolURI Universal Resource IndicatorUSB Universal Serial BusUSM User-based Security ModelVACM View-based Access Control ModelWAN Wide Area NetworkWN Wide Area Node, embedded Linux based devices with

DHTWPAN Wireless Personal Area NetworkWSN Wireless Sensor NetworkWWAN Wireless Wide Area NetworkXML Extensible Markup LanguageZDO ZigBee Device Object

vi

Contents

Abstract ii

Acknowledgements iv

Abbreviations & Acronyms v

List of Figures ix

1 Introduction 11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Research Objective . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Thesis Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 Wireless Sensor Networks (WSN) . . . . . . . . . . . . . . . . 52.2 Machine to Machine (M2M) . . . . . . . . . . . . . . . . . . . 62.3 Internet of Things (IoT) . . . . . . . . . . . . . . . . . . . . . 72.4 ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Constrained Application Protocol

(CoAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 Distributed Hash Table (DHT) . . . . . . . . . . . . . . . . . 102.8 Peer-to-Peer (P2P) Technologies . . . . . . . . . . . . . . . . . 112.9 Simple Network Management Protocol

(SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.10 Smart-M3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Decentralized M2M Network Design 153.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16

vii

3.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . 183.4 Functional Description . . . . . . . . . . . . . . . . . . . . . . 19

3.4.1 M2M Communication Enabler Abstraction Layer . . . 203.4.2 Monitoring and Controlling Node . . . . . . . . . . . . 223.4.3 Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Smart-M3 System . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Decentralized M2M Management 254.1 Challenges in Decentralization . . . . . . . . . . . . . . . . . 254.2 MCN Functionality . . . . . . . . . . . . . . . . . . . . . . . . 264.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 P2P4M2M Protocol Stack . . . . . . . . . . . . . . . . . . . . 284.5 MCN Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.6.1 Name Resolution . . . . . . . . . . . . . . . . . . . . . 304.6.2 MCN Operation . . . . . . . . . . . . . . . . . . . . . . 314.6.3 LN to WN . . . . . . . . . . . . . . . . . . . . . . . . . 324.6.4 WN to LN . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Prototype Implementation 365.1 Hardware Specification . . . . . . . . . . . . . . . . . . . . . . 36

5.1.1 LN Hardware . . . . . . . . . . . . . . . . . . . . . . . 365.1.2 PN Hardware . . . . . . . . . . . . . . . . . . . . . . . 385.1.3 WN Hardware . . . . . . . . . . . . . . . . . . . . . . . 395.1.4 MCN Hardware . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Software Specification . . . . . . . . . . . . . . . . . . . . . . 395.3 Software Structure . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3.1 M2M System Startup . . . . . . . . . . . . . . . . . . . 43

6 Evaluation and Discussion 45

7 Conclusions and Future Work 487.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Bibliography 50

viii

List of Figures

1.1 Decentralization of M2M Network . . . . . . . . . . . . . . . . 2

2.1 Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . 62.2 ZigBee Protocol Stack . . . . . . . . . . . . . . . . . . . . . . 82.3 6LoWPAN Network . . . . . . . . . . . . . . . . . . . . . . . . 92.4 SNMP Network Management . . . . . . . . . . . . . . . . . . 12

3.1 Decentralized M2M Network Architecture (P2P4M2M) . . . . 183.2 M2MCE Abstraction Layer . . . . . . . . . . . . . . . . . . . 213.3 Smart-M3 System . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 P2P4M2M Network Protocol Stack Diagram . . . . . . . . . . 284.2 Command Line Interface . . . . . . . . . . . . . . . . . . . . . 294.3 Message Sequence for Name Resolution . . . . . . . . . . . . . 314.4 MCN sets association between sensor and actuator . . . . . . 324.5 Information from LN towards WN . . . . . . . . . . . . . . . . 334.6 Information from WN towards LN . . . . . . . . . . . . . . . . 34

5.1 Local Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.3 Lab Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Software Architecture of PN . . . . . . . . . . . . . . . . . . . 43

ix

Chapter 1

Introduction

1.1 Overview

Machine-to-Machine (M2M) technology gained roots in early 2000s, pow-ered by the ubiquitous wireless cellular connectivity. Today it is evolvingbeyond the telemetry applications and becoming cardinal enabler for inno-vative concepts like Internet-of-Things (IoT), leading to a whole new setof possible applications. Currently there are 13 billion connected devicesand it is envisioned that by the year 2020, this number will reach 50 bil-lion [18]. We believe that the key to achieve this level of massive scalabilityis using Peer-to-Peer (P2P) based decentralized architecture and interoper-ability using open standards. Architecturally, the Internet is composed ofheterogeneous sub-networks, similarly, we believe that the next generationof M2M networks would also consist of collection of heterogeneous subnetsjoined together using gateways or proxies, giving a hierarchical structure.Hence, we are conducting research into scalable decentralized hierarchicalM2M networks using IETF and IEEE aligned open standards and protocols.The decentralization is achieved using Distributed Hash Table (DHT) basedP2P algorithms. The project involves studying the latest state-of-the-arttechnologies like 6LoWPAN, ZigBee, CoAP, Smart-M3, and creating a pro-totype testbed platform of embedded Linux and ZigBee devices to carry theexperiments and analysis.

1.2 Research Objective

The current M2M and Wireless Sensor Network (WSN) networks use cen-tralized approaches. The WSNs use sensors to collect information about itsenvironment and relay it to central location, where the data is processed.

1

CHAPTER 1. INTRODUCTION 2

Centralized

= Sensor = Actuator

Figure 1.1: Decentralization of M2M Network

M2M networks use embedded devices for remote monitoring and manage-ment from central locations. In both the cases, the intelligence and decisionmaking is done using centralized entities.

However, the centralized approaches have several challenges which donot lend themselves to the envisioned use-cases for M2M and IoT. Three keyissues are:

scalability to the order of millions of nodes distribution of intelligence among nodes (more details about this in

Section 2)

tolerate failure of parts-of-networks (centralized entities have singlepoint of failure for entire network)

Our aim is to solve the above challenges by decentralizing the M2M net-works using DHT-based P2P mechanisms and creating a P2P4M2M net-work. Chapter 3 Section 3.1 describes details on how P2P addresses these


challenges. The objective of our research project is to study the challengesin the decentralization of M2M networks. The research project is dividedinto three Masters thesis - (1) Adapting DHT for M2M network require-ments [11] (2) Using proxy to connect ZigBee based Wireless Personal AreaNetwork (WPAN) to the M2M network [35] (3) Using SNMP in decentralizedmanner to manage the M2M network (this thesis).

In tune with the IETF approach of have running code 1, developing aprototype testbed is an important part of this research project. This testbedplatform will then be used for further research on the overall topic of decen-tralizing M2M networks.

During the remaining of this thesis, we shall use the term P2P4M2Mresearch project to refer to the overall research project in which this thesiswas done.

1.3 Thesis Scope

This thesis studies the management of decentralized M2M network usingopen standards. The main topics that are studied are decentralized man-agement, node discovery, resource discovery, node configuration, and proxyfunctionality.

The following specific objectives defines the scope of this thesis:

1. Develop network management software for decentralized M2M networkand a Managing and Controlling Node (MCN) that provides humaninterface

2. Make the M2M network self-reliant i.e. the M2M network should beable to operate normally even when MCN is disconnected

3. The software should have gateway or proxy module that allows man-agement of ZigBee based sub-network

4. The software should allow information interoperability using Smart-M3semantic web platform, enabling web applications to interact with thedecentralized M2M system

The DHT implementation and the ZigBee Proxy module implementationis out of scope of this thesis. The contribution of this thesis is listed in detailin the Chapter 6.

1http://www.ietf.org/tao.html


This thesis is part of work package for Devices and Interoperability Ecosys-tem (DIEM) 2 program funded by TEKES 3 - the Finnish Funding Agencyfor Technology and Innovation. The P2P4M2M research project in whichthis thesis was done also involves close collaboration with the Future Inter-net program, which is part of ICT cluster of the Finnish Strategic Centresfor Science, Technology and Innovation (ICT SHOK) 4. Inline with the ob-jectives of these research programs, interoperability and future Internet arekey aspects of our P2P4M2M research project. This explains the emphasisof the research project on CoAP, IP, SNMP and IEEE 802.15.4 technologies.

1.4 Thesis Organization

Chapter 2 describes an overview of the protocols and technologies used inthe prototype, which would provide useful background for understanding thisthesis. It is followed by Chapter 3 which describes the design principles usedfor the prototype, its system architecture and functionality. Next, Chapter 4covers the challenges and solutions for decentralized management of the M2Mnetwork.

The hardware and software specifications for the prototype implementa-tion are given in Chapter 5. It also covers the software architecture of theprototype and the system startup details. Then, in Chapter 6, we discuss andevaluate the learnings from this project. In Chapter 7, the learnings fromthis project are summed up and useful take-away conclusions are presented.Finally, we mention the research work that will be carried out in future usingthe testbed developed under the scope of this project.

2http://www.diem.fi3http://http://www.tekes.fi4http://www.futureinternet.fi

Chapter 2

Background

Our research involves numerous technologies and protocols. In this chapterwe give a brief overview of them.

2.1 Wireless Sensor Networks (WSN)

Wireless Sensor Networks (WSN) have come a long way from their beginningin University research, and have laid the foundation for latest concepts likeIoT. As shown in Figure 2.1, WSN consists of a collection of sensing andactuating devices, commonly called as motes, and gateway nodes. The motesare typically battery powered embedded devices which are resource limitedin terms of computational power. Also their wireless connectivity has shortrange. The gateway nodes, however, have higher configuration in terms ofhardware and wireless range, which enables them to communicate with basestation.

WSN operates with nominal or no infrastructure support. Due to lackof infrastructure support and resource constrained nature of devices, thetraditional networking protocols are not suitable for WSN. Wireless meshnetworking is one of the most common technique to overcome the disad-vantages of short range connectivity. Due to the academic parentage, mostof WSN research produced proprietary solutions and lacked interoperability.IEEE 802.15.4 is the first open standard for low power radio that got globalacceptance. Then based on IEEE 802.15.4, ZigBee became one of the firststandards to gain commercial interest. WSN is mainly used for tracking andmonitoring use-cases [54].

The concepts of WSN, M2M IoT, ZigBee and 6LoWPAN are inter-twingedand the boundary between them is not sharp. We will point out the dis-tinguishing characteristics of each of these technologies in their respective

5

CHAPTER 2. BACKGROUND 6

SensorMote

GatewayMote

Figure 2.1: Wireless Sensor Network

sections.

2.2 Machine to Machine (M2M)

The success and ubiquity of wireless cellular modems enabled M2M to gainmarket breakthrough for telemetry and remote management use-cases likemanaging vending machines [46]. The observation that the value of machinesincreases tremendously when they are networked with one another [32], hasled to a fast growing interest in M2M domain. However, there is no clearlyagreed upon definition for the term M2M. Two good definitions are as follows:

M2M consists of machines and backend services that are used for remotemonitoring and controlling of devices. The devices typically have longrange wired or wireless capabilities, and most often they use cellularmodems for wireless connectivity.

M2M is a system where machines exchange information and run thesystem with little or no human intervention

M2M has created possibilities of new unforeseen business ventures. M2Mis making devices smarter and the world more efficient. Examples include


intelligent supply chain management and smart utility metering. The tech-nologies to enable M2M are already available and the key challenges for M2Mare integrating these technologies and creating global standards. ETSI haslaunched the M2M Technical Committee 1 to meet these challenges.

WSNs enable M2M but an important difference between WSN and M2Mis that WSN domain deals with the challenges for networking resource con-strained devices with short range low power wireless connectivity. In con-trast, M2M devices typically have cellular based wide area connectivity andas such, the M2M domain is more concerned with standardization and cre-ating service platforms. Also, M2M devices need not always have sensors oractuators.

2.3 Internet of Things (IoT)

The term Internet of Things (IoT) was originally coined by Kevin Ashton [8]to use Radio-frequency identification (RFID) technology with Internet. Sincethen, the term IoT has expanded in its scope and now it refers to the networkof embedded devices (also called smart objects) with native IPv6 capabilitiesthat are connected to the global Internet. A significant characteristics ofIoT is that its scale is expected to be of the order of trillions [46]. The IoTInitiative (IoT-i) program has come up with a set of futuristic and ambitioususe-cases for IoT 2.

IETF has three work groups relevant for IoT wireless smart objects:

Constrained RESTful Environments (CoRE) [2] IPv6 over low power wireless area networks (6LoWPAN) [1] Routing Over Low-power and Lossy Networks (ROLL) [3]IETF encourages wireless smart objects to use IEEE 802.15.4, so it has

created 6LoWPAN group to adapt IPv6 for IEEE 802.15.4. Together withROLL and CoRE, 6LoWPAN specifies a complete system to connect wirelessdevices to Internet.

IoT is closely related to M2M, with the chief distinguishing attributebeing that, unlike M2M devices, the IoT devices must be IP-enabled andconnected to the global Internet. Internet connectivity for embedded devicesopens a huge range of possible applications, but also brings new challengesin the field of security.

1http://www.etsi.org/website/technologies/m2m.aspx2http://www.iot-i.eu


2.4 ZigBee

ZigBee protocol suit is created by an industry consortium called ZigBee Al-liance. It builds upon IEEE 802.15.4 to cover the complete vertical protocolstack by adding networking support, security, and service discovery. Zig-Bee application profiles which ensure that the manufacturers products areinteroperable at application level. Figure 2.2 3 shows the ZigBee protocolstack.

Figure 2.2: ZigBee Protocol Stack

ZigBee uses bands including 2.4GHz, 900MHz and 868MHz. It supportsboth short range and long range wireless connectivity using IEEE 802.15.4and cellular modems, respectively. Hence, ZigBee devices can be used forboth, WSN and M2M domain.

Unlike 6LoWPAN, ZigBee does not have IP connectivity, though it in-tends to do so in near future 4. Another difference between 6LoWPAN and

3http://i.cmpnet.com/eetimes.fr/news/2008/zigbee_stack_4.gif4http://zigbee.org/imwp/idms/popups/pop_download.asp?contentID=

15754


ZigBee is that 6LoWPAN does not specify application level profiles like Zig-Bee.

2.5 6LoWPAN

IETF has created 6LoWPAN working group [1] to define the specifications forLow-power wireless personal area networks (LoWPANs) consisting of IEEE802.15.4 devices. 6LoWPAN creates a thin layer over IEEE 802.15.4 to adaptit for IPv6. RFC 4919 [31] gives its objective and problem statement and RFC4944 [38] specifies the 6LoWPAN protocol. Figure 2.3 shows a 6LoWPANNetwork.

Global IPv6 InternetNode

Edge Router

LoWPAN

Figure 2.3: 6LoWPAN Network

6LoWPAN devices are suitable for a WSN domain. Additionally, 6LoW-PAN devices can participate in IoT, courtesy edge routers, which transpar-ently provide native IPv6 based access to Internet. Reference [14] is a goodcase study for using 6LoWPAN devices for IoT.


2.6 Constrained Application Protocol

(CoAP)

Constrained Application Protocol (CoAP) is web protocol that has been cre-ated with the objective of applying Representational State Transfer (REST)architecture [19] to the M2M domain. The industry standard protocol forREST is HTTP. However, HTTP is ill suitable for M2M due to the con-strained environment of M2M. Hence, HTTP is customized for M2M in theform of CoAP by defining smaller messages with simpler parsing. CoAP usesasynchronous messaging over connectionless transport protocol with request-response messaging model. CoAP is specified in the IETF drafts [21], [45],and [47]. It includes a resource discovery mechanism which is critical forM2M communication.

CoAP can be used in WSN domain as well as M2M domain. It enablesembedded devices to be part of IoT, thanks to its full compatibility withHTTP.

2.7 Distributed Hash Table (DHT)

Distributed Hash Table (DHT) is a distributed system that provides servicesto store and retrieve data using a (key,value) pair. DHT has a simple interface- it returns a unique key when the data is stored; this key can then later beused to retrieve the data. The mapping from key to value and the valueitself is stored among nodes in a distributed manner. Typically, the data isreplicated on separate nodes to accommodate node failures or nodes leavingDHT system. Caching is used to improve system performance.

DHT are very sophisticated data structures that have revolutionized dis-tributed networks. In 2001, [9] listed the first significant set of DHT algo-rithms namely- CAN, Chord, Pastry, and Tapestry - which bootstrapped theDHT research field.

The key DHT challenges are optimizing store/retrieve operations, faulttolerance, handling concurrent changes, malicious nodes and indexing [9].Reference [51] describes the security challenges for DHT systems.

DHT algorithms have been used for creating advanced network topologiesand lookup services and they are fundamental for creating P2P networks.They can also be used for distributed storage applications that stores anyarbitrary data in a network. As an example Hazelcast [4] uses DHT to createa data distribution platform.


2.8 Peer-to-Peer (P2P) Technologies

Peer-to-Peer (P2P) refers to a network where nodes can communicate witheach other without requiring any central entity to coordinate. This conceptis in contrast to the client/server architecture. The distinguishing character-istics of P2P are decentralized network, autonomous nodes and combinationof client and server functionality in all nodes [20]. In P2P, all nodes haveequal control in network and every nodes shares its resources in terms ofstorage, network bandwidth, and CPU cycles.

Although P2P systems have been around for sometime time, it is therecent advancements in distributed computing techniques, like DHT basedapproaches, that have sparked vigour in the P2P domain.

2.9 Simple Network Management Protocol

(SNMP)

The main tasks of network management can be categorized as follows [10]:

Monitoring the network, services and managing faults Administration, consisting of housekeeping activities like keeping track

of devices and other resources in the network.

Maintaining the network software and hardware Provisioning the system, which involves configuring the devices

SNMP is the IEFT recommended standard for handling these tasks. TheSNMP network management has three components:

The SNMP protocol: It defines the operations performed by ProtocolData Units (PDUs) and their message formats.

Management Information Base (MIB) - It is the collection of variablesthat are monitored and controlled on managed devices. The variablesare identified using Object IDentifiers (OID) in an extensible hierarchi-cal namespace.

Structure of Management Information (SMI) - It defines the subset ofAbstract Syntax Notation One (ASN.1) rules which are used to defineMIB variables.


Manager- NMS- No MIB

Managed Devices / Agent- MIB

SNMP PDUs(Agent to Manager)- Response- Trap- InformRequest

SNMP PDUs (from Manager to Agent)- GetRequest- SetRequest- GetNextRequest- GetBulkRequest

Figure 2.4: SNMP Network Management

SNMP protocol uses request-response messaging between two types ofentities - Managers and Agents. SNMP Managers are typically separatecomputers which are used to monitor and control the Agents. They alsohost Network Management System (NMS) software, though NMS is not cov-ered by SNMP specifications. SNMP Agents are the managed devices whichimplement MIB.

SNMP protocol uses the following message types:

These messages are sent from Manger to Agent GetRequest. It is used to retrieve the value of a single or possibly

list of variable(s).

SetRequest. It is used to configure the value of a single or possiblylist of variable(s).

GetNextRequest. It is used to discover variables and their values.


GetBulkRequest. This was added in SNMPv2 to discover vari-ables with higher efficiency.

InformRequest. It is asynchronous notification message used forManager to Manager communication. It can also be used forAgent to Manager communication.

These messages are sent from Agent to Manager Response. It carriers the values of variables for all the Manager

initiated messages.

Trap. It also carriers the values of variables with the differencethat it is initiated by Agent. It is used by Agent for asynchronousnotifications.

There are multiple versions of SNMP, but practically only 3 versions areused - SNMPv1 (RFC 1157 [12]), SNMPv2c (RFC 1901 [13]), and SNMPv3(RFC 3411 [23]). Research in [43] concluded that SMNP is most commonlyused for monitoring and not for configuring the network and devices. Also,the market penetration of SNMPv3 is not deep.

There has been a lot of interesting research work for decentralizationusing SNMP, for example [26] and [39]. However, the hierarchical tree struc-ture remains as the most popular decentralization mechanism with currentgeneration of NMS, which makes these approaches different from our work.

2.10 Smart-M3

Smart-M3 system is an information sharing platform for interoperability be-tween vendor, device and domain [24]. It uses blackboard architecture modelto allow cross-domain devices to share information about their local envi-ronment. The resources in a device are described in Resource DescriptionFramework (RDF) representation using Web Ontology Language (OWL) 5.Open source implementation of Smart-M3 platform is available under BSDlicense 6.

In essence, Smart-M3 provides a Semantic Web platform, very similar tothe idea of Tim Berners-Lee described in [33]. The biggest difference is thatthe information in Smart-M3 smart space is local in nature and changes moredynamically than that in the Internet level global smart space.

Smart-M3 consists of the following components:

5http://www.w3.org/standards/techs/owl6http://smart-m3.sourceforge.net


Smart-M3 Space. It is a named searchable area of information in Smart-M3 platform, commonly called Smart Space.

Smart-M3 Semantic Information Broker (SIB). It is a physical or virtualentity which stores the information in Smart-M3 Space.

Knowledge Process (KP). It is Smart-M3 agent sitting on a devicewhich is responsible for interactions with the Smart-M3 SIB like in-serting, reading or removing information.

Smart Space Access Protocol (SSAP). It is the session-based protocolused by KPs to access the information available in SIB. It providesseven operations - join, leave, insert, remove, update, query, subscribe,unsubscribe. The exchanged data is encoded in XML or JASON.

We use Smart-M3 platform to study the integration of decentralized M2Mnetwork with Semantic Web 7.

7http://www.w3.org/standards/semanticweb

Chapter 3

Decentralized M2M Network De-sign

In this chapter we describe the motivation for decentralizing M2M networksusing P2P, followed by the principles used for designing the M2M networkarchitecture. Then an overview of the network architecture is presented, andfinally a description of the three most important functional entities in thenetwork is given.

3.1 Motivation

In Section 1.2 we mention that the centralized systems suffer from scalabilityissues and difficulty in distributing intelligence in network. In this section weelaborate on the need to distribute intelligence in M2M networks, and howP2P effectively solves the scalability issue of M2M networks.

The current technology trend is that the intelligence is moving towardsthe edge of network, for example in the cellular systems, Base TransreceiverStations (BTS) have evolved into intelligent NodeB. The intelligent devicescan interact with other devices to share information, and then use the localinformation to make decision by itself without requiring any central entitiesto issue commands. We believe that intelligent devices with Artificial In-telligence (AI) is key for success of concepts like IoT. Consider one of theproposed use-cases for IoT 1: there is an accident on road, which causes thealarm clock to start ringing 30 minutes before set-time to enable the personto reach office on time. Another use-case is handling traffic light signalingand speed limits according to traffic patterns and weather conditions. How-ever, most software can only handle the scenarios for which it was explicitly

1http://ws4d.e-technik.uni-rostock.de/pipesbox

15

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 16

designed, and it takes AI to handle new unforeseen scenarios. Since IoTuse-cases involve using complex set of information to handle unforeseen sce-narios, AI is critical for IoT success. Even though gaming industry have beenusing AI since a long time, it is Apple Siri application 2 which has broughtAI to mainstream masses for the first time since more than four decades ofComputer Science. P2P technologies enable distribution of intelligence inthe network, hence it is well suited for integrating AI with M2M networks.This is an exciting research area, however, AI and its integration with M2Mnetworks is out of scope for this thesis, and we focus on using P2P for M2Mcommunication.

Additionally, peer-to-peer technologies can be used effectively to achieveInternet level of scalability. For example, consider a centralized networkconsisting of 100000 nodes. Now if another 1000 nodes have to join thenetwork, it would require additional resources from the centralized entitiesputting additional load, and the system can easily be saturated. In contrast,in a peer-to-peer based system, each new node joining the network pools itsown resources towards the network system thereby allowing higher scalability.BitTorrent is a very good example to illustrate the concept. In a BitTorrentsystem, a machine originally hosting a file needs to transfer the segments ofthe file only once, and all the other peer machines can get a copy of the file byexchanging the segments among themselves. This way each machine which isa part of the peer-to-peer system shares its resources - computational, storageand network bandwidth - with the whole system allowing even distributionof load, and hence allowing system to scale easily.

3.2 Design Principles

In this section we outline the design principles along with a brief motivationfor making these design choices.

IEEE 802.15.4 3 has emerged as the undisputed leader in low power radiotechnology [46]. It is used in most of the M2M specifications like 6LoW-PAN [38], ZigBee, ISA100.11a [5], and WirelessHART [6]. The networkformed by IEEE 802.15.4 devices is typically referred to as Wireless Per-sonal Area Network (WPAN). We considered among ZigBee and 6LoWPANdevices for our prototype testbed. The 6LoWPAN devices have native IPsupport, hence they are a good candidate, however, 6LoWPAN devices werenot easily available at the time of writing this thesis and they were more ex-pensive. On the other hand, ZigBee devices are easily available, and moreover

2http://www.apple.com/iphone/features/siri.html3http://www.ieee802.org/15/pub/TG4.html


ZigBee consortium is already aligning themselves to IP 4, hence we selectedZigBee devices for WPAN.

Internet is a huge success story and two factors have been critical to itsmass adoption - interoperability based on open standards and connectingvastly heterogeneous networks by allowing flexibility on the physical layertechnologies. We believe that these two factors will also be very importantfor the success of next generation M2M networks. In specific, IP capabilitywill be crucial since it will enable the embedded devices to easily integratewith the existing Internet infrastructure. To study connecting heterogeneousnetworks, connecting IP enabled M2M network with ZigBee network is oneof the important aspects of P2P4M2M research project.

The objective of P2P4M2M research project is to decentralize M2M net-works using P2P technologies. We have chosen RELOAD protocol [48], whichis a DHT based P2P protocol, to form the decentralized distributed system.It is known that currently it is infeasible to execute DHT implementationson low resource embedded devices [36], hence, the ZigBee motes do not useP2P technologies. We have chosen Linux based microcontroller boards forhosting Chord protocol.

Another interesting aspect is the range of communication. We are in-terested in both, local communication between devices (for example, homeappliances talking with smart energy metering) and long distance commu-nication (for example, a user checking the status of home appliances fromoffice). The IoT Initiative (IoT-i) program 5 has defined 60 potential use-cases for IoT and in several cases the devices are spread over large physicaldistance. Low powered radio technology like ZigBee enable local communi-cation, but for long distance we need wireless cellular technologies. Hence,we have decided to use 3G connectivity for the devices that are connectedusing P2P. Cellular based M2M devices have the benefit of easier installationand enabling higher mobility and bandwidth 6.

Additionally, cellular based embedded devices can also nicely work asGateway devices to connect the WPAN formed by low powered ZigBee de-vices. The resulting hierarchical structure adds to the scalability of the sys-tem and allows the possibilities of interoperating with heterogeneous tech-nologies through Gateway (since the WPAN could be 6LoWPAN or someother technology).

A monitoring and controlling entity is required in the M2M network toprovide interface to humans. Since we want the network to be self-reliant, the

4https://docs.zigbee.org/zigbee-docs/dcn/09-5003.pdf5http://www.iot-i.eu6http://www.etsi.org/Website/Technologies/M2M.aspx


network must be able to work without requiring continuous presence of thisentity. Also, keeping in-line with the decentralization goal, the managementfunction should be spread over the devices in the network. Hence, all theM2M devices will host management software.

Summing up the above design principles leads to the system architecturedesign as shown in Figure 3.1 in next section.

3.3 System Architecture

LN- ZigBee

WN-WWAN-P2P

PN-WWAN-P2P-ZigBee

LN- ZigBee

WN-WWAN-P2P

Monitor/ControlApplicationMonitoring &Controlling

WWAN

WPAN

= Sensor = Actuator

P2P Network

Figure 3.1: Decentralized M2M Network Architecture (P2P4M2M)

The system architecture for our prototype is shown in Figure 3.1. Hence-forth, we will use the term P2P4M2M to refer to this particular decentralizedM2M network architecture. There are 4 distinct types of nodes in P2P4M2Mnetwork and they have been termed individually for easy reference. All the4 nodes differ in their hardware and functionality.


Monitoring and Controlling Node (MCN) : This device provideshuman interface to the P2P4M2M network and it is used to configurethe nodes and P2P system. It will not have any sensors or actuators.It can be a laptop, tablet or smart-phone possibly running a GUI. Inour prototype, we have used a laptop. As explained later, MCN usesSNMP protocol for network management.

Wide Area Node (WN) : This device forms part of the P2P over-lay using the DHT based implementation. It uses 3G wireless cellularconnectivity and since these devices can communicate over large dis-tances, the collection of these devices is called Wireless Wide AreaNetwork (WWAN). A WWAN can have both sensors and actuators,and it uses CoAP for M2M communication.

Local Node (LN) : This device is cheaper, but at the same time ahighly constrained device with limited processing, storage and shortrange radio connectivity. It cannot host DHT based P2P implementa-tion, but thanks to the Proxy Node functionality, it still participatesin the P2P overlay. It can have both sensors and actuators. In ourprototype, ZigBee devices are used as LNs.

Proxy Node (PN) : This device is same as WN with the addition thatit also performs the Gateway and Proxy functionality for the LNs. Ithas an attached ZigBee Coordinator device which enables it to handleWPAN management and provide messaging interface to the LNs. Itis also responsible for the protocol conversion for CoAP and SNMPmessages into ZigBee protocol (and vice-versa).

Since WNs can have sensors and actuators, they only differ from ZigBeedevices in terms of their ability to host DHT implementation and IP connec-tivity. So WN represents the next generation M2M embedded devices, whenthe advancements in P2P algorithms and hardware capabilities will allowthese devices to host DHT. Hence without loss of generality or flexibility,this system architecture represents a decentralized M2M network.

The table 3.1 captures the important properties of all the four types ofM2M devices.

3.4 Functional Description

The following three functional entities have been researched and developedin the overall scope of the P2P4M2M research project.


Local Node (LN)

WPAN (e.g. ZigBee)

No DHT Moderate hardware

(e.g. 8kB RAM) Simple OS (e.g.

TinyOS or Arduino Platform)

Either S or A

Cheap

Proxy Node (PN)

WPAN (e.g. ZigBee) WWAN (e.g. 3G) DHT Advanced hardware

(e.g. 256 MB RAM) Advanced OS (e.g.

Linux)

Can optionally have either S, A, or both

Costlier

Wide-area Node (WN)

WWAN (e.g. 3G)

DHT Advanced hardware

(e.g. 256 MB RAM) Advanced OS (e.g.

Linux)

Can optionally have either S, A, or both

Costlier

Monitoring & Controlling Node

(MCN)

WWAN or fixed access

DHT Normal PC

hardware, Tablet Desktop OS (e.g.

Windows)

S/A-WWAN-DHT

Proxy S/A-WWAN-DHT-ZigBee

Cheap S- ZigBee

Monitor/ControlApplication

S = SensorA = Actuator

Table 3.1: Device Properties

3.4.1 M2M Communication Enabler Abstraction Layer

We have used OSI layering principles to separate the system functionality intohierarchical layers, where each layer provides well defined APIs for higherlayers. Now, DHT algorithm by themselves only provides the ability tostore and retrieve a key-value pair. To develop a decentralized M2M systemusing DHT, we needed to create an abstraction layer - which we termedas M2M Communication Enabler (M2MCE) - on top of DHT, which hidesthe distributed nature of information storage and provides an API to accessinformation as if the information was stored on the local node itself (hence theAPIs are implemented as synchronous function calls and not as asynchronousmessage passing or callback functions). In addition, M2MCE also providesAPIs to enable messaging using the P2P overlay, and accessing the logicalpredecessor/successor nodes of P2P (Chord based) overlay.

The M2MCE layer provides the following functions:-

APIs which allow nodes to join and leave the P2P overlay. These APIs


MCN / CoAP / PN

DHT

OS

MCN / CoAP / PN

DHT

OS

MCN / CoAP / PN

DHT

OS

...

M2MCE Layer

M2MCEhides

distributedarchitecture

Figure 3.2: M2MCE Abstraction Layer

are used by WN and PN to register/unregister to the M2M system.LNs do not directly use these APIs, but PN does it on their behalf.

Interface for distributed data storage, which internally builds upon theunderlying DHT algorithm. Typically, the data is stored over severalpeers and it is ensured that there is no loss of data even if some peersleave the system. This distributed storage can also be used to storenetwork alarms, traps etc.

Since all the nodes register to P2P4M2M using M2MCE, it can easilymaintain a log of all the nodes in the network using the distributedstorage. This gives an easy node discovery mechanism.

Distributed DNS functionality. As such, the M2M system is about ma-chines communicating with machines and hence do not need a humanreadable name. However, humans need to interact with the system forprovisioning and maintenance, so having human understandable names


for devices is required. Also, these names are used in CoAP URIs. Ad-ditionally, the notion of name helps decouple identity and location formobile nodes avoiding the well known issue with IPv4.

M2MCE allows broadcast messaging service in the P2P4M2M network,using the Chord overlay. There can be different techniques used tobroadcast message, but these methods are transparent for the higherlayer (above M2MCE). It is a research agenda for M2MCE to find themost efficient method for broadcasting.

Detailed description of M2MCE is beyond the scope of this thesis, butthe complete details can be found in [11].

3.4.2 Monitoring and Controlling Node

Since MCN is part of the focus area of this thesis, it is covered in-depth inthe chapter 4.

3.4.3 Proxy Node

The proxy node performs the following functions:-

The WWAN uses SNMP and CoAP protocols, whereas the WPAN usesZigBee protocols. Hence, PN does the protocol conversion from SNMPand CoAP to ZigBee. A few messages have direct mapping betweenthe protocols (like the SNMP MIB to trigger detaching a LN is directlymapped to ZigBee ZDO message ZDO CLUSTER MGMT LEAVEREQUEST), and the other messages are sent to LNs using Type-Length-Value (TLV) format. PN also interfaces with the CoAP proxyand SNMP proxy as per their respective specifications

PN is responsible for the ZigBee WPAN management, including nodediscovery and service discovery. After the PN starts, it enables theZigBee coordinator node (which is part of PN). Whenever a LN joins(or leaves) the WPAN, it inform the ZigBee coordinator node, whichfurther informs the PN. In this way, the PN keeps track of all the LNsthat are part of the WPAN. ZigBee coordinator node uses a timer basedheartbeat mechanism to discover any LN that leaves WPAN withoutinforming, for example due to failure. PN uses ZigBee protocol todiscover the services hosted by LNs.


When the LNs join the WPAN, the PN assigns them a name using thewell known dot notation, for example, if the PN name is PN100, thenit can assign LN names like PN100.LN1, PN100.LN2, PN100.LN. ThenPN uses M2MCE interface to join the P2P overlay on behalf of eachLN. Hence, PN represents LNs in P2P overlay, provides an abstractionto the other peer nodes such that the LNs appear as a full-fledged peer.In a way, we can think of LNs as pseudo-peers. Similarly, when a LNleaves WPAN, PN performs leave operation on DHT on behalf of thedeparting LN.

LNs are front-ended by PN, and M2MCE layer translates a LN name(like PN100.LN1) into the IP address of the PN (since LN can haveonly ZigBee address). So for any messages exchanged between WWANand WPAN, PN does the translation between IP adress and ZigBeedevice address.

PN caches sensor data. This is especially useful for the sleeping sensordevices, which periodically wake up and send data to the PN. PN thencaches this data and uses it to handle any future request. PN can alsouse P2P overlay to cache the data if required.

PN can potentially provide firewall functionality to secure WPAN, how-ever this is left as future work.

Detailed description of PN is beyond the scope of this thesis, but thecomplete details can be found in [35].

3.5 Smart-M3 System

Smart-M3 system is an information sharing platform for interoperability be-tween vendor, device and domain [24]. We used Smart-M3 platform to studyintegration of P2P4M2M with Semantic Web 7.

The Figure 3.3 shows the Smart-M3 system which is used for sharingthe information in M2M network, for example the sensor values. All thenetwork nodes in P2P4M2M have a Smart-M3 Knowledge Process (KP) [24]which is responsible for interacting with the Smart-M3 platform. The LN arerepresented in the Smart-M3 system by PN, and the KP in PN is responsiblefor interoperating between Smart-M3s Smart Space Access protocol (SSAP)and ZigBee protocol. Smart-M3 Semantic Information Broker (SIB) is thegeographical smart space containing information about all the nodes and

7http://www.w3.org/standards/semanticweb


LN- ZigBee

WN-WWAN-P2P

PN-WWAN-P2P-ZigBee

LN- ZigBee

WN-WWAN-P2P

SmartM3 Client

WPAN

KP

KP

KP

KPKP

Smart-M3SIB

= Sensor = Actuator = Knowledge Process

Figure 3.3: Smart-M3 System

resources available [24]. The KPs in all M2M devices (WNs and LNs viaPN) populate the Smart-M3 SIB with the information about all the nodesand their resources. Then any device with KP can act as Smart-M3 client andinteract via Smart-M3 SIB, to display the list of resources and retrieve anyresources value. For example, all ZigBee motes have temperature sensors andGPS modules, and a Smart-M3 client can interact with both the resourcesand get the temperature at any particular location. It is worthwhile to notethat CoAP protocol is not used here.

Chapter 4

Decentralized M2M Management

We use SNMP for decentralized M2M network management. As such, SNMPstarted essentially as a centralized paradigm [37], in-part due to the designprinciple that the impact of adding management functionality to manageddevices should be minimized [41]. As networks evolved, the scale and com-putational power of managed nodes increased massively. This created interestin decentralizing network management by moving towards Management byDelegation paradigm [22]; Remote Network MONitoring (RMON) MIB [52]is a good example of the initial work towards this. Since then a wide range oftechniques have been developed for decentralized management, including ar-tificial intelligence [28]. In this thesis we use a novel mechanism of adaptingDHT and using P2P principles for distributed network management func-tionality.

4.1 Challenges in Decentralization

The key challenges in decentralizing P2P4M2M network (Figure 3.1) are asfollows:

Node discovery and resource discovery mechanisms Identifying SNMP MIB for P2P4M2M network for node configurations Making the network self-reliant i.e. MCN should not be required to be

present in the network all the time

Navigating graphs formed by the M2M devices for request and responsemessages

Proxy functionality for SNMP

25

CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 26

Identification method for LNs that are behind PN

4.2 MCN Functionality

The MCN address the above challenges and performs the following functions:

MCN is used for node discovery. SNMP does not provide any mecha-nism for node discovery, so every NMS has its own node discovery mech-anism. In P2P4M2M network, node discovery information is stored inDHT by M2MCE layer. MCN uses M2MCE API to fetch the list of allthe nodes that are part of the network. For performance improvement,the M2MCE layer also provides API to access delta updates to thenetwork information i.e. the list of nodes joining DHT since last re-quest. To handle multiple MCNs, the M2MCE layer has to keep trackof multiple delta information, hence there has to be an upper limit onthe number of simultaneous MCN nodes present in the DHT overlay.Since M2MCE layer knows the type of node (LN, PN or MCN), it canallocate the context when MCN joins and release it when MCN leavesthe network.

MCN is used for resource discovery and provisioning. The resources canbe dynamically added or removed on nodes. The database of resourcesin stored in MIB and it is also used by CoAP to advertise the resourcesto other nodes using the /.well-known URL [21]. The resource list inMIB is considered as master, which keeps it synchronized across CoAPand SNMP protocols.

In alignment with the P2P principle that there should not be any cen-tral entity required for setting up the network or communication be-tween peer nodes, MCN is not required to be part of the network all thetime. P2P4M2M network is made self-reliant delegating the node join-ing procedure to RELOAD protocol in the managed (WN/PN) nodes,and by not storing any information on MCN that is required for networkfunctioning. The latter is achieved by (as mentioned above) storing thenode discovery information in DHT and the resource discovery infor-mation in the managed nodes. MCN retrieves this information whenrequired, but does not store it. However, for efficiency, MCN does cachethis information.

MCN manages the WPAN using the proxy features of PN for opera-tions like detaching the LNs from the WPAN. SNMP Proxy Forwarder


application [34] is used for this. We devised dot notation for namingLNs to take into account the hierarchical nature of network. This alsoallows any arbitrary level of nesting in the network.

MCN is used to manage the WWAN for operations like detaching nodesfrom P2P overlay, assigning the type of node as WN or PN, setting thenode name, setting the association between sensor and association. Ansalient point here is that only the device configuration - like sensor-actuator association - is controlled by MCN, the flow of data betweenthem is using CoAP and autonomously done by the nodes.

MCN is used for setting system parameters on nodes like enabling ordisabling the Smart-M3 feature, controlling the logging level etc. MCNuses SNMP to manage the nodes, so it can use the standard MIBsto configure system parameters. Since the nodes use IP, IP-MIB andIF-MIB MIBs are particularly useful.

The graph navigation for request-response is handled by the RELOADprotocol, which in turn uses the ring topology provided by the Chordalgorithm. Although, CoAP and SNMP can use the overlay messagingfacilities provided by RELOAD protocol, in the prototype they useM2MCE layers DDNS APIs to translate node name to address, andthen directly communicate with the node.

MCN has a command-line interface which abstracts user from SNMP,allowing the users to be concerned with the functionality rather thanSNMP protocol. However, support for generic SNMP PDUs is alsoprovided for flexibility.

As future work, MCN can have a GUI interface for laptops and smart-phones, which allows access to full functionality of MCN like nodediscovery, visual indications for alarms, resource discovery, and a libraryof graphs and charts for displaying data from nodes. The idea is tohave a generic interface for M2M network which should be portablefor other M2M and IoT networks. A good example of work in thisdirection is Pachube 1, which allows storing of data feeds, controllingthem and displaying data. The challenge here is to have a genericinterface, massive scalability, and support for real time operation.

1https://pachube.com


4.3 Security

PN is responsible for the security of WPAN. It uses the ZigBee providedmechanisms for the security of the application data and the network. Itutilizes ZigBee Coordinator node (which is part of PN itself) as the Trust-Center for managing and distributing keys. LNs use the shared keys forcryptographic algorithms. M2MCE layer is responsible for the security ofP2P overlay and stored data.

MCN is responsible for SNMP security and securing access. Reliable secu-rity was introduced to SNMP with version 3, however, currently MCN usesSNMPv2c and implementation of SNMPv3 remains to be done. SNMPv3User-based Security Model (USM) will be used for authenticating users.

4.4 P2P4M2M Protocol Stack

Application

SNMP Manager

UDP

IP

3G/2G

M2MCEDHT

RelayRelay

ZigBee API lib

COAP SNMP

ZigBee API lib UDP

ZigBee API lib

IP

802.15.4 3G/2G

Application

CoAP SNMP

UDP

IP

3G/2G

M2MCEDHT

M2MCEDHT

SNMPProxyCoAPProxy

ProxyLogic

Application

ZigBee NWK

802.15.4

ZigBeeAPS

ZigBeeAPP ZDO

CoAPSNMP

MCNWNPNLN

Figure 4.1: P2P4M2M Network Protocol Stack Diagram


The Figure 4.1 shows how SNMP, CoAP, DHT-based Chord and M2MCEare stacked with each other. It can be seen that CoAP does not require MCNto be present in the network.

4.5 MCN Interfaces

Figure 4.2 displays the MCN command line interface, along with the Smart-M3 and WN interfaces. The list of commands available can be seen from thefigure.

Figure 4.2: Command Line Interface

MCN interfaces with M2MCE layer for the following functionality:

translate node names into corresponding IP address (DDNS function-ality)

get list of nodes that are part of M2M network get additional information about nodes like their joining time get the list of nodes that have joined or left network since the last query


MCN interfaces with PN for the following functionality:

send and receive messages in WPAN protocol conversion between SNMP, CoAP, and Smart-M3 messages

into ZigBee messages and vice-versa

WPAN management

4.6 Scenarios

A few scenarios are explained here which describe the functioning of theprototype testbed. We show the message sequence charts, followed by itsexplanation.

4.6.1 Name Resolution

As mentioned in Section 3.4.1, M2MCE layer provides a distributed nameresolution service to other entities like MCN and WN. The M2MCE APIfor this is a synchronous function call which takes node name as input andreturns its corresponding IP address.These below points are in reference to the message sequence chart in Fig-ure 4.4.

1. First a node, like MCN and WN, invokes M2MCE join() API to registerthemselves and become part of the P2P4M2M network. M2MCE layer,in turn, uses P2P operations to distribute the information over thenetwork. These P2P operations and distributed storage is hidden fromhigher layers by M2MCE.

2. Later when required, any node (MCN here) invokes the M2MCE getIP()API to get the IP address for a given node name. M2MCE layer againuses P2P operations to retrieve the information from distributed stor-age.

3. Note that when getIP() is invoked to resolve IP address for a LN,the IP address returned is in-fact that of the PN representing the LN.However, the routing of message to LN is transparent to the sendingnode as the proxy feature on PN is responsible for routing the messageto the correct target LN. This proxy feature uses the uri-host part ofthe CoAP [21] and Proxy Forwarder [34] feature of the SNMP.


MCN WN M2MCE WN nodes

P2P Messages

P2P Messages

P2P Messages

join(name,type)

join(name, type)

getIP(nodeName)

success

IP Address

success ...

Figure 4.3: Message Sequence for Name Resolution

Similar interaction happens for node discovery and other functionality whichstore/retrieve data into/from the DHT-based database, with M2MCE layerproviding a higher level abstraction API which hides all the complexitiesof distributed system. This message sequence is basic and part of all thesubsequently described scenarios.

4.6.2 MCN Operation

One of the functionalities of MCN is setting the association between sensorsand actuators of any two arbitrary nodes. The node containing a sensoruses this association to inform the node containing the actuator when apredetermined event occurs. For example, a sensor monitoring fire can informactuator controlling sprinklers when it detects a fire outbreak.

1. Typically the first thing to do before sending message to any node is toresolve the node name into its IP address (as explained in Section 4.6.1).


MCN M2MCE WN LNPN

getIP() using P2P

SNMP Get (resources)

ZigBee msg

ZigBee Ack

SNMP Response (resources list)

SNMP Set (association)

SNMP Response (success)

SNMP Set (association)

SNMP Response (success)

node storesassociation

node storesassociation

Resource Discover for LN

Figure 4.4: MCN sets association between sensor and actuator

2. Next, MCN uses SNMP protocol to discover the resources (sensors andactuators) on a WN node. Then using this list of resources, MCNcan associate a sensor with an actuator on another node (the resourcediscovery for node containing an actuator is not shown in the chart).

3. The procedure is similar for LNs, except in step(1) above the IP addressreturned by M2MCE layer is that of PN, and the SNMP message isdynamically converted into ZigBee protocol by PN.

4.6.3 LN to WN

The Figure 4.5 shows information sent from LN (in WPAN) to WN (inWWAN), via PN.

1. When an event is detected at LN, it checks if any sensor-actuator as-sociation is configured with the particular sensor detecting the event.If an association is found, LN sends the event information in a ZigBee


MCN WN M2MCE LNPN

getIP() using P2P

CoAP PUT msg

CoAP ACK msg

ZigBee msg

ZigBee Ack

Event Detected by Sensor

MCN not required

Actuation Event

CoAP protocol ZigBee protocol

Figure 4.5: Information from LN towards WN

message to the target node using the ZigBee coordinator node (whichis part of PN).

2. On receiving the ZigBee message, PN converts the ZigBee message intoCoAP message and uses CoAP library to send it to the target node.CoAP library uses the M2MCE API to resolve the target node nameinto IP address, and then uses UDP protocol to send the message.

3. The target node receives the CoAP message and triggers the actuatorusing the information in the CoAP message. It then acknowledges themessage by sending CoAP message to the PN.

4. On receiving the CoAP Acknowledgement, PN converts it to ZigBeeAcknowledgement and sends it to the LN, completing the transaction.

5. It is worthwhile to note that MCN is not required in any step of thisscenario, thus making the network self-reliant.


4.6.4 WN to LN

MCN WN M2MCE LNPN

getIP() using P2P

CoAP PUT msg

CoAP Deferred Ack

ZigBee msg

ZigBee Ack

Event Detected

by Sensor

MCN not required

CoAP Empty Ack

CoAP Ack (for Ack)

ActuationEvent

CoAP protocol ZigBee protocol

Figure 4.6: Information from WN towards LN

The Figure 4.6 shows information sent in the opposite direction of Fig-ure 4.5 i.e. from WN (in WWAN) to LN (in WPAN), via PN.

1. When an event is detected at WN, it checks its MIB if any sensor-actuator association is configured with the particular sensor detectingthe event. If an association is found, WN uses CoAP library to sendthe event information in a CoAP message to the target node.

2. Since the LN is represented by the PN, the CoAP message is receivedby the CoAP server on the PN. The CoAP server checks HOST URIfield of the CoAP message to identify the target LN for which themessage is intended. The PN then converts the CoAP message intoZigBee message and uses zigbee-api library to send the message to LN.

3. The target LN finally receives the ZigBee message and triggers the


actuator using the information in the message. It then acknowledgesthe message by sending ZigBee Ack message to the PN.

4. On receiving the ZigBee Acknowledgement, PN converts it to CoAPAcknowledgement and sends it to the source WN, completing the trans-action. The PN uses CoAP Token to match the Requests and Acknowl-edgements.

5. Like the previous scenario of LN to WN communication, it is worth-while to note that MCN is not required in any step of this scenario,thus making the network self-reliant.

Chapter 5

Prototype Implementation

This chapter describes the hardware and software used for the prototypetestbed and the system startup details. We also give the rationale for choos-ing these specific hardware and software. In general, we have preferred touse open source software wherever possible.

5.1 Hardware Specification

The prototype testbed uses the hardware described below. In order to dupli-cate our prototype testbed, we recommend using hardware with same speci-fications. In order to allow flexibility, we have used Java, Linux, ZigBee andArdurino platforms which work on a wide variety of hardware, and henceminimal modifications should be required to run our software on differenthardware.

5.1.1 LN Hardware

We have used ZigBee devices as LNs. Figure 5.1 shows the LN hardware.They are constituted of two part - a microcontroller board and a ZigBeeRadio Frequency (RF) module.

There are several vendors providing microcontroller boards that sup-port ZigBee RF modules. Among them, we mainly considered 3 boards:WaspmoteTM (from company called Libelium 1), MulleTM (from companycalled Eistec 2) and IRISTM Mote (from company called Crossbow 3), and

1http://www.libelium.com2http://www.eistec.se3http://www.xbow.com

36

CHAPTER 5. PROTOTYPE IMPLEMENTATION 37

Figure 5.1: Local Node

finally we selected Waspmote 4 board because of the following reasons:-

It comes with good development kit It uses Open Source APIs It has excellent documentation It comes with 3 ranges 2.4GHz - 7km, 900MHz - 24km, and 868MHz -

40km

It consumes very little power : 0.7uA in Hibernate mode, 62uA in DeepSleep mode and 9mA when ON.

It has the possibility to add more than 50 sensors, giving a lot offlexibility

WaspmoteTM board has Atmels 5 ATmega1281 microcontroller operatingat 8MHz frequency with 8KB SRAM, 4KB EEPROM, and 128KB FLASH.It uses the Arduino6 platform, which comes with a IDE to develop, build and

4http://www.libelium.com/products/waspmote5http://www.atmel.com6http://www.arduino.cc


upload software onto the device. In addition to ZigBee, it supports Bluetoothand GPRS radio technologies.

To provide the ZigBee connectivity, we have used XBeeTM ZB 7 ZigBeeTM

RF Modules from Digi International Inc 8 which are interoperable with othervendors ZigBee RF modules. Additionally, these RF modules are compatiblewith Waspmote microcontroller boards.

5.1.2 PN Hardware

Figure 5.2: Proxy Node

Figure 5.2 shows the PN hardware. PN uses the same hardware as WN,with the addition of a Waspmote Gateway device which is attached to the

7http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-zb-module

8http://www.digi.com


Gumstix using USB. This gateway device, together with the zigbee-api li-brary 9, provides the interface to the WPAN. This interface is used by theCoAP and SNMP software modules to provide the Proxy functionality.

5.1.3 WN Hardware

The WN hardware is identical to PN shown in Figure 5.2 with the excep-tion that it does not have Waspmote Gateway device. We use single-board-computer (SBC) called Overo EarthTM 10 from the company Gumstix Inc 11.Overo Earth are Linux based SBC which are available in a wide range of con-figurations (choices in DSP, Graphics acceleration, operating temperatureranges etc), and it is compatible with numerous expansion boards which canadd capabilities like GPS, touch screen LCD, HDMI etc to the SBC. It usesOMAPTM 3503 Applications Processor from Texas Instruments 12 (which isbased on ARM CortexTM A8 CPU design). In addition, there is a devel-opment community around different products from Gumstix Inc providing alot of open source software and technical discussion forums. We have usedMicroSD card (on Overo Earth) to store the Linux image, which is very easyto clone, simplifying the procedure of adding extra nodes in the testbeds. Allthese factors make Overo Earth suitable for rapid prototyping.

The wireless connectivity is provided by using 3G UMTS dongle which isconnected to the SBC using USB.

5.1.4 MCN Hardware

Dell Latitude D630 laptop is used as MCN. In addition, this laptop is alsoused as a Smart-M3 client. Another laptop (Dell Latitude D630) is used torun 3 entities - the bootstrap node for the P2P network, a set of simulatedWNs, and the Smart-M3 SIB.

Figure 5.3 shows the complete lab setup for P2P4M2M.

5.2 Software Specification

We have used the following software, mostly open source, for the prototypeimplementation:

9http://code.google.com/p/xbee-api10http://www.gumstix.com/store/product_info.php?products_id=21111http://www.gumstix.com12http://www.ti.com


Figure 5.3: Lab Setup

SNMP4J : SNMP4J 13 is an open source enterprise grade implementa-tion of state-of-the-art SNMP using Java 2SE 1.6. It is used on WN andPN for implementing both SNMP-Agent and SNMP-Manager function-ality, and on the MCN for SNMP-Manager functionality. The versionsused are 1.11.3 and 1.4.3 for the SNMP-Manager and SNMP-Agent,respectively.

JCoAP : JCoAP 14 is an open source Java based implementation ofthe CoAP protocol. We have used version 0.1, which is based on theIETF drafts draft-ietf-core-coap-05, draft-ietf-core-block-03, draft-ietf-core-link-format-04, and draft-ietf-core-observe-02. We had also con-

13http://www.snmp4j.org14https://github.com/dapaulid/JCoAP


sidered another CoAP implementation jCoAP15 (notice the small j),however, on evaluation we found that JCoAP was more feature- com-plete than jCoAP, hence we used JCoAP. One important feature thatJCoAP lacked was the proxy functionality (as defined in Section-5.3 ofCoAP specification [21]), so it was added as part of this thesis.

zigbee-api library : Libelium does not provide any library to interfacewith the ZigBee gateway device, hence we had to use a third partylibrary. Zigbee-api library is an open source Java implementation forinterfacing with Radio Frequency devices complying with XBee/XBee-Pro series 1 (802.15.4) and series 2 (ZNet 2.5 and ZB/ZigBee Pro). Itrequires RXTX 16 java library to communicate with ZigBee coordinatornode using USB port.

P2P network based on DHT : We have used Ericsson Researchsimplementation of P2P network which is based on DHT. It uses Peer-to-Peer Protocol (P2PP) and Chord algorithm. RELOAD protocol [25]is the IETF successor of P2PP and since M2MCE completely abstractsP2PP from MCN, for the purpose of this thesis, we mention RELOADprotocol even though the prototype uses P2PP.

Arduino : Libelium Waspmote development uses Arduino develop-ment environment. We used Waspmote IDE version 2, which in turnis based on Arduino IDE. The Waspmote IDE provides code examplesfor handling various sensors in Waspmote which are very helpful indevelopment.

Linux : Linux embedded operating system is used on Gumstix (usedas WNs in the prototype). The flavour used is linux-gnueabi, whichis ARM EABI Debian based port of Linux for the ARM architecture(named armel). opkg 17 based package management is used.

CACAO JVM : CACAO 18 Java Virtual Machine (JVM) is developedby Vienna University of Technology with support for ARM processors.We chose CACAO over JamVM 19 because it supported the pre-existingDHT based P2P implementation out-of-the-box.

15http://code.google.com/p/jcoap16http://users.frii.com/jarvi/rxtx17http://code.google.com/p/opkg18http://www.cacaovm.org19http://jamvm.sourceforge.net


Smart-M3 Platform : We have used Smart-M3 platform, which iscreated as part of DIEM project, to provide information level interop-erability using Smart-M3 Knowledge Processes [24]. The version usedis 0.9.5 [17].

Smart-M3 Java library : Smart-M3 platform provides interface inC. Language bindings have been created for Java and Python to enablesoftware development in these languages. We have used the Java bind-ing created by University of Bologna and Finnish Technical ResearchCentre VTT [50], version 5.5. The java binding internally uses JSONlibrary.

It is worth noting that all the software is developed using Java, other thanthe C on Waspmotes (since Waspmotes do not support Java). The basic ideabehind using Java is to allow easy porting to new (different) hardware, andgiven that M2M field is rapidly advancing, we expect to continually upgradethe testbed hardware.

5.3 Software Structure

The high level software architecture of PN is shown in Figure 5.4. The designof WN and MCN is subset of PN, so it is not explicitly discussed here.The software is split into 3 Java ARchive (JAR) packages for modularity- m2mManager.jar, proxy,jar and m2mce.jar - and they use Java RemoteMethod Invocation (RMI) 20 for communicating with each other. These 3JAR files are present in all nodes which allows the flexibility to change aPN into WN (and vice-versa) and to use any node as MCN. There are 6significant modules contained in these 3 JAR packages:

1. M2MCE

2. Proxy

3. SNMP

4. Smart-M3 Client

5. CoAP client-server library

6. MCN command-line application

Out of the above 6 modules, the last 4 were implemented as part of thisthesis.

20http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf


M2mManager M2MCE Proxy

Java Virtual Machine

Linux Operating System

RMIAPI

CoAPLib

RMIAPI

SmartM3

Figure 5.4: Software Architecture of PN

5.3.1 M2M System Startup

First the P2P bootstrap-peer device is started, followed by the rest of thedevices in the network. Each node begins by launching M2mManager mod-ule, and then onwards the M2mManager module is responsible for furtherlaunching the other modules and configure the local node. The M2mManagermodule uses SNMP MIB information for this purpose.

M2mManager checks if there are any MIB values specified in the (op-tional) configuration file and loads these values, if any, into the MIB. Next,M2mManager checks the node-type (PN/WN/MCN), the node name, andthe feature flag for Smart-M3, and accordingly does the following:

If a node name is given in configuration file, M2mManager uses thisname and the node-type to invoke the join() API of M2MCE module.M2MCE then contacts the bootstrap-peer and joins the P2P overlay. Ifno node name is specified in the configuration file, M2MCE module au-tomatically assigns a name. This mechanism is used since in a network


with large number of nodes, it would not be possible to individuallyassign names to all nodes; on the other hand, this offers capability toassign/modify node names via MCN.

If node-type is PN, M2mManager launches the Proxy module; if thenode-type is MCN, it instead launches the command-line module; oth-erwise, it does not launch any extra module.

If the feature flag for Smart-M3 is enabled, M2mManager launches theSmart-M3 module. Then Smart-M3 module retrieves all the resourcespresent in the node and publishes them in Smart-M3 SIB. If the nodeis a PN, Smart-M3 is responsible for discovering resources on the LNsand publishing them in Smart-M3 SIB. Additionally, Smart-M3 modulesubscribes, with the Smart-M3 SIB, for any requests for the registeredresources.

Lastly, M2mManager launches the CoAP module which, in turn, startslistening for any CoAP requests.

At the end of above steps, the system is up and functional. Now, theMCN commandline interface can be used for operations like node discovery,resource discovery, setting sensor-actuator associations, controlling log leveletc. Similarly, Smart-M3 client can be used to retrieve information from theM2M devices. The list of available commands for MCN and Smart-M3 isshown in Figure 4.2.

Chapter 6

Evaluation and Discussion

There are several interesting research work which focus on evaluating SNMPand developing extensions to SNMP for resource constrained M2M devices,for example, [30], [42] and [16]. However, this thesis considers decentraliza-tion aspects of the M2M network management.

Over a period of time, several techniques have been used to decentralizenetwork management. For example, [44] uses navigation patterns and [7,40, 53] adapt databases to propagate request-responses. One of the mostcommon technique centers around using hierarchical architecture of networkmanagers, like [29, 49]. However, we use a novel mechanism of adapting DHTto handle network management.

The main contribution and findings of this thesis is as follows:

We have identified the following SNMP MIB for M2M domain. This isuseful for IETF MIB standardization efforts like the IETF 6LoWPANMIB Draft [27].

Sensor-Actuator associations. This is a fundamental attributethat needs to be stored in the MIB. There have been similar ideasof creating sensor-actuator associations using different protocols,like Web Services for Devices (WS4D) 1 which uses Microsoft tech-nologies to provide the same functionality.

GPS coordinates for M2M devices. This attribute is essential forM2M GUI to spatially display the devices, and invaluable whileconfiguring the sensor-actuator associations.

1http://www.ws4d.org

45

CHAPTER 6. EVALUATION AND DISCUSSION 46

We have found that the capability and efficiency of SNMP in this net-work architecture depends largely on the DHT. For example, the vol-ume of data that can be stored in a given DHT algorithm determineswhether we can store only the node discovery information or also theresource discovery information. Similarly, the node discovery capabili-ties of the network will be limited by the response time with which theChord algorithm reorganizes its ring-structure when a node leaves orjoins the network.

We have developed a decentralized M2M prototype which acts as aplatform for further research. At the time of writing this thesis, aresearch work is in-progress for developing a generic M2M GUI usingthis prototype.

The prototype demonstrated and solved challenges for the following:

Integrating IETF aligned protocols to develop a M2M network- CoAP, SNMP, RELOAD, IP, IEEE 802.15.4. In addition, itwas shown that this network could interwork with other hetero-geneous networks, like ZigBee, using proxies. Resource discoveryprocedures for CoAP and SNMP were united by designating theSNMP MIB as master information, and CoAP protocol stack re-ferring it.

Using SNMP for decentralized management. This is especiallyinteresting because SNMP is considered essentially as a central-ized system. Decentralization was largely enabled by the modulardesign of SNMP, which itself was originally done to help tran-sition from SNMP to OSI based ISO Common Management In-formation Services/ Common Management Information Protocol(CMIS/CMIP) [15] (though, eventually, CMIS/CMIP did not be-come popular for Internet devices).

Integrating the decentralized M2M network with Semantic Webusing Smart-M3.

Creating a self-reliant M2M network, where management nodeis not required to be present in the network continuously. Thiswas achieved by not storing any information required for networkfunctionality in the management node (i.e. MCN).

A strong need was seen for standardizing the resource names for sen-sors and actuators to ensure interoperability. Since WSN has its rootsin academia, very little attention was given to standardization aspects.

CHAPTER 6. EVALUATION AND DISCUSSION 47

On the other hand, M2M domain evolved with a large number of pro-prietary standards with little interoperability (like oBIX 2, ZigBee 3).For instance, CoAP allows resource discovery but without any standardname for resources, like temperature, machines cannot autonomouslydo resource discovery. Currently, the IETF drafts on CoAP and 6LoW-PAN mention that the names could be standardized, but there is noproposal to do so.

During the Smart-M3 integration it was found that the abstractionlayer provided by Ontology and Resource Description Framework (RDF)in Smart-M3 is too generic and complex. Better abstraction modelsneed to be developed for wider adoption of Smart-M3 by programmers.Also, security is missing.

IPv6 and HTTP have been adapted to resource constrained devicesand networks as 6LowPAN and CoAP, respectively. Similarly DHTalso needs to be adapted for M2M network. Currently, the DHT im-plementations are not suitable even for cellular smart-phones, whichhave significant computing power, as found in the performance mea-surements in [36]. As such, according to Moores Law, the embeddeddevices should already have advanced capabilities to host DHT im-plementations. However the current generation of low power wirelessembedded devices are still resource constrained. We believe that thisis mainly due to two reasons. Firstly, there was no killer application orwidespread use-case requiring more powerful devices. Secondly, the de-vices need to maximize battery which gets progressively difficult withincreasing hardware complexity. However, now with IoT and M2Mtechnologies gaining momentum, we believe that the device capabil-ities will improve. Also, at the same time P2P technologies will beadapted and advanced, demanding less computational and bandwidthresources, thereby facilitating incorporation of P2P on M2M networks.

2http://www.obix.org3http://www.zigbee.org

Chapter 7

Conclusions and Future Work

The objective of the overall P2P4M2M research project in which this thesiswas done was to study the challenges in decentralization of M2M networksand implement a prototype testbed. The scope of this thesis was to in-vestigate the management of decentralized M2M network using SNMP. Tothe best of our knowledge, this is the first research work into applying P2Pprinciples to M2M networks and SNMP. The central topics studied were de-centralized management, node discovery, resource discovery, node configura-tion, and proxy functionality. The project started with the study of possibleuse-cases for next generation M2M networks, followed by an evaluation ofseveral embedded hardware and software which could be used in our proto-type testbed. Finally, the design and implementation for the prototype wascarried out by integrating IETF and IEEE aligned protocols - CoAP, SNMP,IP, RELOAD and IEEE 802.15.4. We also integrated the M2M network withSemantic Web using Smart-M3. The resulting prototype is being used as aplatform for further research into decentralizing M2M.

In this thesis we identified SNMP MIB for M2M networks, and establishedthat SNMP can be easily used for decentralized management by adaptingP2P mechanisms. It was seen that the capability and efficiency of SNMPfor decentralized management largely depends on the underlying decentral-ization mechanism, for example, the volume of data that can be stored inDHT, and how fast the Chord algorithm reorganizes when nodes leave or join.Hence, a need was seen for research into customizing RELOAD and Chordfor M2M, much in the manner IPv6 and HTTP have been customized forM2M in the form of 6LoWPAN and CoAP, respectively. Another finding wasthat the standardization of resource names was not being covered in scopeof CoAP, 6LoWPAN or any other drafts. This might lead to the undesirablesituation where product vendors develop proprietary resource names. Webelieve that the CoAP specification is the most suitable place to standardize

48

CHAPTER 7. CONCLUSIONS AND FUTURE WORK 49

the resource names.Lastly, we devised two techniques in order to achieve a self-reliant M2M

network, which remove the requirement for any management node to becontinuously connected in order for the network to function. Firstly, weensured that no required data was stored in the management node. Thiswas primarily achieved by storing the node discovery information in DHT,and storing the resource discovery information in SNMP MIB. Secondly, thenode joining was handled by RELOAD protocol of managed nodes themselvesinstead of the management node.

7.1 Future work

This work represents an early step towards decentralizing M2M networksand decentralized management using P2P principles. The timeline for ma-turing this technology is envisioned to be two to three years and considerableresearch remains to be done.

Currently, our prototype is being used for GUI development as part ofanother students Masters thesis. This GUI will have generic M2M function-alities like displaying devices location on a geographical map, node discovery,resource discovery, using graphs and charts to display sensor-actuator data,setting parameters on devices etc. Pachube 1 is a good example towardsthis domain. The challenge is to have a generic interface covering maximumenvisioned M2M functionality (so that it is portable to other M2M and IoTsystems), massive scalability, and support for real time operation.

Among other things, work needs to be done for customizing P2P protocolsfor M2M and implementing distributed Smart-M3 SIB using DHT. Then,significant further research is required in the direction of implementing andcomparing different P2P decentralization mechanisms and the centralizedapproaches. Additionall

Date post:	07-Nov-2015
Category:	Documents
Upload:	itemboleh
View:	234 times
Download:	0 times

Nalin Gupta Thesis

Documents