Nalin Gupta Thesis

Aalto University
School of Science
Degree Programme of Computer Science and Engineering
Nalin Gupta
Management of Decentralized DHT Based

M2M Network
Masters Thesis
Espoo, May 6, 2012
Supervisor:
Instructor:
Professor Antti Yla-Jaaski

Aalto University School of Science, Finland
Jouni M
aenp
aa M.Sc. (Tech.)
Ericsson Research, Finland
Aalto University
School of Science
Degree Programme of Computer Science and Engineering
ABSTRACT OF
MASTERS 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-Jaaski
Aalto University School of Science, Finland
Instructor:
Jouni Maenpaa M.Sc. (Tech.)
Ericsson Research, Finland
Machine-to-Machine (M2M) technology is evolving beyond the traditional telemetry use-cases and becoming key enabler for innovative concepts like Internet-ofThings (IoT), leading to a whole new set of possible applications. Currently there
are 13 billion connected devices and it is envisioned that by the year 2020, this
number will reach 50 billion. We believe that the key to achieve this massive scalability is using peep-to-peer based decentralized architecture and interoperability
using open standards. Architecturally, the Internet is composed of a collection
of heterogeneous sub-networks; similarly, we believe that the next generation of
M2M networks would also consist of heterogeneous networks joined together using
gateways or proxies, giving a hierarchical architecture.
Hence, we are conducting research into decentralized hierarchical Machine-toMachine (M2M) networks using Internet Engineering Task Force (IETF) and
Institute of Electrical and Electronics Engineers (IEEE) aligned protocols. The
decentralization is achieved using Distributed Hash Table (DHT) based Peer-toPeer (P2P) algorithms. The project involves studying the latest state-of-the-art
technologies like IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), ZigBee, Constrained Application Protocol (CoAP), Distributed Hash Table (DHT), Smart-M3, and creating a prototype testbed platform of embedded
Linux and ZigBee devices to carry the experiments and analysis. The focus of
this thesis is on how to manage this decentralized hierarchical M2M network using Simple Network Management Protocol (SNMP). The central topics studied
are decentralized management, node discovery, resource discovery, node configuration, and proxy functionality.
Keywords:
M2M, Decentralized, Network Management, SNMP, Proxy,
DHT, IoT, Smart-M3, CoAP
Language:
English
ii
Aalto-yliopisto
Perustieteiden korkeakoulu
Tietotekniikan tutkinto-ohjelma
DIPLOMITYON
TIIVISTELMA
Tekij
a:
Nalin Gupta
Ty
on nimi:
DHT-pohjaisen hajautetun M2M-verkon hallinta
P
aiv
ays:
6.5.2012
Sivum
a
ar
a: 9+ 54
Professuuri:
Tietoliikenneohjelmistot
Koodi:
T-110
Valvoja:
Professori Antti Yla-Jaaski
Aalto-yliopisto, Perustieteiden korkeakoulu
Ohjaaja:
Jouni Maenpaa M.Sc. (Tech.)
Oy L M Ericsson Ab
Machine-to-Machine (M2M) -teknologioiden kaytto on laajenemassa perinteisista
telemetriasovelluksista uusille sovellusalueille. M2M-teknologiat mahdollistavat
joukon uusia innovatiivisia ratkaisuja kuten niin sanotun esineiden Internet ekosysteemin. Nama ratkaisut puolestaan avaavat mahdollisuuksia uusien sovellusten luomiseen. Talla hetkella markkinoilla on 13 miljardia Internet-verkkoon
kytkettya laitetta. Joidenkin arvioiden mukaan vuoteen 2020 mennessa naiden
laitteiden maara kasvaa jopa 50 miljardiin. Taman diplomityon lahtokohtana
on, etta keskeisia tekijoita nain skaalautuvan jarjestelman luomisessa ovat avoimet standardit ja vertaisverkkoteknologioihin perustuvat hajautetut arkkitehtuurit. Internetin arkkitehtuuri koostuu joukosta aliverkkoja. Myos tassa diplomityossa lahtokohtana on hierarkkinen arkkitehtuuri, jossa yhdyskaytava- ja
valityspalvelimet liittavat yhteen joukon heterogeenisia M2M-verkkoja. Tahan
ajatukseen pohjautuen diplomityon tavoitteena on tutkia hajautettuja M2Mverkkoja, jotka perustuvat Internet Engineering Task Force (IETF) ja Institute of Electrical and Electronic Engineers (IEEE) -standardointiorganisaatioiden
yhteyskaytantoihin. Tassa diplomityossa hajautetun arkkitehtuurin toteuttamiseen kaytetaan Distributed Hash Table (DHT) -ja vertaisverkkoalgoritmeja.
Tyossa tutkitaan myos viimeisimpia teknologioita kuten IPv6 over Low power
Wireless Personal Area Networks (6LoWPAN), ZigBee, Constrained Application Protocol (CoAP), DHT ja Smart-M3. Tyohon kuuluu myos prototyyppialustan kehittaminen. Tama alusta koostuu sulautetuista Linux- ja ZigBeelaitteista. Alustaa kaytetaan kokeiden suorittamiseen ja jarjestelman analysointiin. Diplomityon keskeisena tavoitteena on tutkia kuinka hallita hierarkkista
ja hajautettua M2M-verkkoa kayttaen Simple Network Management Protocol
(SNMP) -protokollaa. Tyon keskeisimpia tutkimusaiheita ovat hajautettu verkonhallinta, laitteiden loytaminen, resurssien loytaminen, laitteiden konfigurointi
ja valityspalvelintoiminnallisuus.
Asiasanat:
Kieli:
M2M, hajautettu, verkonhallinta, SNMP, valityspalvelin,

DHT, esineiden Internet, Smart-M3, CoAP
Englanti
iii
Acknowledgements
I would like to express my sincere gratitude to Professor Antti Yla-Jaaski for
supervising my thesis and supporting my studies without which this moment
would not have been possible.
I am deeply grateful to my instructors Jouni Maenpaa and Jani Hautakorpi
for providing me with the opportunity to work in the prestigious Ericsson
Research NomadicLab, and for their guidance, encouragement and kindness
throughout the research work.
I would also like to thank my fellow students Jaime Jimenez and Daoyuan
Li for their friendship and support during the thesis.
Espoo, May 6, 2012

Nalin Gupta
iv
Abbreviations and Acronyms

3G
6LoWPAN
ACK
API
APS
ASN.1
BSD
CoAP
CoRE
DHT
DDNS
DNS
EABI
GPRS
GPS
ICT
IDE
IETF
IoT
IPC
JAR
JSON
LR-WPAN
LoWPAN
LN
M2M
M2MCE
MCN
3rd Generation Mobile Telecommunications

IPv6 over Low-power Wireless Personal Area
Networks
Acknowledgment
Application Programming Interface
Application Support Sub-layer
Abstract Syntax Notation One
Berkeley Software Distribution
Constrained Application Protocol
Constrained RESTful Environments working group
Distributed Hash Table
Distributed Domain Name Service
Domain Name Service
Embedded Application Binary Interface
General Packet Radio Service
Global Positioning System
Information and Communication Technologies
Integrated Development Environment
Internet Engineering Task Force
Internet of Things
Inter-Process Communication
Java ARchive
JavaScript Object Notation
Low-Rate Wireless Personal Network
Low-power Wireless Personal Network
Local Node, less powerful devices without DHT e.g.
ZigBee motes
Machine-to-Machine
Machine-to-Machine Communication Enabler
Monitoring and Controlling Node
v
MD5
MIB
OID
OSI
P2P
P2P4M2M
PAN
PDU
PN
QoS
REST
RFID
RMI
RPC
RTT
SIB
SMI
SNMP
UDP
URI
USB
USM
VACM
WAN
WN
WPAN
WSN
WWAN
XML
ZDO
Message-Digest algorithm 5
Managed Information Base
Object IDentifiers
Open Systems Interconnection
Peer-to-Peer
Peer-to-Peer for M2M Network
Personal Area Network
Protocol Data Unit
Proxy Node for interfacing LNs with WN
Quality of Service
Representational State Transfer
Radio-Frequency IDentification
Remote Method Invocation
Remote Procedure Call
Round Trip Time
Semantic Information Broker
Structure of Management Information
Simple Network Management Protocol
User Datagram Protocol
Universal Resource Indicator
Universal Serial Bus
User-based Security Model
View-based Access Control Model
Wide Area Network
Wide Area Node, embedded Linux based devices with
DHT
Wireless Personal Area Network
Wireless Sensor Network
Wireless Wide Area Network
Extensible Markup Language
ZigBee Device Object
vi
Contents
Abstract
ii
Acknowledgements
iv
Abbreviations & Acronyms
List of Figures
1 Introduction
1.1 Overview . . . . . . .
1.2 Research Objective .
1.3 Thesis Scope . . . . .
1.4 Thesis Organization .
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Background
2.1 Wireless Sensor Networks (WSN) . . .
2.2 Machine to Machine (M2M) . . . . . .
2.3 Internet of Things (IoT) . . . . . . . .
2.4 ZigBee . . . . . . . . . . . . . . . . . .
2.5 6LoWPAN . . . . . . . . . . . . . . . .
2.6 Constrained Application Protocol
(CoAP) . . . . . . . . . . . . . . . . .
2.7 Distributed Hash Table (DHT) . . . .
2.8 Peer-to-Peer (P2P) Technologies . . . .
2.9 Simple Network Management Protocol
(SNMP) . . . . . . . . . . . . . . . . .
2.10 Smart-M3 . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
3
4
.
.
.
.
.
5
5
6
7
8
9
. . . . . . . . . . . . . 10
. . . . . . . . . . . . . 10
. . . . . . . . . . . . . 11
. . . . . . . . . . . . . 11
. . . . . . . . . . . . . 13
3 Decentralized M2M Network Design

15
3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
3.3
3.4
3.5
System Architecture . . . . . . . . . . . . . . . .
Functional Description . . . . . . . . . . . . . . .
3.4.1 M2M Communication Enabler Abstraction
3.4.2 Monitoring and Controlling Node . . . . .
3.4.3 Proxy Node . . . . . . . . . . . . . . . . .
Smart-M3 System . . . . . . . . . . . . . . . . . .
4 Decentralized M2M Management

