Research Article Protocol and Architecture to Bring Things ...downloads.hindawi.com/journals/ijdsn/2014/158252.pdf · things in Internet [ ]. Ideally, things on the IoT will have

Research ArticleProtocol and Architecture to Bring Things intoInternet of Things

Aacutengel Asensio Aacutelvaro Marco Rubeacuten Blasco and Roberto Casas

Aragon Institute of Research University Zaragoza 50018 Zaragoza Spain

Correspondence should be addressed to Alvaro Marco amarcounizares

Received 1 December 2013 Revised 16 February 2014 Accepted 16 February 2014 Published 13 April 2014

Academic Editor Zuqing Zhu

Copyright copy 2014 Angel Asensio et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

The Internet of Things (IoT) concept proposes that everyday objects are globally accessible from the Internet and integrate intonew services having a remarkable impact on our society Opposite to Internet world things usually belong to resource-challengedenvironmentswhere energy data throughput and computing resources are scarce Building upon existing standards in the field suchas IEEE1451 and ZigBee and rooted in context semantics this paper proposes CTP (CommunicationThings Protocol) as a protocolspecification to allow interoperability among things with different communication standards as well as simplicity and functionalityto build IoT systems Also this paper proposes the use of the IoT gateway as a fundamental component in IoT architectures toprovide seamless connectivity and interoperability among things and connect two different worlds to build the IoT the Thingsworld and the Internet world Both CTP and IoT gateway constitute a middleware content-centric architecture presented as themechanism to achieve a balance between the intrinsic limitations of things in the physical world and what is required from them inthe virtual world Saidmiddleware content-centric architecture is implementedwithin the frame of two European projects targetingsmart environments and proving said CTPrsquos objectives in real scenarios

1 Introduction

Since the last decade we are assisting in a progressivejump from a nonubiquitous Internet where humans accessInternet using a computer at their work or at home to thecurrent ubiquitous Internet where we access the Internetusing smartphones tabs or TVs anytime anywhere In thesame way now comes the time of the Internet of Things(IoT) when not only humans but also things any objectsurrounding us are present in Internet [1]

Things must be considered in the broadest sense of theword as real or virtual entities that exist and evolve in acontext and time and have univocal identifiers On the otherhand the term Internet applied to them conveys the idea thatall these things are heavily communicated and interrelatedamong them Commonly IoT can be approached fromdifferent perspectives Internet for communications cloudand services things for physical elements sensor networksand user interfaces and semantic that considers ontology ofthings in Internet [2]

Ideally things on the IoT will have full interconnectivityand computation resources being natural to consider con-necting these things to the web using current paradigmsDifferent works investigate the types of things (sometimescalled smart objects) their nature and relationship withthe IoT according to the different perspectives a thing hasawareness representation interaction and so forth [3] Theclassification of things into standard groups helps to showthat they are the physical part of IoT with constraints andneeds that must be taken into account So coming down toimplementation while IoT concept talks about ubiquitousinvisible and context aware things technology poses hurdlessuch as energy supply price and size of devices seamless con-nectivity or interoperability [4] Additionally as currentlyInternet has a wired backbone ldquobeing thererdquo forces all thethings to be IP compatible and use access points or gatewaysto bridge global fiber optic or cabled infrastructure

Wireless communication protocols are mandatory ifthings need to be mobile and ubiquitous Depending on thespecific application and leaving aside proprietary protocols

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2014 Article ID 158252 18 pageshttpdxdoiorg1011552014158252

2 International Journal of Distributed Sensor Networks

Internet

Network of things B

Network of things A

Things world

Internet world

Physicaldata network layer

Stack layer

Application layer

phyethernet IP layer

TCP UDP layer

Application layerIoT bundle layer

IoT gateway

Data and services world

Cloud and data services

Autonomous systems

User oriented servicesU

nder

stan

ding

wal

l

IP w

all

Figure 1 IoT architecture

different standards are commonly used to provide connec-tivity ZigBee RFID Bluetooth 6lowPAN WIFI 3G and soforth Many works evidence the importance of selecting themost appropriated technology in each situation comparingthem in terms of network topology coverage data through-put or energy consumption In any case the more data youneed to exchange the further you need to communicatethe more time you need to be online then more energyyou need and consequently the quicker you will run out ofbatteries

The arrival of IoT will lead to appearing multitude of newservices improving the quality of life of people and offeringnew business opportunities Ultimately the IoT is expectedto bring a revolution in the concept of society similar tohow Internet changed the concept of communications andinformation [5] In the last few years initiatives and projectrelated with IoT have been growing in number and scopethroughout the entire world The IoT concept is becomingtremendously popular and already appearing systems thatclaim to offer IoT solutions to the final user without hightechnical requirements [6] Current developments are in earlystages being most of the services based on monitoring orsensing variables to extract information and then analyze andrepresent them [7]

It is considered that the development of IoT will play animportant role in the near future thus public and privateinvestments have been made in RampD demonstration anddeployment activities [8 9] To date most of IoT solutionsare small subnets of interconnected objects It is not possibleto talk about IoT until all objects are interconnected and toimprove this interconnectivity an architecture that ensuresinteroperability between systems is mandatory Thus bothpublic and private initiatives are currently focusing on stan-dardization of the IoT [10ndash14]

In summary the evolution of IoT implies overcoming realthingsrsquo limitations enabling them to communicate with theInternet using a common language In this paper we proposeCTP (Communication Things Protocol) as an ontology-based solution to enable understanding among things andthe use of an IoT gateway to take things to the Internetworld

2 Internet of Things

21 Architecture Most IoT implementations follow an archi-tecture that contains different worlds each of them with theirown characteristics Figure 1 shows an example [15]

The things world relates to michroelectromechanicalsystems smart sensors simple human-machine interfaces(HMIs) and so forth which associate in networks (Networksof Things NoT) to ubiquitously interact with other thingsthe environment andor people NoT are usually resource-challenged ecosystems typically with medium-high timeaccess delays high error rates low data throughput andlimited online time where energy consumption must beoptimized to the maximum In a simplified model of a thingbasic blocks of communication computation and interaction(sensors actuators and HMI) are distinguished

The Internet world usually is constructed around com-puters centralized software infrastructures or in the cloud[16] Applications and services use things to provide contextawareness artificial intelligence affective computing and soforth [16] Depending on their consideration tablets andsmartphones can be included in both worlds Neverthelessdue to their power (computing communications batterylifetime user interfaces etc) we find it more appropriateto consider them closer to the world of computers andInternet than to the world of things Currently Internet actsas the base infrastructure for the exchange of informationHowever access to it has several constraints such as theneed for unique identifier the change of communicationtechnology and the adoption of the Internet ProtocolsNowadays this ldquoIP wallrdquo is usually jumped through an IoTgateway

Internet is the global interconnectionmethodwheremul-titude of services and applications use extracted informationof IoT to provide services to end users On each of themneeds are a virtual representation of the things of the IoTin order to enable interaction Once ldquoIP wallrdquo is saved andthanks to the connectivity provided by the Internet servicescan access the information but for the information to beuseful it must be understood and this poses what we call theldquounderstanding wallrdquo

International Journal of Distributed Sensor Networks 3

22 Interoperability IoT interoperability implies capacityto both exchange data (crossing the IP wall) and under-stands the information embedded in data (crossing theunderstanding wall) Communication standards ensure stacklayerrsquos communication between things in the same networksharing the same protocol that is network managementand maintenance security data exchange and so forthNevertheless if application layer is not defined thingswill notunderstand among them unless previously agreed betweendevelopers that is information understanding This is thecase of 6lowPAN RFID WiFi or cellular for example iftwo manufacturers want to develop 6lowPAN temperaturesensors and thermostats are able to interoperate amongthem there is no common definition to adopt they willneed to agree on the protocol exchange application-relatedinformation temperature data format procedure to virtuallybind devices and so forth

Automation and control networks such as LonworksBACnet Konnex or CANOpen define how devices arerepresented in their networks objects and variables are themost common approaches Bluetooth and ZigBee go onestep further in interoperability defining profiles and deviceobjects within the application layer Bluetooth defines profiles(hands-free health device human-interface device etc)corresponding to vertical applications For example we couldbuild a monitoring infrastructure with Bluetooth micro-phones streaming audio according to hands-free profile nomatter their manufacturer any certified host compliant withthe profile will play the audio gateway role without anyadditional programming [17]

ZigBee not only defines vertical profiles (home automa-tion energy metering healthcare etc) but also defineshorizontal functional domains to specify how devices mustexchange application data attending their functionality [18]For example every ZigBee compliant temperature sen-sor must implement ldquomeasurement amp sensing functionaldomainrdquo and any other device in the network (eg a thermo-stat) would be able to get temperature information as definedin the specification Additionally ZigBee allows instantiationof intelligence in the network by defining how to coordinatedevices to produce scenes and create virtual bindings amongdevices [19] for example to program a switch to turn on twolights and open a motorized door

Sometimes two specifications coordinate to solve inter-operability such as ZigBee that specifies how to interoperatewith BACnet Devices using any wireless communicationstandard (eg ZigBee) cannot directly interoperate withdevices over other standards (eg WiFi) unless there is aprotocol aggregator and translator connecting both worldsthe IoT gateway

