-
Aalto University
School of Science
Degree Programme of Computer Science and Engineering
Nalin Gupta
Management of Decentralized DHT BasedM2M Network
Masters ThesisEspoo, May 6, 2012
Supervisor: Professor Antti Yla-JaaskiAalto University School of
Science, Finland
Instructor: Jouni Maenpaa M.Sc. (Tech.)Ericsson Research,
Finland
-
Aalto UniversitySchool of ScienceDegree Programme of Computer
Science and Engineering
ABSTRACT OFMASTERS THESIS
Author: Nalin Gupta
Title:Management of Decentralized DHT Based M2M Network
Date: May 6, 2012 Pages: 9+ 54
Professorship: Data Communication Software Code: T-110
Supervisor: Professor Antti Yla-JaaskiAalto University School of
Science, Finland
Instructor: Jouni Maenpaa M.Sc. (Tech.)Ericsson Research,
Finland
Machine-to-Machine (M2M) technology is evolving beyond the
traditional teleme-try use-cases and becoming key enabler for
innovative concepts like Internet-of-Things (IoT), leading to a
whole new set of possible applications. Currently thereare 13
billion connected devices and it is envisioned that by the year
2020, thisnumber will reach 50 billion. We believe that the key to
achieve this massive scal-ability is using peep-to-peer based
decentralized architecture and interoperabilityusing open
standards. Architecturally, the Internet is composed of a
collectionof heterogeneous sub-networks; similarly, we believe that
the next generation ofM2M networks would also consist of
heterogeneous networks joined together usinggateways or proxies,
giving a hierarchical architecture.
Hence, we are conducting research into decentralized
hierarchical Machine-to-Machine (M2M) networks using Internet
Engineering Task Force (IETF) andInstitute of Electrical and
Electronics Engineers (IEEE) aligned protocols. Thedecentralization
is achieved using Distributed Hash Table (DHT) based Peer-to-Peer
(P2P) algorithms. The project involves studying the latest
state-of-the-arttechnologies like IPv6 over Low power Wireless
Personal Area Networks (6LoW-PAN), ZigBee, Constrained Application
Protocol (CoAP), Distributed Hash Ta-ble (DHT), Smart-M3, and
creating a prototype testbed platform of embeddedLinux and ZigBee
devices to carry the experiments and analysis. The focus ofthis
thesis is on how to manage this decentralized hierarchical M2M
network us-ing Simple Network Management Protocol (SNMP). The
central topics studiedare decentralized management, node discovery,
resource discovery, node configu-ration, and proxy
functionality.
Keywords: M2M, Decentralized, Network Management, SNMP,
Proxy,DHT, IoT, Smart-M3, CoAP
Language: English
ii
-
Aalto-yliopistoPerustieteiden korkeakouluTietotekniikan
tutkinto-ohjelma
DIPLOMITYONTIIVISTELMA
Tekija: Nalin Gupta
Tyon nimi:DHT-pohjaisen hajautetun M2M-verkon hallinta
Paivays: 6.5.2012 Sivumaara: 9+ 54
Professuuri: Tietoliikenneohjelmistot Koodi: T-110
Valvoja: Professori Antti Yla-JaaskiAalto-yliopisto,
Perustieteiden korkeakoulu
Ohjaaja: Jouni Maenpaa M.Sc. (Tech.)Oy L M Ericsson Ab
Machine-to-Machine (M2M) -teknologioiden kaytto on laajenemassa
perinteisistatelemetriasovelluksista uusille sovellusalueille.
M2M-teknologiat mahdollistavatjoukon uusia innovatiivisia
ratkaisuja kuten niin sanotun esineiden Internet -ekosysteemin.
Nama ratkaisut puolestaan avaavat mahdollisuuksia uusien
sovel-lusten luomiseen. Talla hetkella markkinoilla on 13 miljardia
Internet-verkkoonkytkettya laitetta. Joidenkin arvioiden mukaan
vuoteen 2020 mennessa naidenlaitteiden maara kasvaa jopa 50
miljardiin. Taman diplomityon lahtokohtanaon, etta keskeisia
tekijoita nain skaalautuvan jarjestelman luomisessa ovat avoi-met
standardit ja vertaisverkkoteknologioihin perustuvat hajautetut
arkkiteh-tuurit. Internetin arkkitehtuuri koostuu joukosta
aliverkkoja. Myos tassa diplo-mityossa lahtokohtana on hierarkkinen
arkkitehtuuri, jossa yhdyskaytava- javalityspalvelimet liittavat
yhteen joukon heterogeenisia M2M-verkkoja. Tahanajatukseen
pohjautuen diplomityon tavoitteena on tutkia hajautettuja
M2M-verkkoja, jotka perustuvat Internet Engineering Task Force
(IETF) ja Institu-te of Electrical and Electronic Engineers (IEEE)
-standardointiorganisaatioidenyhteyskaytantoihin. Tassa
diplomityossa hajautetun arkkitehtuurin toteuttami-seen kaytetaan
Distributed Hash Table (DHT) -ja vertaisverkkoalgoritmeja.Tyossa
tutkitaan myos viimeisimpia teknologioita kuten IPv6 over Low
powerWireless Personal Area Networks (6LoWPAN), ZigBee, Constrained
Applica-tion Protocol (CoAP), DHT ja Smart-M3. Tyohon kuuluu myos
prototyyp-pialustan kehittaminen. Tama alusta koostuu sulautetuista
Linux- ja ZigBee-laitteista. Alustaa kaytetaan kokeiden
suorittamiseen ja jarjestelman analysoin-tiin. Diplomityon
keskeisena tavoitteena on tutkia kuinka hallita hierarkkistaja
hajautettua M2M-verkkoa kayttaen Simple Network Management
Protocol(SNMP) -protokollaa. Tyon keskeisimpia tutkimusaiheita ovat
hajautettu ver-konhallinta, laitteiden loytaminen, resurssien
loytaminen, laitteiden konfigurointija
valityspalvelintoiminnallisuus.
Asiasanat: M2M, hajautettu, verkonhallinta, SNMP,
valityspalvelin,DHT, esineiden Internet, Smart-M3, CoAP
Kieli: Englanti
iii
-
Acknowledgements
I would like to express my sincere gratitude to Professor Antti
Yla-Jaaski forsupervising my thesis and supporting my studies
without which this momentwould not have been possible.
I am deeply grateful to my instructors Jouni Maenpaa and Jani
Hautakorpifor providing me with the opportunity to work in the
prestigious EricssonResearch NomadicLab, and for their guidance,
encouragement and kindnessthroughout the research work.
I would also like to thank my fellow students Jaime Jimenez and
DaoyuanLi for their friendship and support during the thesis.
Espoo, May 6, 2012
Nalin Gupta
iv
-
Abbreviations and Acronyms
3G 3rd Generation Mobile Telecommunications6LoWPAN IPv6 over
Low-power Wireless Personal Area
NetworksACK AcknowledgmentAPI Application Programming
InterfaceAPS Application Support Sub-layerASN.1 Abstract Syntax
Notation OneBSD Berkeley Software DistributionCoAP Constrained
Application ProtocolCoRE Constrained RESTful Environments working
groupDHT Distributed Hash TableDDNS Distributed Domain Name
ServiceDNS Domain Name ServiceEABI Embedded Application Binary
InterfaceGPRS General Packet Radio ServiceGPS Global Positioning
SystemICT Information and Communication TechnologiesIDE Integrated
Development EnvironmentIETF Internet Engineering Task ForceIoT
Internet of ThingsIPC Inter-Process CommunicationJAR Java
ARchiveJSON JavaScript Object NotationLR-WPAN Low-Rate Wireless
Personal NetworkLoWPAN Low-power Wireless Personal NetworkLN Local
Node, less powerful devices without DHT e.g.
ZigBee motesM2M Machine-to-MachineM2MCE Machine-to-Machine
Communication EnablerMCN Monitoring and Controlling Node
v
-
MD5 Message-Digest algorithm 5MIB Managed Information BaseOID
Object IDentifiersOSI Open Systems InterconnectionP2P
Peer-to-PeerP2P4M2M Peer-to-Peer for M2M NetworkPAN Personal Area
NetworkPDU Protocol Data UnitPN Proxy Node for interfacing LNs with
WNQoS Quality of ServiceREST Representational State TransferRFID
Radio-Frequency IDentificationRMI Remote Method InvocationRPC
Remote Procedure CallRTT Round Trip TimeSIB Semantic Information
BrokerSMI Structure of Management InformationSNMP Simple Network
Management ProtocolUDP User Datagram ProtocolURI Universal Resource
IndicatorUSB Universal Serial BusUSM User-based Security ModelVACM
View-based Access Control ModelWAN Wide Area NetworkWN Wide Area
Node, embedded Linux based devices with
DHTWPAN Wireless Personal Area NetworkWSN Wireless Sensor
NetworkWWAN Wireless Wide Area NetworkXML Extensible Markup
LanguageZDO ZigBee Device Object
vi
-
Contents
Abstract ii
Acknowledgements iv
Abbreviations & Acronyms v
List of Figures ix
1 Introduction 11.1 Overview . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . 11.2 Research Objective . . . . . . . . . .
. . . . . . . . . . . . . . 11.3 Thesis Scope . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 31.4 Thesis Organization . . . .
. . . . . . . . . . . . . . . . . . . . 4
2 Background 52.1 Wireless Sensor Networks (WSN) . . . . . . . .
. . . . . . . . 52.2 Machine to Machine (M2M) . . . . . . . . . . .
. . . . . . . . 62.3 Internet of Things (IoT) . . . . . . . . . . .
. . . . . . . . . . 72.4 ZigBee . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . 82.5 6LoWPAN . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 92.6 Constrained Application
Protocol
(CoAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 102.7 Distributed Hash Table (DHT) . . . . . . . . . . . . . . .
. . 102.8 Peer-to-Peer (P2P) Technologies . . . . . . . . . . . . .
. . . . 112.9 Simple Network Management Protocol
(SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 112.10 Smart-M3 . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . 13
3 Decentralized M2M Network Design 153.1 Motivation . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . 153.2 Design
Principles . . . . . . . . . . . . . . . . . . . . . . . . . 16
vii
-
3.3 System Architecture . . . . . . . . . . . . . . . . . . . .
. . . 183.4 Functional Description . . . . . . . . . . . . . . . .
. . . . . . 19
3.4.1 M2M Communication Enabler Abstraction Layer . . . 203.4.2
Monitoring and Controlling Node . . . . . . . . . . . . 223.4.3
Proxy Node . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Smart-M3 System . . . . . . . . . . . . . . . . . . . . . .
. . . 23
4 Decentralized M2M Management 254.1 Challenges in
Decentralization . . . . . . . . . . . . . . . . . 254.2 MCN
Functionality . . . . . . . . . . . . . . . . . . . . . . . . 264.3
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 284.4 P2P4M2M Protocol Stack . . . . . . . . . . . . . . . . . .
. . 284.5 MCN Interfaces . . . . . . . . . . . . . . . . . . . . .
. . . . . 294.6 Scenarios . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 30
4.6.1 Name Resolution . . . . . . . . . . . . . . . . . . . . .
304.6.2 MCN Operation . . . . . . . . . . . . . . . . . . . . . .
314.6.3 LN to WN . . . . . . . . . . . . . . . . . . . . . . . . .
324.6.4 WN to LN . . . . . . . . . . . . . . . . . . . . . . . . .
34
5 Prototype Implementation 365.1 Hardware Specification . . . .
. . . . . . . . . . . . . . . . . . 36
5.1.1 LN Hardware . . . . . . . . . . . . . . . . . . . . . . .
365.1.2 PN Hardware . . . . . . . . . . . . . . . . . . . . . . .
385.1.3 WN Hardware . . . . . . . . . . . . . . . . . . . . . . .
395.1.4 MCN Hardware . . . . . . . . . . . . . . . . . . . . . .
39
5.2 Software Specification . . . . . . . . . . . . . . . . . . .
. . . 395.3 Software Structure . . . . . . . . . . . . . . . . . .
. . . . . . 42
5.3.1 M2M System Startup . . . . . . . . . . . . . . . . . . .
43
6 Evaluation and Discussion 45
7 Conclusions and Future Work 487.1 Future work . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 49
Bibliography 50
viii
-
List of Figures
1.1 Decentralization of M2M Network . . . . . . . . . . . . . .
. . 2
2.1 Wireless Sensor Network . . . . . . . . . . . . . . . . . .
. . . 62.2 ZigBee Protocol Stack . . . . . . . . . . . . . . . . .
. . . . . 82.3 6LoWPAN Network . . . . . . . . . . . . . . . . . .
. . . . . . 92.4 SNMP Network Management . . . . . . . . . . . . .
. . . . . 12
3.1 Decentralized M2M Network Architecture (P2P4M2M) . . . .
183.2 M2MCE Abstraction Layer . . . . . . . . . . . . . . . . . . .
213.3 Smart-M3 System . . . . . . . . . . . . . . . . . . . . . . .
. 24
4.1 P2P4M2M Network Protocol Stack Diagram . . . . . . . . . .
284.2 Command Line Interface . . . . . . . . . . . . . . . . . . .
. . 294.3 Message Sequence for Name Resolution . . . . . . . . . .
. . . 314.4 MCN sets association between sensor and actuator . . .
. . . 324.5 Information from LN towards WN . . . . . . . . . . . .
. . . . 334.6 Information from WN towards LN . . . . . . . . . . .
. . . . . 34
5.1 Local Node . . . . . . . . . . . . . . . . . . . . . . . . .
. . . 375.2 Proxy Node . . . . . . . . . . . . . . . . . . . . . .
. . . . . . 385.3 Lab Setup . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . 405.4 Software Architecture of PN . . . . . . . .
. . . . . . . . . . . 43
ix
-
Chapter 1
Introduction
1.1 Overview
Machine-to-Machine (M2M) technology gained roots in early 2000s,
pow-ered by the ubiquitous wireless cellular connectivity. Today it
is evolvingbeyond the telemetry applications and becoming cardinal
enabler for inno-vative concepts like Internet-of-Things (IoT),
leading to a whole new setof possible applications. Currently there
are 13 billion connected devicesand it is envisioned that by the
year 2020, this number will reach 50 bil-lion [18]. We believe that
the key to achieve this level of massive scalabilityis using
Peer-to-Peer (P2P) based decentralized architecture and
interoper-ability using open standards. Architecturally, the
Internet is composed ofheterogeneous sub-networks, similarly, we
believe that the next generationof M2M networks would also consist
of collection of heterogeneous subnetsjoined together using
gateways or proxies, giving a hierarchical structure.Hence, we are
conducting research into scalable decentralized hierarchicalM2M
networks using IETF and IEEE aligned open standards and
protocols.The decentralization is achieved using Distributed Hash
Table (DHT) basedP2P algorithms. The project involves studying the
latest state-of-the-arttechnologies like 6LoWPAN, ZigBee, CoAP,
Smart-M3, and creating a pro-totype testbed platform of embedded
Linux and ZigBee devices to carry theexperiments and analysis.
1.2 Research Objective
The current M2M and Wireless Sensor Network (WSN) networks use
cen-tralized approaches. The WSNs use sensors to collect
information about itsenvironment and relay it to central location,
where the data is processed.
1
-
CHAPTER 1. INTRODUCTION 2
Centralized
= Sensor = Actuator
Figure 1.1: Decentralization of M2M Network
M2M networks use embedded devices for remote monitoring and
manage-ment from central locations. In both the cases, the
intelligence and decisionmaking is done using centralized
entities.
However, the centralized approaches have several challenges
which donot lend themselves to the envisioned use-cases for M2M and
IoT. Three keyissues are:
scalability to the order of millions of nodes distribution of
intelligence among nodes (more details about this in
Section 2)
tolerate failure of parts-of-networks (centralized entities have
singlepoint of failure for entire network)
Our aim is to solve the above challenges by decentralizing the
M2M net-works using DHT-based P2P mechanisms and creating a P2P4M2M
net-work. Chapter 3 Section 3.1 describes details on how P2P
addresses these
-
CHAPTER 1. INTRODUCTION 3
challenges. The objective of our research project is to study
the challengesin the decentralization of M2M networks. The research
project is dividedinto three Masters thesis - (1) Adapting DHT for
M2M network require-ments [11] (2) Using proxy to connect ZigBee
based Wireless Personal AreaNetwork (WPAN) to the M2M network [35]
(3) Using SNMP in decentralizedmanner to manage the M2M network
(this thesis).
In tune with the IETF approach of have running code 1,
developing aprototype testbed is an important part of this research
project. This testbedplatform will then be used for further
research on the overall topic of decen-tralizing M2M networks.
During the remaining of this thesis, we shall use the term
P2P4M2Mresearch project to refer to the overall research project in
which this thesiswas done.
1.3 Thesis Scope
This thesis studies the management of decentralized M2M network
usingopen standards. The main topics that are studied are
decentralized man-agement, node discovery, resource discovery, node
configuration, and proxyfunctionality.
The following specific objectives defines the scope of this
thesis:
1. Develop network management software for decentralized M2M
networkand a Managing and Controlling Node (MCN) that provides
humaninterface
2. Make the M2M network self-reliant i.e. the M2M network should
beable to operate normally even when MCN is disconnected
3. The software should have gateway or proxy module that allows
man-agement of ZigBee based sub-network
4. The software should allow information interoperability using
Smart-M3semantic web platform, enabling web applications to
interact with thedecentralized M2M system
The DHT implementation and the ZigBee Proxy module
implementationis out of scope of this thesis. The contribution of
this thesis is listed in detailin the Chapter 6.
1http://www.ietf.org/tao.html
-
CHAPTER 1. INTRODUCTION 4
This thesis is part of work package for Devices and
Interoperability Ecosys-tem (DIEM) 2 program funded by TEKES 3 -
the Finnish Funding Agencyfor Technology and Innovation. The
P2P4M2M research project in whichthis thesis was done also involves
close collaboration with the Future Inter-net program, which is
part of ICT cluster of the Finnish Strategic Centresfor Science,
Technology and Innovation (ICT SHOK) 4. Inline with the ob-jectives
of these research programs, interoperability and future Internet
arekey aspects of our P2P4M2M research project. This explains the
emphasisof the research project on CoAP, IP, SNMP and IEEE 802.15.4
technologies.
1.4 Thesis Organization
Chapter 2 describes an overview of the protocols and
technologies used inthe prototype, which would provide useful
background for understanding thisthesis. It is followed by Chapter
3 which describes the design principles usedfor the prototype, its
system architecture and functionality. Next, Chapter 4covers the
challenges and solutions for decentralized management of the
M2Mnetwork.
The hardware and software specifications for the prototype
implementa-tion are given in Chapter 5. It also covers the software
architecture of theprototype and the system startup details. Then,
in Chapter 6, we discuss andevaluate the learnings from this
project. In Chapter 7, the learnings fromthis project are summed up
and useful take-away conclusions are presented.Finally, we mention
the research work that will be carried out in future usingthe
testbed developed under the scope of this project.
2http://www.diem.fi3http://http://www.tekes.fi4http://www.futureinternet.fi
-
Chapter 2
Background
Our research involves numerous technologies and protocols. In
this chapterwe give a brief overview of them.
2.1 Wireless Sensor Networks (WSN)
Wireless Sensor Networks (WSN) have come a long way from their
beginningin University research, and have laid the foundation for
latest concepts likeIoT. As shown in Figure 2.1, WSN consists of a
collection of sensing andactuating devices, commonly called as
motes, and gateway nodes. The motesare typically battery powered
embedded devices which are resource limitedin terms of
computational power. Also their wireless connectivity has
shortrange. The gateway nodes, however, have higher configuration
in terms ofhardware and wireless range, which enables them to
communicate with basestation.
WSN operates with nominal or no infrastructure support. Due to
lackof infrastructure support and resource constrained nature of
devices, thetraditional networking protocols are not suitable for
WSN. Wireless meshnetworking is one of the most common technique to
overcome the disad-vantages of short range connectivity. Due to the
academic parentage, mostof WSN research produced proprietary
solutions and lacked interoperability.IEEE 802.15.4 is the first
open standard for low power radio that got globalacceptance. Then
based on IEEE 802.15.4, ZigBee became one of the firststandards to
gain commercial interest. WSN is mainly used for tracking
andmonitoring use-cases [54].
The concepts of WSN, M2M IoT, ZigBee and 6LoWPAN are
inter-twingedand the boundary between them is not sharp. We will
point out the dis-tinguishing characteristics of each of these
technologies in their respective
5
-
CHAPTER 2. BACKGROUND 6
SensorMote
GatewayMote
Figure 2.1: Wireless Sensor Network
sections.
2.2 Machine to Machine (M2M)
The success and ubiquity of wireless cellular modems enabled M2M
to gainmarket breakthrough for telemetry and remote management
use-cases likemanaging vending machines [46]. The observation that
the value of machinesincreases tremendously when they are networked
with one another [32], hasled to a fast growing interest in M2M
domain. However, there is no clearlyagreed upon definition for the
term M2M. Two good definitions are as follows:
M2M consists of machines and backend services that are used for
remotemonitoring and controlling of devices. The devices typically
have longrange wired or wireless capabilities, and most often they
use cellularmodems for wireless connectivity.
M2M is a system where machines exchange information and run
thesystem with little or no human intervention
M2M has created possibilities of new unforeseen business
ventures. M2Mis making devices smarter and the world more
efficient. Examples include
-
CHAPTER 2. BACKGROUND 7
intelligent supply chain management and smart utility metering.
The tech-nologies to enable M2M are already available and the key
challenges for M2Mare integrating these technologies and creating
global standards. ETSI haslaunched the M2M Technical Committee 1 to
meet these challenges.
WSNs enable M2M but an important difference between WSN and
M2Mis that WSN domain deals with the challenges for networking
resource con-strained devices with short range low power wireless
connectivity. In con-trast, M2M devices typically have cellular
based wide area connectivity andas such, the M2M domain is more
concerned with standardization and cre-ating service platforms.
Also, M2M devices need not always have sensors oractuators.
2.3 Internet of Things (IoT)
The term Internet of Things (IoT) was originally coined by Kevin
Ashton [8]to use Radio-frequency identification (RFID) technology
with Internet. Sincethen, the term IoT has expanded in its scope
and now it refers to the networkof embedded devices (also called
smart objects) with native IPv6 capabilitiesthat are connected to
the global Internet. A significant characteristics ofIoT is that
its scale is expected to be of the order of trillions [46]. The
IoTInitiative (IoT-i) program has come up with a set of futuristic
and ambitioususe-cases for IoT 2.
IETF has three work groups relevant for IoT wireless smart
objects:
Constrained RESTful Environments (CoRE) [2] IPv6 over low power
wireless area networks (6LoWPAN) [1] Routing Over Low-power and
Lossy Networks (ROLL) [3]IETF encourages wireless smart objects to
use IEEE 802.15.4, so it has
created 6LoWPAN group to adapt IPv6 for IEEE 802.15.4. Together
withROLL and CoRE, 6LoWPAN specifies a complete system to connect
wirelessdevices to Internet.
IoT is closely related to M2M, with the chief distinguishing
attributebeing that, unlike M2M devices, the IoT devices must be
IP-enabled andconnected to the global Internet. Internet
connectivity for embedded devicesopens a huge range of possible
applications, but also brings new challengesin the field of
security.
1http://www.etsi.org/website/technologies/m2m.aspx2http://www.iot-i.eu
-
CHAPTER 2. BACKGROUND 8
2.4 ZigBee
ZigBee protocol suit is created by an industry consortium called
ZigBee Al-liance. It builds upon IEEE 802.15.4 to cover the
complete vertical protocolstack by adding networking support,
security, and service discovery. Zig-Bee application profiles which
ensure that the manufacturers products areinteroperable at
application level. Figure 2.2 3 shows the ZigBee protocolstack.
Figure 2.2: ZigBee Protocol Stack
ZigBee uses bands including 2.4GHz, 900MHz and 868MHz. It
supportsboth short range and long range wireless connectivity using
IEEE 802.15.4and cellular modems, respectively. Hence, ZigBee
devices can be used forboth, WSN and M2M domain.
Unlike 6LoWPAN, ZigBee does not have IP connectivity, though it
in-tends to do so in near future 4. Another difference between
6LoWPAN and
3http://i.cmpnet.com/eetimes.fr/news/2008/zigbee_stack_4.gif4http://zigbee.org/imwp/idms/popups/pop_download.asp?contentID=
15754
-
CHAPTER 2. BACKGROUND 9
ZigBee is that 6LoWPAN does not specify application level
profiles like Zig-Bee.
2.5 6LoWPAN
IETF has created 6LoWPAN working group [1] to define the
specifications forLow-power wireless personal area networks
(LoWPANs) consisting of IEEE802.15.4 devices. 6LoWPAN creates a
thin layer over IEEE 802.15.4 to adaptit for IPv6. RFC 4919 [31]
gives its objective and problem statement and RFC4944 [38]
specifies the 6LoWPAN protocol. Figure 2.3 shows a
6LoWPANNetwork.
Global IPv6 InternetNode
Edge Router
LoWPAN
Figure 2.3: 6LoWPAN Network
6LoWPAN devices are suitable for a WSN domain. Additionally,
6LoW-PAN devices can participate in IoT, courtesy edge routers,
which transpar-ently provide native IPv6 based access to Internet.
Reference [14] is a goodcase study for using 6LoWPAN devices for
IoT.
-
CHAPTER 2. BACKGROUND 10
2.6 Constrained Application Protocol
(CoAP)
Constrained Application Protocol (CoAP) is web protocol that has
been cre-ated with the objective of applying Representational State
Transfer (REST)architecture [19] to the M2M domain. The industry
standard protocol forREST is HTTP. However, HTTP is ill suitable
for M2M due to the con-strained environment of M2M. Hence, HTTP is
customized for M2M in theform of CoAP by defining smaller messages
with simpler parsing. CoAP usesasynchronous messaging over
connectionless transport protocol with request-response messaging
model. CoAP is specified in the IETF drafts [21], [45],and [47]. It
includes a resource discovery mechanism which is critical forM2M
communication.
CoAP can be used in WSN domain as well as M2M domain. It
enablesembedded devices to be part of IoT, thanks to its full
compatibility withHTTP.
2.7 Distributed Hash Table (DHT)
Distributed Hash Table (DHT) is a distributed system that
provides servicesto store and retrieve data using a (key,value)
pair. DHT has a simple interface- it returns a unique key when the
data is stored; this key can then later beused to retrieve the
data. The mapping from key to value and the valueitself is stored
among nodes in a distributed manner. Typically, the data
isreplicated on separate nodes to accommodate node failures or
nodes leavingDHT system. Caching is used to improve system
performance.
DHT are very sophisticated data structures that have
revolutionized dis-tributed networks. In 2001, [9] listed the first
significant set of DHT algo-rithms namely- CAN, Chord, Pastry, and
Tapestry - which bootstrapped theDHT research field.
The key DHT challenges are optimizing store/retrieve operations,
faulttolerance, handling concurrent changes, malicious nodes and
indexing [9].Reference [51] describes the security challenges for
DHT systems.
DHT algorithms have been used for creating advanced network
topologiesand lookup services and they are fundamental for creating
P2P networks.They can also be used for distributed storage
applications that stores anyarbitrary data in a network. As an
example Hazelcast [4] uses DHT to createa data distribution
platform.
-
CHAPTER 2. BACKGROUND 11
2.8 Peer-to-Peer (P2P) Technologies
Peer-to-Peer (P2P) refers to a network where nodes can
communicate witheach other without requiring any central entity to
coordinate. This conceptis in contrast to the client/server
architecture. The distinguishing character-istics of P2P are
decentralized network, autonomous nodes and combinationof client
and server functionality in all nodes [20]. In P2P, all nodes
haveequal control in network and every nodes shares its resources
in terms ofstorage, network bandwidth, and CPU cycles.
Although P2P systems have been around for sometime time, it is
therecent advancements in distributed computing techniques, like
DHT basedapproaches, that have sparked vigour in the P2P
domain.
2.9 Simple Network Management Protocol
(SNMP)
The main tasks of network management can be categorized as
follows [10]:
Monitoring the network, services and managing faults
Administration, consisting of housekeeping activities like keeping
track
of devices and other resources in the network.
Maintaining the network software and hardware Provisioning the
system, which involves configuring the devices
SNMP is the IEFT recommended standard for handling these tasks.
TheSNMP network management has three components:
The SNMP protocol: It defines the operations performed by
ProtocolData Units (PDUs) and their message formats.
Management Information Base (MIB) - It is the collection of
variablesthat are monitored and controlled on managed devices. The
variablesare identified using Object IDentifiers (OID) in an
extensible hierarchi-cal namespace.
Structure of Management Information (SMI) - It defines the
subset ofAbstract Syntax Notation One (ASN.1) rules which are used
to defineMIB variables.
-
CHAPTER 2. BACKGROUND 12
Manager- NMS- No MIB
Managed Devices / Agent- MIB
SNMP PDUs(Agent to Manager)- Response- Trap- InformRequest
SNMP PDUs (from Manager to Agent)- GetRequest- SetRequest-
GetNextRequest- GetBulkRequest
Figure 2.4: SNMP Network Management
SNMP protocol uses request-response messaging between two types
ofentities - Managers and Agents. SNMP Managers are typically
separatecomputers which are used to monitor and control the Agents.
They alsohost Network Management System (NMS) software, though NMS
is not cov-ered by SNMP specifications. SNMP Agents are the managed
devices whichimplement MIB.
SNMP protocol uses the following message types:
These messages are sent from Manger to Agent GetRequest. It is
used to retrieve the value of a single or possibly
list of variable(s).
SetRequest. It is used to configure the value of a single or
possiblylist of variable(s).
GetNextRequest. It is used to discover variables and their
values.
-
CHAPTER 2. BACKGROUND 13
GetBulkRequest. This was added in SNMPv2 to discover vari-ables
with higher efficiency.
InformRequest. It is asynchronous notification message used
forManager to Manager communication. It can also be used forAgent
to Manager communication.
These messages are sent from Agent to Manager Response. It
carriers the values of variables for all the Manager
initiated messages.
Trap. It also carriers the values of variables with the
differencethat it is initiated by Agent. It is used by Agent for
asynchronousnotifications.
There are multiple versions of SNMP, but practically only 3
versions areused - SNMPv1 (RFC 1157 [12]), SNMPv2c (RFC 1901 [13]),
and SNMPv3(RFC 3411 [23]). Research in [43] concluded that SMNP is
most commonlyused for monitoring and not for configuring the
network and devices. Also,the market penetration of SNMPv3 is not
deep.
There has been a lot of interesting research work for
decentralizationusing SNMP, for example [26] and [39]. However, the
hierarchical tree struc-ture remains as the most popular
decentralization mechanism with currentgeneration of NMS, which
makes these approaches different from our work.
2.10 Smart-M3
Smart-M3 system is an information sharing platform for
interoperability be-tween vendor, device and domain [24]. It uses
blackboard architecture modelto allow cross-domain devices to share
information about their local envi-ronment. The resources in a
device are described in Resource DescriptionFramework (RDF)
representation using Web Ontology Language (OWL) 5.Open source
implementation of Smart-M3 platform is available under BSDlicense
6.
In essence, Smart-M3 provides a Semantic Web platform, very
similar tothe idea of Tim Berners-Lee described in [33]. The
biggest difference is thatthe information in Smart-M3 smart space
is local in nature and changes moredynamically than that in the
Internet level global smart space.
Smart-M3 consists of the following components:
5http://www.w3.org/standards/techs/owl6http://smart-m3.sourceforge.net
-
CHAPTER 2. BACKGROUND 14
Smart-M3 Space. It is a named searchable area of information in
Smart-M3 platform, commonly called Smart Space.
Smart-M3 Semantic Information Broker (SIB). It is a physical or
virtualentity which stores the information in Smart-M3 Space.
Knowledge Process (KP). It is Smart-M3 agent sitting on a
devicewhich is responsible for interactions with the Smart-M3 SIB
like in-serting, reading or removing information.
Smart Space Access Protocol (SSAP). It is the session-based
protocolused by KPs to access the information available in SIB. It
providesseven operations - join, leave, insert, remove, update,
query, subscribe,unsubscribe. The exchanged data is encoded in XML
or JASON.
We use Smart-M3 platform to study the integration of
decentralized M2Mnetwork with Semantic Web 7.
7http://www.w3.org/standards/semanticweb
-
Chapter 3
Decentralized M2M Network De-sign
In this chapter we describe the motivation for decentralizing
M2M networksusing P2P, followed by the principles used for
designing the M2M networkarchitecture. Then an overview of the
network architecture is presented, andfinally a description of the
three most important functional entities in thenetwork is
given.
3.1 Motivation
In Section 1.2 we mention that the centralized systems suffer
from scalabilityissues and difficulty in distributing intelligence
in network. In this section weelaborate on the need to distribute
intelligence in M2M networks, and howP2P effectively solves the
scalability issue of M2M networks.
The current technology trend is that the intelligence is moving
towardsthe edge of network, for example in the cellular systems,
Base TransreceiverStations (BTS) have evolved into intelligent
NodeB. The intelligent devicescan interact with other devices to
share information, and then use the localinformation to make
decision by itself without requiring any central entitiesto issue
commands. We believe that intelligent devices with Artificial
In-telligence (AI) is key for success of concepts like IoT.
Consider one of theproposed use-cases for IoT 1: there is an
accident on road, which causes thealarm clock to start ringing 30
minutes before set-time to enable the personto reach office on
time. Another use-case is handling traffic light signalingand speed
limits according to traffic patterns and weather conditions.
How-ever, most software can only handle the scenarios for which it
was explicitly
1http://ws4d.e-technik.uni-rostock.de/pipesbox
15
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 16
designed, and it takes AI to handle new unforeseen scenarios.
Since IoTuse-cases involve using complex set of information to
handle unforeseen sce-narios, AI is critical for IoT success. Even
though gaming industry have beenusing AI since a long time, it is
Apple Siri application 2 which has broughtAI to mainstream masses
for the first time since more than four decades ofComputer Science.
P2P technologies enable distribution of intelligence inthe network,
hence it is well suited for integrating AI with M2M networks.This
is an exciting research area, however, AI and its integration with
M2Mnetworks is out of scope for this thesis, and we focus on using
P2P for M2Mcommunication.
Additionally, peer-to-peer technologies can be used effectively
to achieveInternet level of scalability. For example, consider a
centralized networkconsisting of 100000 nodes. Now if another 1000
nodes have to join thenetwork, it would require additional
resources from the centralized entitiesputting additional load, and
the system can easily be saturated. In contrast,in a peer-to-peer
based system, each new node joining the network pools itsown
resources towards the network system thereby allowing higher
scalability.BitTorrent is a very good example to illustrate the
concept. In a BitTorrentsystem, a machine originally hosting a file
needs to transfer the segments ofthe file only once, and all the
other peer machines can get a copy of the file byexchanging the
segments among themselves. This way each machine which isa part of
the peer-to-peer system shares its resources - computational,
storageand network bandwidth - with the whole system allowing even
distributionof load, and hence allowing system to scale easily.
3.2 Design Principles
In this section we outline the design principles along with a
brief motivationfor making these design choices.
IEEE 802.15.4 3 has emerged as the undisputed leader in low
power radiotechnology [46]. It is used in most of the M2M
specifications like 6LoW-PAN [38], ZigBee, ISA100.11a [5], and
WirelessHART [6]. The networkformed by IEEE 802.15.4 devices is
typically referred to as Wireless Per-sonal Area Network (WPAN). We
considered among ZigBee and 6LoWPANdevices for our prototype
testbed. The 6LoWPAN devices have native IPsupport, hence they are
a good candidate, however, 6LoWPAN devices werenot easily available
at the time of writing this thesis and they were more ex-pensive.
On the other hand, ZigBee devices are easily available, and
moreover
2http://www.apple.com/iphone/features/siri.html3http://www.ieee802.org/15/pub/TG4.html
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 17
ZigBee consortium is already aligning themselves to IP 4, hence
we selectedZigBee devices for WPAN.
Internet is a huge success story and two factors have been
critical to itsmass adoption - interoperability based on open
standards and connectingvastly heterogeneous networks by allowing
flexibility on the physical layertechnologies. We believe that
these two factors will also be very importantfor the success of
next generation M2M networks. In specific, IP capabilitywill be
crucial since it will enable the embedded devices to easily
integratewith the existing Internet infrastructure. To study
connecting heterogeneousnetworks, connecting IP enabled M2M network
with ZigBee network is oneof the important aspects of P2P4M2M
research project.
The objective of P2P4M2M research project is to decentralize M2M
net-works using P2P technologies. We have chosen RELOAD protocol
[48], whichis a DHT based P2P protocol, to form the decentralized
distributed system.It is known that currently it is infeasible to
execute DHT implementationson low resource embedded devices [36],
hence, the ZigBee motes do not useP2P technologies. We have chosen
Linux based microcontroller boards forhosting Chord protocol.
Another interesting aspect is the range of communication. We are
in-terested in both, local communication between devices (for
example, homeappliances talking with smart energy metering) and
long distance commu-nication (for example, a user checking the
status of home appliances fromoffice). The IoT Initiative (IoT-i)
program 5 has defined 60 potential use-cases for IoT and in several
cases the devices are spread over large physicaldistance. Low
powered radio technology like ZigBee enable local communi-cation,
but for long distance we need wireless cellular technologies.
Hence,we have decided to use 3G connectivity for the devices that
are connectedusing P2P. Cellular based M2M devices have the benefit
of easier installationand enabling higher mobility and bandwidth
6.
Additionally, cellular based embedded devices can also nicely
work asGateway devices to connect the WPAN formed by low powered
ZigBee de-vices. The resulting hierarchical structure adds to the
scalability of the sys-tem and allows the possibilities of
interoperating with heterogeneous tech-nologies through Gateway
(since the WPAN could be 6LoWPAN or someother technology).
A monitoring and controlling entity is required in the M2M
network toprovide interface to humans. Since we want the network to
be self-reliant, the
4https://docs.zigbee.org/zigbee-docs/dcn/09-5003.pdf5http://www.iot-i.eu6http://www.etsi.org/Website/Technologies/M2M.aspx
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 18
network must be able to work without requiring continuous
presence of thisentity. Also, keeping in-line with the
decentralization goal, the managementfunction should be spread over
the devices in the network. Hence, all theM2M devices will host
management software.
Summing up the above design principles leads to the system
architecturedesign as shown in Figure 3.1 in next section.
3.3 System Architecture
LN- ZigBee
WN-WWAN-P2P
PN-WWAN-P2P-ZigBee
LN- ZigBee
WN-WWAN-P2P
Monitor/ControlApplicationMonitoring &Controlling
WWAN
WPAN
= Sensor = Actuator
P2P Network
Figure 3.1: Decentralized M2M Network Architecture (P2P4M2M)
The system architecture for our prototype is shown in Figure
3.1. Hence-forth, we will use the term P2P4M2M to refer to this
particular decentralizedM2M network architecture. There are 4
distinct types of nodes in P2P4M2Mnetwork and they have been termed
individually for easy reference. All the4 nodes differ in their
hardware and functionality.
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 19
Monitoring and Controlling Node (MCN) : This device
provideshuman interface to the P2P4M2M network and it is used to
configurethe nodes and P2P system. It will not have any sensors or
actuators.It can be a laptop, tablet or smart-phone possibly
running a GUI. Inour prototype, we have used a laptop. As explained
later, MCN usesSNMP protocol for network management.
Wide Area Node (WN) : This device forms part of the P2P over-lay
using the DHT based implementation. It uses 3G wireless
cellularconnectivity and since these devices can communicate over
large dis-tances, the collection of these devices is called
Wireless Wide AreaNetwork (WWAN). A WWAN can have both sensors and
actuators,and it uses CoAP for M2M communication.
Local Node (LN) : This device is cheaper, but at the same time
ahighly constrained device with limited processing, storage and
shortrange radio connectivity. It cannot host DHT based P2P
implementa-tion, but thanks to the Proxy Node functionality, it
still participatesin the P2P overlay. It can have both sensors and
actuators. In ourprototype, ZigBee devices are used as LNs.
Proxy Node (PN) : This device is same as WN with the addition
thatit also performs the Gateway and Proxy functionality for the
LNs. Ithas an attached ZigBee Coordinator device which enables it
to handleWPAN management and provide messaging interface to the
LNs. Itis also responsible for the protocol conversion for CoAP and
SNMPmessages into ZigBee protocol (and vice-versa).
Since WNs can have sensors and actuators, they only differ from
ZigBeedevices in terms of their ability to host DHT implementation
and IP connec-tivity. So WN represents the next generation M2M
embedded devices, whenthe advancements in P2P algorithms and
hardware capabilities will allowthese devices to host DHT. Hence
without loss of generality or flexibility,this system architecture
represents a decentralized M2M network.
The table 3.1 captures the important properties of all the four
types ofM2M devices.
3.4 Functional Description
The following three functional entities have been researched and
developedin the overall scope of the P2P4M2M research project.
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 20
Local Node (LN)
WPAN (e.g. ZigBee)
No DHT Moderate hardware
(e.g. 8kB RAM) Simple OS (e.g.
TinyOS or Arduino Platform)
Either S or A
Cheap
Proxy Node (PN)
WPAN (e.g. ZigBee) WWAN (e.g. 3G) DHT Advanced hardware
(e.g. 256 MB RAM) Advanced OS (e.g.
Linux)
Can optionally have either S, A, or both
Costlier
Wide-area Node (WN)
WWAN (e.g. 3G)
DHT Advanced hardware
(e.g. 256 MB RAM) Advanced OS (e.g.
Linux)
Can optionally have either S, A, or both
Costlier
Monitoring & Controlling Node
(MCN)
WWAN or fixed access
DHT Normal PC
hardware, Tablet Desktop OS (e.g.
Windows)
S/A-WWAN-DHT
Proxy S/A-WWAN-DHT-ZigBee
Cheap S- ZigBee
Monitor/ControlApplication
S = SensorA = Actuator
Table 3.1: Device Properties
3.4.1 M2M Communication Enabler Abstraction Layer
We have used OSI layering principles to separate the system
functionality intohierarchical layers, where each layer provides
well defined APIs for higherlayers. Now, DHT algorithm by
themselves only provides the ability tostore and retrieve a
key-value pair. To develop a decentralized M2M systemusing DHT, we
needed to create an abstraction layer - which we termedas M2M
Communication Enabler (M2MCE) - on top of DHT, which hidesthe
distributed nature of information storage and provides an API to
accessinformation as if the information was stored on the local
node itself (hence theAPIs are implemented as synchronous function
calls and not as asynchronousmessage passing or callback
functions). In addition, M2MCE also providesAPIs to enable
messaging using the P2P overlay, and accessing the
logicalpredecessor/successor nodes of P2P (Chord based)
overlay.
The M2MCE layer provides the following functions:-
APIs which allow nodes to join and leave the P2P overlay. These
APIs
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 21
MCN / CoAP / PN
DHT
OS
MCN / CoAP / PN
DHT
OS
MCN / CoAP / PN
DHT
OS
...
M2MCE Layer
M2MCEhides
distributedarchitecture
Figure 3.2: M2MCE Abstraction Layer
are used by WN and PN to register/unregister to the M2M
system.LNs do not directly use these APIs, but PN does it on their
behalf.
Interface for distributed data storage, which internally builds
upon theunderlying DHT algorithm. Typically, the data is stored
over severalpeers and it is ensured that there is no loss of data
even if some peersleave the system. This distributed storage can
also be used to storenetwork alarms, traps etc.
Since all the nodes register to P2P4M2M using M2MCE, it can
easilymaintain a log of all the nodes in the network using the
distributedstorage. This gives an easy node discovery
mechanism.
Distributed DNS functionality. As such, the M2M system is about
ma-chines communicating with machines and hence do not need a
humanreadable name. However, humans need to interact with the
system forprovisioning and maintenance, so having human
understandable names
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 22
for devices is required. Also, these names are used in CoAP
URIs. Ad-ditionally, the notion of name helps decouple identity and
location formobile nodes avoiding the well known issue with
IPv4.
M2MCE allows broadcast messaging service in the P2P4M2M
network,using the Chord overlay. There can be different techniques
used tobroadcast message, but these methods are transparent for the
higherlayer (above M2MCE). It is a research agenda for M2MCE to
find themost efficient method for broadcasting.
Detailed description of M2MCE is beyond the scope of this
thesis, butthe complete details can be found in [11].
3.4.2 Monitoring and Controlling Node
Since MCN is part of the focus area of this thesis, it is
covered in-depth inthe chapter 4.
3.4.3 Proxy Node
The proxy node performs the following functions:-
The WWAN uses SNMP and CoAP protocols, whereas the WPAN
usesZigBee protocols. Hence, PN does the protocol conversion from
SNMPand CoAP to ZigBee. A few messages have direct mapping
betweenthe protocols (like the SNMP MIB to trigger detaching a LN
is directlymapped to ZigBee ZDO message ZDO CLUSTER MGMT
LEAVEREQUEST), and the other messages are sent to LNs using
Type-Length-Value (TLV) format. PN also interfaces with the CoAP
proxyand SNMP proxy as per their respective specifications
PN is responsible for the ZigBee WPAN management, including
nodediscovery and service discovery. After the PN starts, it
enables theZigBee coordinator node (which is part of PN). Whenever
a LN joins(or leaves) the WPAN, it inform the ZigBee coordinator
node, whichfurther informs the PN. In this way, the PN keeps track
of all the LNsthat are part of the WPAN. ZigBee coordinator node
uses a timer basedheartbeat mechanism to discover any LN that
leaves WPAN withoutinforming, for example due to failure. PN uses
ZigBee protocol todiscover the services hosted by LNs.
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 23
When the LNs join the WPAN, the PN assigns them a name using
thewell known dot notation, for example, if the PN name is PN100,
thenit can assign LN names like PN100.LN1, PN100.LN2, PN100.LN.
ThenPN uses M2MCE interface to join the P2P overlay on behalf of
eachLN. Hence, PN represents LNs in P2P overlay, provides an
abstractionto the other peer nodes such that the LNs appear as a
full-fledged peer.In a way, we can think of LNs as pseudo-peers.
Similarly, when a LNleaves WPAN, PN performs leave operation on DHT
on behalf of thedeparting LN.
LNs are front-ended by PN, and M2MCE layer translates a LN
name(like PN100.LN1) into the IP address of the PN (since LN can
haveonly ZigBee address). So for any messages exchanged between
WWANand WPAN, PN does the translation between IP adress and
ZigBeedevice address.
PN caches sensor data. This is especially useful for the
sleeping sensordevices, which periodically wake up and send data to
the PN. PN thencaches this data and uses it to handle any future
request. PN can alsouse P2P overlay to cache the data if
required.
PN can potentially provide firewall functionality to secure
WPAN, how-ever this is left as future work.
Detailed description of PN is beyond the scope of this thesis,
but thecomplete details can be found in [35].
3.5 Smart-M3 System
Smart-M3 system is an information sharing platform for
interoperability be-tween vendor, device and domain [24]. We used
Smart-M3 platform to studyintegration of P2P4M2M with Semantic Web
7.
The Figure 3.3 shows the Smart-M3 system which is used for
sharingthe information in M2M network, for example the sensor
values. All thenetwork nodes in P2P4M2M have a Smart-M3 Knowledge
Process (KP) [24]which is responsible for interacting with the
Smart-M3 platform. The LN arerepresented in the Smart-M3 system by
PN, and the KP in PN is responsiblefor interoperating between
Smart-M3s Smart Space Access protocol (SSAP)and ZigBee protocol.
Smart-M3 Semantic Information Broker (SIB) is thegeographical smart
space containing information about all the nodes and
7http://www.w3.org/standards/semanticweb
-
CHAPTER 3. DECENTRALIZED M2M NETWORK DESIGN 24
LN- ZigBee
WN-WWAN-P2P
PN-WWAN-P2P-ZigBee
LN- ZigBee
WN-WWAN-P2P
SmartM3 Client
WPAN
KP
KP
KP
KPKP
Smart-M3SIB
= Sensor = Actuator = Knowledge Process
Figure 3.3: Smart-M3 System
resources available [24]. The KPs in all M2M devices (WNs and
LNs viaPN) populate the Smart-M3 SIB with the information about all
the nodesand their resources. Then any device with KP can act as
Smart-M3 client andinteract via Smart-M3 SIB, to display the list
of resources and retrieve anyresources value. For example, all
ZigBee motes have temperature sensors andGPS modules, and a
Smart-M3 client can interact with both the resourcesand get the
temperature at any particular location. It is worthwhile to
notethat CoAP protocol is not used here.
-
Chapter 4
Decentralized M2M Management
We use SNMP for decentralized M2M network management. As such,
SNMPstarted essentially as a centralized paradigm [37], in-part due
to the designprinciple that the impact of adding management
functionality to manageddevices should be minimized [41]. As
networks evolved, the scale and com-putational power of managed
nodes increased massively. This created interestin decentralizing
network management by moving towards Management byDelegation
paradigm [22]; Remote Network MONitoring (RMON) MIB [52]is a good
example of the initial work towards this. Since then a wide range
oftechniques have been developed for decentralized management,
including ar-tificial intelligence [28]. In this thesis we use a
novel mechanism of adaptingDHT and using P2P principles for
distributed network management func-tionality.
4.1 Challenges in Decentralization
The key challenges in decentralizing P2P4M2M network (Figure
3.1) are asfollows:
Node discovery and resource discovery mechanisms Identifying
SNMP MIB for P2P4M2M network for node configurations Making the
network self-reliant i.e. MCN should not be required to be
present in the network all the time
Navigating graphs formed by the M2M devices for request and
responsemessages
Proxy functionality for SNMP
25
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 26
Identification method for LNs that are behind PN
4.2 MCN Functionality
The MCN address the above challenges and performs the following
functions:
MCN is used for node discovery. SNMP does not provide any
mecha-nism for node discovery, so every NMS has its own node
discovery mech-anism. In P2P4M2M network, node discovery
information is stored inDHT by M2MCE layer. MCN uses M2MCE API to
fetch the list of allthe nodes that are part of the network. For
performance improvement,the M2MCE layer also provides API to access
delta updates to thenetwork information i.e. the list of nodes
joining DHT since last re-quest. To handle multiple MCNs, the M2MCE
layer has to keep trackof multiple delta information, hence there
has to be an upper limit onthe number of simultaneous MCN nodes
present in the DHT overlay.Since M2MCE layer knows the type of node
(LN, PN or MCN), it canallocate the context when MCN joins and
release it when MCN leavesthe network.
MCN is used for resource discovery and provisioning. The
resources canbe dynamically added or removed on nodes. The database
of resourcesin stored in MIB and it is also used by CoAP to
advertise the resourcesto other nodes using the /.well-known URL
[21]. The resource list inMIB is considered as master, which keeps
it synchronized across CoAPand SNMP protocols.
In alignment with the P2P principle that there should not be any
cen-tral entity required for setting up the network or
communication be-tween peer nodes, MCN is not required to be part
of the network all thetime. P2P4M2M network is made self-reliant
delegating the node join-ing procedure to RELOAD protocol in the
managed (WN/PN) nodes,and by not storing any information on MCN
that is required for networkfunctioning. The latter is achieved by
(as mentioned above) storing thenode discovery information in DHT
and the resource discovery infor-mation in the managed nodes. MCN
retrieves this information whenrequired, but does not store it.
However, for efficiency, MCN does cachethis information.
MCN manages the WPAN using the proxy features of PN for
opera-tions like detaching the LNs from the WPAN. SNMP Proxy
Forwarder
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 27
application [34] is used for this. We devised dot notation for
namingLNs to take into account the hierarchical nature of network.
This alsoallows any arbitrary level of nesting in the network.
MCN is used to manage the WWAN for operations like detaching
nodesfrom P2P overlay, assigning the type of node as WN or PN,
setting thenode name, setting the association between sensor and
association. Ansalient point here is that only the device
configuration - like sensor-actuator association - is controlled by
MCN, the flow of data betweenthem is using CoAP and autonomously
done by the nodes.
MCN is used for setting system parameters on nodes like enabling
ordisabling the Smart-M3 feature, controlling the logging level
etc. MCNuses SNMP to manage the nodes, so it can use the standard
MIBsto configure system parameters. Since the nodes use IP, IP-MIB
andIF-MIB MIBs are particularly useful.
The graph navigation for request-response is handled by the
RELOADprotocol, which in turn uses the ring topology provided by
the Chordalgorithm. Although, CoAP and SNMP can use the overlay
messagingfacilities provided by RELOAD protocol, in the prototype
they useM2MCE layers DDNS APIs to translate node name to address,
andthen directly communicate with the node.
MCN has a command-line interface which abstracts user from
SNMP,allowing the users to be concerned with the functionality
rather thanSNMP protocol. However, support for generic SNMP PDUs is
alsoprovided for flexibility.
As future work, MCN can have a GUI interface for laptops and
smart-phones, which allows access to full functionality of MCN like
nodediscovery, visual indications for alarms, resource discovery,
and a libraryof graphs and charts for displaying data from nodes.
The idea is tohave a generic interface for M2M network which should
be portablefor other M2M and IoT networks. A good example of work
in thisdirection is Pachube 1, which allows storing of data feeds,
controllingthem and displaying data. The challenge here is to have
a genericinterface, massive scalability, and support for real time
operation.
1https://pachube.com
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 28
4.3 Security
PN is responsible for the security of WPAN. It uses the ZigBee
providedmechanisms for the security of the application data and the
network. Itutilizes ZigBee Coordinator node (which is part of PN
itself) as the Trust-Center for managing and distributing keys. LNs
use the shared keys forcryptographic algorithms. M2MCE layer is
responsible for the security ofP2P overlay and stored data.
MCN is responsible for SNMP security and securing access.
Reliable secu-rity was introduced to SNMP with version 3, however,
currently MCN usesSNMPv2c and implementation of SNMPv3 remains to
be done. SNMPv3User-based Security Model (USM) will be used for
authenticating users.
4.4 P2P4M2M Protocol Stack
Application
SNMP Manager
UDP
IP
3G/2G
M2MCEDHT
RelayRelay
ZigBee API lib
COAP SNMP
ZigBee API lib UDP
ZigBee API lib
IP
802.15.4 3G/2G
Application
CoAP SNMP
UDP
IP
3G/2G
M2MCEDHT
M2MCEDHT
SNMPProxyCoAPProxy
ProxyLogic
Application
ZigBee NWK
802.15.4
ZigBeeAPS
ZigBeeAPP ZDO
CoAPSNMP
MCNWNPNLN
Figure 4.1: P2P4M2M Network Protocol Stack Diagram
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 29
The Figure 4.1 shows how SNMP, CoAP, DHT-based Chord and
M2MCEare stacked with each other. It can be seen that CoAP does not
require MCNto be present in the network.
4.5 MCN Interfaces
Figure 4.2 displays the MCN command line interface, along with
the Smart-M3 and WN interfaces. The list of commands available can
be seen from thefigure.
Figure 4.2: Command Line Interface
MCN interfaces with M2MCE layer for the following
functionality:
translate node names into corresponding IP address (DDNS
function-ality)
get list of nodes that are part of M2M network get additional
information about nodes like their joining time get the list of
nodes that have joined or left network since the last query
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 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 theprototype testbed. We show the message sequence
charts, followed by itsexplanation.
4.6.1 Name Resolution
As mentioned in Section 3.4.1, M2MCE layer provides a
distributed nameresolution service to other entities like MCN and
WN. The M2MCE APIfor this is a synchronous function call which
takes node name as input andreturns its corresponding IP
address.These below points are in reference to the message sequence
chart in Fig-ure 4.4.
1. First a node, like MCN and WN, invokes M2MCE join() API to
registerthemselves and become part of the P2P4M2M network. M2MCE
layer,in turn, uses P2P operations to distribute the information
over thenetwork. These P2P operations and distributed storage is
hidden fromhigher layers by M2MCE.
2. Later when required, any node (MCN here) invokes the M2MCE
getIP()API to get the IP address for a given node name. M2MCE layer
againuses P2P operations to retrieve the information from
distributed stor-age.
3. Note that when getIP() is invoked to resolve IP address for a
LN,the IP address returned is in-fact that of the PN representing
the LN.However, the routing of message to LN is transparent to the
sendingnode as the proxy feature on PN is responsible for routing
the messageto the correct target LN. This proxy feature uses the
uri-host part ofthe CoAP [21] and Proxy Forwarder [34] feature of
the SNMP.
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 31
MCN WN M2MCE WN nodes
P2P Messages
P2P Messages
P2P Messages
join(name,type)
join(name, type)
getIP(nodeName)
success
IP Address
success ...
Figure 4.3: Message Sequence for Name Resolution
Similar interaction happens for node discovery and other
functionality whichstore/retrieve data into/from the DHT-based
database, with M2MCE layerproviding a higher level abstraction API
which hides all the complexitiesof distributed system. This message
sequence is basic and part of all thesubsequently described
scenarios.
4.6.2 MCN Operation
One of the functionalities of MCN is setting the association
between sensorsand actuators of any two arbitrary nodes. The node
containing a sensoruses this association to inform the node
containing the actuator when apredetermined event occurs. For
example, a sensor monitoring fire can informactuator controlling
sprinklers when it detects a fire outbreak.
1. Typically the first thing to do before sending message to any
node is toresolve the node name into its IP address (as explained
in Section 4.6.1).
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 32
MCN M2MCE WN LNPN
getIP() using P2P
SNMP Get (resources)
ZigBee msg
ZigBee Ack
SNMP Response (resources list)
SNMP Set (association)
SNMP Response (success)
SNMP Set (association)
SNMP Response (success)
node storesassociation
node storesassociation
Resource Discover for LN
Figure 4.4: MCN sets association between sensor and actuator
2. Next, MCN uses SNMP protocol to discover the resources
(sensors andactuators) on a WN node. Then using this list of
resources, MCNcan associate a sensor with an actuator on another
node (the resourcediscovery for node containing an actuator is not
shown in the chart).
3. The procedure is similar for LNs, except in step(1) above the
IP addressreturned by M2MCE layer is that of PN, and the SNMP
message isdynamically converted into ZigBee protocol by PN.
4.6.3 LN to WN
The Figure 4.5 shows information sent from LN (in WPAN) to WN
(inWWAN), via PN.
1. When an event is detected at LN, it checks if any
sensor-actuator as-sociation is configured with the particular
sensor detecting the event.If an association is found, LN sends the
event information in a ZigBee
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 33
MCN WN M2MCE LNPN
getIP() using P2P
CoAP PUT msg
CoAP ACK msg
ZigBee msg
ZigBee Ack
Event Detected by Sensor
MCN not required
Actuation Event
CoAP protocol ZigBee protocol
Figure 4.5: Information from LN towards WN
message to the target node using the ZigBee coordinator node
(whichis part of PN).
2. On receiving the ZigBee message, PN converts the ZigBee
message intoCoAP message and uses CoAP library to send it to the
target node.CoAP library uses the M2MCE API to resolve the target
node nameinto IP address, and then uses UDP protocol to send the
message.
3. The target node receives the CoAP message and triggers the
actuatorusing the information in the CoAP message. It then
acknowledges themessage by sending CoAP message to the PN.
4. On receiving the CoAP Acknowledgement, PN converts it to
ZigBeeAcknowledgement and sends it to the LN, completing the
transaction.
5. It is worthwhile to note that MCN is not required in any step
of thisscenario, thus making the network self-reliant.
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 34
4.6.4 WN to LN
MCN WN M2MCE LNPN
getIP() using P2P
CoAP PUT msg
CoAP Deferred Ack
ZigBee msg
ZigBee Ack
Event Detected
by Sensor
MCN not required
CoAP Empty Ack
CoAP Ack (for Ack)
ActuationEvent
CoAP protocol ZigBee protocol
Figure 4.6: Information from WN towards LN
The Figure 4.6 shows information sent in the opposite direction
of Fig-ure 4.5 i.e. from WN (in WWAN) to LN (in WPAN), via PN.
1. When an event is detected at WN, it checks its MIB if any
sensor-actuator association is configured with the particular
sensor detectingthe event. If an association is found, WN uses CoAP
library to sendthe event information in a CoAP message to the
target node.
2. Since the LN is represented by the PN, the CoAP message is
receivedby the CoAP server on the PN. The CoAP server checks HOST
URIfield of the CoAP message to identify the target LN for which
themessage is intended. The PN then converts the CoAP message
intoZigBee message and uses zigbee-api library to send the message
to LN.
3. The target LN finally receives the ZigBee message and
triggers the
-
CHAPTER 4. DECENTRALIZED M2M MANAGEMENT 35
actuator using the information in the message. It then
acknowledgesthe message by sending ZigBee Ack message to the
PN.
4. On receiving the ZigBee Acknowledgement, PN converts it to
CoAPAcknowledgement and sends it to the source WN, completing the
trans-action. The PN uses CoAP Token to match the Requests and
Acknowl-edgements.
5. Like the previous scenario of LN to WN communication, it is
worth-while to note that MCN is not required in any step of this
scenario,thus making the network self-reliant.
-
Chapter 5
Prototype Implementation
This chapter describes the hardware and software used for the
prototypetestbed and the system startup details. We also give the
rationale for choos-ing these specific hardware and software. In
general, we have preferred touse open source software wherever
possible.
5.1 Hardware Specification
The prototype testbed uses the hardware described below. In
order to dupli-cate our prototype testbed, we recommend using
hardware with same speci-fications. In order to allow flexibility,
we have used Java, Linux, ZigBee andArdurino platforms which work
on a wide variety of hardware, and henceminimal modifications
should be required to run our software on differenthardware.
5.1.1 LN Hardware
We have used ZigBee devices as LNs. Figure 5.1 shows the LN
hardware.They are constituted of two part - a microcontroller board
and a ZigBeeRadio Frequency (RF) module.
There are several vendors providing microcontroller boards that
sup-port ZigBee RF modules. Among them, we mainly considered 3
boards:WaspmoteTM (from company called Libelium 1), MulleTM (from
companycalled Eistec 2) and IRISTM Mote (from company called
Crossbow 3), and
1http://www.libelium.com2http://www.eistec.se3http://www.xbow.com
36
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 37
Figure 5.1: Local Node
finally we selected Waspmote 4 board because of the following
reasons:-
It comes with good development kit It uses Open Source APIs It
has excellent documentation It comes with 3 ranges 2.4GHz - 7km,
900MHz - 24km, and 868MHz -
40km
It consumes very little power : 0.7uA in Hibernate mode, 62uA in
DeepSleep mode and 9mA when ON.
It has the possibility to add more than 50 sensors, giving a lot
offlexibility
WaspmoteTM board has Atmels 5 ATmega1281 microcontroller
operatingat 8MHz frequency with 8KB SRAM, 4KB EEPROM, and 128KB
FLASH.It uses the Arduino6 platform, which comes with a IDE to
develop, build and
4http://www.libelium.com/products/waspmote5http://www.atmel.com6http://www.arduino.cc
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 38
upload software onto the device. In addition to ZigBee, it
supports Bluetoothand GPRS radio technologies.
To provide the ZigBee connectivity, we have used XBeeTM ZB 7
ZigBeeTM
RF Modules from Digi International Inc 8 which are interoperable
with othervendors ZigBee RF modules. Additionally, these RF modules
are compatiblewith Waspmote microcontroller boards.
5.1.2 PN Hardware
Figure 5.2: Proxy Node
Figure 5.2 shows the PN hardware. PN uses the same hardware as
WN,with the addition of a Waspmote Gateway device which is attached
to the
7http://www.digi.com/products/wireless-wired-embedded-solutions/zigbee-rf-modules/zigbee-mesh-module/xbee-zb-module
8http://www.digi.com
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 39
Gumstix using USB. This gateway device, together with the
zigbee-api li-brary 9, provides the interface to the WPAN. This
interface is used by theCoAP and SNMP software modules to provide
the Proxy functionality.
5.1.3 WN Hardware
The WN hardware is identical to PN shown in Figure 5.2 with the
excep-tion that it does not have Waspmote Gateway device. We use
single-board-computer (SBC) called Overo EarthTM 10 from the
company Gumstix Inc 11.Overo Earth are Linux based SBC which are
available in a wide range of con-figurations (choices in DSP,
Graphics acceleration, operating temperatureranges etc), and it is
compatible with numerous expansion boards which canadd capabilities
like GPS, touch screen LCD, HDMI etc to the SBC. It usesOMAPTM 3503
Applications Processor from Texas Instruments 12 (which isbased on
ARM CortexTM A8 CPU design). In addition, there is a devel-opment
community around different products from Gumstix Inc providing alot
of open source software and technical discussion forums. We have
usedMicroSD card (on Overo Earth) to store the Linux image, which
is very easyto clone, simplifying the procedure of adding extra
nodes in the testbeds. Allthese factors make Overo Earth suitable
for rapid prototyping.
The wireless connectivity is provided by using 3G UMTS dongle
which isconnected to the SBC using USB.
5.1.4 MCN Hardware
Dell Latitude D630 laptop is used as MCN. In addition, this
laptop is alsoused as a Smart-M3 client. Another laptop (Dell
Latitude D630) is used torun 3 entities - the bootstrap node for
the P2P network, a set of simulatedWNs, and the Smart-M3 SIB.
Figure 5.3 shows the complete lab setup for P2P4M2M.
5.2 Software Specification
We have used the following software, mostly open source, for the
prototypeimplementation:
9http://code.google.com/p/xbee-api10http://www.gumstix.com/store/product_info.php?products_id=21111http://www.gumstix.com12http://www.ti.com
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 40
Figure 5.3: Lab Setup
SNMP4J : SNMP4J 13 is an open source enterprise grade
implementa-tion of state-of-the-art SNMP using Java 2SE 1.6. It is
used on WN andPN for implementing both SNMP-Agent and SNMP-Manager
function-ality, and on the MCN for SNMP-Manager functionality. The
versionsused are 1.11.3 and 1.4.3 for the SNMP-Manager and
SNMP-Agent,respectively.
JCoAP : JCoAP 14 is an open source Java based implementation
ofthe CoAP protocol. We have used version 0.1, which is based on
theIETF drafts draft-ietf-core-coap-05, draft-ietf-core-block-03,
draft-ietf-core-link-format-04, and draft-ietf-core-observe-02. We
had also con-
13http://www.snmp4j.org14https://github.com/dapaulid/JCoAP
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 41
sidered another CoAP implementation jCoAP15 (notice the small
j),however, on evaluation we found that JCoAP was more feature-
com-plete than jCoAP, hence we used JCoAP. One important feature
thatJCoAP lacked was the proxy functionality (as defined in
Section-5.3 ofCoAP specification [21]), so it was added as part of
this thesis.
zigbee-api library : Libelium does not provide any library to
interfacewith the ZigBee gateway device, hence we had to use a
third partylibrary. Zigbee-api library is an open source Java
implementation forinterfacing with Radio Frequency devices
complying with XBee/XBee-Pro series 1 (802.15.4) and series 2 (ZNet
2.5 and ZB/ZigBee Pro). Itrequires RXTX 16 java library to
communicate with ZigBee coordinatornode using USB port.
P2P network based on DHT : We have used Ericsson
Researchsimplementation of P2P network which is based on DHT. It
uses Peer-to-Peer Protocol (P2PP) and Chord algorithm. RELOAD
protocol [25]is the IETF successor of P2PP and since M2MCE
completely abstractsP2PP from MCN, for the purpose of this thesis,
we mention RELOADprotocol even though the prototype uses P2PP.
Arduino : Libelium Waspmote development uses Arduino
develop-ment environment. We used Waspmote IDE version 2, which in
turnis based on Arduino IDE. The Waspmote IDE provides code
examplesfor handling various sensors in Waspmote which are very
helpful indevelopment.
Linux : Linux embedded operating system is used on Gumstix
(usedas WNs in the prototype). The flavour used is linux-gnueabi,
whichis ARM EABI Debian based port of Linux for the ARM
architecture(named armel). opkg 17 based package management is
used.
CACAO JVM : CACAO 18 Java Virtual Machine (JVM) is developedby
Vienna University of Technology with support for ARM processors.We
chose CACAO over JamVM 19 because it supported the pre-existingDHT
based P2P implementation out-of-the-box.
15http://code.google.com/p/jcoap16http://users.frii.com/jarvi/rxtx17http://code.google.com/p/opkg18http://www.cacaovm.org19http://jamvm.sourceforge.net
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 42
Smart-M3 Platform : We have used Smart-M3 platform, which
iscreated as part of DIEM project, to provide information level
interop-erability using Smart-M3 Knowledge Processes [24]. The
version usedis 0.9.5 [17].
Smart-M3 Java library : Smart-M3 platform provides interface
inC. Language bindings have been created for Java and Python to
enablesoftware development in these languages. We have used the
Java bind-ing created by University of Bologna and Finnish
Technical ResearchCentre VTT [50], version 5.5. The java binding
internally uses JSONlibrary.
It is worth noting that all the software is developed using
Java, other thanthe C on Waspmotes (since Waspmotes do not support
Java). The basic ideabehind using Java is to allow easy porting to
new (different) hardware, andgiven that M2M field is rapidly
advancing, we expect to continually upgradethe testbed
hardware.
5.3 Software Structure
The high level software architecture of PN is shown in Figure
5.4. The designof WN and MCN is subset of PN, so it is not
explicitly discussed here.The software is split into 3 Java ARchive
(JAR) packages for modularity- m2mManager.jar, proxy,jar and
m2mce.jar - and they use Java RemoteMethod Invocation (RMI) 20 for
communicating with each other. These 3JAR files are present in all
nodes which allows the flexibility to change aPN into WN (and
vice-versa) and to use any node as MCN. There are 6significant
modules contained in these 3 JAR packages:
1. M2MCE
2. Proxy
3. SNMP
4. Smart-M3 Client
5. CoAP client-server library
6. MCN command-line application
Out of the above 6 modules, the last 4 were implemented as part
of thisthesis.
20http://java.sun.com/j2se/1.5/pdf/rmi-spec-1.5.0.pdf
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 43
M2mManager M2MCE Proxy
Java Virtual Machine
Linux Operating System
RMIAPI
CoAPLib
RMIAPI
SmartM3
Figure 5.4: Software Architecture of PN
5.3.1 M2M System Startup
First the P2P bootstrap-peer device is started, followed by the
rest of thedevices in the network. Each node begins by launching
M2mManager mod-ule, and then onwards the M2mManager module is
responsible for furtherlaunching the other modules and configure
the local node. The M2mManagermodule uses SNMP MIB information for
this purpose.
M2mManager checks if there are any MIB values specified in the
(op-tional) configuration file and loads these values, if any, into
the MIB. Next,M2mManager checks the node-type (PN/WN/MCN), the node
name, andthe feature flag for Smart-M3, and accordingly does the
following:
If a node name is given in configuration file, M2mManager uses
thisname and the node-type to invoke the join() API of M2MCE
module.M2MCE then contacts the bootstrap-peer and joins the P2P
overlay. Ifno node name is specified in the configuration file,
M2MCE module au-tomatically assigns a name. This mechanism is used
since in a network
-
CHAPTER 5. PROTOTYPE IMPLEMENTATION 44
with large number of nodes, it would not be possible to
individuallyassign names to all nodes; on the other hand, this
offers capability toassign/modify node names via MCN.
If node-type is PN, M2mManager launches the Proxy module; if
thenode-type is MCN, it instead launches the command-line module;
oth-erwise, it does not launch any extra module.
If the feature flag for Smart-M3 is enabled, M2mManager launches
theSmart-M3 module. Then Smart-M3 module retrieves all the
resourcespresent in the node and publishes them in Smart-M3 SIB. If
the nodeis a PN, Smart-M3 is responsible for discovering resources
on the LNsand publishing them in Smart-M3 SIB. Additionally,
Smart-M3 modulesubscribes, with the Smart-M3 SIB, for any requests
for the registeredresources.
Lastly, M2mManager launches the CoAP module which, in turn,
startslistening for any CoAP requests.
At the end of above steps, the system is up and functional. Now,
theMCN commandline interface can be used for operations like node
discovery,resource discovery, setting sensor-actuator associations,
controlling log leveletc. Similarly, Smart-M3 client can be used to
retrieve information from theM2M devices. The list of available
commands for MCN and Smart-M3 isshown in Figure 4.2.
-
Chapter 6
Evaluation and Discussion
There are several interesting research work which focus on
evaluating SNMPand developing extensions to SNMP for resource
constrained M2M devices,for example, [30], [42] and [16]. However,
this thesis considers decentraliza-tion aspects of the M2M network
management.
Over a period of time, several techniques have been used to
decentralizenetwork management. For example, [44] uses navigation
patterns and [7,40, 53] adapt databases to propagate
request-responses. One of the mostcommon technique centers around
using hierarchical architecture of networkmanagers, like [29, 49].
However, we use a novel mechanism of adapting DHTto handle network
management.
The main contribution and findings of this thesis is as
follows:
We have identified the following SNMP MIB for M2M domain. This
isuseful for IETF MIB standardization efforts like the IETF
6LoWPANMIB Draft [27].
Sensor-Actuator associations. This is a fundamental
attributethat needs to be stored in the MIB. There have been
similar ideasof creating sensor-actuator associations using
different protocols,like Web Services for Devices (WS4D) 1 which
uses Microsoft tech-nologies to provide the same functionality.
GPS coordinates for M2M devices. This attribute is essential
forM2M GUI to spatially display the devices, and invaluable
whileconfiguring the sensor-actuator associations.
1http://www.ws4d.org
45
-
CHAPTER 6. EVALUATION AND DISCUSSION 46
We have found that the capability and efficiency of SNMP in this
net-work architecture depends largely on the DHT. For example, the
vol-ume of data that can be stored in a given DHT algorithm
determineswhether we can store only the node discovery information
or also theresource discovery information. Similarly, the node
discovery capabili-ties of the network will be limited by the
response time with which theChord algorithm reorganizes its
ring-structure when a node leaves orjoins the network.
We have developed a decentralized M2M prototype which acts as
aplatform for further research. At the time of writing this thesis,
aresearch work is in-progress for developing a generic M2M GUI
usingthis prototype.
The prototype demonstrated and solved challenges for the
following:
Integrating IETF aligned protocols to develop a M2M network-
CoAP, SNMP, RELOAD, IP, IEEE 802.15.4. In addition, itwas shown
that this network could interwork with other hetero-geneous
networks, like ZigBee, using proxies. Resource discoveryprocedures
for CoAP and SNMP were united by designating theSNMP MIB as master
information, and CoAP protocol stack re-ferring it.
Using SNMP for decentralized management. This is
especiallyinteresting because SNMP is considered essentially as a
central-ized system. Decentralization was largely enabled by the
modulardesign of SNMP, which itself was originally done to help
tran-sition from SNMP to OSI based ISO Common Management
In-formation Services/ Common Management Information
Protocol(CMIS/CMIP) [15] (though, eventually, CMIS/CMIP did not
be-come popular for Internet devices).
Integrating the decentralized M2M network with Semantic Webusing
Smart-M3.
Creating a self-reliant M2M network, where management nodeis not
required to be present in the network continuously. Thiswas
achieved by not storing any information required for
networkfunctionality in the management node (i.e. MCN).
A strong need was seen for standardizing the resource names for
sen-sors and actuators to ensure interoperability. Since WSN has
its rootsin academia, very little attention was given to
standardization aspects.
-
CHAPTER 6. EVALUATION AND DISCUSSION 47
On the other hand, M2M domain evolved with a large number of
pro-prietary standards with little interoperability (like oBIX 2,
ZigBee 3).For instance, CoAP allows resource discovery but without
any standardname for resources, like temperature, machines cannot
autonomouslydo resource discovery. Currently, the IETF drafts on
CoAP and 6LoW-PAN mention that the names could be standardized, but
there is noproposal to do so.
During the Smart-M3 integration it was found that the
abstractionlayer provided by Ontology and Resource Description
Framework (RDF)in Smart-M3 is too generic and complex. Better
abstraction modelsneed to be developed for wider adoption of
Smart-M3 by programmers.Also, security is missing.
IPv6 and HTTP have been adapted to resource constrained
devicesand networks as 6LowPAN and CoAP, respectively. Similarly
DHTalso needs to be adapted for M2M network. Currently, the DHT
im-plementations are not suitable even for cellular smart-phones,
whichhave significant computing power, as found in the performance
mea-surements in [36]. As such, according to Moores Law, the
embeddeddevices should already have advanced capabilities to host
DHT im-plementations. However the current generation of low power
wirelessembedded devices are still resource constrained. We believe
that thisis mainly due to two reasons. Firstly, there was no killer
application orwidespread use-case requiring more powerful devices.
Secondly, the de-vices need to maximize battery which gets
progressively difficult withincreasing hardware complexity.
However, now with IoT and M2Mtechnologies gaining momentum, we
believe that the device capabil-ities will improve. Also, at the
same time P2P technologies will beadapted and advanced, demanding
less computational and bandwidthresources, thereby facilitating
incorporation of P2P on M2M networks.
2http://www.obix.org3http://www.zigbee.org
-
Chapter 7
Conclusions and Future Work
The objective of the overall P2P4M2M research project in which
this thesiswas done was to study the challenges in decentralization
of M2M networksand implement a prototype testbed. The scope of this
thesis was to in-vestigate the management of decentralized M2M
network using SNMP. Tothe best of our knowledge, this is the first
research work into applying P2Pprinciples to M2M networks and SNMP.
The central topics studied were de-centralized management, node
discovery, resource discovery, node configura-tion, and proxy
functionality. The project started with the study of
possibleuse-cases for next generation M2M networks, followed by an
evaluation ofseveral embedded hardware and software which could be
used in our proto-type testbed. Finally, the design and
implementation for the prototype wascarried out by integrating IETF
and IEEE aligned protocols - CoAP, SNMP,IP, RELOAD and IEEE
802.15.4. We also integrated the M2M network withSemantic Web using
Smart-M3. The resulting prototype is being used as aplatform for
further research into decentralizing M2M.
In this thesis we identified SNMP MIB for M2M networks, and
establishedthat SNMP can be easily used for decentralized
management by adaptingP2P mechanisms. It was seen that the
capability and efficiency of SNMPfor decentralized management
largely depends on the underlying decentral-ization mechanism, for
example, the volume of data that can be stored inDHT, and how fast
the Chord algorithm reorganizes when nodes leave or join.Hence, a
need was seen for research into customizing RELOAD and Chordfor
M2M, much in the manner IPv6 and HTTP have been customized forM2M
in the form of 6LoWPAN and CoAP, respectively. Another finding
wasthat the standardization of resource names was not being covered
in scopeof CoAP, 6LoWPAN or any other drafts. This might lead to
the undesirablesituation where product vendors develop proprietary
resource names. Webelieve that the CoAP specification is the most
suitable place to standardize
48
-
CHAPTER 7. CONCLUSIONS AND FUTURE WORK 49
the resource names.Lastly, we devised two techniques in order to
achieve a self-reliant M2M
network, which remove the requirement for any management node to
becontinuously connected in order for the network to function.
Firstly, weensured that no required data was stored in the
management node. Thiswas primarily achieved by storing the node
discovery information in DHT,and storing the resource discovery
information in SNMP MIB. Secondly, thenode joining was handled by
RELOAD protocol of managed nodes themselvesinstead of the
management node.
7.1 Future work
This work represents an early step towards decentralizing M2M
networksand decentralized management using P2P principles. The
timeline for ma-turing this technology is envisioned to be two to
three years and considerableresearch remains to be done.
Currently, our prototype is being used for GUI development as
part ofanother students Masters thesis. This GUI will have generic
M2M function-alities like displaying devices location on a
geographical map, node discovery,resource discovery, using graphs
and charts to display sensor-actuator data,setting parameters on
devices etc. Pachube 1 is a good example towardsthis domain. The
challenge is to have a generic interface covering maximumenvisioned
M2M functionality (so that it is portable to other M2M and
IoTsystems), massive scalability, and support for real time
operation.
Among other things, work needs to be done for customizing P2P
protocolsfor M2M and implementing distributed Smart-M3 SIB using
DHT. Then,significant further research is required in the direction
of implementing andcomparing different P2P decentralization
mechanisms and the centralizedapproaches. Additionall