4.1 Challenges in Decentralization .
4.2 MCN Functionality . . . . . . . .
4.3 Security . . . . . . . . . . . . . .
4.4 P2P4M2M Protocol Stack . . . .
4.5 MCN Interfaces . . . . . . . . . .
4.6 Scenarios . . . . . . . . . . . . . .
4.6.1 Name Resolution . . . . .
4.6.2 MCN Operation . . . . . .
4.6.3 LN to WN . . . . . . . . .
4.6.4 WN to LN . . . . . . . . .
5 Prototype Implementation
5.1 Hardware Specification . . .
5.1.1 LN Hardware . . . .
5.1.2 PN Hardware . . . .
5.1.3 WN Hardware . . . .
5.1.4 MCN Hardware . . .
5.2 Software Specification . . .
5.3 Software Structure . . . . .
5.3.1 M2M System Startup
.
.
.
.
.
.
.
.
6 Evaluation and Discussion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
Layer
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
20
22
22
23
.
.
.
.
.
.
.
.
.
.
25
25
26
28
28
29
30
30
31
32
34
.
.
.
.
.
.
.
.
36
36
36
38
39
39
39
42
43
45
7 Conclusions and Future Work

48
7.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Bibliography
50
viii
List of Figures
1.1
Decentralization of M2M Network . . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
Wireless Sensor Network . . .

ZigBee Protocol Stack . . . .
6LoWPAN Network . . . . . .
SNMP Network Management
3.1
3.2
3.3
Decentralized M2M Network Architecture (P2P4M2M) . . . . 18

M2MCE Abstraction Layer . . . . . . . . . . . . . . . . . . . 21
Smart-M3 System . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1
4.2
4.3
4.4
4.5
4.6
P2P4M2M Network Protocol Stack Diagram . . . .

Command Line Interface . . . . . . . . . . . . . . .
Message Sequence for Name Resolution . . . . . . .
MCN sets association between sensor and actuator
Information from LN towards WN . . . . . . . . . .
Information from WN towards LN . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
29
31
32
33
34
5.1
5.2
5.3
5.4
Local Node . . . . .
Proxy Node . . . . .
Lab Setup . . . . . .
Software Architecture
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
40
43
. . . .
. . . .
. . . .
of PN
.
.
.
.
ix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 6
. 8
. 9
. 12
Chapter 1
Introduction
1.1
Overview
Machine-to-Machine (M2M) technology gained roots in early 2000s, powered by the ubiquitous wireless cellular connectivity. Today it is evolving
beyond the telemetry applications and becoming cardinal enabler for innovative concepts like Internet-of-Things (IoT), leading to a whole new set
of possible applications. Currently there are 13 billion connected devices
and it is envisioned that by the year 2020, this number will reach 50 billion [18]. We believe that the key to achieve this level of massive scalability
is using Peer-to-Peer (P2P) based decentralized architecture and interoperability using open standards. Architecturally, the Internet is composed of
heterogeneous sub-networks, similarly, we believe that the next generation
of M2M networks would also consist of collection of heterogeneous subnets
joined together using gateways or proxies, giving a hierarchical structure.
Hence, we are conducting research into scalable decentralized hierarchical
M2M networks using IETF and IEEE aligned open standards and protocols.
The decentralization is achieved using Distributed Hash Table (DHT) based
P2P algorithms. The project involves studying the latest state-of-the-art
technologies like 6LoWPAN, ZigBee, CoAP, Smart-M3, and creating a prototype testbed platform of embedded Linux and ZigBee devices to carry the
experiments and analysis.
1.2
Research Objective
The current M2M and Wireless Sensor Network (WSN) networks use centralized approaches. The WSNs use sensors to collect information about its
environment and relay it to central location, where the data is processed.
1
CHAPTER 1. INTRODUCTION
Centralized
= Sensor
= Actuator
Figure 1.1: Decentralization of M2M Network
M2M networks use embedded devices for remote monitoring and management from central locations. In both the cases, the intelligence and decision
making is done using centralized entities.
However, the centralized approaches have several challenges which do
not lend themselves to the envisioned use-cases for M2M and IoT. Three key
issues 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 single
point of failure for entire network)
Our aim is to solve the above challenges by decentralizing the M2M networks using DHT-based P2P mechanisms and creating a P2P4M2M network. Chapter 3 Section 3.1 describes details on how P2P addresses these
challenges. The objective of our research project is to study the challenges

in the decentralization of M2M networks. The research project is divided
into three Masters thesis - (1) Adapting DHT for M2M network requirements [11] (2) Using proxy to connect ZigBee based Wireless Personal Area
Network (WPAN) to the M2M network [35] (3) Using SNMP in decentralized
manner to manage the M2M network (this thesis).
In tune with the IETF approach of have running code 1 , developing a
prototype testbed is an important part of this research project. This testbed
platform will then be used for further research on the overall topic of decentralizing M2M networks.
During the remaining of this thesis, we shall use the term P2P4M2M
research project to refer to the overall research project in which this thesis
was done.
1.3
Thesis Scope
This thesis studies the management of decentralized M2M network using

open standards. The main topics that are studied are decentralized management, node discovery, resource discovery, node configuration, and proxy
functionality.
The following specific objectives defines the scope of this thesis:
1. Develop network management software for decentralized M2M network
and a Managing and Controlling Node (MCN) that provides human
interface
2. Make the M2M network self-reliant i.e. the M2M network should be
able to operate normally even when MCN is disconnected
3. The software should have gateway or proxy module that allows management of ZigBee based sub-network
4. The software should allow information interoperability using Smart-M3
semantic web platform, enabling web applications to interact with the
decentralized M2M system
The DHT implementation and the ZigBee Proxy module implementation
is out of scope of this thesis. The contribution of this thesis is listed in detail
in the Chapter 6.
1
http://www.ietf.org/tao.html
This thesis is part of work package for Devices and Interoperability Ecosystem (DIEM) 2 program funded by TEKES 3 - the Finnish Funding Agency
for Technology and Innovation. The P2P4M2M research project in which
this thesis was done also involves close collaboration with the Future Internet program, which is part of ICT cluster of the Finnish Strategic Centres
for Science, Technology and Innovation (ICT SHOK) 4 . Inline with the objectives of these research programs, interoperability and future Internet are
key aspects of our P2P4M2M research project. This explains the emphasis
of 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 in

the prototype, which would provide useful background for understanding this
thesis. It is followed by Chapter 3 which describes the design principles used
for the prototype, its system architecture and functionality. Next, Chapter 4
covers the challenges and solutions for decentralized management of the M2M
network.
The hardware and software specifications for the prototype implementation are given in Chapter 5. It also covers the software architecture of the
prototype and the system startup details. Then, in Chapter 6, we discuss and
evaluate the learnings from this project. In Chapter 7, the learnings from
this project are summed up and useful take-away conclusions are presented.
Finally, we mention the research work that will be carried out in future using
the testbed developed under the scope of this project.
http://www.diem.fi
http://http://www.tekes.fi
4
http://www.futureinternet.fi
3
Chapter 2
Background
Our research involves numerous technologies and protocols. In this chapter
we give a brief overview of them.
2.1
Wireless Sensor Networks (WSN)
Wireless Sensor Networks (WSN) have come a long way from their beginning
in University research, and have laid the foundation for latest concepts like
IoT. As shown in Figure 2.1, WSN consists of a collection of sensing and
actuating devices, commonly called as motes, and gateway nodes. The motes
are typically battery powered embedded devices which are resource limited
in terms of computational power. Also their wireless connectivity has short
range. The gateway nodes, however, have higher configuration in terms of
hardware and wireless range, which enables them to communicate with base
station.
WSN operates with nominal or no infrastructure support. Due to lack
of infrastructure support and resource constrained nature of devices, the
traditional networking protocols are not suitable for WSN. Wireless mesh
networking is one of the most common technique to overcome the disadvantages of short range connectivity. Due to the academic parentage, most
of WSN research produced proprietary solutions and lacked interoperability.
IEEE 802.15.4 is the first open standard for low power radio that got global
acceptance. Then based on IEEE 802.15.4, ZigBee became one of the first
standards to gain commercial interest. WSN is mainly used for tracking and
monitoring use-cases [54].
The concepts of WSN, M2M IoT, ZigBee and 6LoWPAN are inter-twinged
and the boundary between them is not sharp. We will point out the distinguishing characteristics of each of these technologies in their respective
5
CHAPTER 2. BACKGROUND
Sensor
Mote
Gateway
Mote
Figure 2.1: Wireless Sensor Network
sections.
2.2
Machine to Machine (M2M)
The success and ubiquity of wireless cellular modems enabled M2M to gain
market breakthrough for telemetry and remote management use-cases like
managing vending machines [46]. The observation that the value of machines
increases tremendously when they are networked with one another [32], has
led to a fast growing interest in M2M domain. However, there is no clearly
agreed upon definition for the term M2M. Two good definitions are as follows:
M2M consists of machines and backend services that are used for remote
monitoring and controlling of devices. The devices typically have long
range wired or wireless capabilities, and most often they use cellular
modems for wireless connectivity.
M2M is a system where machines exchange information and run the
system with little or no human intervention
M2M has created possibilities of new unforeseen business ventures. M2M
is making devices smarter and the world more efficient. Examples include
intelligent supply chain management and smart utility metering. The technologies to enable M2M are already available and the key challenges for M2M
are integrating these technologies and creating global standards. ETSI has
launched the M2M Technical Committee 1 to meet these challenges.
WSNs enable M2M but an important difference between WSN and M2M
is that WSN domain deals with the challenges for networking resource constrained devices with short range low power wireless connectivity. In contrast, M2M devices typically have cellular based wide area connectivity and
as such, the M2M domain is more concerned with standardization and creating service platforms. Also, M2M devices need not always have sensors or
actuators.
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. Since
then, the term IoT has expanded in its scope and now it refers to the network
of embedded devices (also called smart objects) with native IPv6 capabilities
that are connected to the global Internet. A significant characteristics of
IoT is that its scale is expected to be of the order of trillions [46]. The IoT
Initiative (IoT-i) program has come up with a set of futuristic and ambitious
use-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 with
ROLL and CoRE, 6LoWPAN specifies a complete system to connect wireless
devices to Internet.
IoT is closely related to M2M, with the chief distinguishing attribute
being that, unlike M2M devices, the IoT devices must be IP-enabled and
connected to the global Internet. Internet connectivity for embedded devices
opens a huge range of possible applications, but also brings new challenges
in the field of security.
1
2
http://www.etsi.org/website/technologies/m2m.aspx
http://www.iot-i.eu
2.4
ZigBee
ZigBee protocol suit is created by an industry consortium called ZigBee Alliance. It builds upon IEEE 802.15.4 to cover the complete vertical protocol
stack by adding networking support, security, and service discovery. ZigBee application profiles which ensure that the manufacturers products are
interoperable at application level. Figure 2.2 3 shows the ZigBee protocol
stack.
Figure 2.2: ZigBee Protocol Stack
ZigBee uses bands including 2.4GHz, 900MHz and 868MHz. It supports