Although IP connectivity is not necessarily required toensure inter-thing communication many standards includeIP as part of their specification to ease the process to connectthings to the Internet Nevertheless this is not enough toensure interoperability at required IoT application levelAs things are resource-challenged communication nodesefficient data transmissionmechanisms are needed at IP levelCoAP [20] XMPP [21] RESTful HTTP [22] and MQTT arerelevant specifications at this level

Once efficient connectivity between devices is grantedstandards such as EEML (Extended Environments Mark-up Language) SensorWeb (including SensorML and Trans-ducerML) or SenseWeb provide interpretation to bytesexchanged integrating sensors and actuators with the virtualworldThese schemes just express queries and datamodelinglacking of semantics and ontologies that are necessaryfor complex information processing and support to servicecomposition and adaptation at higher levels of abstraction

IEEE1451 standard is a network-independent specifica-tion for smart transducers (sensors or actuators) that providesa common language regardless of the protocol used Thestandard defines different application profiles environmental(climate monitoring greenhouse gases and other chemicalsensors) smart meter (monitor water gas or electricity con-sumption) health care (monitor the body using external orimplantable sensors) and smart home automation and indus-trial (pipersquos monitoring comfort and surveillance sensors)[23]The standard is based on the Transducer ElectronicDataSheet (TEDS) to describe a set of communication interfacesfor connecting transducers to microprocessors instrumen-tation systems and controlfield networks According toIEEE14510 specification TEDS provides information abouttransducerrsquos identification operation calibration manufac-turer and so forth

Lying on IEEE14515 specification for radio-specific pro-tocols [24] it is possible to implement wireless sensornetworks using IEEE1451 over communication standard pro-tocols such as Wifi [25] Bluetooth ZigBee [26] or 6LowPan[27] Similarly IEEE14512 defines cabled SPI and UARTIEEE14516 over CANOpen and IEEE14517 over RFIDThis interoperability is enabled by the Network CapableApplication Processor (NCAP) that aggregates the differentTransducer Interface Modulersquos communication standards(TIM) over the same common languageThroughNCAP andfollowing IEEE1451 it is possible to implement web servicesthat make things discoverable accessible and controllablevia the Internet 22 In the same line ZigBee defines theZigBeeGateway Public Application Profile that specifies howdevices must be connected to the Internet and to serviceproviders

Initiatives such as Sensei project [7] COSE [28] DogOnt[29] and other [30] different ontological approaches tomodelthings (sensors actuators simple human-machine interfacesappliances etc) in smart environments associate containeddevices through semantic relationships [31] and seamlesslyintegrate things with web services

3 Common Things Protocol (CTP)

31 Rationale Networks of things (NoT) defined as smartinfrastructures of embedded devices with local intelligenceand access to the ldquoinformation etherrdquo are the base of theIoT As a part of the Internet one of the basic needs is theinteraction mechanism between agents which implies thatbetween them theremust be connectivity and understandingin order to provide interoperability To achieve this goal dif-ferent IoT protocols are being proposed to provide efficient


seamless and robust connectivity (CoAP XMPP RESTfulHTTP MQTT etc) but not providing semantics From anintegral perspective IEEE1451 appears to be a good suitedoption for the IoT as it tackles specification from sensor tonetwork interface providing independence from the com-munication protocol enabling self-identification of deviceslong-term self-documentation plug and play capacity to easefield installation upgrade and maintenance [32] On theother hand the standard has a limited penetration in IoTapplications out of the electronic instrumentation field Rea-sons for that can be the little compatible hardware available(no commercial wireless sensor networks consider it) becauseIoT developers mainly come from the computer science field(usually considering semantic approaches) due to complex-ity of the standard [33] or the excessive detail in electronicaspects that are not commonly used by the application (egtransducer channel reads delay time or incoming propagationdelay through the data transport logic) Communicationstandards such as ZigBee or 6LoWPAN are much more usedin IoT applications but involve hardware restrictions and lackof interoperability among them

The Common Things Protocol (CTP) aims to providea specification that allows interoperability among commu-nication standards and coexistence with IoT protocols butprioritizing simplicity efficiency and functionality to buildfinal IoT systems

CTP takes into consideration existing specifications in thestandards and the needs from the final applications that areto be supported by the things in the field It integrates thestrategies concepts and terms of some of the alternativesfor example IEEE1451 TEDrsquos concept to provide devicersquosinformation sensor and actuator working modes and soforth or ZigBee concepts of clusters and endpoints CTPdefinition is approached from an ontological perspectiveconsidering things not just as sensors [34] but as electronicdevices that perform some sort of function in the IoTapplication being in contact with user and context and usuallyfulfilling the following paradigms

(i) context interaction embedded sensors (to sense theusercontext) actuators (tomodify the environment)andor simple human interfaces (to interact withpeople)

(ii) computin to have computing capabilities and mem-ory that allow them to implement from the simplestlogic to complicated services or data processing algo-rithms

(iii) communication to have at least one usually wirelesscommunication media commonly following a stan-dard and adapted to communication requirements(range power consumption and data throughput) Itis required to interoperate among them and integratein the Internet Thus unless they are able to directlyconnect to Internet a network gateway is requiredto allow interoperability among different networks ofthings and to provide Internet access

(iv) being an electronic thing as anything in this worldregardless it is electronic or not each thing is unique

ActuatorSensor Processingmemory

Energy sources

Human interface

Communications

Figure 2Thing block diagram

and ldquolivesrdquo in a specific space and time Additionallyas any electronics it needs energy to operate

Figure 2 represents said paradigms in the block diagramof a thing able to integrate in the IoT

Thus derived from their capacity to interact with thecontext CTP considers that things can have three differentfunctionalities

(i) sensors that gather and process information fromthe real world in environmental and person-centriccontexts [35] Information from the environmentalcontext is useful to create an objective snapshot ofwhat is happening in every moment while person-centric helps to understand and evaluate the objectivedata in order to extract conclusions to define guide-lines or to identify patterns adapted to each user

(ii) actuators that provide the ability to act over theenvironment IoT applications may need to act overthe environment when the user is not able to control(eg because heshe has a disability) or heshe isnot aware of specific situations that require actuation(eg forget about the heating when going to sleep) orsimply heshe is not present in the environment

(iii) pervasive human-machine interfaces including tradi-tional (switches and dimmers) and new interactionparadigms providing the user with relevant infor-mation or notifying himher about events in newand natural ways (eg a color device turns red whenhousersquos energy consumption is high)

Regardless its functionality each thingwill always ldquoliverdquo ina certain location and time andwill have a processor commu-nication transceiver and power source Similar toMetaTEDSin IEEE1451 and ZigBeeDevice Object (ZDO) in ZigBee thisconstitutes the basic set of attributes and functionalities ofany device which is modeled by the endpoint BASE in CTPDepending on the specific functionalities it integrates it willalso implementmultiple application endpoints that should beof any of the said categories SENSOR ACTUATOR or HMI

Thus an endpoint can be defined as each of the subde-vices that have a complete functionality and together withothers build the thing in total we just define the said 4endpoints tomodel anything Additionally a cluster is defined


as a set of commands events and responses (some manda-tory to implement in order to guarantee interoperability)which together define a communication interface betweentwo endpoints Clusters constitute the implementation ofthe ontological representation of thingrsquos nature for exampleendpoint BASE includes location time and power clustersEndpoint and cluster concepts are sharedwith ZigBee and aresimilar to transducer channels in IEEE1451

Commands are usually action requests to an endpoint(of the same or different thing) that should send back aresponse informing about the action result for example askfor a sensor value and get it back The ontology definesattributeswhich are implemented in the protocol asGETSETrequests and responses Events are asynchronously generatedmessages sent to previously subscribed endpoints for exam-ple presence detected by a sensor is sent to light actuatorWhen defining a communication interface two strategiescan be adopted (i) using a small but well defined numberof messages where the versatility is achieved by parameters(ii) or defining a greater number of messages allowing morespecific control with lower parametric content [36] Anexample of this duality is to define a single configurationcommand with many parameters or several commands toadjust each parameter independently The selection of oneor another philosophy conditions ease of use generaliza-tion capacity adaptability to different scenarios and futuremaintenance and backwards compatibility CTP choosesto define a reduced and simple communication interfacesdefining the meaning type and range of the parameters whenneeded For example many clusters have in common a read-only information attribute in the case of sensors it providesinformation of ranges accuracy format units and so forthof the measure it provides while for actuators the sameattribute indicates how the actuator should be controlledSimilarly some clusters include a read-and-write configura-tion attribute whose specific parametrization depends on thedevice

32 Endpoints and Clusters Figure 3 shows the four end-point types (BASE SENSOR ACTUATOR and HMI) withtheir associated clusters and the main attributes commandsresponses and events

321 Endpoint BASE All devices regardless their naturemust have endpoint BASE containing the generic and com-mon characteristics whatever their functions are Relatedwith this endpoint we define the following clusters

Cluster DEVICE It manages device identification descriptionof their functionalities (as in IEEE1451 TEDSrsquos globallyunique identifier and transducer channels) and minimumself-operation functionalities (as BIOS) Its implementation ismandatory in all CTP devices as it is the basis for ensuringinteractionwith other system elements Devicesmay have theability to operate in different ways depending on the contextthe mode parameter is used to switch between them and tofacilitate the use of the thing by providing to a nonadvanceduser a set of predefined modes of operation that do not

need any previous settings to set mode and operate Alsothis cluster has several capabilities oriented to work with lowpower devices for example and similar with TEDS a timeoutparameter that indicates the amount of time after an actionforwhich the lack of reply following the receipt of a commandmay be interpreted as a failed operation

Cluster LOCATION Each device will always have a locationthat can be essential information for many services It canbe known or not it can change or remain and devicecan self-calculate it or be written externally whichever thecase this cluster allows getting and setting devicersquos positionprogramming its timed update or reporting it in response tospecific events

Cluster POWER As location every device will have a powersource (battery mains energy harvesting etc) its typeconsumption profile and energy remaining are the maininformation deal within this cluster

Cluster TIME Again as location and power every deviceldquoliverdquo in a specific instant of time and whether relative orabsolute this cluster allows the management of temporalinformation such as time synchronization and scheduling oftimed actions

Cluster PROXY Similar to TEDS this cluster acts as an aggre-gator of endpoints (or transducer channels) and dataloggermanager (if memory is available) simplifying access to dataIt reduces communication burden and thus increases batteryefficiency

Often implementation of networks of smart sensors andactuators goes through a central device that receives datafrom sensors processes the information and then ordersactions to the actuators This has a number of problems (i)density of data traffic (ii) increased energy consumption(iii) masking the mesh concept since there is a central nodeacting as sink and source of information and (iv) reducingrobustness to failure To face that it is possible to define abasic distributed intelligence by subordinating the behaviorof some devices to the events generated by other devices

Cluster BEHAVIOR Similar to ZigBee this allows the creationof groups of devices or endpoints and the establishmentof logical relationships (bindings) among them We expandits native definition defining the concept of a trigger eventfor a binding which allows that any endpoint generatingevents (eg timing threshold event etc) could trigger anyendpoint(s) in one or more devices with their correspondingparameters (eg changing the mode to low power of adevice) Also as in TEDSwhen defining embedded actuatorsthese bindings can be internal to a device and serve forexample to trigger actions button event triggers a lightactuator

This cluster also allows delegation of systemrsquos intelligencein the devices as it providesmethods to program autonomousoperation based on the specification of operational rules Itis based on logical rules that verify compliance with certainconditions of different endpoints of the device Each situation


Endpoint HMIEndpoint ACTUATOREndpoint SENSOR

EndpointCluster

Device cluster

Device ID-RDevice info-RDevice mode-RWDevice description-RW

PingResetSelf-check

Location cluster

Location info-R Location-RWLocation config-RW

Time cluster

Time info-RTime-RW Alarm config-RW

Power cluster

Power info-R Power level-RPower config-RW

Proxy cluster

Sensor event clusterSensor event info-RSensor event config-RWSensor event elapsed time-R

Sensor clusterSensor info-RSensor config-RWSensor data transmit config-RW

Get sensor data

Sensor data (data set and packet)

Proxy data (data set and packet)

Sensor rearm

Sensor event

Actuator clusterActuator info-RActuator config-RWActuator status-R

Set actuator status

Sensor stats clusterSensor stats info-RSensor stats-R

Clear sensor stats

HMI input cluster

HMI input info-RHMI input config-RW

Get HMI input status

HMI input status

HMI output clusterHMI output info-RHMI output config-RWHMI output status-R

Set HMI output status

Power event

Proxy info-RProxy config-RWProxy datalogg config-RW

Get proxy data

Behavior clusterBinding config-RWBehavior config-RW

Execute behavior

Attribute (GETSET)CommandResponseevent

Endpoint BASE

Alarm raised

Figure 3 Summary of endpoints clusters and main interfaces in CTP

that activates a behavior is called activation scenario Noticethat as a result of a rule of behavior a binding could betriggered

322 Endpoint SENSOR Sensors are elements that canextract information from the context CTP allows man-agement of basic features and supports more abstract andcomplex capabilities

Cluster SENSOR As transducer channels TEDS it managesthe basic actions to request measure defines sensor settings(eg sampling period) and defines themode for transmittingthe data set or data packets aggregating severalmeasurements(eg on command timed or buffer full) It also providesessential attributes of the measurement such as units accu-racy data ranges warm-up time vectors and data packetsEvery sensor type must implement this cluster


Layer 0-NoT bridge connectivity

Layer 1-NoT bridge interpretation

Layer 2-NoT management

Layer 3-CTP devices

Layer 4-IoT services

Serial connection objecteg serial port

NoT bridge objecteg ZigBee bridge

NoT objectseg ZigBee devices

CTP objectseg temperature sensors

Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

Figure 4 IoT gateway middleware architecture

Cluster SENSOR EVENT Again as transducer channelsTEDS it configures event triggers associated with a sensor(eg upper and lower thresholds bit patterns etc) andprovides the events

Cluster SENSOR STATS This cluster performs local prepro-cessing and analysis of the captured data This is of specialinterest when we are interested in obtaining a summaryof the observation (eg maximum values average valuesetc) As energy consumption between communication andcomputation in a wireless sensor node has a high ratio(ldquosending one bitrdquo versus ldquocomputing one instructionrdquo) [37]its implementation is especially interesting in low powerapplications

323 Endpoint ACTUATOR While sensors allow obtainingcontextual data actuators are the elements that providemeans to act over the environment In relation with theIoT an actuator can be considered as a device that trans-mits information or energy to another power mechanismor system (motors electromagnets thermocouples heaterscoolers etc) that finally alters the environment Thus athing with actuation capabilities is usually a device withcontrol outputs which is connected to an electromechanicalsystem that opens doors windows shutters control lightingheating and so forth

Cluster ACTUATOR It manages basic actions controls thestates of the actuator and defines its configuration parame-tersThese states can be as simple as onoff or define complexoperation patterns such as open the door for twominutes andthen close and lock it

324 Endpoint HMI HMI (Human Machine Interface)devices are aimed to interact with a human user In factthey could be considered as sensors and actuators to interfacepeople (in the same way that sensor and actuator connectwith the environment) But given its importance and differentuse from the application perspective it is convenient toassign its own type of endpoint CTP considers the followingclusters

ClusterHMI INPUT Itmanages configuration and operationof simple input devices interface such as buttons switches or

dimmers It also considers groups of elements such as arraysof keys to model a keypad

Cluster HMI OUTPUT It manages basic operation of simpleoutput devices such as LEDs and buzzers It also considersgroups of elements such as arrays of LEDS to model a LEDstrip

4 IoT-Gateway Architecture

According to the proposed architecture the different thingsmaybe on several NoTs must interconnect to the Internetthat is jumping to the IP world In most cases this involveschanging not only the communications protocol but alsocommunication technology which imposes the need of agateway interfacing things and Internet worlds

In the proposed architecture the gateway is not a singlebridge between protocols it is also an intelligence aggregatorand distributor of services The IoT gateway must sup-port management (discovering recruiting and connectingdevices) in the NoTs and provide interoperability betweenthem Such duty requires that the IoT gateway have enoughpower computation to handle requests and responses fromboth domains and a flexible architecture to ensure interop-erability To accomplish such task the layered middlewarearchitecture shown in Figure 4 is proposed

Lower layer of the middleware is in charge of providingbase connectivity with the NoT through the device actingas the network bridge typically a USB dongle a Bluetoothdevice or a TCP socket which results in a sort of serialconnection object allowing sending and receiving bytes asdata streams

Second layer adds meaning to those bytes implementingthe specific communication protocol of the bridge andallowing effective communication with the NoT This resultsin an object representing the bridge which encapsulatesthe communication protocol with appropriate methods andfields

Middle layer is in charge of managing the NoT throughthe usage of the bridge representation service being capableof discovering network devices (things) recruiting themand handling network unavailability At this layer objectsrepresenting network devices are available although they arealready described in terms of the underlying technology


IoT gateway

Temperature and humidity sensors

Power consumption sensors + load control

Heating energy sensor

ZigBee

Cloud services

Data aggregation

Energy consumption habits recognition

Recommendations on efficient energy usage

Proactive actions over enery

consumption

User interface

Router


Power consumption sensors

Figure 5 Test scenarios

In the next layer objects related to NoT devices aredescribed as CTP objects regardless their network tech-nology and full interoperability among things is achievedCTP objects are described as a main device representingthe endpoint BASE plus a collection of channels related toremainder endpoints

Upper layer is devoted to gateway IoT services which useCTP objects to link them to remote services (such as sendingdata to a remote database or allowing accessing a thing froma remote client) or build local services to perform offlineoperations

5 Experimentation and Results

CTP has been successfully applied in several projects butthe largest implementations have been done in two Europeanprojects ldquoEasy Line Plusrdquo [38] in the domain of AmbientAssisted Living and ldquoRenaissancerdquo [39] in the domain ofEnergy Efficient Buildings The Easy Line Plus project setsthe frame to define the CTP protocol but it was within theRenaissance project where all the aspects described abovehave been formally deployed and tested Therefore we willdescribe below the Renasissance project setup