both short range and long range wireless connectivity using IEEE 802.15.4
and cellular modems, respectively. Hence, ZigBee devices can be used for
both, WSN and M2M domain.
Unlike 6LoWPAN, ZigBee does not have IP connectivity, though it intends to do so in near future 4 . Another difference between 6LoWPAN and
3
http://i.cmpnet.com/eetimes.fr/news/2008/zigbee_stack_4.gif
http://zigbee.org/imwp/idms/popups/pop_download.asp?contentID=
15754
4
ZigBee is that 6LoWPAN does not specify application level profiles like ZigBee.
2.5
6LoWPAN
IETF has created 6LoWPAN working group [1] to define the specifications for
Low-power wireless personal area networks (LoWPANs) consisting of IEEE
802.15.4 devices. 6LoWPAN creates a thin layer over IEEE 802.15.4 to adapt
it for IPv6. RFC 4919 [31] gives its objective and problem statement and RFC
4944 [38] specifies the 6LoWPAN protocol. Figure 2.3 shows a 6LoWPAN
Network.
LoWPAN
Global IPv6 Internet
Node
Edge
Router
Figure 2.3: 6LoWPAN Network
6LoWPAN devices are suitable for a WSN domain. Additionally, 6LoWPAN devices can participate in IoT, courtesy edge routers, which transparently provide native IPv6 based access to Internet. Reference [14] is a good
case study for using 6LoWPAN devices for IoT.
2.6
10
Constrained Application Protocol

(CoAP)
Constrained Application Protocol (CoAP) is web protocol that has been created with the objective of applying Representational State Transfer (REST)
architecture [19] to the M2M domain. The industry standard protocol for
REST is HTTP. However, HTTP is ill suitable for M2M due to the constrained environment of M2M. Hence, HTTP is customized for M2M in the
form of CoAP by defining smaller messages with simpler parsing. CoAP uses
asynchronous messaging over connectionless transport protocol with requestresponse messaging model. CoAP is specified in the IETF drafts [21], [45],
and [47]. It includes a resource discovery mechanism which is critical for
M2M communication.
CoAP can be used in WSN domain as well as M2M domain. It enables
embedded devices to be part of IoT, thanks to its full compatibility with
HTTP.
2.7
Distributed Hash Table (DHT)
Distributed Hash Table (DHT) is a distributed system that provides services

to 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 be
used to retrieve the data. The mapping from key to value and the value
itself is stored among nodes in a distributed manner. Typically, the data is
replicated on separate nodes to accommodate node failures or nodes leaving
DHT system. Caching is used to improve system performance.
DHT are very sophisticated data structures that have revolutionized distributed networks. In 2001, [9] listed the first significant set of DHT algorithms namely- CAN, Chord, Pastry, and Tapestry - which bootstrapped the
DHT research field.
The key DHT challenges are optimizing store/retrieve operations, fault
tolerance, 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 topologies
and lookup services and they are fundamental for creating P2P networks.
They can also be used for distributed storage applications that stores any
arbitrary data in a network. As an example Hazelcast [4] uses DHT to create
a data distribution platform.
2.8
11
Peer-to-Peer (P2P) Technologies
Peer-to-Peer (P2P) refers to a network where nodes can communicate with

each other without requiring any central entity to coordinate. This concept
is in contrast to the client/server architecture. The distinguishing characteristics of P2P are decentralized network, autonomous nodes and combination
of client and server functionality in all nodes [20]. In P2P, all nodes have
equal control in network and every nodes shares its resources in terms of
storage, network bandwidth, and CPU cycles.
Although P2P systems have been around for sometime time, it is the
recent advancements in distributed computing techniques, like DHT based
approaches, 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. The
SNMP network management has three components:
The SNMP protocol: It defines the operations performed by Protocol
Data Units (PDUs) and their message formats.
Management Information Base (MIB) - It is the collection of variables
that are monitored and controlled on managed devices. The variables
are identified using Object IDentifiers (OID) in an extensible hierarchical namespace.
Structure of Management Information (SMI) - It defines the subset of
Abstract Syntax Notation One (ASN.1) rules which are used to define
MIB variables.
12
Manager
- NMS
- No MIB
SNMP PDUs
(from Manager to Agent)
- GetRequest
- SetRequest
- GetNextRequest
- GetBulkRequest
SNMP PDUs
(Agent to Manager)
- Response
- Trap
- InformRequest
Managed Devices /
Agent
- MIB
Figure 2.4: SNMP Network Management
SNMP protocol uses request-response messaging between two types of

entities - Managers and Agents. SNMP Managers are typically separate
computers which are used to monitor and control the Agents. They also
host Network Management System (NMS) software, though NMS is not covered by SNMP specifications. SNMP Agents are the managed devices which
implement 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 possibly
list of variable(s).
GetNextRequest. It is used to discover variables and their values.
13
GetBulkRequest. This was added in SNMPv2 to discover variables with higher efficiency.
InformRequest. It is asynchronous notification message used for
Manager to Manager communication. It can also be used for
Agent 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 difference
that it is initiated by Agent. It is used by Agent for asynchronous
notifications.
There are multiple versions of SNMP, but practically only 3 versions are
used - SNMPv1 (RFC 1157 [12]), SNMPv2c (RFC 1901 [13]), and SNMPv3
(RFC 3411 [23]). Research in [43] concluded that SMNP is most commonly
used 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 decentralization
using SNMP, for example [26] and [39]. However, the hierarchical tree structure remains as the most popular decentralization mechanism with current
generation of NMS, which makes these approaches different from our work.
2.10
Smart-M3
Smart-M3 system is an information sharing platform for interoperability between vendor, device and domain [24]. It uses blackboard architecture model
to allow cross-domain devices to share information about their local environment. The resources in a device are described in Resource Description
Framework (RDF) representation using Web Ontology Language (OWL) 5 .
Open source implementation of Smart-M3 platform is available under BSD
license 6 .
In essence, Smart-M3 provides a Semantic Web platform, very similar to
the idea of Tim Berners-Lee described in [33]. The biggest difference is that
the information in Smart-M3 smart space is local in nature and changes more
dynamically than that in the Internet level global smart space.
Smart-M3 consists of the following components:
5
6
http://www.w3.org/standards/techs/owl
http://smart-m3.sourceforge.net
14
Smart-M3 Space. It is a named searchable area of information in SmartM3 platform, commonly called Smart Space.
Smart-M3 Semantic Information Broker (SIB). It is a physical or virtual
entity which stores the information in Smart-M3 Space.
Knowledge Process (KP). It is Smart-M3 agent sitting on a device
which is responsible for interactions with the Smart-M3 SIB like inserting, reading or removing information.
Smart Space Access Protocol (SSAP). It is the session-based protocol
used by KPs to access the information available in SIB. It provides
seven 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 M2M
network with Semantic Web 7 .
http://www.w3.org/standards/semanticweb
Chapter 3
Decentralized M2M Network Design

In this chapter we describe the motivation for decentralizing M2M networks
using P2P, followed by the principles used for designing the M2M network
architecture. Then an overview of the network architecture is presented, and
finally a description of the three most important functional entities in the
network is given.
3.1
Motivation
In Section 1.2 we mention that the centralized systems suffer from scalability
issues and difficulty in distributing intelligence in network. In this section we
elaborate on the need to distribute intelligence in M2M networks, and how
P2P effectively solves the scalability issue of M2M networks.
The current technology trend is that the intelligence is moving towards
the edge of network, for example in the cellular systems, Base Transreceiver
Stations (BTS) have evolved into intelligent NodeB. The intelligent devices
can interact with other devices to share information, and then use the local
information to make decision by itself without requiring any central entities
to issue commands. We believe that intelligent devices with Artificial Intelligence (AI) is key for success of concepts like IoT. Consider one of the
proposed use-cases for IoT 1 : there is an accident on road, which causes the
alarm clock to start ringing 30 minutes before set-time to enable the person
to reach office on time. Another use-case is handling traffic light signaling
and speed limits according to traffic patterns and weather conditions. However, most software can only handle the scenarios for which it was explicitly
1
http://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 IoT

use-cases involve using complex set of information to handle unforeseen scenarios, AI is critical for IoT success. Even though gaming industry have been
using AI since a long time, it is Apple Siri application 2 which has brought
AI to mainstream masses for the first time since more than four decades of
Computer Science. P2P technologies enable distribution of intelligence in
the network, hence it is well suited for integrating AI with M2M networks.
This is an exciting research area, however, AI and its integration with M2M
networks is out of scope for this thesis, and we focus on using P2P for M2M
communication.
Additionally, peer-to-peer technologies can be used effectively to achieve
Internet level of scalability. For example, consider a centralized network
consisting of 100000 nodes. Now if another 1000 nodes have to join the
network, it would require additional resources from the centralized entities
putting 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 its
own resources towards the network system thereby allowing higher scalability.
BitTorrent is a very good example to illustrate the concept. In a BitTorrent
system, a machine originally hosting a file needs to transfer the segments of
the file only once, and all the other peer machines can get a copy of the file by
exchanging the segments among themselves. This way each machine which is
a part of the peer-to-peer system shares its resources - computational, storage
and network bandwidth - with the whole system allowing even distribution
of load, and hence allowing system to scale easily.
3.2
Design Principles
In this section we outline the design principles along with a brief motivation
for making these design choices.
IEEE 802.15.4 3 has emerged as the undisputed leader in low power radio
technology [46]. It is used in most of the M2M specifications like 6LoWPAN [38], ZigBee, ISA100.11a [5], and WirelessHART [6]. The network
formed by IEEE 802.15.4 devices is typically referred to as Wireless Personal Area Network (WPAN). We considered among ZigBee and 6LoWPAN
devices for our prototype testbed. The 6LoWPAN devices have native IP
support, hence they are a good candidate, however, 6LoWPAN devices were
not easily available at the time of writing this thesis and they were more expensive. On the other hand, ZigBee devices are easily available, and moreover
2
3
http://www.apple.com/iphone/features/siri.html
http://www.ieee802.org/15/pub/TG4.html
17
ZigBee consortium is already aligning themselves to IP 4 , hence we selected