51 Test Scenario ldquoRenaissancerdquo main objective is energysaving through the implementation of bioclimatic buildingsurban planning and rehabilitation incorporating renewableenergy and reduction of energy consumption in householdsby improving habits of energy usage by users Throughremote data analysis the system derives user patterns relatingtheir energy consumption and comfort variables and thenissues recommendations in order to increase their awarenessand enhances energy savings This requires an accurate and

long-term monitoring of energy consumption and environ-mental conditions in order to generate enough data to extractrelevant information

To meet the needs of this project the IoT paradigm isthe ideal solution The simplified structure of the systemis a number of things that ubiquitously extract contextinformation (temperature humidity heating energy andpower consumption) Through the proposed architecturethis information is handled (data aggregation data basemanagement and cloud computing) and analyzed (habitsrecognition) to provide a range of services (data visualizationuser profiling assessment of the best practices and userinformation through multimodal user interfaces)

Technically the system developed followed the archi-tecture in Figure 1 things use ZigBee standard plus CTPIoT gateway is a Linux embedded PC running the alreadypresented middleware and services run in different hosts(PC mobile phones) using data stored in the cloud Asevaluation has been done in a real and operative deploymentthe system previously ensured a number of quality require-ments such as stability ease of deployment and maintenanceand low intrusiveness in the context Similarly a number oflimitations related to the things have been solved namelyreducing power consumption to ensure months of operationwith the same batteries cost-effectiveness and reduced size

Two different types of installations have been done asfollows (Figure 5)

(i) 80m2 dwellingswith oneZigBee network formed by 3ambient (temperature + humidity) sensors 1 heatingenergy sensor 1 monophasic power consumptionsensor and an IoT gateway

(ii) 20000m2 building with one ZigBee network formedby 70 ambient sensors 20 triphasic power consump-tion sensors 17 routers and an IoT gateway


ZigBee moduleMicrocontroler

RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port

Top layer Bottom layer

Figure 6 Zigbee thing hardware implementation

In both cases although the environment is quite differentthe technological development is similar allowing assessingand evaluating CTP in different scenarios

The system has been installed and was running for 9months in 43 dwellings simultaneously (ie 43 systems) inZaragoza proven to be stable no maintenance was neededand the expected functionality was provided The buildinginstallation has been running for 6months (already running)at the University of Zaragoza [40]

52 ZigBee Network of Things Besides forming a ZigBeenetwork the sensors developed allow sensing the physicalenvironment connecting to analog or digital simple externalsensors (eg presence detector magnetic contact etc) andconnecting to external commercial smart meters (eg com-mercial electricity or heating water consumption)

The aforementioned 20000m2 building with long cor-ridors anti-fire doors and so forth is a challenging sce-nario for wireless communication network with a hundredof nodes A multihop mesh topology with an overlap ofcoverage areas and redundant communication paths wasdeployed The ZigBee network backbone is formed by 17routers 1 network coordinator and a data sink connectedto the IoT gateway The infrastructure is devoted to keeprouting tables to date and interconnect 90 CTP things (70ambient sensors and 20 power consumption sensors) thatare ZigBee Sleepy End Devices Any sensor enters lowpower mode between measurements being disconnectedfrom the network along this time and its father (a router)holds its messages Periodically sensors poll their parentsto check for incoming messages This time between pollsintroduces latency in the communication but reduces energyconsumption of the thing to avoid possible loss of messagesit is set to 4 seconds Also time between measurementstime between sending data timestamping and so forth canbe configured in order to balance power consumption andapplication requirements In this application environmentalnodes measure and immediately send data every 10 minutes

while power consumption sensors measure and store dataevery minute and then send it every 10 minutes As it is notnecessary thatmeasures are simultaneous the update processof the system is randomized to reduce the probability ofseveral things trying to send messages at the same instantwhich would increase medium access time and thereforeenergy consumption

521 Hardware Hardware implementation (Figure 6) isdesigned to be versatile Device implementation is based ina dual hardware architecture where a low power microcon-troller (PIC18F26J11) runs the main application and controlsthe network coprocessor that implements ZigBee Pro stack(Ember 357) After deep analysis and experimentation wefound architecturemore efficient in terms of power consump-tion than using a system on chip solution (embedding a radiomodule plus a programmable microcontroller) as it allowssplitting tasks between two specialized microcontrollers onefor sensing and processing tasks and the second for com-munication [41] The device additionally has an EEPROMmemory a real time clock expansion ports a button a LEDand a temperature and humidity digital I2C sensor (SensirionSHT21) Along with these onboard capacities the hardwarefeatures two expansion ports first for connection of externalanalogdigital sensors and second for communications toexternal systems Thanks to them different things are built anoninvasive AC current sensor (a SCT-013-000 0-100A splitcore current transformer) enables power consumption sensorand a communication port connected to a commercial device(Kamstrup) for measuring heating water consumption

522 Firmware Accordingly the basic configuration of thedevice (only onboard capabilities) presents 5 endpoints base(base type) temperature (sensor type) humidity (sensortype) button (HMI type) and LED (HMI type) Note thatalthough SHT21 sensor is a single electronic component thatmeasures temperature and humidity there are two differentendpoints one for each magnitude


Nevertheless similar to IEEE1451 access to both end-points is possible using the proxy cluster within the baseendpoint According to the devices connected to the portsdescribed above news endpoints (power and heating waterconsumption both sensor types) are added when necessaryThe CTP protocol is therefore suited to the different charac-teristics of the hardware while performing an abstraction ofit

Clusters implemented per endpoint are as follows

(i) BASE device power (for battery level monitoring)time (to provide timestamps) proxy and behavior (toprogram clima control when event happens)

(ii) SENSOR sensor (to provide single measurements)sensor event (to get events when upper and lowerthresholds are surpassed) and sensor stats (to providemaximum and minimum levels)

(iii) HMI HMI input (to handle button events) and HMIoutput (to handle LED operation)

The use of CTP provides a structured and simple pro-gramming strategy which results in modular code with highreusability Figure 7 shows a simplified view of the proposedstructure for a common firmware of a thing configurationof the microcontroller peripherals ZigBee communicationsand CTP and system behavior

53 IoT Gateway An embedded computer running Linuxwhere the middleware described before was implementedacts as the IoT gateway The middleware architecture fallswithin the SOA (Service Oriented Architecture) paradigmand we use OSGi [42] (Open Services Gateway initiative) asdevelopment framework OSGi defines a framework wherepieces of code are organized into bundles that can bemanaged separately OSGi bundles are agents whichmight bededicated to specialized tasks such as handling a serial portproviding a command line interface collecting aggregatingand analyzing data and so forthThese bundles communicateand interact with each other by means of services which arepublishedwithin the framework and each bundle can acquireand utilize themThemain strength ofOSGi is that the frame-work manages these bundles dynamically allowing them tobe upgraded without terminating the full application as wellas enabling the availability of the services to other bundlesdepending on the situation That allows us provinding newfeatures and capabilities to the IoT Gateway by adding newservices which may use the services already existing in theframework but keeping current features unaltered

Using OSGi as development framework also eases devel-opment of the middleware layers as we may focus onone single layer when developing comprising one of morebundles while the whole application layers will be arrangedon execution time Middle-layer interfaces are also defined tospecify interoperability among adjacent layers and eliminatedirect dependencies among bundles implementing each layerAccording to Figure 8 the different layers have the followingobjectives

(i) The network bridge is a USB dongle with a ZigBeemodule that can be controlled through an AT com-mand interface on a serial port On the lower layerthe Serial Communication middle interface definesa SerialConnection service which basically allowswriting bytes and notifies about incoming bytes anda SerialDriver service which is in charge of creatingand discovering available SerialConnection servicesMain bundle implementing this layer operates theUART interface but other stream-based interfacessuch as a Bluetooth connection may adopt the samemiddle-layer interface allowing communication withBluetooth devices transparently to the upper layersIn our particular case we have implemented anapplication service that wraps a SerialConnectioninto a TCP socket and at the remote client anotherbundle creates a SerialConnection services that allowscommunication with the SerialConnection serviceson the server side like a local one This would allowany service on the Internet to remotely handle theserial port traffic which is very useful for debuggingor auditing deployed IoT systems

(ii) On the NoT Bridge Interpretation layer a Zigbee-Gateway bundle looks for newly created SerialCon-nection services checks if they correspond to the Zig-bee USB dongle and creates ZigbeeGateway servicesimplementing the AT command protocol in such acase Again the ZigbeeGateway service is defined inthe ZigbeeGateway middle interface which isolateslayers and allows using different versions of the USBdongle

(iii) Above that there is a ZigbeeDriver which uses theZigbeeGateway to accomplish network managementtasks such as network creation or device enumer-ation and a Driver Manager which uses the Zig-beeDriver to perform automatic maintenance taskssuch as message route maintenance It would bepossible to aggregate these services into a singleone but that will introduce complexity and hinderinteroperability whereas using separated servicesincreases reliability and robustness as units of code aresmaller and easier to test This allows also deployinggateway facilities to accomplish transversal taskssuch as network monitoring debug maintenanceand commissioning which may use limited parts oftheDriver Layer In the case of having other networksthe scheme is similar The ZigbeeDriver will createZigbeeNode services representing nodes in the net-work which allows sending and receiving messagesto and from the physical device and provides Zigbeerelated properties such as its MAC address or its type

(iv) On the CTP Devices layer a CTP Driver service willuse the ZigbeeNode services to create CTP Deviceservices representing the real devices available on theNoT following the CTP definition This layer isolatesdevicesrsquo technology and registers them attending totheir nature in order to provide interoperability atemperature sensor always provides temperature the


Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc

ctpDeviceDefinitionh

zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh

ctp2ZBcctpParseInputc

ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc

CommManagercctpManagerc

InitialitationEventManagerc

DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc

Figure 7 ZigBee thing firmware implementation

same way regardless its technologyThere are also dif-ferent gateway facilities at this level (web services andTCP sockets) providing Internet access and virtualrepresentation in order to allow remote applicationsto use NoT infrastructure

(v) At the IoT services layer a Data Collector servicetracks for CTP Device services of type Sensor sub-scribes itself to receive a notification when a newsensor value is received and sends a data report toa remote database where it can be accessed fromelsewhere

At this point local network devices which were notable to reach the IoT by themselves are now represented

by OSGi services which are smart enough to operate onthe IoT and among them Internet applications access-ing those things require address resolution services whichallow reaching them through an URL [2] This is over-come by delegating thingsrsquo addresses resolution to the IoTgateway which forwards incoming requests to the physicalthing Thus accessing things from the Internet is grantedby knowing the IoT gateway address It is also feasiblethat things themselves access the IoT services directly forexample we feed data from sensors to IoT services onthe cloud specialized on data managing like Cosm [43] orNimbits [44]

On top of the middleware described and thanks to theOSGi modularity we also have developed communicationsterminal to sniff ZigBee communication (mainly intended as


Publish 11

Publish 11

Communication linklowast 1

Publish 1lowast

Publish 11Communication linklowast 1

Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer

NoT management layer

NoT Bridge Interpretation layer

NoT Bridge Connectivity layer

ltltInterface bundlegtgtSerialCommunication

middle interface

SerialConnectionservice

SerialDriverservice

ltltImplementation bundlegtgtSerialCommunication

Bundle

Defined inDefined in

ZigbeeGatewaybundle

Uses

ZigbeeGatewayservice

ltltInterface bundlegtgtZigbeeGatewaymiddle interfaceDefined in

ZigbeeDriverbundle

Uses

ZigbeeDriverservice

ltltinterface bundlegtgtZigbeeDriver

middle-interface

Defined inltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses

ltltImplementation bundlegtgt



CTP Driverbundle

ltltObjectgtgtCTP Driver

service

ltltInterface bundlegtgtCTP

middle interface

Defined inltltObjectgtgtCTP Device

service

Defined in

ltltImplementation bundlegtgtData Collector

bundle

ltltObjectgtgtData Collector

Service

Uses

Internet Data cloud

Publish 11

Publish 11


11Communication link

Creates 1lowast

Creates 1lowast

Creates 1lowast



a development tool for hardwarefirmwaresoftware develop-ers) and aNetworkManager that allows full management andcommissioning of deployed ZigBee networks

54 System Performance The system deployed is built by abackbone of 19 nodes (1 coordinator 17 routers and 1 datasink) that exchange network management messages Also 90sleepy sensors poll their parents every 10 seconds and reportthe data sink every 10 minutes Due to network topologysome sensor messages must be relayed by routers up tofive times to get to the data sink which passes them to theIoT gateway that maintains networkrsquos virtual image checksdata inconsistencies registers loss of expected messages anduploads data to exploitation database These processes allownetwork commissioning node-problem targeting and dataintegrity validation

Evaluating the quality of service (QoS) of an IoT appli-cation is not easy as it is a large and complex systembased on heterogeneous technology and high applicationdependency Currently there are not well-defined standardmetrics that can be used as a common agreed andwidespreadcomparison of IoT systems derived from this applicationspecificity researchers usually define their own metrics [45ndash47] As IoT is usually made up by different subsystems it ispossible to analyze the layers separately for example thereare manymetrics to evaluate the effectiveness of data transferin networks [48] however the success of an IoT should beassessed as a whole not just one particular aspect of thearchitecture [49]

The system proposed uses 90 sensors to deterministicallymeasure ambient and power consumption information andmake it available in the IoTThree different areas are assessedrelative and absolute energetic cost data efficiency andmessage latency

Data efficiency considers the amount of data generated inthe ZigBee network and the data correctly stored in the clouddatabase Similar indicators are used to assess the quality ofa communication network in which case it is common toconsider lost messages and total messages However for theglobal evaluation of the IoT is preferable to consider bothends of the system thus we use themessages generated by thephysical things and the amount of data available in the logicalscope Note that if there would be nondeterministic events(eg alarms presence detection etc) the data generatedin the IoT will not be known a priori and also difficult tomeasure We define the data efficiency of the IoT DEIoT as

DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)

whereDAIoT is the data available on the IoTDGNoT is the datagenerated by the NoT 119899 is the number of things MS

119894is the

number of messages sent by thing 119868 and ND119894is the amount

of data sent in each message (we assume this is constant forall the messages sent by a thing) This value can be measuredaccumulated or disaggregated in different periods to assessthe variation of stability over the time In our case we checkthe number of new registers in database and consideringthat the total number of inputs should be 12960 per day

35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16

1 hop 2 hops 3 hops 4 hops 5 hops

(s)

Figure 9 Latency time intervals

(defined by the number of things and their scheduling) wecan calculate the ratio In our case the accumulated dataefficiency is 983 It has been found that in general errors aredue to failures on the electrical supply or Ethernet networknot directly attributable to the system

Message latency quantifies the availability of a thing inorder to exchange information with it Again we considerthis availability from the IoT layer that is how much timetakes to force a sensor to refresh and effectively update thedata in the cloud There are two main factors that influencethis indicator how many hops away from the gateway is thesensor and how much time does the sensor spend in sleepmode (ie disconnected from the ZigBee network)Thus wedefine the message latency per hop MLH

119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)

where RT119894119895is the response time for thing 119894 which is 119895

hops away from the gateway and 119899119895is the number of

things being 119895 hops away from the gateway Figure 9 showsthe latency intervals (in seconds) within a 95 confidenceinterval according to the distance in hops between sensor andgateway If we need to provide a global metric of the systemlatency we would say it will be between 06 s and 159 s

Energy consumption of a device is a common indicatorof its efficiency In the particular case of IoT we must takeinto consideration the consumption of the things andalsocommunications infrastructure (routers) and logical infras-tructure (gateway) Given the data volume managed energyconsumption of routers and gateway is independent from theamount of data sent by things and the absolute energetic costof the system over time AEC(119905) can be defined as follows

AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)

where 119875Gtw is the power consumption of the gateway 119875119877

is the power consumption of a router 119899119877is the number of

routers 119875119894is the power consumption of thing 119894 and 119899 is the

number of things As we show in [41] to calculate a thingrsquospower consumption a good characterization of its duty cycleis required We have defined the figure of merit of power


minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()

Number of things added

Ambient sensorPower sensorRouter

Figure 10 Relative energetic cost variation with respect to theproposed scenario when including new devices

consumption for each type of thing and the routers and weconsider constant the power consumption of the gatewayFor the proposed IoT the absolute energetic cost in oneday is 1976MJ (549 kWsdoth) It is important to remark thatonly 0013 of the energy is due to things battery-powereddevices Given that in the proposed scenario the numberof data and time are directly related we can also define therelative energetic cost REC as the energy required per byte ofprocessed data during a day

REC = AEC (119905)DAIoT

100381610038161003816100381610038161003816100381610038161 day (4)

For the present IoT application we have a relativeenergetic cost of 12197 J per byte sent This includes 15mJcorresponding to the energy drained from batteries Thisparameter is related to the scalability of the network if weenlarge the communications infrastructure (more routers tohave broader coverage) and increase the number of things (tohavemoremeasurement points) relative energetic cost variesas in Figure 10

Including new sensors supposes decreasing the REC asthey provide additional data with reduced energy consump-tion Specifically power sensor consumption is related toa better REC than ambient sensor as it sends more data(44 bytes versus 4 bytes) with a similar energy consumptionAs expected including routers improves network backboneandor range but worsens the metric as they do not increaseDAIoT

6 Discussion

Main conclusion of the described field trial is that architectureand the protocol proposed are feasible in large and long-termIoT deployments Also it demonstrates that implementationof CTP over ZigBee in order to create low power things(running with batteries for a year) that efficiently integratesin an IoT system is possible As we developed the wholesystem from the hardware design of things to the serviceimplementation our concerns have been from the limited

resources of hardware and firmware to the versatility andgenerality required by applications

In order to analyze under which circumstances CTPis a convenient option Table 1 compares it with main IoTprotocols mentioned in Section 2 Three different levels areidentified (1) standard communication protocols (6lowPANRFID WiFi Cellular ZigBee and Bluetooth) (2) protocolsabstracting from communication media and being mountedover the protocolrsquos payload (IEEE1451 CTP) and (3) proto-cols assuming IP connectivity on anything (CoAP RESTfull-HTTP XMPP MQTT SensorWeb EEML and SenseWeb)Comparison items are as follow