ZigBee devices for WPAN.
Internet is a huge success story and two factors have been critical to its
mass adoption - interoperability based on open standards and connecting
vastly heterogeneous networks by allowing flexibility on the physical layer
technologies. We believe that these two factors will also be very important
for the success of next generation M2M networks. In specific, IP capability
will be crucial since it will enable the embedded devices to easily integrate
with the existing Internet infrastructure. To study connecting heterogeneous
networks, connecting IP enabled M2M network with ZigBee network is one
of the important aspects of P2P4M2M research project.
The objective of P2P4M2M research project is to decentralize M2M networks using P2P technologies. We have chosen RELOAD protocol [48], which
is a DHT based P2P protocol, to form the decentralized distributed system.
It is known that currently it is infeasible to execute DHT implementations
on low resource embedded devices [36], hence, the ZigBee motes do not use
P2P technologies. We have chosen Linux based microcontroller boards for
hosting Chord protocol.
Another interesting aspect is the range of communication. We are interested in both, local communication between devices (for example, home
appliances talking with smart energy metering) and long distance communication (for example, a user checking the status of home appliances from
office). The IoT Initiative (IoT-i) program 5 has defined 60 potential usecases for IoT and in several cases the devices are spread over large physical
distance. Low powered radio technology like ZigBee enable local communication, but for long distance we need wireless cellular technologies. Hence,
we have decided to use 3G connectivity for the devices that are connected
using P2P. Cellular based M2M devices have the benefit of easier installation
and enabling higher mobility and bandwidth 6 .
Additionally, cellular based embedded devices can also nicely work as
Gateway devices to connect the WPAN formed by low powered ZigBee devices. The resulting hierarchical structure adds to the scalability of the system and allows the possibilities of interoperating with heterogeneous technologies through Gateway (since the WPAN could be 6LoWPAN or some
other technology).
A monitoring and controlling entity is required in the M2M network to
provide interface to humans. Since we want the network to be self-reliant, the
4
https://docs.zigbee.org/zigbee-docs/dcn/09-5003.pdf
http://www.iot-i.eu
6
http://www.etsi.org/Website/Technologies/M2M.aspx
5
18
network must be able to work without requiring continuous presence of this

entity. Also, keeping in-line with the decentralization goal, the management
function should be spread over the devices in the network. Hence, all the
M2M devices will host management software.
Summing up the above design principles leads to the system architecture
design as shown in Figure 3.1 in next section.
3.3
System Architecture
Monitoring &
Controlling
Monito
r/
Applica Control
tion
WWAN
PN
-WWAN
-P2P
-ZigBee
WPAN
WN
-WWAN
-P2P
WN
-WWAN
-P2P
P2P Network
LN
- ZigBee
LN
- ZigBee
= Sensor
= Actuator
Figure 3.1: Decentralized M2M Network Architecture (P2P4M2M)

The system architecture for our prototype is shown in Figure 3.1. Henceforth, we will use the term P2P4M2M to refer to this particular decentralized
M2M network architecture. There are 4 distinct types of nodes in P2P4M2M
network and they have been termed individually for easy reference. All the
4 nodes differ in their hardware and functionality.
19
Monitoring and Controlling Node (MCN) : This device provides

human interface to the P2P4M2M network and it is used to configure
the 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. In
our prototype, we have used a laptop. As explained later, MCN uses
SNMP protocol for network management.
Wide Area Node (WN) : This device forms part of the P2P overlay using the DHT based implementation. It uses 3G wireless cellular
connectivity and since these devices can communicate over large distances, the collection of these devices is called Wireless Wide Area
Network (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 a
highly constrained device with limited processing, storage and short
range radio connectivity. It cannot host DHT based P2P implementation, but thanks to the Proxy Node functionality, it still participates
in the P2P overlay. It can have both sensors and actuators. In our
prototype, ZigBee devices are used as LNs.
Proxy Node (PN) : This device is same as WN with the addition that
it also performs the Gateway and Proxy functionality for the LNs. It
has an attached ZigBee Coordinator device which enables it to handle
WPAN management and provide messaging interface to the LNs. It
is also responsible for the protocol conversion for CoAP and SNMP
messages into ZigBee protocol (and vice-versa).
Since WNs can have sensors and actuators, they only differ from ZigBee
devices in terms of their ability to host DHT implementation and IP connectivity. So WN represents the next generation M2M embedded devices, when
the advancements in P2P algorithms and hardware capabilities will allow
these 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 of
M2M devices.
3.4
Functional Description
The following three functional entities have been researched and developed
in the overall scope of the P2P4M2M research project.
20
Monito
r/
Applica Control
tion
Cheap S
- ZigBee
Local Node (LN)
Proxy S/A
-WWAN
-DHT
-ZigBee
Proxy Node (PN)
S/A
-WWAN
-DHT
Wide-area Node
(WN)
Monitoring &
Controlling Node
(MCN)
WPAN (e.g. ZigBee)
WPAN (e.g. ZigBee)

WWAN (e.g. 3G)
WWAN (e.g. 3G)
WWAN or fixed
access
No DHT
DHT
DHT
DHT
Moderate hardware
(e.g. 8kB RAM)
Advanced hardware
(e.g. 256 MB RAM)
Advanced hardware
(e.g. 256 MB RAM)
Normal PC
hardware, Tablet
Simple OS (e.g.
TinyOS or Arduino
Platform)
Advanced OS (e.g.
Linux)
Advanced OS (e.g.
Linux)
Desktop OS (e.g.
Windows)
Either S or A
Can optionally have

either S, A, or both
Can optionally have

either S, A, or both
Cheap
Costlier
Costlier
S = Sensor
A = 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 into
hierarchical layers, where each layer provides well defined APIs for higher
layers. Now, DHT algorithm by themselves only provides the ability to
store and retrieve a key-value pair. To develop a decentralized M2M system
using DHT, we needed to create an abstraction layer - which we termed
as M2M Communication Enabler (M2MCE) - on top of DHT, which hides
the distributed nature of information storage and provides an API to access
information as if the information was stored on the local node itself (hence the
APIs are implemented as synchronous function calls and not as asynchronous
message passing or callback functions). In addition, M2MCE also provides
APIs to enable messaging using the P2P overlay, and accessing the logical
predecessor/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
MCN / CoAP / PN
M2MCE
hides
distributed
architecture
21
MCN / CoAP / PN
M2MCE Layer
DHT
DHT
OS
OS
...
DHT
OS
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 the
underlying DHT algorithm. Typically, the data is stored over several
peers and it is ensured that there is no loss of data even if some peers
leave the system. This distributed storage can also be used to store
network alarms, traps etc.
Since all the nodes register to P2P4M2M using M2MCE, it can easily
maintain a log of all the nodes in the network using the distributed
storage. This gives an easy node discovery mechanism.
Distributed DNS functionality. As such, the M2M system is about machines communicating with machines and hence do not need a human
readable name. However, humans need to interact with the system for
provisioning and maintenance, so having human understandable names
22
for devices is required. Also, these names are used in CoAP URIs. Additionally, the notion of name helps decouple identity and location for
mobile 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 to
broadcast message, but these methods are transparent for the higher
layer (above M2MCE). It is a research agenda for M2MCE to find the
most efficient method for broadcasting.
Detailed description of M2MCE is beyond the scope of this thesis, but
the 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 in
the chapter 4.
3.4.3
Proxy Node
The proxy node performs the following functions: The WWAN uses SNMP and CoAP protocols, whereas the WPAN uses
ZigBee protocols. Hence, PN does the protocol conversion from SNMP
and CoAP to ZigBee. A few messages have direct mapping between
the protocols (like the SNMP MIB to trigger detaching a LN is directly
mapped to ZigBee ZDO message ZDO CLUSTER MGMT LEAVE
REQUEST), and the other messages are sent to LNs using TypeLength-Value (TLV) format. PN also interfaces with the CoAP proxy
and SNMP proxy as per their respective specifications
PN is responsible for the ZigBee WPAN management, including node
discovery and service discovery. After the PN starts, it enables the
ZigBee coordinator node (which is part of PN). Whenever a LN joins
(or leaves) the WPAN, it inform the ZigBee coordinator node, which
further informs the PN. In this way, the PN keeps track of all the LNs
that are part of the WPAN. ZigBee coordinator node uses a timer based
heartbeat mechanism to discover any LN that leaves WPAN without
informing, for example due to failure. PN uses ZigBee protocol to
discover the services hosted by LNs.
23
When the LNs join the WPAN, the PN assigns them a name using the
well known dot notation, for example, if the PN name is PN100, then
it can assign LN names like PN100.LN1, PN100.LN2, PN100.LN. Then
PN uses M2MCE interface to join the P2P overlay on behalf of each
LN. Hence, PN represents LNs in P2P overlay, provides an abstraction
to 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 LN
leaves WPAN, PN performs leave operation on DHT on behalf of the
departing 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 have
only ZigBee address). So for any messages exchanged between WWAN
and WPAN, PN does the translation between IP adress and ZigBee
device address.
PN caches sensor data. This is especially useful for the sleeping sensor
devices, which periodically wake up and send data to the PN. PN then
caches this data and uses it to handle any future request. PN can also
use P2P overlay to cache the data if required.
PN can potentially provide firewall functionality to secure WPAN, however this is left as future work.
Detailed description of PN is beyond the scope of this thesis, but the
complete details can be found in [35].
3.5
Smart-M3 System
Smart-M3 system is an information sharing platform for interoperability between vendor, device and domain [24]. We used Smart-M3 platform to study
integration of P2P4M2M with Semantic Web 7 .
The Figure 3.3 shows the Smart-M3 system which is used for sharing
the information in M2M network, for example the sensor values. All the
network nodes in P2P4M2M have a Smart-M3 Knowledge Process (KP) [24]
which is responsible for interacting with the Smart-M3 platform. The LN are
represented in the Smart-M3 system by PN, and the KP in PN is responsible
for interoperating between Smart-M3s Smart Space Access protocol (SSAP)
and ZigBee protocol. Smart-M3 Semantic Information Broker (SIB) is the
geographical smart space containing information about all the nodes and
7
http://www.w3.org/standards/semanticweb
24
WN
-WWAN
-P2P
KP
WPAN
PN
-WWAN
-P2P
-ZigBee
LN
- ZigBee
KP
KP
SmartM
3
Client
Smart-M3
SIB
LN
- ZigBee
WN
-WWAN
-P2P
KP
= Sensor
= Actuator
KP = Knowledge
Process
Figure 3.3: Smart-M3 System
resources available [24]. The KPs in all M2M devices (WNs and LNs via
PN) populate the Smart-M3 SIB with the information about all the nodes
and their resources. Then any device with KP can act as Smart-M3 client and
interact via Smart-M3 SIB, to display the list of resources and retrieve any
resources value. For example, all ZigBee motes have temperature sensors and
GPS modules, and a Smart-M3 client can interact with both the resources
and get the temperature at any particular location. It is worthwhile to note
that CoAP protocol is not used here.
Chapter 4
Decentralized M2M Management