(i) Application layer interoperability among things indi-cates whether things can effectively exchange infor-mation among them for example if a light controller(protocol A) can be operated by a light sensor (pro-tocol B) Communication standards (1) are limited onthis because they are not intended to define how tointeroperate with other standards On the other sideprotocols abstracting from communication standard(2 3) are precisely designed to enable this featureAlso IP-based protocols (3) are more restrictive asthey need that things are IP enabled

(ii) Thingsrsquo representation models indicate if the protocolprovides a virtual representation of things for exam-ple a temperature sensor has some characteristics(range accuracy etc) and provides some methods(get temperature measurement configure it etc)The protocols that just consider data exchange (eg6LowPAN WiFi or MQTT) do not provide this def-inition hindering interoperability ZigBee and Blue-tooth define some things those considered in theirapplications IEEE1451 CTP and SensorWeb definehow anything needs to be specified for example thedatasheet format

(iii) Thingsrsquo interaction model interaction means on stepfurther than representation as it implies providingrelationships among things for example how a lightcontroller can be operated by a light sensor

(iv) Suitability for low power and lossy networks thisrelies very much on the possibility to run on wirelesssensor network standards mainly ZigBee and 6Low-PAN

(v) Simplicity and exhaustiveness are important featuresthat determine adoption of protocols For exampleIEE1451 is a very exhaustive protocol defining every-thing in a sensor but precisely this makes its usecomplicated by an app developer that just wantstemperature value of a sensor

According to Table 1 most similar protocols are CTPIEEE1451 and ZigBee Cluster Library In order to make amore detailed comparison among them we define a scenariobased on a ZigBee temperature sensor where these threespecifications are encapsulated in the payload of the ZigBeeapplication layer (Figure 11)


Table 1 IoT protocols comparison

Application layer interoperability among things

Thingsrsquorepresentation

models

Thingsrsquointeraction

model

LLN (Low Power and Lossy Networks) suitability

SimplicityExhaustiveness

and level of detail

1

6lowPAN RFID WiFi and Celular

Limited to standard (stack layer)

No No 6lowPAN excellentOthers fair

Not applicable (App layer not defined)


ZigBee Cluster Library Bluetooth

Profiles

Limited to standard (App layer)

Yes but limited to specificapplications


ZigBee excellentBluetooth fair Good Excellent

2

IEEE1451 Full (delegated to NoT protocol)

Yes but limited to sensor and actuators


Excellent Good Excellent

CTP Full (delegated to NoT protocol) Yes Yes Excellent Excellent Good

3

CoAPRESTfullHTTPXMPP MQTT

Full (delegated to IP protocol) No No CoAP good (UDP)

Others fair (TCP)



SensorWeb EEML SenseWeb

Full (delegated to IP protocol) Yes No Fair (TCP) EEML Excellent

Others FairEEML GoodOthers Excellent

PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint

APDcounter Payload CRC

ZigBee application layerFramecontrol

SEQnumber Add Inf Data payload CRC

1 byte 1 byte 1 byte2 bytes 2 bytes 2 bytes 2 bytes

IEEE802154 MAC layer

IEEE802154 physical layer

Figure 11 ZigBee protocol encapsulation

Communication is established through requests and cor-responding responses Table 2 contains the frame descrip-tions for the three cases Each frame includes different fieldsdefined in the specifications

In order to use the temperature sensor several requestsneed to be answered by the sensor (1) retrieving gen-eral information about the device (2) retrieving chan-nelendpoint mandatory information and (3) retrievingtemperature measurement If using ZCL sensor temperaturemust be 2 bytes in length in degrees Celsius and specifiedin the range from minus27315∘C to 32767∘C with aresolutionof 001∘C Thus step 2 is not needed as information aboutthe measure is already defined This is positive in termsof easy use but limitative in some cases if using CTP orIEEE 1451 variables such as accuracy range units and soforth are open to the hardware developer and must bespecified in the channelendpoint mandatory informationTable 3 indicates the number of bytes exchanged for each

action and the number of variables encoded It shouldbe noted that just mandatory fields are considered in thetable

Regarding protocol efficiency it is obvious that ZCL is themost efficient but this has important implications as ZCLfocuses on specific application domains (home and buildingautomation health etc) if the thing is not specified in thestandard or the representation of the information differs fromit its implementation is not possible and thus it will not beinteroperable For example there is no way to use inertialsensors according to ZCL

On the other hand IEEE 1451 is the heaviest protocolbecause it leaves open a lot of variables This flexibility turnsto be itsmain drawback to be used in IoT applications becauseit makes it too complicated for developers not versed intoelectronics Additionally as it is more oriented to electronicsthan to application it does not consider human-machineinterfaces in its specification just sensors and actuators


Table 2 Frame description of IEEE 1451 CTP and ZCL

Header Payload

IEEE 1451

Request(6 + n) bytes

Response (3 + n) bytes

CTP CTP Frame(5 + n) bytes

ZigBeeCluster Library

ZCL Frame(5 + n) bytes

Destination transducer channel 2bytesCommand Class 1byteCommand Function 1byteOffset Length 2bytes

Success flag 1byteOffset Length 2bytes

Endpoint destination 1byteLength 2bytesCluster identification 1byteCommand identifier 1byte

Frame Control 1byteManufacturer code 2bytesTransaction sequence number 1byteCommand identifier 1byte

Id attribute 2bytes

Data nbytes

Value attribute nbytes

Value attribute m nbytesId attribute m 2bytes

Data nbytes

Data nbytes

Table 3 Number of payload bytes (differentiating request + response) and variables associated

IEEE 1451 CTPZigBee Cluster

LibraryObservations

Bytes Variables Bytes Variables Bytes Variables

Retrieve general information about the

device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1

In case of ZCL information obtained is partial same amounttype of variables must be done from a lower level of the protocol at ZigBee Device Object42 (7 + 35)

Retrieve channelendpoint mandatory information

111 (7 + 104)18

34(5 + 29)

7 ZCL strictly defines the nature of the variables in each cluster so no need to declaration 33 (7 + 26)

Retrieve temperature measurement

12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash

As a summary CTP is a balanced protocol especiallysuited for the IoT allowing definition of any device and justspecifying those variables that are needed at application levelAs it can be efficiently encapsulated in any communicationprotocol it is strongly focused on the interoperability ofthings while considering their technical limitations (energyprocessing and communication capabilities) CTP is basedon an ontological representation and interactionmodel thusbesides interoperability it allows local intelligence and inter-action among things Also as it describes the characteristicsand properties of things higher-level protocols can use it as asource of information

7 Conclusions

IoT is perceived as a huge generator of services and appli-cations but it requires that two important issues to besolved thingsrsquo connectivity (communication of the physicalthings with the Internet) and interoperability at all levels(understanding of the information exchanged) This paperemphasizes the need to maintain an integrative and broadpoint of view when considering architectures and proto-cols for IoT Considering IoT development areas and their

associated technologies an architecture and protocol witha comprehensive view considering current technologicalcapabilities at all levels (services gateway communicationsfirmware and hardware) are proposed

In order to tackle connectivity challenge the appropriate-ness of using gateway-based solutions to connect Networksof Things with the Internet has been discussed This isconsidered an optimal way to solve the problem of theheterogeneous networks jumping from the real world tothe IP world and ensuring the unambiguous designation ofeach of the things in the Internet performing a tunnelingprocess (eg the need of a unique identification) Regardingthe functionality of the IoT gateway the use of layered andmodular middleware architecture to constitute a versatileinteroperable scalable and easy to maintain system has beenproposed

Common Things Protocol (CTP) has been presented asa solution to provide interoperability among things Mainguidelines considered in its design are an ontological repre-sentation and interaction model of things andimplementa-tion feasibility in standard communication protocols CTPreflects the need for equilibrium between the networks ofthings data traffic and virtualized world of things which


is not common in the current proposals Main principlesof CTP are self-description of the nature and capabilitiesof the thing organization capabilities through the endpointand cluster concepts simplifying the use of the thing instandard situations through mechanisms such as modes andscenarios allowing distributed intelligence by using bindingsand behaviors and being simple and compact to ease itsimplementation fitting on current standard communicationprotocols

The IoT architecture (ZigBee network of things IoTgateway and related Internet services) and CTP proposalhave been implemented in two European research projectsrelated to smart environments for Ambient Assisted Livingand energy efficiency The paper describes specific hardwareand software implementations and deployment in large scaleenvironments with real end users during periods of severalmonths We also measure energetic cost data efficiency andmessage latency metrics demonstrating proposalrsquos feasibilityand suitability in order to meet current IoT requirements

This paper does not intend to define a standard but an ini-tial proposal to adopt a minimum agreement (currently notconsidered in the state of the art) with a global and inclusivevision that facilitates the development of the IoT To this endit should be mentioned that most of the developments shownhave been carried out under open source license in particularCTP is accessible and well documented [50]

Conflict of Interests

The authors declare that there is no conflict of interestsregarding the publication of this paper

References

[1] I T Union ldquoITU Internet Reports 2005The Internet ofThingsrdquo2005

[2] L Atzori A Iera and G Morabito ldquoThe Internet of Things asurveyrdquoComputer Networks vol 54 no 15 pp 2787ndash2805 2010

[3] G Kortuem F Kawsar V Sundramoorthy and D FittonldquoSmart objects as building blocks for the internet of thingsrdquoIEEE Internet Computing vol 14 no 1 pp 44ndash51 2010

[4] R V Kulkarni A Forster and G K Venayagamoorthy ldquoCom-putational intelligence in wireless sensor networks a surveyrdquoIEEE Communications Surveys and Tutorials vol 13 no 1 pp68ndash96 2011

[5] ISTAG ldquoOrientations for EU ICT RampD amp Innovationbeyond 2013-10 keys recomendationrdquo July 2011 httpcordiseuropaeufp7ictistagdocumentsistag key recommenda-tions beyond 2013 fullpdf

[6] M Swan ldquoSensor Mania The Internet of Things WearableComputing Objective Metrics and the Quantified Self 2 0rdquoJournal of Sensor and Actuator Networks vol 1 no 3 pp 217ndash253 2012

[7] ldquosensei (Real World Dimension of the NEtwork of the Future)rdquohttpwwwict-senseiorgindexphp

[8] ldquoIoT- A (Internet of Things Architecture)rdquo httpwwwiot-aeupublic

[9] ldquoInternet of Things Strategic Research Roadmaprdquo EuropeanCommission-Information Society and Media DG-BU31 0118B-1049 Brussels Belgium 2009

[10] D Uckelmann M Harrison and M Florian ldquoAn architecturalapproach towards the future internet of thingsrdquo in Architectingthe Internet of Things pp 1ndash24 Springer 2011

[11] D Miorandi S Sicari F de Pellegrini and I ChlamtacldquoInternet of things vision applications and research challengesrdquoAd Hoc Networks vol 10 no 7 pp 1497ndash1516 2012

[12] MQTT httpmqttorg[13] ldquoipSo Alliancerdquo httpwwwipso-allianceorg[14] T Uslander A Berre C Granell et al ldquoThe future internet

enablement of the environment information spacerdquo in Proceed-ings of the International Symposium on Environmental SoftwareSystems (ISESS rsquo13) Neusiedl am See Austria 2013

[15] C Gomez J Paradells and J Caballero Sensors EverywhereWireless Network Technologies and Solutions Fundacion Voda-fone Espana 2010

[16] A Kapadia S Myers X Wang and G Fox ldquoSecure cloud com-putingwith brokered trusted sensor networksrdquo inProceedings ofthe International Symposium on Collaborative Technologies andSystems (CTS rsquo10) pp 581ndash592 May 2010

[17] A Ibarz G Bauer R Casas AMarco and P Lukowicz ldquoDesignand evaluation of a sound based water flow measurementsystemrdquo Lecture Notes in Computer Science vol 5279 pp 41ndash542008

[18] ZigBee Specification ldquoZigBee Cluster Library Specificationrdquo(053474r17) 2008

[19] Y-F Lee H-S Liu M-S Wei and C-H Peng ldquoA flexiblebinding mechanism for ZigBee sensorsrdquo in Proceedings ofthe 5th International Conference on Intelligent Sensors SensorNetworks and Information Processing (ISSNIP rsquo09) pp 273ndash278December 2009

[20] C Bormann A P Castellani and Z Shelby ldquoCoAP anapplication protocol for billions of tiny internet nodesrdquo IEEEInternet Computing vol 16 no 2 pp 62ndash67 2012

[21] XMPP Standards Foundation ldquoXMPP Standardrdquo httpxmpporg

[22] ldquoConstrained RESTful Environments (core)rdquo httpsdata-trackerietforgwgcorecharter

[23] ldquoHow Can IEEE 1451 Be Appliedrdquo June 2007 httpieee1451nistgov

[24] I I a M Society IEEE Standard for a Smart TransducerInterface for Sensors and Actuators 2007

[25] D Sweetser V Sweetser and J Nemeth-Johannes ldquoA modularapproach to IEEE-14515 wireless sensor developmentrdquo in Pro-ceedings of the IEEE Sensors Applications Symposium pp 82ndash87February 2006

[26] J Higuera J Polo and M Gasulla ldquoA ZigBee Wireless sensornetwork compliant with the IEEE 1451 standardrdquo in Proceedingsof the IEEE Sensors Applications Symposium (SAS rsquo09) pp 309ndash313 February 2009

[27] J E Higuera and J Polo ldquoIEEE 1451 standard in 6LoWPANsensor networks using a compact physical-layer transducerelectronic datasheetrdquo IEEETransactions on Instrumentation andMeasurement vol 60 no 8 pp 2751ndash2758 2011

[28] ZWemlinger and L Holder ldquoTheCOSE ontology bringing thesemantic web to smart environmentsrdquo inTowardUseful Servicesfor Elderly and People with Disabilities vol 6719 pp 205ndash209Springer 2011

[29] D Bonino E Castellina and F Corno ldquoDOG an ontology-powered OSGi domotic gatewayrdquo in Proceedings of the 20thIEEE International Conference on Tools with Artificial Intelli-gence (ICTAI rsquo08) pp 157ndash160 November 2008


[30] W Wang S De G Cassar and K Moessner ldquoKnowledgerepresentation in the internet of things semanticmodelling andits applicationsrdquo Automatika vol 54 no 4 pp 388ndash400 2013

[31] B Christophe ldquoSemantic profiles to model the lsquoweb of thingsrsquordquoin Proceedings of the 7th International Conference on SemanticsKnowledge and Grids (SKG rsquo11) pp 51ndash58 October 2011

[32] E Y Song and K Lee ldquoUnderstanding IEEE 1451mdashnetworkedsmart transducer interface standardmdashwhat is a smart trans-ducerrdquo IEEE Instrumentation and Measurement Magazine vol11 no 2 pp 11ndash17 2008

[33] R Johnson and S P Woods ldquoProposed enhancements to theIEEE 1451 2 standard for smart transducersrdquo September 2009httparchivessensorsmagcomarticles090174mainshtml

[34] M Compton P Barnaghi L Bermudez et al ldquoThe SSN ontol-ogy of theW3C semantic sensor network incubator grouprdquoWebSemantics vol 17 pp 25ndash32 2012

[35] L Feng P M G Apers and W Jonker ldquoTowards context-aware data management for ambient intelligencerdquo in Databaseand Expert Systems Applications vol 3180 of Lecture Notes inComputer Science pp 422ndash431 Springer 2004

[36] S Petersen and S Carlsen ldquoWirelessHART versus ISA10011athe format war hits the factory floorrdquo IEEE Industrial ElectronicsMagazine vol 5 no 4 pp 23ndash34 2011

[37] I F Akyildiz W Su Y Sankarasubramaniam and E CayircildquoWireless sensor networks a surveyrdquo Computer Networks vol38 no 4 pp 393ndash422 2002

[38] European 6th Framework Programme for Research and Tech-nological Development ldquoEasy Line Plusrdquo httpwwweasyline-pluscom

[39] C P E Commision ldquoRenaissancerdquo httpwwwrenaissance-projecteulang=en

[40] U o Zaragoza ldquoLiga Energetica edificio I+D+irdquo httpproy-ectosostenibilidadunizaresinstitutosindexphpmonitoriza-cion

[41] A Asensio R Blasco A Marco and R Casas ldquoHardwarearchitecture design for WSN runtime extensionrdquo InternationalJournal of Distributed Sensor Networks vol 2013 Article ID136745 11 pages 2013

[42] O A website ldquoOSGi Alliance websiterdquo httpwwwosgiorgMainHomePage

[43] httpwwwcosmcom[44] httpwwwnimbitscom[45] MW Ryu J Kim S S Lee andMH Song ldquoSurvey on internet

of things toward case studyrdquo Smart Computing Review vol 2no 3 2012

[46] M Paschou E Sakkopoulos E Sourla and A TsakalidisldquoHealth Internet of Things metrics and methods for efficientdata transferrdquo SimulationModelling Practice andTheory vol 34pp 186ndash199 2013

[47] A P Castellani N Bui P Casari M Rossi Z Shelby and MZorzi ldquoArchitecture and protocols for the internet of things acase studyrdquo in Proceedings of the 8th IEEE International Confer-ence on Pervasive Computing and Communications Workshops(PERCOM rsquo10) pp 678ndash683 April 2010

[48] S Forsstrom P Osterberg and T Kanter ldquoEvaluating ubiqui-tous sensor information sharing on the internet of thingsrdquo inProceedings of the IEEE 11th International Conference on TrustSecurity and Privacy in Computing and Communications 2012

[49] J Gubbia R Buyyab SMarusic andM Palaniswami ldquoInternetof Things (IoT) a vision architectural elements and future

directionsrdquo Future Generation Computer Systems no 29 pp1645ndash1660 2013

[50] HOWLab 2013 httpopenlabunizaresindexphpconocim-ientoctp

International Journal of

AerospaceEngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014

RoboticsJournal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Active and Passive Electronic Components