We use SNMP for decentralized M2M network management. As such, SNMP
started essentially as a centralized paradigm [37], in-part due to the design
principle that the impact of adding management functionality to managed
devices should be minimized [41]. As networks evolved, the scale and computational power of managed nodes increased massively. This created interest
in decentralizing network management by moving towards Management by
Delegation paradigm [22]; Remote Network MONitoring (RMON) MIB [52]
is a good example of the initial work towards this. Since then a wide range of
techniques have been developed for decentralized management, including artificial intelligence [28]. In this thesis we use a novel mechanism of adapting
DHT and using P2P principles for distributed network management functionality.
4.1
Challenges in Decentralization
The key challenges in decentralizing P2P4M2M network (Figure 3.1) are as

follows:
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 response
messages
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 mechanism for node discovery, so every NMS has its own node discovery mechanism. In P2P4M2M network, node discovery information is stored in
DHT by M2MCE layer. MCN uses M2MCE API to fetch the list of all
the nodes that are part of the network. For performance improvement,
the M2MCE layer also provides API to access delta updates to the
network information i.e. the list of nodes joining DHT since last request. To handle multiple MCNs, the M2MCE layer has to keep track
of multiple delta information, hence there has to be an upper limit on
the number of simultaneous MCN nodes present in the DHT overlay.
Since M2MCE layer knows the type of node (LN, PN or MCN), it can
allocate the context when MCN joins and release it when MCN leaves
the network.
MCN is used for resource discovery and provisioning. The resources can
be dynamically added or removed on nodes. The database of resources
in stored in MIB and it is also used by CoAP to advertise the resources
to other nodes using the /.well-known URL [21]. The resource list in
MIB is considered as master, which keeps it synchronized across CoAP
and SNMP protocols.
In alignment with the P2P principle that there should not be any central entity required for setting up the network or communication between peer nodes, MCN is not required to be part of the network all the
time. P2P4M2M network is made self-reliant delegating the node joining procedure to RELOAD protocol in the managed (WN/PN) nodes,
and by not storing any information on MCN that is required for network
functioning. The latter is achieved by (as mentioned above) storing the
node discovery information in DHT and the resource discovery information in the managed nodes. MCN retrieves this information when
required, but does not store it. However, for efficiency, MCN does cache
this information.
MCN manages the WPAN using the proxy features of PN for operations like detaching the LNs from the WPAN. SNMP Proxy Forwarder
27
application [34] is used for this. We devised dot notation for naming
LNs to take into account the hierarchical nature of network. This also
allows any arbitrary level of nesting in the network.
MCN is used to manage the WWAN for operations like detaching nodes
from P2P overlay, assigning the type of node as WN or PN, setting the
node name, setting the association between sensor and association. An
salient point here is that only the device configuration - like sensoractuator association - is controlled by MCN, the flow of data between
them is using CoAP and autonomously done by the nodes.
MCN is used for setting system parameters on nodes like enabling or
disabling the Smart-M3 feature, controlling the logging level etc. MCN
uses SNMP to manage the nodes, so it can use the standard MIBs
to configure system parameters. Since the nodes use IP, IP-MIB and
IF-MIB MIBs are particularly useful.
The graph navigation for request-response is handled by the RELOAD
protocol, which in turn uses the ring topology provided by the Chord
algorithm. Although, CoAP and SNMP can use the overlay messaging
facilities provided by RELOAD protocol, in the prototype they use
M2MCE layers DDNS APIs to translate node name to address, and
then 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 than
SNMP protocol. However, support for generic SNMP PDUs is also
provided for flexibility.
As future work, MCN can have a GUI interface for laptops and smartphones, which allows access to full functionality of MCN like node
discovery, visual indications for alarms, resource discovery, and a library
of graphs and charts for displaying data from nodes. The idea is to
have a generic interface for M2M network which should be portable
for other M2M and IoT networks. A good example of work in this
direction is Pachube 1 , which allows storing of data feeds, controlling
them and displaying data. The challenge here is to have a generic
interface, massive scalability, and support for real time operation.
1
https://pachube.com
4.3
28
Security
PN is responsible for the security of WPAN. It uses the ZigBee provided

mechanisms for the security of the application data and the network. It
utilizes ZigBee Coordinator node (which is part of PN itself) as the TrustCenter for managing and distributing keys. LNs use the shared keys for
cryptographic algorithms. M2MCE layer is responsible for the security of
P2P overlay and stored data.
MCN is responsible for SNMP security and securing access. Reliable security was introduced to SNMP with version 3, however, currently MCN uses
SNMPv2c and implementation of SNMPv3 remains to be done. SNMPv3
User-based Security Model (USM) will be used for authenticating users.
4.4
P2P4M2M Protocol Stack
Application
ZigBee
APP
Proxy
Logic
Relay
CoAP
Proxy
COAP SNMP
ZDO
ZigBee
APS
ZigBee API
lib
ZigBee NWK
802.15.4
LN
SNMP
Proxy
802.15.4
PN
Application
CoAP
SNMP
Application
SNMP Manager
M2MCE
M2MCE
M2MCE
DHT
DHT
DHT
UDP
UDP
UDP
IP
IP
IP
3G/2G
3G/2G
3G/2G
WN
MCN
SNMP
Figure 4.1: P2P4M2M Network Protocol Stack Diagram
CoAP
29
The Figure 4.1 shows how SNMP, CoAP, DHT-based Chord and M2MCE
are stacked with each other. It can be seen that CoAP does not require MCN
to be present in the network.
4.5
MCN Interfaces
Figure 4.2 displays the MCN command line interface, along with the SmartM3 and WN interfaces. The list of commands available can be seen from the
figure.
Figure 4.2: Command Line Interface
MCN interfaces with M2MCE layer for the following functionality:

translate node names into corresponding IP address (DDNS functionality)
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
30
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 the
prototype testbed. We show the message sequence charts, followed by its
explanation.
4.6.1
Name Resolution
As mentioned in Section 3.4.1, M2MCE layer provides a distributed name

resolution service to other entities like MCN and WN. The M2MCE API
for this is a synchronous function call which takes node name as input and
returns its corresponding IP address.
These below points are in reference to the message sequence chart in Figure 4.4.
1. First a node, like MCN and WN, invokes M2MCE join() API to register
themselves and become part of the P2P4M2M network. M2MCE layer,
in turn, uses P2P operations to distribute the information over the
network. These P2P operations and distributed storage is hidden from
higher 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 again
uses P2P operations to retrieve the information from distributed storage.
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 sending
node as the proxy feature on PN is responsible for routing the message
to the correct target LN. This proxy feature uses the uri-host part of
the CoAP [21] and Proxy Forwarder [34] feature of the SNMP.
MCN
WN
M2MCE
31
WN nodes
P2P Messages
join(name,type)
success
P2P Messages
join(name, type)
...
success
P2P Messages
getIP(nodeName)
IP Address
Figure 4.3: Message Sequence for Name Resolution
Similar interaction happens for node discovery and other functionality which
store/retrieve data into/from the DHT-based database, with M2MCE layer
providing a higher level abstraction API which hides all the complexities
of distributed system. This message sequence is basic and part of all the
subsequently described scenarios.
4.6.2
MCN Operation
One of the functionalities of MCN is setting the association between sensors

and actuators of any two arbitrary nodes. The node containing a sensor
uses this association to inform the node containing the actuator when a
predetermined event occurs. For example, a sensor monitoring fire can inform
actuator controlling sprinklers when it detects a fire outbreak.
1. Typically the first thing to do before sending message to any node is to
resolve the node name into its IP address (as explained in Section 4.6.1).
MCN
M2MCE
WN
PN
32
LN
getIP() using P2P

SNMP Get (resources)
SNMP Response (resources list)
SNMP Set (association)
SNMP Response (success)
node stores
association
Resource Discover for LN