Control Scienceand Engineering

Journal of



RotatingMachinery


Hindawi Publishing Corporation httpwwwhindawicom

Journal ofEngineeringVolume 2014

Submit your manuscripts athttpwwwhindawicom

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics


Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014

SensorsJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation



DistributedSensor Networks



Internet

Network of things B

Network of things A

Things world

Internet world

Physicaldata network layer

Stack layer

Application layer

phyethernet IP layer

TCP UDP layer

Application layerIoT bundle layer

IoT gateway

Data and services world

Cloud and data services

Autonomous systems

User oriented servicesU

nder

stan

ding

wal

l

IP w

all

Figure 1 IoT architecture

different standards are commonly used to provide connec-tivity ZigBee RFID Bluetooth 6lowPAN WIFI 3G and soforth Many works evidence the importance of selecting themost appropriated technology in each situation comparingthem in terms of network topology coverage data through-put or energy consumption In any case the more data youneed to exchange the further you need to communicatethe more time you need to be online then more energyyou need and consequently the quicker you will run out ofbatteries

The arrival of IoT will lead to appearing multitude of newservices improving the quality of life of people and offeringnew business opportunities Ultimately the IoT is expectedto bring a revolution in the concept of society similar tohow Internet changed the concept of communications andinformation [5] In the last few years initiatives and projectrelated with IoT have been growing in number and scopethroughout the entire world The IoT concept is becomingtremendously popular and already appearing systems thatclaim to offer IoT solutions to the final user without hightechnical requirements [6] Current developments are in earlystages being most of the services based on monitoring orsensing variables to extract information and then analyze andrepresent them [7]

It is considered that the development of IoT will play animportant role in the near future thus public and privateinvestments have been made in RampD demonstration anddeployment activities [8 9] To date most of IoT solutionsare small subnets of interconnected objects It is not possibleto talk about IoT until all objects are interconnected and toimprove this interconnectivity an architecture that ensuresinteroperability between systems is mandatory Thus bothpublic and private initiatives are currently focusing on stan-dardization of the IoT [10ndash14]

In summary the evolution of IoT implies overcoming realthingsrsquo limitations enabling them to communicate with theInternet using a common language In this paper we proposeCTP (Communication Things Protocol) as an ontology-based solution to enable understanding among things andthe use of an IoT gateway to take things to the Internetworld

2 Internet of Things

21 Architecture Most IoT implementations follow an archi-tecture that contains different worlds each of them with theirown characteristics Figure 1 shows an example [15]

The things world relates to michroelectromechanicalsystems smart sensors simple human-machine interfaces(HMIs) and so forth which associate in networks (Networksof Things NoT) to ubiquitously interact with other thingsthe environment andor people NoT are usually resource-challenged ecosystems typically with medium-high timeaccess delays high error rates low data throughput andlimited online time where energy consumption must beoptimized to the maximum In a simplified model of a thingbasic blocks of communication computation and interaction(sensors actuators and HMI) are distinguished

The Internet world usually is constructed around com-puters centralized software infrastructures or in the cloud[16] Applications and services use things to provide contextawareness artificial intelligence affective computing and soforth [16] Depending on their consideration tablets andsmartphones can be included in both worlds Neverthelessdue to their power (computing communications batterylifetime user interfaces etc) we find it more appropriateto consider them closer to the world of computers andInternet than to the world of things Currently Internet actsas the base infrastructure for the exchange of informationHowever access to it has several constraints such as theneed for unique identifier the change of communicationtechnology and the adoption of the Internet ProtocolsNowadays this ldquoIP wallrdquo is usually jumped through an IoTgateway

Internet is the global interconnectionmethodwheremul-titude of services and applications use extracted informationof IoT to provide services to end users On each of themneeds are a virtual representation of the things of the IoTin order to enable interaction Once ldquoIP wallrdquo is saved andthanks to the connectivity provided by the Internet servicescan access the information but for the information to beuseful it must be understood and this poses what we call theldquounderstanding wallrdquo






















Energy sources

Human interface

Communications


























EndpointCluster

Device cluster


PingResetSelf-check

Location cluster


Time cluster


Power cluster


Proxy cluster



Get sensor data



Sensor rearm

Sensor event


Set actuator status


Clear sensor stats

HMI input cluster



HMI input status



Power event


Get proxy data


Execute behavior


Endpoint BASE

Alarm raised









Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation






























Energy sources

Human interface

Communications


























EndpointCluster

Device cluster


PingResetSelf-check

Location cluster


Time cluster


Power cluster


Proxy cluster



Get sensor data



Sensor rearm

Sensor event


Set actuator status


Clear sensor stats

HMI input cluster



HMI input status



Power event


Get proxy data


Execute behavior


Endpoint BASE

Alarm raised









Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation


















Energy sources

Human interface

Communications


























EndpointCluster

Device cluster


PingResetSelf-check

Location cluster


Time cluster


Power cluster


Proxy cluster



Get sensor data



Sensor rearm

Sensor event


Set actuator status


Clear sensor stats

HMI input cluster



HMI input status



Power event


Get proxy data


Execute behavior


Endpoint BASE

Alarm raised









Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation

























EndpointCluster

Device cluster


PingResetSelf-check

Location cluster


Time cluster


Power cluster


Proxy cluster



Get sensor data



Sensor rearm

Sensor event


Set actuator status


Clear sensor stats

HMI input cluster



HMI input status



Power event


Get proxy data


Execute behavior


Endpoint BASE

Alarm raised









Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











EndpointCluster

Device cluster


PingResetSelf-check

Location cluster


Time cluster


Power cluster


Proxy cluster



Get sensor data



Sensor rearm

Sensor event


Set actuator status


Clear sensor stats

HMI input cluster



HMI input status



Power event


Get proxy data


Execute behavior


Endpoint BASE

Alarm raised









Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













Layer 3-CTP devices






Tech

nolo

gy d

epen

denc

y

Inte

rope

rabi

lity

















IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










IoT gateway




ZigBee

Cloud services

Data aggregation




consumption

User interface

Router

















RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











RTCC

Ambient sensor

Power

HMI

Memory

Comm port

Sensor port
























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation























Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










Beha

vior

al t

imer

s and

alar

ms

ZigB

ee

THSc

SHT21c

kmpc

storagec

ctpBindingBehaviorc

kmpUartc

FATc


zbNetc

ctpDefinitionsh

zbATczbUartc

24xx512c

Perip

hera

ls(e

ndpo

ints)

CTP

Dev

ice

ctpBindingsh


ctpGenerateOutputc

ctpc

ctph

Behaviorc

Bootloader

Beha

vior

al

SchedulerInterrupts

zbTransportc



DeviceManagerc

Com

mon

for C

TP d

evic

es

Com

mon

for C

TP d

evic

es w

ith Z

igBe

e co

mm

unic

atio

n

Onb

oard

dev

ices

Microcontroler

CTSensorc

kamstrumpc Out

boar

d de

vice

s(C

onne

cted

on

port

s)

RTOScInterruptsc








Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










Publish 11

Publish 11


Publish 1lowast


Publish 1lowast

Publish 1lowast

IoT services layer

CTP Devices layer





middle interface


SerialDriverservice


Bundle


ZigbeeGatewaybundle

Uses



ZigbeeDriverbundle

Uses

ZigbeeDriverservice


middle-interface


ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ltltObjectgtgt

ZigbeeNodeservice

Defined in

Uses




CTP Driverbundle


service


middle interface


service

Defined in


bundle


Service

Uses

Internet Data cloud

Publish 11

Publish 11



Creates 1lowast

Creates 1lowast

Creates 1lowast








DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation















DEIoT =DAIoTDGNoT

=

DAIoTsum

119899

119894=1(MS119894times ND

119894)

(1)


119894is the



35

66

98

129

159

06

36

66

96

124

18

54

8

11

145

0

2

4

6

8

10

12

14

16


(s)




119895 as

MLH119895=

sum

119899119895

119894=1RT119894119895

119899119895

(2)





AEC (119905) = [119875Gtw + 119899119877 times 119875119877 +119899

sum

119894=1

119875119894] times 119905 (3)






minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










minus100

minus80

minus60

minus40

minus20

0

20

0 20 40 60 80 100 120

REC

varia

tion

()






100381610038161003816100381610038161003816100381610038161 day (4)



6 Discussion














models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













models


model



and level of detail

1







Profiles





2






3



Others fair (TCP)






PreamSEQ

Startframe

Framelength MPDU

Destinendpoint

Groupaddress

Clusteridentifier

Profileidentifier

Sourceendpoint















Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











Header Payload

IEEE 1451










Id attribute 2bytes

Data nbytes



Data nbytes

Data nbytes



LibraryObservations



device

50 (7 + 43)21

45 (5 + 31)

514

(7 + 7)1



111 (7 + 104)18

34(5 + 29)



12 (7 + 5) 112

(5 + 7)1

14 (7 + 7)

1

mdash mdash


7 Conclusions











References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation















References





















































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation

































RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









Documents

Research Article Protocol and Architecture to Bring Things ...downloads.hindawi.com/journals/ijdsn/2014/158252.pdf · things in Internet [ ]. Ideally, things on the IoT will have