SNMP Set (association)
ZigBee Ack
ZigBee msg
node stores
association
SNMP Response (success)
Figure 4.4: MCN sets association between sensor and actuator
2. Next, MCN uses SNMP protocol to discover the resources (sensors and
actuators) on a WN node. Then using this list of resources, MCN
can associate a sensor with an actuator on another node (the resource
discovery 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 address
returned by M2MCE layer is that of PN, and the SNMP message is
dynamically 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 (in
WWAN), via PN.
1. When an event is detected at LN, it checks if any sensor-actuator association 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
PN
33
LN
ZigBee msg
Event
Detected
by Sensor
getIP() using P2P

CoAP PUT msg
Actuation
Event
CoAP ACK msg
ZigBee Ack
MCN not required
CoAP protocol
ZigBee protocol
Figure 4.5: Information from LN towards WN
message to the target node using the ZigBee coordinator node (which
is part of PN).
2. On receiving the ZigBee message, PN converts the ZigBee message into
CoAP message and uses CoAP library to send it to the target node.
CoAP library uses the M2MCE API to resolve the target node name
into IP address, and then uses UDP protocol to send the message.
3. The target node receives the CoAP message and triggers the actuator
using the information in the CoAP message. It then acknowledges the
message by sending CoAP message to the PN.
4. On receiving the CoAP Acknowledgement, PN converts it to ZigBee
Acknowledgement and sends it to the LN, completing the transaction.
5. It is worthwhile to note that MCN is not required in any step of this
scenario, thus making the network self-reliant.
4.6.4
34
WN to LN
MCN
WN
Event
Detected
by Sensor
M2MCE
PN
LN
getIP() using P2P

CoAP PUT msg
CoAP Empty Ack
ZigBee msg
ZigBee Ack
Actuation
Event
CoAP Deferred Ack

CoAP Ack (for Ack)
MCN not required
CoAP protocol
ZigBee protocol
Figure 4.6: Information from WN towards LN

The Figure 4.6 shows information sent in the opposite direction of Figure 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 sensoractuator association is configured with the particular sensor detecting
the event. If an association is found, WN uses CoAP library to send
the event information in a CoAP message to the target node.
2. Since the LN is represented by the PN, the CoAP message is received
by the CoAP server on the PN. The CoAP server checks HOST URI
field of the CoAP message to identify the target LN for which the
message is intended. The PN then converts the CoAP message into
ZigBee message and uses zigbee-api library to send the message to LN.
3. The target LN finally receives the ZigBee message and triggers the
35
actuator using the information in the message. It then acknowledges

the message by sending ZigBee Ack message to the PN.
4. On receiving the ZigBee Acknowledgement, PN converts it to CoAP
Acknowledgement and sends it to the source WN, completing the transaction. The PN uses CoAP Token to match the Requests and Acknowledgements.
5. Like the previous scenario of LN to WN communication, it is worthwhile 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 prototype
testbed and the system startup details. We also give the rationale for choosing these specific hardware and software. In general, we have preferred to
use open source software wherever possible.
5.1
Hardware Specification
The prototype testbed uses the hardware described below. In order to duplicate our prototype testbed, we recommend using hardware with same specifications. In order to allow flexibility, we have used Java, Linux, ZigBee and
Ardurino platforms which work on a wide variety of hardware, and hence
minimal modifications should be required to run our software on different
hardware.
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 ZigBee
Radio Frequency (RF) module.
There are several vendors providing microcontroller boards that support ZigBee RF modules. Among them, we mainly considered 3 boards:
WaspmoteTM (from company called Libelium 1 ), MulleTM (from company
called Eistec 2 ) and IRISTM Mote (from company called Crossbow 3 ), and
1
http://www.libelium.com
http://www.eistec.se
3
http://www.xbow.com
2
36
CHAPTER 5. PROTOTYPE IMPLEMENTATION
37
Figure 5.1: Local Node
finally we selected Waspmote
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 Deep
Sleep mode and 9mA when ON.
It has the possibility to add more than 50 sensors, giving a lot of
flexibility
WaspmoteTM board has Atmels 5 ATmega1281 microcontroller operating
at 8MHz frequency with 8KB SRAM, 4KB EEPROM, and 128KB FLASH.
It uses the Arduino6 platform, which comes with a IDE to develop, build and
4
http://www.libelium.com/products/waspmote
http://www.atmel.com
6
http://www.arduino.cc
5
38
upload software onto the device. In addition to ZigBee, it supports Bluetooth

and 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 other
vendors ZigBee RF modules. Additionally, these RF modules are compatible
with 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
7
http://www.digi.com/products/wireless-wired-embedded-solutions/
zigbee-rf-modules/zigbee-mesh-module/xbee-zb-module
8
http://www.digi.com
39
Gumstix using USB. This gateway device, together with the zigbee-api library 9 , provides the interface to the WPAN. This interface is used by the
CoAP 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 exception that it does not have Waspmote Gateway device. We use single-boardcomputer (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 configurations (choices in DSP, Graphics acceleration, operating temperature
ranges etc), and it is compatible with numerous expansion boards which can
add capabilities like GPS, touch screen LCD, HDMI etc to the SBC. It uses
OMAPTM 3503 Applications Processor from Texas Instruments 12 (which is
based on ARM CortexTM A8 CPU design). In addition, there is a development community around different products from Gumstix Inc providing a
lot of open source software and technical discussion forums. We have used
MicroSD card (on Overo Earth) to store the Linux image, which is very easy
to clone, simplifying the procedure of adding extra nodes in the testbeds. All
these factors make Overo Earth suitable for rapid prototyping.
The wireless connectivity is provided by using 3G UMTS dongle which is
connected to the SBC using USB.
5.1.4
MCN Hardware
Dell Latitude D630 laptop is used as MCN. In addition, this laptop is also
used as a Smart-M3 client. Another laptop (Dell Latitude D630) is used to
run 3 entities - the bootstrap node for the P2P network, a set of simulated
WNs, 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 prototype
implementation:
9
http://code.google.com/p/xbee-api
http://www.gumstix.com/store/product_info.php?products_id=211
11
http://www.gumstix.com
12
http://www.ti.com
10
40
Figure 5.3: Lab Setup
SNMP4J : SNMP4J 13 is an open source enterprise grade implementation of state-of-the-art SNMP using Java 2SE 1.6. It is used on WN and
PN for implementing both SNMP-Agent and SNMP-Manager functionality, and on the MCN for SNMP-Manager functionality. The versions
used 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 of
the CoAP protocol. We have used version 0.1, which is based on the
IETF drafts draft-ietf-core-coap-05, draft-ietf-core-block-03, draft-ietfcore-link-format-04, and draft-ietf-core-observe-02. We had also con13
14
http://www.snmp4j.org
https://github.com/dapaulid/JCoAP
41
sidered another CoAP implementation jCoAP15 (notice the small j),

however, on evaluation we found that JCoAP was more feature- complete than jCoAP, hence we used JCoAP. One important feature that
JCoAP lacked was the proxy functionality (as defined in Section-5.3 of
CoAP specification [21]), so it was added as part of this thesis.
zigbee-api library : Libelium does not provide any library to interface
with the ZigBee gateway device, hence we had to use a third party
library. Zigbee-api library is an open source Java implementation for
interfacing with Radio Frequency devices complying with XBee/XBeePro series 1 (802.15.4) and series 2 (ZNet 2.5 and ZB/ZigBee Pro). It
requires RXTX 16 java library to communicate with ZigBee coordinator
node using USB port.
P2P network based on DHT : We have used Ericsson Researchs
implementation of P2P network which is based on DHT. It uses Peerto-Peer Protocol (P2PP) and Chord algorithm. RELOAD protocol [25]
is the IETF successor of P2PP and since M2MCE completely abstracts
P2PP from MCN, for the purpose of this thesis, we mention RELOAD
protocol even though the prototype uses P2PP.
Arduino : Libelium Waspmote development uses Arduino development environment. We used Waspmote IDE version 2, which in turn
is based on Arduino IDE. The Waspmote IDE provides code examples
for handling various sensors in Waspmote which are very helpful in
development.
Linux : Linux embedded operating system is used on Gumstix (used
as WNs in the prototype). The flavour used is linux-gnueabi, which
is 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 developed
by Vienna University of Technology with support for ARM processors.
We chose CACAO over JamVM 19 because it supported the pre-existing
DHT based P2P implementation out-of-the-box.
15
http://code.google.com/p/jcoap
http://users.frii.com/jarvi/rxtx
17
http://code.google.com/p/opkg
18
http://www.cacaovm.org
19
http://jamvm.sourceforge.net
16
42
Smart-M3 Platform : We have used Smart-M3 platform, which is

created as part of DIEM project, to provide information level interoperability using Smart-M3 Knowledge Processes [24]. The version used
is 0.9.5 [17].
Smart-M3 Java library : Smart-M3 platform provides interface in
C. Language bindings have been created for Java and Python to enable
software development in these languages. We have used the Java binding created by University of Bologna and Finnish Technical Research
Centre VTT [50], version 5.5. The java binding internally uses JSON
library.
It is worth noting that all the software is developed using Java, other than
the C on Waspmotes (since Waspmotes do not support Java). The basic idea
behind using Java is to allow easy porting to new (different) hardware, and
given that M2M field is rapidly advancing, we expect to continually upgrade
the testbed hardware.
5.3
Software Structure
The high level software architecture of PN is shown in Figure 5.4. The design
of 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 Remote
Method Invocation (RMI) 20 for communicating with each other. These 3
JAR files are present in all nodes which allows the flexibility to change a
PN into WN (and vice-versa) and to use any node as MCN. There are 6
significant 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 this
thesis.
20
http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf
M2mManager
M2MCE
Smart
M3
43
Proxy
RMI
API
CoAP
Lib
RMI
API
Java Virtual Machine
Linux Operating System
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 the
devices in the network. Each node begins by launching M2mManager module, and then onwards the M2mManager module is responsible for further
launching the other modules and configure the local node. The M2mManager
module uses SNMP MIB information for this purpose.
M2mManager checks if there are any MIB values specified in the (optional) configuration file and loads these values, if any, into the MIB. Next,
M2mManager checks the node-type (PN/WN/MCN), the node name, and
the feature flag for Smart-M3, and accordingly does the following:
If a node name is given in configuration file, M2mManager uses this
name and the node-type to invoke the join() API of M2MCE module.
M2MCE then contacts the bootstrap-peer and joins the P2P overlay. If
no node name is specified in the configuration file, M2MCE module automatically assigns a name. This mechanism is used since in a network
44
with large number of nodes, it would not be possible to individually

assign names to all nodes; on the other hand, this offers capability to
assign/modify node names via MCN.
If node-type is PN, M2mManager launches the Proxy module; if the
node-type is MCN, it instead launches the command-line module; otherwise, it does not launch any extra module.
If the feature flag for Smart-M3 is enabled, M2mManager launches the
Smart-M3 module. Then Smart-M3 module retrieves all the resources
present in the node and publishes them in Smart-M3 SIB. If the node
is a PN, Smart-M3 is responsible for discovering resources on the LNs
and publishing them in Smart-M3 SIB. Additionally, Smart-M3 module
subscribes, with the Smart-M3 SIB, for any requests for the registered
resources.
Lastly, M2mManager launches the CoAP module which, in turn, starts
listening for any CoAP requests.
At the end of above steps, the system is up and functional. Now, the
MCN commandline interface can be used for operations like node discovery,
resource discovery, setting sensor-actuator associations, controlling log level
etc. Similarly, Smart-M3 client can be used to retrieve information from the
M2M devices. The list of available commands for MCN and Smart-M3 is
shown in Figure 4.2.
Chapter 6
Evaluation and Discussion

There are several interesting research work which focus on evaluating SNMP
and developing extensions to SNMP for resource constrained M2M devices,
for example, [30], [42] and [16]. However, this thesis considers decentralization aspects of the M2M network management.
Over a period of time, several techniques have been used to decentralize
network management. For example, [44] uses navigation patterns and [7,
40, 53] adapt databases to propagate request-responses. One of the most
common technique centers around using hierarchical architecture of network
managers, like [29, 49]. However, we use a novel mechanism of adapting DHT
to 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 is
useful for IETF MIB standardization efforts like the IETF 6LoWPAN
MIB Draft [27].
Sensor-Actuator associations. This is a fundamental attribute
that needs to be stored in the MIB. There have been similar ideas
of creating sensor-actuator associations using different protocols,
like Web Services for Devices (WS4D) 1 which uses Microsoft technologies to provide the same functionality.
GPS coordinates for M2M devices. This attribute is essential for
M2M GUI to spatially display the devices, and invaluable while
configuring the sensor-actuator associations.
1
http://www.ws4d.org
45
CHAPTER 6. EVALUATION AND DISCUSSION
46
We have found that the capability and efficiency of SNMP in this network architecture depends largely on the DHT. For example, the volume of data that can be stored in a given DHT algorithm determines
whether we can store only the node discovery information or also the
resource discovery information. Similarly, the node discovery capabilities of the network will be limited by the response time with which the
Chord algorithm reorganizes its ring-structure when a node leaves or
joins the network.
We have developed a decentralized M2M prototype which acts as a
platform for further research. At the time of writing this thesis, a
research work is in-progress for developing a generic M2M GUI using
this 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, it
was shown that this network could interwork with other heterogeneous networks, like ZigBee, using proxies. Resource discovery
procedures for CoAP and SNMP were united by designating the
SNMP MIB as master information, and CoAP protocol stack referring it.
Using SNMP for decentralized management. This is especially
interesting because SNMP is considered essentially as a centralized system. Decentralization was largely enabled by the modular
design of SNMP, which itself was originally done to help transition from SNMP to OSI based ISO Common Management Information Services/ Common Management Information Protocol
(CMIS/CMIP) [15] (though, eventually, CMIS/CMIP did not become popular for Internet devices).
Integrating the decentralized M2M network with Semantic Web
using Smart-M3.
Creating a self-reliant M2M network, where management node
is not required to be present in the network continuously. This
was achieved by not storing any information required for network
functionality in the management node (i.e. MCN).
A strong need was seen for standardizing the resource names for sensors and actuators to ensure interoperability. Since WSN has its roots
in 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 proprietary standards with little interoperability (like oBIX 2 , ZigBee 3 ).
For instance, CoAP allows resource discovery but without any standard
name for resources, like temperature, machines cannot autonomously
do resource discovery. Currently, the IETF drafts on CoAP and 6LoWPAN mention that the names could be standardized, but there is no
proposal to do so.
During the Smart-M3 integration it was found that the abstraction
layer provided by Ontology and Resource Description Framework (RDF)
in Smart-M3 is too generic and complex. Better abstraction models
need to be developed for wider adoption of Smart-M3 by programmers.
Also, security is missing.
IPv6 and HTTP have been adapted to resource constrained devices
and networks as 6LowPAN and CoAP, respectively. Similarly DHT
also needs to be adapted for M2M network. Currently, the DHT implementations are not suitable even for cellular smart-phones, which
have significant computing power, as found in the performance measurements in [36]. As such, according to Moores Law, the embedded
devices should already have advanced capabilities to host DHT implementations. However the current generation of low power wireless
embedded devices are still resource constrained. We believe that this
is mainly due to two reasons. Firstly, there was no killer application or
widespread use-case requiring more powerful devices. Secondly, the devices need to maximize battery which gets progressively difficult with
increasing hardware complexity. However, now with IoT and M2M
technologies gaining momentum, we believe that the device capabilities will improve. Also, at the same time P2P technologies will be
adapted and advanced, demanding less computational and bandwidth
resources, thereby facilitating incorporation of P2P on M2M networks.
2
3
http://www.obix.org
http://www.zigbee.org
Chapter 7
Conclusions and Future Work

The objective of the overall P2P4M2M research project in which this thesis
was done was to study the challenges in decentralization of M2M networks
and implement a prototype testbed. The scope of this thesis was to investigate the management of decentralized M2M network using SNMP. To
the best of our knowledge, this is the first research work into applying P2P
principles to M2M networks and SNMP. The central topics studied were decentralized management, node discovery, resource discovery, node configuration, and proxy functionality. The project started with the study of possible
use-cases for next generation M2M networks, followed by an evaluation of
several embedded hardware and software which could be used in our prototype testbed. Finally, the design and implementation for the prototype was
carried out by integrating IETF and IEEE aligned protocols - CoAP, SNMP,
IP, RELOAD and IEEE 802.15.4. We also integrated the M2M network with
Semantic Web using Smart-M3. The resulting prototype is being used as a
platform for further research into decentralizing M2M.
In this thesis we identified SNMP MIB for M2M networks, and established
that SNMP can be easily used for decentralized management by adapting
P2P mechanisms. It was seen that the capability and efficiency of SNMP
for decentralized management largely depends on the underlying decentralization mechanism, for example, the volume of data that can be stored in
DHT, and how fast the Chord algorithm reorganizes when nodes leave or join.
Hence, a need was seen for research into customizing RELOAD and Chord
for M2M, much in the manner IPv6 and HTTP have been customized for
M2M in the form of 6LoWPAN and CoAP, respectively. Another finding was
that the standardization of resource names was not being covered in scope
of CoAP, 6LoWPAN or any other drafts. This might lead to the undesirable
situation where product vendors develop proprietary resource names. We
believe 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 be
continuously connected in order for the network to function. Firstly, we
ensured that no required data was stored in the management node. This
was primarily achieved by storing the node discovery information in DHT,
and storing the resource discovery information in SNMP MIB. Secondly, the
node joining was handled by RELOAD protocol of managed nodes themselves
instead of the management node.
7.1
Future work
This work represents an early step towards decentralizing M2M networks

and decentralized management using P2P principles. The timeline for maturing this technology is envisioned to be two to three years and considerable
research remains to be done.
Currently, our prototype is being used for GUI development as part of
another students Masters thesis. This GUI will have generic M2M functionalities 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 towards
this domain. The challenge is to have a generic interface covering maximum
envisioned M2M functionality (so that it is portable to other M2M and IoT
systems), massive scalability, and support for real time operation.
Among other things, work needs to be done for customizing P2P protocols
for M2M and implementing distributed Smart-M3 SIB using DHT. Then,
significant further research is required in the direction of implementing and
comparing different P2P decentralization mechanisms and the centralized
approaches. Additionally, 6LoWPAN devices need to be integrated into the
prototype.
https://pachube.com
Bibliography
[1] IETF 6LOWPAN working Group. http://tools.ietf.org/wg/6lowpan.
[2] IETF CoRE working Group. http://tools.ietf.org/wg/core.
[3] IETF ROLL working Group. http://tools.ietf.org/wg/roll.
[4] In-Memory Data Grid - Hazelcast. http://www.hazelcast.com.
[5] ISA100.11a Draft Standard release 1. Tech. rep., ISA100.11a Working
Group, December 21, 2007.
[6] WirelessHART Communication Standard. HART 7.0 Specifications,
September 7, 2007.
[7] Anerousis, N. An Architecture for Building Scalable, Web-based Management Services. Journel of Network and Systems Management 7, 1
(1999), 73104.
[8] Ashton, K. That Internet of Things Thing. RFID Journal. http:
//www.rfidjournal.com/article/view/4986, 2009.
[9] Balakrishnan, H., Kaashoek, M. F., Karger, D., Morris, R.,
and Stoica, I. Looking Up Data in P2P Systems. Commun. ACM
46, 2 (Feb. 2003), 4348.
[10] Black, U. D. Network Management Standards: SNMP, CMOT, &
OSI. McGraw-Hill Inc.,US, 1992.
[11] Bolonio, J. A. J. Adapting a DHT (Distributed Hash Table) to
a Self-Reliant M2M (Machineto- Machine) Network. Masters thesis,
Aalto School of Science and Technology, Finland, 2011.
[12] Case, J., Fedor, M., Schoffstall, M., and Davin, J. Simple
Network Management Protocol (SNMP). RFC 1157 (Historic), May
1990.
50
BIBLIOGRAPHY
51
[13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S. Introduction to Community-based SNMPv2. RFC 1901 (Historic), Jan.
1996.
[14] Castellani, A. P., Bui, N., Casari, P., Rossi, M., Shelby,
Z., and Zorzi, M. Architecture and protocols for the internet of
things: A case study. In PerCom 2010 Workshops: Proceedings of the
8th Annual IEEE International Conference on Pervasive Computing and
Communications Workshops, Mannheim, Germany (2010), pp. 678683.
[15] Cerf, V. IAB recommendations for the development of Internet network management standards. RFC 1052, Apr. 1988.
[16] Choi, H., Kim, N., and Cha, H. 6LoWPAN-SNMP: Simple Network
Management Protocol for 6LoWPAN. In 11th IEEE International Conference on High Performance Computing and Communications, HPCC
2009, 25-27 June 2009, Seoul, Korea (2009), IEEE, pp. 305313.
[17] DIEM. Smart-M3 platform. http://smart-m3.sourceforge.net. Accessed Sept 1, 2011.
[18] Ericsson. More than 50 billion connected devices, taking connected
devices to mass market and profitability. http://www.ericsson.com/
res/docs/whitepapers/wp-50-billions.pdf. Accessed April 1, 2011.
[19] Fielding, R. T. Architectural Styles and the Design of Network-based
Software Architectures. PhD thesis, University of California, Irvine,
2000.
[20] Fischbach, K., Schmitt, C., and Schoder, D. Core Concepts in
Peer-to-Peer Networking. In Peer to Peer Computing: The Evolution of
a Disruptive Technology. Idea Group Inc., 2005, ch. 1.
[21] Frank, B., Shelby, Z., Hartke, K., and Bormann, C. Constrained Application Protocol (CoAP). Tech. Rep. draft-ietf-core-coap,
IETF Secretariat, Fremont, CA, USA, July 2011.
[22] Goldszmidt, G., Yemini, Y., and Yemini, S. Network Management by Delegation: the MAD Approach. In CASCON First Decade
High Impact Papers (New York, NY, USA, 2010), CASCON 10, ACM,
pp. 7892.
BIBLIOGRAPHY
52
[23] Harrington, D., Presuhn, R., and Wijnen, B. An Architecture

for Describing Simple Network Management Protocol (SNMP) Management Frameworks. RFC 3411 (Standard), Dec. 2002. Updated by RFCs
5343, 5590.
[24] Honkola, J., Laine, H., Brown, R., and Tyrkko, O. Smart-m3
information sharing platform. In The 1st Intl Workshop on Semantic
Interoperability for Smart Spaces (SISS 2010) (June 2010).
[25] Jennings, C., Lowekamp, B. B., Rescorla, E., Baset, S. A.,
and Schulzrinne, H. REsource LOcation And Discovery (RELOAD)
Base Protocol. draft-ietf-p2psip-base (work in progress), Internet Engineering Task Force, July 2011.
[26] Jr., E. P. D., and Nanya, T. An SNMP-based implementation of
the adaptive distributed system-level diagnosis algorithm for LAN fault
management. In NOMS (1996), pp. 530539.
[27] Kim, K., Yoo, S., Mukhtar, H., and Park, S. 6LoWPAN Management Information Base. draft-daniel-lowpan-mib (work in progress),
Apr. 2010.
[28] Koch, F. L., and Westphall, C. B. Decentralized Network Management Using Distributed Artificial Intelligence. J. Netw. Syst. Manage. 9, 4 (Dec. 2001), 375388.
[29] Kooijman, R. Divide and Conquer in Network Management Using
Event-Driven Network Area Agents. Tech. rep., TU Delft, 1995.
nwa
lder, J. Evaluation of the resource re[30] Kuryla, S., and Scho
quirements of SNMP agents on constrained devices. In Proceedings of
the 5th international conference on Autonomous infrastructure, management, and security: managing the dynamics of networks and services
(Berlin, Heidelberg, 2011), AIMS11, Springer-Verlag, pp. 100111.
[31] Kushalnagar, N., Montenegro, G., and Schumacher, C.
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals. RFC 4919 (Informational), Aug. 2007.
[32] Lawton, G. Machine-to-machine technology gears up for growth. Computer 37, 9 (sept. 2004), 12 15.
BIBLIOGRAPHY
53
[33] Lee, B. T., Hendler, J., and Lassila, O. The semantic web.
Scientific American (May 2001).
[34] Levi, D., Meyer, P., and Stewart, B. SNMPv3 Applications.
RFC 2273 (Proposed Standard), Jan. 1998. Obsoleted by RFC 2573.
[35] Li, D. A Proxy for Distributed Hash Table based Machine-to-Machine
Networks. Masters thesis, Aalto School of Science and Technology,
Finland, 2011.
enpa
a
, J., and Bolonio, J. J. Performance of resource location
[36] Ma
and discovery (reload) on mobile phones. In Wireless Communications
and Networking Conference (WCNC), 2010 IEEE (April 2010), pp. 1
6.
[37] Meyer, K., Erlinger, M., Betser, J., Sunshine, C., Goldszmidt, G., and Yemini, Y. Decentralizing Control and Intelligence
in Network Management. In Proceedings of the fourth international symposium on Integrated network management IV (London, UK, UK, 1995),
Chapman & Hall, Ltd., pp. 416.
[38] Montenegro, G., Kushalnagar, N., Hui, J., and Culler, D.
Transmission of IPv6 Packets over IEEE 802.15.4 Networks. RFC 4944
(Proposed Standard), Sept. 2007.
[39] Peng, Y., Wang, W., Hao, Z., and Meng, Y. An SNMP Usage
for RELOAD. draft-peng-p2psip-snmp (work in progress), Mar. 2012.
[40] Rogers, C. M. ANQL - An Active Networks Query Language. Computer Networks 50, 14 (2006), 25642576.
[41] Rose, M. T. The Simple Book: An Introduction to Internet Management, 2nd ed. Prentice Hall, 1994.
[42] Schoenwaelder, J., Mukhtar, H., Yoo, S., and Kim, K. SNMP
Optimizations for Constrained Devices. draft-hamid-6lowpan-snmpoptimizations (work in progress), Apr. 2011.
[43] Schoenwaelder, J., Pras, A., Harvan, M., Schippers, J., and
van de Meent, R. SNMP Traffic Analysis: Approaches, Tools, and
First Results. In Proceedings of the Tenth International Symposium on
Integrated Network Management, Munich, Germany (Piscataway, May
2007), IEEE Computer Society, pp. 324332.
BIBLIOGRAPHY
54
[44] seng Lim, K., Adam, C., and Stadler, R. Decentralizing Network
Management. Tech. rep., Royal Institute of Technology (KTH), Nov.
2005.
[45] Shelby, Z. CoRE Link Format. Tech. Rep. draft-ietf-core-link-format,
IETF Secretariat, Fremont, CA, USA, June 2012.
[46] Shelby, Z., and Bormann, C. 6LoWPAN: The Wireless Embedded
Internet. John Wiley & Sons, Inc, 2010.
[47] Shelby, Z., and Hartke, K. Observing Resources in CoAP. Tech.
Rep. draft-ietf-core-observe, IETF Secretariat, Fremont, CA, USA, Mar.
2011.
[48] Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., and
Balakrishnan, H. Chord: A scalable peer-to-peer lookup service
for internet applications. In Proceedings of the ACM SIGCOMM 01
Conference (San Diego, California, August 2001).
[49] Subramanyan, R., Miguel-Alonso, J., and Fortes, J. A. B. A
scalable SNMP-based distibuted monitoring system for heterogeneous
network computing. In Proceedings of the 2000 ACM/IEEE conference
on Supercomputing (CDROM) (Washington, DC, USA, 2000), Supercomputing 00, IEEE Computer Society.
[50] University of Bologna, and VTT. Java-KPI interface for SmartM3. http://smartm3-javakpi.sourceforge.net.
[51] Urdaneta, G., Pierre, G., and Steen, M. V. A survey of DHT
security techniques. ACM Comput. Surv. 43, 2 (Feb. 2011), 8:18:49.
[52] Waldbusser, S. Remote Network Monitoring Management Information Base. RFC 1271 (Proposed Standard), Nov. 1991. Obsoleted by
RFC 1757, updated by RFC 1513.
[53] Yao, Y., and Gehrke, J. Query Processing for Sensor Networks,
vol. 5. CIDR, 2003, pp. 3030.
[54] Yick, J., Mukherjee, B., and Ghosal, D. Wireless sensor network
survey. Comput. Netw. 52 (August 2008), 22922330.

Nalin Gupta Thesis

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Nalin Gupta Thesis

Transféré par

Droits d'auteur :

Formats disponibles

Aalto University

Management of Decentralized DHT Based

Professor Antti Yla-Jaaski

M2M, hajautettu, verkonhallinta, SNMP, valityspalvelin,

Espoo, May 6, 2012

Abbreviations and Acronyms

3rd Generation Mobile Telecommunications

Abbreviations & Acronyms

3 Decentralized M2M Network Design

4 Decentralized M2M Management

6 Evaluation and Discussion

7 Conclusions and Future Work

Decentralization of M2M Network . . . . . . . . . . . . . . . .

Wireless Sensor Network . . .

Decentralized M2M Network Architecture (P2P4M2M) . . . . 18

P2P4M2M Network Protocol Stack Diagram . . . .

Figure 1.1: Decentralization of M2M Network

challenges. The objective of our research project is to study the challenges

This thesis studies the management of decentralized M2M network using

Chapter 2 describes an overview of the protocols and technologies used in

Wireless Sensor Networks (WSN)

Figure 2.1: Wireless Sensor Network

Machine to Machine (M2M)

Internet of Things (IoT)

Figure 2.2: ZigBee Protocol Stack

ZigBee uses bands including 2.4GHz, 900MHz and 868MHz. It supports

Global IPv6 Internet

Figure 2.3: 6LoWPAN Network

Constrained Application Protocol

Distributed Hash Table (DHT)

Distributed Hash Table (DHT) is a distributed system that provides services

Peer-to-Peer (P2P) Technologies

Peer-to-Peer (P2P) refers to a network where nodes can communicate with

Simple Network Management Protocol

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

Figure 2.4: SNMP Network Management

SNMP protocol uses request-response messaging between two types of

Decentralized M2M Network Design

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

designed, and it takes AI to handle new unforeseen scenarios. Since IoT

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

ZigBee consortium is already aligning themselves to IP 4 , hence we selected

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

network must be able to work without requiring continuous presence of this

Figure 3.1: Decentralized M2M Network Architecture (P2P4M2M)

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

Monitoring and Controlling Node (MCN) : This device provides

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

Local Node (LN)

Proxy Node (PN)

WPAN (e.g. ZigBee)

WPAN (e.g. ZigBee)

WWAN (e.g. 3G)

Can optionally have

Can optionally have

Table 3.1: Device Properties

M2M Communication Enabler Abstraction Layer

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

Figure 3.2: M2MCE Abstraction Layer

are used by WN and PN to register/unregister to the M2M system.

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

Monitoring and Controlling Node

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN

CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN