Implementation of True IoT Vision - TUT · Implementation of True IoT Vision: ... that SIP represents a lightweight communication protocol ... use MQTT protocol may go to sleep state

Tampere University of Technology

Implementation of True IoT Vision

CitationMasek P Hosek J Zeman K Stusek M Kovac D Cika P Kroumlpfl F (2016) Implementation of TrueIoT Vision Survey on Enabling Protocols and Hands-On Experience International Journal of Distributed SensorNetworks 2016 [8160282] DOI 10115520168160282Year2016

VersionPublishers PDF (version of record)

Link to publicationTUTCRIS Portal (httpwwwtutfitutcris)

Published inInternational Journal of Distributed Sensor Networks

DOI10115520168160282

CopyrightThis work is licensed under a Creative Commons Attribution 40 International License To view a copy of thislicense visit httpcreativecommonsorglicensesby40

Take down policyIf you believe that this document breaches copyright please contact tutcristutfi and we will remove access tothe work immediately and investigate your claim

Download date04072018

Research ArticleImplementation of True IoT Vision Survey onEnabling Protocols and Hands-On Experience

Pavel Masek1 Jiri Hosek1 Krystof Zeman1 Martin Stusek1 Dominik Kovac1

Petr Cika1 Jan Masek2 Sergey Andreev3 and Franz Kroumlpfl4

1Department of Telecommunications Brno University of Technology Technicka 12 616 00 Brno Czech Republic2Institute of Structural Mechanics Brno University of Technology Technicka 12 616 00 Brno Czech Republic3Department of Electronics and Communications Engineering Tampere University of Technology Korkeakoulunkatu 1033720 Tampere Finland4Telekom Austria Group Lassallestraszlige 9 1020 Vienna Austria

Correspondence should be addressed to Pavel Masek masekpavelfeecvutbrcz

Received 7 January 2016 Accepted 15 February 2016

Academic Editor Piedad Garrido

Copyright copy 2016 Pavel Masek 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

Internet ofThings (IoT) is expected to become a driver in an emerging era of interconnected world through the advanced connec-tivity of smart devices systems and services IoT goes beyond a broad range of Machine-to-Machine (M2M) communicationtechnologies and covers a wide variety of networking protocols There exist solutions like MQTT or SIP collecting data fromsensors CoAP for constrained devices and networks or XMPP for interconnecting devices and people Also there is a plethoraof standards and frameworks (OSGi AllJoyn) bringing closer the paradigm of IoT vision However the main constraint of mostexisting platforms is their limited mutual interoperability To this end we provide a comprehensive description of protocolssuitable to support the IoT vision Further we advocate an alternative approach to already known principles and employ the SIPprotocol as a container for M2M data We provide description of data structures and practical implementation principles of theproposed structures (JSON and Protocol Buffers are discussed in detail) transmitted by SIP as a promising enabler for efficientM2M communication in the IoT world Our reported findings are based on extensive hands-on experience collected after thedevelopment of advanced M2M smart home gateway in cooperation with the operator Telekom Austria Group

1 Introduction

Presently the world around us is humming with data fromsmart meters sensors or actuators Everyday devices likeenergy meters water meters or environment sensors areno longer isolated entities performing their tasks offline Incontrast the goal of smart devices is to make our personaland business lives easier and more efficientmdashtoday we cansee a wide variety of smart devices (eg smart meterssensors and actuators) coming on the market in waves andtargeting to bring intelligent behavior into todayrsquos households[1] All kinds of such devices are interconnected within onecommunication paradigm named Internet of Things (IoT)where the tremendous volumes of measured data need to betransmitted

Following the fact that over the last decade the IoThas attracted an enormous interest from numerous industrydomains [1] the number of Machine-to-Machine (M2M)connections will grow to over 3 billion in 2019 Hencethere is a crucial need to develop appropriate communi-cation protocols for M2M (together with appropriate datastructureformat) to manage data from different sourcesmdashstoring organizing and analyzing data to enrich the newbusinesses with novel revenue streams and valuable services(frameworks) [1 2]

Envisioning the future of M2M communication thetelecommunication operators will play a key role in providingand supporting the communication infrastructure betweenend devices Today the 4G and beyond cellular networks(Long Term Evolution LTE) increasingly introduce support

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2016 Article ID 8160282 18 pageshttpdxdoiorg10115520168160282

2 International Journal of Distributed Sensor Networks

Stage I Stage II Stage III Stage IV

Figure 1 Communication chain representing todayrsquos IoT structuredata from smart meters and sensors (Stage I) is transmitted viacommunication protocols (eg WM-BUS and ZigBee) supportedby meterssensors to aggregation unit calledMTCG (Stage II) Afterperforming aggregation logic data is transmitted via the cellularnetworks (Stage III) towards the end (remote) applicationserviceprovider (Stage IV)

for M2M communication capabilities [3] However IoTbrings along new challenges which cannot be solved by asingle technology Therefore we are likely to encounter anew paradigm called 5G vision or 5G ecosystem providingthe bridge between a massive number of smart devicesdeployed for example within a connected home and remoteapplication running in cloud [4 5] see Figure 1

It becomes obvious that to manage devices and servicesin IoT more than one communication protocol has to bedeployed [6 7] On the other hand it is not always necessaryto develop entirely new platforms to satisfy the demands ofIoT services but also already existing protocols should betaken advantage of as possible candidates for certain IoT usecases For example if we take a closer look at the architectureof LTE networks [5] we can see that the IP MultimediaSubsystem (IMS) is a mandatory part of LTE architectureproviding the possibility of using Session Initiation Protocol(SIP) for transmitting M2M data [8ndash10] Taking into accountthat SIP represents a lightweight communication protocolindependently of the carried data the question is whetherit is feasible to use the SIP protocol as an alternative toother protocols like Message Queuing Telemetry Transport(MQTT) [11 12] Constrained Application Protocol (CoAP)[13] Advanced Message Queuing Protocol (AMQP) [14]Data Distribution Service (DDS) [15] or Extensible Messag-ing and Presence Protocol (XMPP) [16] for communicatingthe M2M data [17]

Inspired by that in this paper we deliver a comprehensivediscussion on remote data management architecture in IoTincluding the summary of proof-of-concept implementationof SIP-based data sharing between smart home gatewayand remote service entities where the JavaScript ObjectNotation (JSON) as data format transmitted within the SIPmessages carrying M2M data from a wide variety of realmeterssensors is utilized (described implementation wascompleted as a part of SyMPHOnY project which stands forthe joint project realized by Brno University of Technology(BUT) and Telekom Austria Group (TAG) [18]) [19 20]In this research we proposed and implemented our ownJSON structure for transmitting M2M data which meets therequirements imposed by industry [21]Therefore we believethat our approach is adequate and sufficiently scalable tosupport M2M applications across future deployment of LTEand future cellular networks

The rest of the paper is organized as follows Section 2 isdevoted to describing possible application protocols forM2Mcommunication in cellular networks Following the describedapplication protocols the bidirectional communication as akey function is described in Section 3 Further in Section 4a discussion on suitability of JSON and Protocol Buffersformats for IoT (M2M) is offered Our implementation ofcreated structures as part of the real use case for TelekomAustria Group (TAG) is provided in Section 5 Finally thelessons learned during the implementation of the JSON andProtocol Buffers within the development of MTCG (smarthome gateway) for M2M data are summarized in concludingSection 6

2 IoT Protocols

Following the concept of IoT devices must be able tocommunicate with each othermdashreferred to as M2M commu-nication [22] Further data from devices should be storedat the central point (MTCG) and as a next step sent to theremote server Many IoT standards and recommendationswere proposed to implement the described idea of IoTTherefore different development groups and standardizationinitiatives have been formed to pave the road towards thedemanded communication protocols (in case of IoTwemeanapplication protocols) the most important representativesinclude World Wide Web Consortium (W3C) [23] InternetEngineering Task Force (IETF) [24] Institute of Electricaland Electronics Engineers (IEEE) [25] and the EuropeanTelecommunications Standards Institute (ETSI) [26] Table 1provides a summary of themost prominent protocols definedby these groups

In this section we provide an overview of the popularprotocols and their core functionality (with respect to theirability to be used as M2M containers)

21 Message Queue Telemetry Transport (MQTT) MQTT isthe messaging protocol introduced in 1999 and standardizedin 2013 at OASIS [27] The protocol itself was aimed atenabling connection between embedded devices and net-works with various applications [11 12] MQTT works withpublishsubscribe pattern to provide flexibility and simplicityof implementation as can be seen in Figure 2 Focusingon the target group of devices the MQTT (running aboveTCP protocol) is appropriate for embedded (resourcepower-constrained) devices using unreliable or low-bandwidthlinks Nowadays two main specifications exist for MQTT (i)MQTT v31 [11] and (ii)MQTT-SN (also known asMQTT-S)[12]

MQTT consists of three key components (i) subscriber(ii) publisher and (iii) broker An interested device canregister as a subscriber for the specific content in order tobe informed by the central point (broker) every time whena publisher disseminates information of interest [11] In thisarchitecture the publisher stands for the metersensor send-ing data toMQTTbroker Secure communication between allparts is achieved by verifying the authorization of publishersand subscribers on the side of broker [12]

International Journal of Distributed Sensor Networks 3

Table 1 Standardization activities in support of IoT

Application Service discovery Infrastructure protocols (OSI layer number-name of the protocol)

Protocol mDNS DNS-SDL4 L3 L3 L2 L1 L1 L1 L1 L1

RLP 6LoWPAN IPv4IPv6 IEEE 80215480211 8023 LTE-A EPC Global IEEE 802154 Z-Wave IMS

DDS times times times times times times

CoAP times times times times times times

AMQP times times times times times times

MQTT times times times times times times

MQTT-SN times times times times times times

XMPP times times times times times times

HTTP REST times times times times times times

SIP times times times times times times

Publisher MQTT broker

Subscriber 1

Subscriber 2

SubscribePublish temperature 21∘C

Figure 2 The architecture of MQTT protocol

Variable length message payload (optional) Variable length header (optional)

Message type DUP QoS level Retain0 1 2 3 4 5 6 7

Remaining length (1ndash4 bytes)

Figure 3 MQTT message format [11]

The message format of MQTT protocol is depicted inFigure 3 The first two bytes are part of fixed header Furtherthe field Message Type contains a variety of messagesfor example Connect (1) Connack (2) Publish (3) andSubscribe (8)

Next the DUP (duplicate) flag informs that the messageis duplicated and receiver may have acquired this messagealready beforeTheQoS field stands for identification of threeQoS levels for delivery of Publish messages The followingfield is called Retain and informs the server to retain thelast Publish message and submit this message to the newsubscribers (this message will be sent as the first message)The last field (Remaining field) indicates the remaining lengthof the message (ie optional parts)

CoAP clients

CoAP serverREST-CoAPproxy server

Internet

CoAP domain

CoAP communicationHTTP communication

1

2

3

Figure 4 CoAP functionality [13]

From the M2M communication point of view the maindisadvantage of MQTT is the fact that end devices whichuse MQTT protocol may go to sleep state for a limitedtime period only (eg a lot of sensors or smart meterssend the data once per few hours and therefore MQTTis not a suitable communication protocol for these power-constrained devices)

22 Constrained Application Protocol (CoAP) CoAP wascreated by the IETF Constrained RESTful Environments(CoRE) working group as the application layer protocol forIoT applications [13 28] CoAP introduces web transfer pro-tocol based REpresentational State Transfer (REST) on topof HTTP In contrast to REST CoAP is utilizing lightweightUDP as transport protocol (TCP is not supported) by defaultThis makes CoAP more suitable for the IoT domain becauseit is possible to build sufficiently basic error checking andverification for UDP to make sure that messages arrivedwithout the significant communication overhead in case ofTCPHowever CoAPwas designed together with REST func-tionality therefore conversion between these two protocolshas to be implemented in communication chain see Figure 4


Payload (optional) Options (optional)

Token (optional)Ver Message ID

16 31T OC

0 1 2 3Code

85 6 7 15

Figure 5 CoAP message format [13]

CoAP can be divided into two sublayers [28]

(i) Messaging Sublayer It detects duplications and basedon that provides reliable communication even overthe UDP transport protocol using the exponen-tial backoff (multiplicative decrease of the rate ofdata transmission in order to gradually establish anacceptable data rate) this is a necessary techniquesince UDP does not include error recovery mecha-nism

(ii) RequestResponse Sublayer It handles REST commu-nication between individual nodes

CoAP utilizes four message types confirmable noncon-firmable reset and acknowledgment Reliability of CoAPis achieved by using confirmable and nonconfirmable mes-sages Similarly to HTTP CoAP utilizes methods such asGET PUT POST and DELETE to perform Create RetrieveUpdate andDelete operations for example the GETmethodcan be used by a server to inquire the clientrsquos temperatureusing the response mode The client sends back the temper-ature if it is available if not it replies with a status code toindicate that the requested data is not found

Message format of CoAP is depicted in Figure 5 The firstand fixed part of each message consists of four bytes of aheader Then a token value may appear whose length rangesfrom zero to eight bytes A typical length of CoAP messagecan vary between 10 and 20 bytes [29] this means that CoAPmay be unsuitable for some domains of IoT

Remark There are studies describing the possible use caseswhere CoAP messages are transmitted via Short MessageService (SMS) [28] thismakes another logical bridge towardsthe idea to use SIP communication protocol as a datacontainer for IoT domain

23 Extensible Messaging and Presence Protocol (XMPP)XMPP represents an IETF instant messaging (IM) standardfor chatting voice and video calling and telepresence [16]XMPP allows IM applications to run authentication accesscontrol privacy measurements and especially Device-to-Device (D2D) and end-to-end (E2E) encryption The overallfunctionality of XMPP protocol is depicted in Figure 6 wheregateway can overcome issues with sending messages betweenforeign networks XMPP connects clients and servers usingthe XML called stanza [30]

Integrated features make XMPP a preferred protocol bymost IM applications and therefore relevant for specific partof IoT ecosystem XMPP also implements a building block for

Gateway

Internet

Internal network communicationForeign networks

1

234

Server 1 Server 2

Figure 6 Communications in XMPP [16]

ltpresencegtltshowgt

ltpresencegt

ltbodygtltmessagegt

ltquerygtltiqgt

ltstreamgt

ltstreamgt

ltmessage to=lsquoxrsquogt

ltiq to=lsquoyrsquogt

Figure 7 Structure of XMPP stanza [30]

secure communication and allows new applications on top ofcore protocols [16] As was mentioned XMPP uses the so-called stanzas which divide the code into three components(i) message (ii) presence and (iii) infoquery see Figure 7

Messages in stanza identify the source and destinationaddress types and IDs of XMPP entities that provide PUSHmethod for retrieving data The presence stanza notifiesend users of the status updates Finally the iq stanza doesthe pairing between message senders and receivers Thepossible disadvantage of XMPP is text-based communicationusing XML This leads to higher network load (overhead)Therefore there is a possible solution to this problem XMLstreams using EXI [31 32]

XMPP is very often compared with the SIP protocolwhere SIP is inherently a peer-to-peer protocol whereasXMPP is inherently client-server Tasks that are easy in client-server systems for example to share state to save dataon server or to post offline messages on server are wellaccomplished with XMPP protocol On the other hand oneof the primary goals of SIP (described later in this section) isto keep the intelligence at the end point Ideally a SIP proxyserver does not even maintain the session state for the SIPdialog [16]


AMQP broker

Publisher

Subscriber 1

Subscriber 2 Exchange

Queue

Queue

Figure 8 AMQP publishsubscribe mechanism [14]

Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message

Figure 9 AMQP message format The header enables a deliveryof parameters including durability priority time to live (TTL) firstacquirer and delivery count [14]

24 Advanced Message Queuing Protocol (AMQP) AMQPrepresents the open standard application layer protocolfocusing on the message-oriented environments in IoT[14] Further AMQP enables guaranteed communicationmdashitrequires a reliable TCP session to exchange messages

Communication via the AMQP is realized by two keycomponents (see Figure 8) [33]

(i) Exchanges They are used for routing messages toappropriate queues Routing (between exchanges andqueues) is based on predefined rulesrequirements

(ii) Message Queues They are stored in message queuesbefore sending to end destination (receiver)

AMQP defines messaging layer on top of the transportlayer (TCP is used as the transport protocol) where allmessaging capabilities are handled Following that two typesof messages are defined in AMQP (i) bare messages (at thesenderrsquos side) and (ii) annotated messages (at the receiverside) see Figure 9

As discussed AMQP requires extensions implementedon transport layer for the aforementionedmessaging layer Incase of transport layer the communication is frame-orientedThe structure of AMQP frame is depicted in Figure 10

In the IoT context AMQP is the most appropriate for thecontrol plane or server-based analysis functionsTherefore itis not a suitable candidate for transmission ofM2Mdata (E2Ecommunication)

25 Data Distribution Service (DDS) DDS was designedas a publish-subscribe protocol for real-time M2M com-munications by Object Management Group (OMG) [1534] In comparison with the aforementioned protocols likeMQTT or AMQP DSS uses multicasting to provide betterreliability and Quality of Service (QoS) DSS supports 23

SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF

Figure 10 The first four bytes indicate the frame size DOFF (DataOffset) represents the position of the body inside the frame TheType field indicates the format and purpose of the frame Forexample 0x00 is used to show that the frame is an AMQP frameor type code 0x01 represents a SASL frame

Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL

Application n Application 2 Application 1

Internet

Datavalues

Datavalues

Figure 11 Conceptual architecture of DSS [15]

QoS policies by which a wide variety of communication usecases can be covered for example security priority andreliability The DDS logic is therefore able to meet the real-time requirements given by specific types of IoTM2M

Architecture of DDS defines two layers (i) Data-CentricPublish-Subscribe (DCPS) and (ii) Data-Local Reconstruc-tion Layer (DLRL) DCPS layer is responsible for deliveringinformation to the end destinations (subscribers) DLRLrepresents on the other hand optional layer which servesas the bridgeinterface to the DCPS functionalities (sharingof distributed data among distributed objects) [35] In DCPSlayer five entities are managing the data flow (see Figure 11)

(i) Publisher It sends required data sets(ii) DataWriter It is used by the application to interact

with the publisher with respect to values and changesregarding data type The thin cooperation between


Publisher and DataWriter is used by application forpublishing data in provided context

(iii) Subscriber It receives data from Publisher and trans-fers them to the application

(iv) DataReader It is controlled by Subscriber to read thereceived data

(v) Topic It is defined by data type and name andconnects DataWriters with DataReaders

26 Comparison of Already Described Protocols Based on theabovementioned facts it can be seen that MQTT XMPPor CoAP can be used as protocols for M2M data butstill there are limitations (eg message length and sensorsinactivity) mainly associated with end-to-end connectivityIn literature several comparisons between these protocolscan be found For example in [36] the authors compareend-to-end transmission delay and bandwidth utilization ofMQTT and CoAP MQTT delivers required data with lowerdelay in comparison to CoAP in case of low packet lossOtherwise in case of high packet loss CoAP gave betterresults In another research [37] the attention was focusedon smartphones application environment Results show thatCoAP offers lower bandwidth usage and lower round triptime (RTT) than MQTT

Offering a new point of view in this space in ourproject [38] we propose a novel way to transmit M2M datathrough the networkmdashwith respect to length of transmitteddata transmission scheduling and E2E nature of M2Mcommunication As discussed in Section 1 the SIP protocolis a common part of todayrsquos cellular networks and eventhough it was invented for different applications like IPtelephony multimedia streaming and instant messaging it isan excellent candidate to become a primary communicationbus for the constituent components of IoT ecosystem (as apart of the emerging 5G vision)

27 Session Initiation Protocol (SIP) SIP represents the text-based request-response protocol (in a way similar to HTTP)where the key attributes are included in the header andadditional data is stored in the message body (eg sessiondescription or capabilities) Nowadays SIP is well establishedin both local and global telecommunication infrastructuresand there is a plethora of end user devices and applicationssupporting this protocol [38] Therefore there is no need toinvest additional resources to implement this protocol withinIoT domain [8]

Although the SIP works in parallel with other com-munication technologies and protocols (eg TCP UDP orStream Control Transmission Protocol (SCTP) can be usedas transport protocols for SIP) there are two key componentsused by SIP [8] (see Figure 12)

(i) User Agents End points of the communication chainare often named as SIP clients There are two subcom-ponents of a user agent (i) client and (ii) serverWhenthere is a request (eg to initiate a session) generatedby User Agent Client (UAC) responding user agent(at the opposite side) is User Agent Server (UAS) It

Internet

Registrar server

SIP proxy server

SIP redirect server

Location server

SIP client 1 SIP client 2 SIP client 3

Figure 12 Communication in SIP [8]

is important to understand that as the user agent willsendmessage and then respond to another user agentit will alternate between both roles during a session

(ii) SIP Servers They are used to resolve usernames toIP addresses A user agent (see previous paragraph)registers with the SIP server (providing username IPaddress and location information) This procedureverifies whether the user agent (SIP client) is onlineso that other user agents can see whether they areavailable and can start a session If the user agentdoes not belong to a certain SIP domain (differentSIP server) it will send request to other servers SIPserver can act in any of the following roles (i) registrarserver (ii) proxy server and (iii) redirect server [8]

The format of SIP header is depicted in Figure 13 andstructure of SIP protocol comprises three layers

(i) Transport Layer It defines how the SIP client (useragent) sends requests and receives responses and howSIP server receives requests and sends response overthe network It is important to mention that all SIPelements work within transport layer

(ii) Transaction Layer It serves for sending requests(from SIP client to SIP server using transport layer)Any task completed by SIP client comprises a seriesof transactions (stateless proxy servers do not containtransaction layer)

(iii) Transaction User Each of the SIP entities (SIP clientsand SIP servers except the stateless proxy servers) actsas transaction user

The question of security communication is also coveredby SIP since the Secure Sockets Layer (SSL)Transport LayerSecurity (TLS) mechanisms are already prepared for secure


Version Flow labelPayload length Payload type Hop limit

Source addressDestination address

0 3 4 15 16 23 24 31

Message body (variable length)

Figure 13 SIP message format [8]

communication between SIP clients For the purposes ofM2M (home automation) communication SIP MESSAGE(for PUT and GET actions) and SIP SUBSCRIBE (for status-based events like alarm notification) can be used [8]

28 IoT Application Protocols Summary To conclude thissection three protocols are mentioned very often in thecontext ofM2M communicationMQTT (Section 21) CoAP(Section 22) and SIP (Section 27) In addition to MQTTand CoAP the SIP has been recognized as an efficientdata container for home automationIoT communication[18 38] see Table 2 for comparison of IoT applicationprotocols Moreover open-ended nature of SIP (where theSIP MESSAGE can contain any data structure with dynamiclength) provides a solid basis to address issues specific tothe homeindustry automation domain Together with theoperatorsrsquo maintained infrastructure the SIP constitutes asecure and reliable communication protocol for remote IoTservices

3 Bidirectional Communication in IoTApplication Protocols

In the previous section we discussed the most frequentlyused protocols in IoT domain Together with the described(overall) parameters of each protocol there is one additionalrequirement which impacts the choice of an appropriateapplication protocol Nowadays in IoT the one-way commu-nication is no longer the predominant type of data transmis-sion between sensors and cloud apps We often encounteran emerging need for remote controlling and adjustment ofsmart devices (meters sensors actuators etc)Therefore thetwo-way (bidirectional) communication plays the key role intodayrsquos IoT architecture [1]

In this section the protocols previously identified as themost attractive (ie CoAP MQTT and SIP) are describedand compared mindful of the two-way communication fea-ture

31 CoAP CoAP employs two-layer structure (i) the bottomlayer is calledmessage layer and has been created to deal withthe UDP transport protocol and asynchronous switching (ii)the requestresponse layer manages communication methodand also requestresponse message

311 Message Layer Message layer of CoAP protocol con-sists of 4 message types (i) CON (confirmable) (ii) NON

Client Server

CON [0x8b56]

ACK [0x8b56]

(a) Reliable message transport

Client Server

NON [0x8b57]

(b) Unreliable message trans-port

Figure 14 Message layer model reliableunreliable [13 28]

Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)

(token 0x21)205 content

ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)

Figure 15The successful and failed response results of GETmethod[13]

(nonconfirmable) (iii) ACK (acknowledgment) and (iv) RST(reset) [13 28] The communication via message layer modelcan be divided into two groups

(i) ReliableMessage TransportThe transmission ismain-tained until the same message ID (like 0x8b56 seeFigure 14(a)) in ACK message is received at the sideof the client If server fails to process the incomingmessage it responds by replacing the ACK with theRST message

(ii) Unreliable Message Transport It is transported withtheNON typemessageThere is no need to sendACKbut the message has to contain message ID for thepurpose of retransmission If server fails to processmessage it responds by RST see Figure 14(b)

312 RequestResponse Layer Using the requestresponselayer model the communication can be handled as follows

(i) Piggy-Backed Approach In this case the client sendsrequest (using the CON or NON message) andreceives ACK message If the transmission is suc-cessful the ACK contains response message which isidentified by token (0x21 see Figure 15(a)) In case offailure the ACK contains failure response code (seeFigure 15(b))

(ii) Separate Response In the case when the serverreceives CON message and is not able to respondimmediately it sends an empty ACK message to theclient When the server is ready to respond to the


Table 2 Comparison of IoT application protocols

Protocols RESTful Transport Publishsubscribe Requestresponse Security QoS Header size (bytes)CoAP UDP SMS DTLS 4MQTT times TCP times SSL 2MQTT-SN times TCP times SSL 2XMPP times TCP SSL times mdashAMQP times TCP times SSL 8SIP times TCP UDP SMS SSL TLS mdashDDS times TCP UDP times SSL DTLS times mdashHTTP TCP times SSL times mdash

Client ServerCON [0x4d45]

ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)

Figure 16 (a) Get request with a separate response (b) noncon-firmable request and response [13]

request the new CONmessage is sent to the client Atthe client side the confirmation message with ACK issent back to server see Figure 16(a)

(iii) Nonconfirmable RequestResponse Unlike the piggy-backed approach the request is sent from a client tothe server in NON type message which indicates thatthe server does not need to confirm the incomingmessage After receiving themessage the server sendsaNON typemessagewith response (see Figure 16(b))

32 MQTT Even though the MQTT application protocol ismentioned very often as a leading candidate for IoT domain[39] it does not support the requestresponse communica-tion see Table 2 This restriction limits the range of possibleuse cases where the MQTT can be used The only availablescenario of bidirectional communication with MQTT illus-trates the publishsubscribe communicationmodelWith oneclient in the role of publisher and one or more nodes assubscribers the information can be sent from a single pointto many other devices or listenersTherefore the deploymentof this application protocol becomes straightforward seeFigure 17

Clientsource (publish) Broker Clientsubscribe

(sink)

Subscribe (topic)

Publish (topic info)


Figure 17 Publishsubscribe process utilized by MQTT [11]

Unregister

SIP client SIP server

401 unauthorized

Unregister with digest

SIP client

Unregister

401 unauthorized

Unregister with digest200OK

200OK

Figure 18 SIP registration procedure [8]

33 SIP As discussed in Section 27 and highlighted inTable 2 the SIP stands for the requestresponse applicationprotocol Sending M2M data via the SIP requires differentbehavior comparing to the traditional voice communicationvia SIP (eg the media session (RTP) is not established) Ingeneral using SIP for IoTM2M the overall communicationprocedure comprises three steps [8 9]

(i) Registration to the SIP Server Each SIP client hasto register to the SIP server to be able to receive orsend the data see Figure 18 The registration processis completed by the 200OK message sent from theserver to the SIP client Depending on the SIP (IMS)network configuration the registration process has tobe reestablished in a loop

(ii) M2M Data RequestResponse After the registrationprocess is completed the M2M data can be trans-mitted using the SIP Since the SIP was designed forrequestresponse communication this can be done


Message (request)

SIP client SIP server SIP client

Message (request)

TransactionDialog

200OK (response)200OK (response)

Message (request) with digestMessage (request) with digest

407 proxy auth required

Figure 19 Requestresponse communication using the SIP protocol[8]

via the SIP message which carries the request orresponse see Figure 19 Request is sent to the SIPserver which will answer back to SIP client withthe 407 Proxy Authentication Request Next the SIPclient sends the message (request) with digest to theSIP server and this message is resent to the end SIPclient In case of response the destination node willsend the message 200OK as a confirmation Usingthe modularity of SIP inside the 200OK messagethe response to the source SIP client is included (theformat inside the requestresponse SIP messages candiffer eg JSON of Google Buffers [40] can be usedsee Section 4)

(iii) Termination of SIP Connection The procedure ofderegistration of SIP clients from the SIP server fol-lows the rules mentioned in the registration processSIP client sends the SIP message Unregister to theSIP server which answers with the 401 unauthorizedmessage After that SIP client sends the SIP messageUnregistered with digest As a response from serverthe 200OK is sent back and the connection is closed[8]

Remark on Reliable SIP Communication SIP representsthe transactional protocol which means that interactionsbetween components (UAC and UAS) take place in seriesof independent message exchanges Specifically a SIP trans-action consists of one request and many responses to thatspecific request Transactions feature client (called clienttransaction) and server (known as server transaction) partsThe client and server transactions are logical functionsembedded in all elements (they exist in user agents andstateful proxy servers) see Figures 19 and 20

Following the fact that SIP usesmainly theUDP transportprotocol the question of reliable communication is raisedhere Especially for requestresponse it is crucial to know ifthe message was delivered or not For that SIP implementsthe logic where with every transaction the CSEQ number(transaction ID) is incremented for each new request withinthe dialog as a traditional sequence number [8]

UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response

Figure 20 Transaction relationships in SIP [8]

4 Data Formats for M2M

While considering SIP as a perspective IoT communicationprotocol we aimed at developing an appropriate data struc-ture inside the SIP message Nowadays JSON format [41]acts as one of the most acknowledged drivers in case ofIoTM2M data structure On the other hand there are newemerging projects trying to rethink the aspect of M2M datasharing One of them is Protocol Buffers [40] which standsfor Googlersquos language-neutral platform-neutral extensiblemechanism for serializing structured data

However after evaluating the state-of-the-art data struc-ture formats we chose the JSON format as our main dataformat which is easy to read and write and in comparisonwith the XML the structure is more suited for generatingand further handling (parsing and converting) Anotheradvantage of using JSON is shorter message length sinceJSON can describe an individual object very efficiently [42]To provide the comprehensive evaluation we also develop apractical example of IoT data structure utilizing the ProtocolBuffers which enables a direct comparison of two differentapproaches

41 JSON Structure JSON is based on a subset of JavaScriptusing the text format that is completely independent ofprogramming language but at the same time it also usesthe rules similar to C family (including C C++ C Perl orPython) These properties caused JSON to quickly become apopular data interchange format

It is very important to mention at the beginning ofthis section that JSON as a generic data structure can beimplemented in various types of communication protocolsfor example the SIP CoAP and MQTT communicationprotocols and is suitable to carry different types of payloadsFollowing this fact the proposed JSON structure (dataformat) in this paper can be also implemented as part of otherprotocols (for different use cases where CoAP orMQTTmayrepresent better choices comparing to the SIP)

Currently the JSON is based on two data structures [43]

(i) Collection of Pairs (Name-Value) This is in manyprograming languages implemented as object recordhash table or associative array

(ii) Ordered List of Values It is often realized as an arrayvector list or sequence


JSONobject

string value

Figure 21 Source code notation for JSONobject each name isfollowed by (colon) and pairs are separated by (comma) [42]

[ ]

value

JSONarray

Figure 22 Source code notation for JSONarray it begins with the[ (left bracket) and ends with ] (right bracket) Values are separatedby (comma) [42]

The above structures are universal and almost all modernprograming languages support them Therefore JSON dataformat is interchangeable with respect to the programminglanguages based on the following structures [43]

(1) Object It is an unordered set of pairs (name-value)An example of object in JSON is depicted in Figure 21

(2) Array It is an ordered collection of values Anexample of array in JSON is depicted in Figure 22

(3) Value Examples of different types of values aredepicted in Figure 23

(4) String It is very similar to C or Java string notationAn example of string in JSON is depicted in Figure 24

(5) Number It is very similar to C or Java string nota-tion An example of number in JSON is depicted inFigure 25

The described options represent the most frequently usedJSON structures a detailed overview of available structurescan be found in [43]

Due to the wide variety of possible JSON messages a lotof examples for different use cases can be found in literature[44ndash46]

42 Protocol Buffers Structure There aremany possible viewson the problem (data structure for M2M content) presentedby this paper and consequently a number of feasible solu-tions As described above JSON structure is one of themost promising solutions and therefore we have utilized thisapproach in our practical implementation However anotheremerging candidate is Protocol Buffers which is a recentlyintroduced tool for serialization of structured data providedby Google

Currently Protocol Buffers exist in two language versionscalled proto2 (latest stable release) andproto3 (alpha version)In this subsection we discuss the proto2 capabilities andstructure as stable implementation recommended by Google

Protocol Buffers are able to work with a variety of pro-gramming languages such as Java C++ C and PythonThe

string

number

object

array

true

false

null

JSONvalue

Figure 23 Source code notation for JSONvalue it can be repre-sented as a string in ldquo rdquo (double quotes) number true false null oran object or an array [42]

ldquo rdquo

JSONstring

Any Unicode character except ldquo or

4 hexadecimal digits

b

f

n

r

t

u

ldquo Quotation mark

Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab

Figure 24 Source code notation for JSONstring sequence ofUnicode characters in ldquo rdquo (double quotes) using (backslash)escapes A character is represented as a single character string [42]

JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot

Figure 25 Source code notation for JSONnumber similar to C orJava it does not contain the octal and hexadecimal formats [42]

basic idea of Protocol Buffers is similar to that in JSON In thefirst step structure of serialized data is defined This is donein proto file by defining Protocol Buffer messages type Eachof these messages is a small logical record of informationcontaining series of fields with name-value pairs There area number of different types used for the value definitionExamples of these types are depicted in Figure 26 Aside fromthose types there is one special type of field called Enum Itspurpose is to predefine values in a list so no other data canbe put inside


double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264

Protocol buffer value type

bool

string

bytes

Figure 26 Source code notation for Protocol Buffers value type

Message fields are assigned with unique numbered tagsThose tags are used to identify fields in the message binaryformat and should not be changed once message type is inuse Tag numbers can be chosen from the range 1ndash229 Formessage fields there are three rules

(i) Required It is obligatory to fill this field with data(ii) Optional Anymessage field with this rulemay ormay

not be filled with data(iii) Repeated Fields with this rule can be repeated several

times including zero

43 Review of Introduced Thoughts Before proceeding withthe description of realized implementation in the followingsection a short summary on ideas discussed in previoussections is appropriate We have introduced the well-knownapplication protocols with respect to the IoT domain Insteadof using traditional protocols we have based our implemen-tation on SIP protocolwhich can act as the container forM2Mdata On top of that we introduced two new data structuresfor M2M data based on (i) JSON and (ii) Protocol Buffersschemes

5 Implementation of Proposed DataStructures in Live Smart Home Project

In this section we focus our attention on practical implemen-tation of two data structures JSON (Section 52) and ProtocolBuffers (Section 54) Our goal is to identify a suitable datastructure for transportation of M2M data from a largenumber of meterssensors to a concentrator node (MTCG)see Figure 29 Since a variety of meters can proliferate in themarket we have been investigating an easily expandable anduniversal data structure

First the overview of the entire communication structureof our SyMPHOnY (Smart Multipurpose Home Gateway)project is given in Section 51 Next the generic JSON schemeis described in more detail in Section 52 Further theattention is focused on the JSON and Protocol Buffers datastructures see Sections 53 and 54 respectively

SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core

middot middot middot

Figure 27 General structure of created framework in the SyM-PHOnY project [18]

51 Overall System Architecture As discussed earlier inSection 2 we chose SIP as a communication protocol for datatransmission In our architecture (see Figure 29) the MTCGnode assumes role of SIP client where data is (i) received (egvia wireless M-BUS interface) from a wide variety of smartdevices and (ii) sent via the IMSSIP network (using the SIPserver as an intermediate node) towards the remote SIP client[47]

511 SW Implementation on theMTCG The created applica-tion framework is written in Java programming language andfollows requirements given by the Open Services GatewayInitiative (OSGi) [48] Following that fact our solution isdivided into several packages called bundles Each of thecreated bundles manages a certain subtask (eg receivingdata from specific communication protocol and acting as aSIP client at the MTCG side) and ultimately the entire logicis managed by the Core Bundle see Figures 27 and 28

Our developed framework [18] is able to run on anydevice based on Acorn RISC Machine (ARM) architectureNowadays there are pilot projects trying to run Java-basedapplications also on MIPS (Microprocessor without Inter-locked Pipeline Stages) platform [49] In addition Oraclecompany announced plans for developing Java libraries forMIPS architecture However these projects are in early devel-opment stage and therefore we decided to use for our projectIP gateway running the ARM SoC (System on Chip) [50] asoperating system the OpenWRT 1407 Barrier Breaker wasused [51]

Since the SIP bundle is the key part of communica-tion chain between MTCG and remote ldquocloud-basedrdquo appwe provide a deeper analysis of SIP implementation inSection 511 Our solution is based on JAIN-SIP API [52]which explicitly supports RFC 3261 [8] functionality andthe following SIP extensions the INFO method (RFC 2976)[53] Reliability of Provisional Responses (RFC 3262) [54]EventNotification Framework (RFC 3265) [55] theUPDATEmethod (RFC 3311) [56] the Reason Header (RFC 3326) [57]theMessagemethod (RFC 3428) [58] defined for instantmes-saging and the REFER method (RFC 3515) [59] DistributingAuthoritative Name Servers via Shared Unicast Addresses(RFC 3581) [60] and the PUBLISH method (RFC 3903)[61] Therefore our implementation of SIP on our gateway(MTCG) does not need any additional packagesextensions


Proxy server SIP client

Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No

Figure 28 Architecture of SIP client bundle in SyMPHOnY [18]

512 SW Implementation on Remote SIP Client Followingthe information in Section 511 there are no special require-ments for the remote SIP client since our solution followsstandardized implementation of SIP protocol [8] We testedX-Lite [62] ZoiPer [63] and Asterisk (client part of Asteriskrunning in the terminal) [64] and as a result all of them wereable to successfully process data sent from MTCG To makethe overall process of data handlingmore effective we createdour own SIP client (source codes are available on GitHub[18]) This tool combines SIP client and logic for parsingreceived JSON-structured data Furthermore if there is aneed for conversion of received data into another data formatwe implemented conversion logic for LPEX (proprietary datastructure used by electricity companies) and CSV [65] datastructures (this highly depends on the requirements at theremote side (specific appindustry use case))

513 Bidirectional (E2E) Communication Considering theaforementioned facts we covered also the question of E2Ecommunication between smart devices and remote cloud-based applications Today the need for bidirectional com-munication grows Even though the majority of transmittedM2M data is represented by one-way communication (fromsensors to the cloud) in the future two-way communication

will play the key role [1] To react accordingly we imple-mented special bundles (see Figure 27)

(i) JSON Bundle In it translation of data is receivedfrommeterssensors to required JSONstructure (sup-ported by remote cloud app) which is subsequentlyincluded in SIP message

(ii) Cloud-API Bundle It manages the commands (forsmart devices) received from applications in the cloudat the side of aggregation node (MTCG)

Requirements related to bidirectional communicationsbring new challenges across the IoT communication chainsee Figure 1 Concerning our proposed architecture in ourSyMPHOnY project [18] we have the following

(i) At the side of cloud-based app the request messagesfor smart metersensor (or even for group of smartdevices) have to be included (in JSON format agreedon by both communication sides) into the body of SIPmessage (Stage IIharr Stage IIIharr Stage IV)

(ii) After the SIP message is received by SIP bundle(running under control of Core Bundle on MTCG)information about targeted sensor(s) is extractedfrom the SIP message body Next the appropriatedata unit (which depends on the used communicationtechnology at the sensor side) is generated (StageII)mdashin parallel the Core Bundle is checking if therequested sensor supports bidirectional communica-tion If not the response to the cloud-based app issent

(iii) During the final part (Stage Iharr Stage II) the requestgenerated by MTCG is sent to the target sensorwhere the relevant action will be performed As anacknowledgment theACKmessage is sent back to thecloud-based app via theMTCG (Stage Irarr Stage IIrarrStage IIIrarr Stage IV)

The above communication chain does not touch upon thequestion of security which is even more important in case oftwo-way communication In case of secure communicationbetween MTCG and remote cloud-based app one of thesupported security mechanisms (SSL and TLS) can be usedThe need for secure communication between MTCG andsmart devices (Stage Iharr Stage II) is closely connected withconcrete devicetechnology and its support of encryptionToday the most widespread encryption mechanism imple-mented by industry manufactures is Advanced EncryptionStandard (AES 128) [66ndash69]

52 Proposed JSON Structure Before we proceed with thedescription of the constructed JSON scheme we need toclarify the question of why it is so important to implementinto the structure the so-called system codes The systemcode represents a unique identifier for the key objects in thedata structure Nowadays the leading system code for M2Mcommunication (especially in smart metering domain) is theObject Identification System (OBIS) codemdashin our project weuse the OBIS as amain system code as an example of anothersystem code the KNX system code can be mentioned [70]


MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases

IMSSIP infrastructure (secure) connection

Photovoltaic panel

Wireless communication technologies (wireless M-BUS ZigBee BLE etc)

Figure 29 SyMPHOnY is able to aggregate information fromarbitrary smart devices and automate actions based on user-defined or network-defined policies using telecommunication operatorsrsquo technologies In our project the SIP communication is implemented as key remote dataexchange technology

The OBIS code identifies the corresponding device valueand represents a text string composed according to theOBIS standard [71] The main reason for using OBIS is thatleading industry companies dealing with metering alreadyimplemented support for OBIS standard

One of the benefits of using OBIS is evident dur-ing machine processing of collected data A parser withknowledge of JSON (or Protocol Buffers) structure as wellas utilizing principles of creating OBIS codes can easilyprocess received data without knowledge of exact internalJSONProtocol Buffers structure Obtained data may there-fore be processed by any system with OBIS code conversionmechanism knowledgeThis makes communication betweendevices by two different vendors much easier

TheOBIS code consists of 6 groupsmarked by letters A toF All of thesemay ormay not be present in the identifier (eggroupsA andB are often omitted) In order to decide towhichgroup the subidentifier belongs the groups are separated byunique separators A-BCDElowastF [71] (see Table 3)

(i) TheA group defines themedium (0 = abstract objects1 = electricity 6 = heat 7 = gas 8 = water etc)

(ii) The B group defines the channel Each device withmultiple channels generating measurement resultscan separate the results into the channels

(iii) The C group defines the physical value (currentvoltage energy level temperature etc)

(iv) TheD group defines the quantity computation outputof specific algorithm

Table 3 Examples of OBIS codes for home automation [71]

Name OBIS code UnitMeter reading total (119860+) 1-0180 kWhPositive active instantaneous power (119875+) 1-0170 kWMeter reading total (119860minus) 1-0280 kWhNegative active instantaneous power (119875minus) 1-0270 kWWater cold meter reading total 8-0100 lWater hot meter reading total 9-0100 lAmbient temperature 0-09690 ∘CRelative humidity 0-09692

(v) The E group specifies the measurement type definedby groups A to D into individual measurements

(vi) The F group separates the results partly defined bygroups A to E

53 JSON Structure Real Data Sets Now let us furtherdescribe the created JSON structure Following the developedJSON scheme available on GitHub [18] we provide anexample of real data set regarding the electricity consumptionmeasurement implemented within the pilot project withTelekomAustria Group As can be seen each of themeasuredvalues is clearly identifiable which is the key requirement forfurther actions with received data for example parsing orconverting JSON into the different data formatstructure

When creating the message following the requirementsgiven by JSON scheme it is crucial to conform to thatstructure because any deviation can cause inadequate reading


system

type SH-GW

location

info Main building 5th floor

format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status

value ZigBee interface not working

]

device

type Smart Meter

objectCodeVersion ObisV29

id [

name Serial Number

value 013146520004-1

objectCode 0-09610

name Metering Point ID

value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [

name Meter reading total (A+)

value 12465

units kWh

info Below 24h average

objectCode 1-0180

name Load profile 15 1015840 total (A+)

value 12

units kWh

objectCode 1-01290

]

Algorithm 1

of desired values The proposed structure uses all of ourpredefined properties to its best There are three propertiesof object system system is related to (i) gateway (type ofgateway) (ii) location and (iii) property data

Data is an array property consisting of two objectsrelated to information about current time at gateway and sta-tus messageThe object device is described by five propertiestype (ldquosmart meterrdquo) objectCodeVersion (this device usesObisV29) id (this device uses two different identifications)timestamp and data The objects in the array data (withinthe ldquodevicerdquo) have properties name value units info (addi-tional information about measured value) and objectCode(because device uses OBIS as system code) see Algorithm 1

54 Proposed Protocol Buffers Structure Protocol Buffersrepresent the second used data structure To distinguish fromthe provided JSON structure with real data set the examplesbelow show our proposed proto structure from the schemeviewpoint The provided structure is divided into 7 partswhich follow the idea of JSON structure

(1) Message FullJSONPacket consists of optional fieldsystem and required field device Those fields featuremessages defined as shown in Algorithm 2

(2) Message System includes an optional field type withvalue type string and two optional fields composed ofmessages as shown in Algorithm 3


syntax = proto2

package vutbr

option java package = czfeecvutbr

option java outer classname = DataStructure

message FullJSONPacket

optional System system = 1

required Device device = 2

Algorithm 2

message System

optional string type = 1

optional Location location = 2

optional SystemData data = 3

Algorithm 3

message Device

required string type = 1

optional string objectCodeVersion = 2

repeated Id id = 3

required string timestamp = 4

repeated DeviceData data = 5

Algorithm 4

(3) Message Device consists of required field of valuetype string called type optional field of value typestring called obejctCodeVersion repeated field idrequired field of value type string called timestampand repeated field data (see Algorithm 4)

(4) Message Location has four required fields of valuetype string info format latitude and longitude (seeAlgorithm 5)

(5) Message SystemData has two required fields of valuetype string name and value one optional field ofvalue type string named info and one optional field ofvalue type enum named Method (see Algorithm 6)

(6) Message Id has two required fields of value type stringname and value as well as one optional field of valuetype string called objectCode (see Algorithm 7)

(7) MessageDeviceData has three required fields of valuetype string name value and units two optionalfields of value string objectCode and info and twooptional fields of value type enum Method andResponseResult (see Algorithm 8)

It is self-evident given the example above that createdstructure of Protocol Buffers is easy to implement and extendthe key principles of JSON scheme are followed This ismainly owning to the possibility of adding new messages tothe structure without a need of changing the existing ones

message Location

required string info = 1

required string format = 2

required string latitude = 3

required string longitude = 4

Algorithm 5

message SystemData

required string name = 1

required string value = 2

optional string info = 3

enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4

optional Method method = 4

Algorithm 6

message Id



optional string objectCode = 3

Algorithm 7

message DeviceData



required string units = 3



enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4

optional ResponseResult responseResult = 7

Algorithm 8


This represents the main advantage in comparison with theJSON structuredata format

6 Conclusions and Lessons Learned

In this final section we discuss the important aspects thatwe faced during our implementation together with the mainconclusions

During the development of new data structures (JSONand Protocol Buffers) suitable for M2M communication viathe cellular networks we solved a number of challenges(i) selection of suitable communication protocol (offeringsmall communication overhead during the initial communi-cation phase enabling the requestresponse communicationbetween sensors and cloud-based applications providing thesecurity in the entire communication chain) (ii) definition ofdata structures which satisfy the requirements of simple anduniversal structure (ready for future conversion into differentindependent data structures (eg LPEX or CSV))

Working with the data structure inside the applicationprotocol we have used and modified two data schemes(i) JSON and (ii) Protocol Buffers based on collaborationwith our industry partners WepTech [67] Bonega [68] andPikkerton [69] to adapt our solution to different requirementsof meter types see Sections 52 and 54 One of the mostimportant tasks was to design a universal structure (sincethe content of data sent from sensors may differ acrossmanufacturers) suitable for effective handling at the side ofremote servercloud-based append application (eg storingand sorting of the received data visualization of the receiveddata and data mining)

Catering for the best candidate among todayrsquos IoT proto-cols we conducted a comparative analysis of CoAP MQTTXMPP AMQP SIP and DDS see Section 2 All of thesesolutions are recognized in literature as application protocolsready for IoTM2M Based on our research we can concludethat in reality only some of the described protocols areactually suitable for the practical implementation to supportcontemporary IoT use cases such as smart homes or homeautomation

If we want to use IoT to its full potential the SIP orCoAP could be used as containers for the M2M data Thisdecision follows from the fact that only these two protocolsare able to provide requestresponse communication whichis becoming the needed functionality in real IoT world Incase of our pilot project we have selected the SIP optionmainly due to the fact that this protocol is already a vitalpart of mobile systems (in 4G and beyond networks the IMScomponent is mandatory in network architecture) Using SIPas a remote communication enabler brings new challengesand business opportunities for telecommunication operatorsThey can extend todayrsquos IP residential gateways (the so-called Internet gateways) with new functionality enablingthe communication between the sensors deployed within theintelligent building and any remote service providerend userinterface [18]

As an output of testing our proposed schemes (JSON andProtocol Buffers) in real use case (using the IMS infrastruc-ture of Telekom Austria Group and real sensorsmeters) we

can conclude that both proposed structures (often named as ascheme) togetherwith SIP as a container for data transmissionrepresent the fully functional approach to transporting M2Mdata over future Internet Furthermore the created solutionsare ready for further modifications (adding new meters orupdating current meter parameters)

The key identified challenges were discussed with ourindustry partners and the resulting implementation wastested as part of a market-ready commercial product There-fore we believe that this comprehensive description ofapplication protocols together with enabling data structuressummarized by this paper will contribute to the importantdevelopments within the IoT vision or the so-called IoTdomain thus making them easier to understand andmanage

Competing Interests

The authors declare that they have no competing interests

Acknowledgments

The described research was supported by the National Sus-tainability Program under Grant LO1401 For the researchinfrastructure of the SIX Center was used The authorswould like to thank Telekom Austria Group for access to SIPinfrastructure and insight into the SIP protocol for M2M andits real-life usage

References

[1] Cisco ldquoCisco visual networking index globalmobile data trafficforecast update 2014ndash2019rdquo White Paper 2015

[2] A Greenspan and C Lewis ldquoMonetize the Internet of ThingsJSON turns a flood of data into business actions and resultsrdquo2015 httpbitly1He09Vu

[3] MCondoluciMDohlerGAraniti AMolinaro andK ZhengldquoToward 5G densenets architectural advances for effectivemachine-type communications over femtocellsrdquo IEEE Commu-nications Magazine vol 53 no 1 pp 134ndash141 2015

[4] P Masek K Zeman Z Kuder et al ldquoWireless M-BUS anattractive M2M technology for 5G-grade home automationrdquoin Proceedings of the EAI International Conference on Cyber-Physical Systems iOt and Sensors Networks (CYCLONE rsquo15) pp1ndash12 Rome Italy October 2015

[5] J Hosek P Masek D Kovac M Ries and F Kropfl ldquoUniversalsmart energy communication platformrdquo in Proceedings of theInternational Conference on Intelligent Green Building and SmartGrid (IGBSG rsquo14) pp 1ndash4 Taipei Taiwan April 2014

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

[7] R Khan S U Khan R Zaheer and S Khan ldquoFuture internetthe internet of things architecture possible applications and keychallengesrdquo in Proceedings of the 10th International Conferenceon Frontiers of Information Technology (FIT rsquo12) pp 257ndash260IEEE Islamabad Pakistan December 2012

[8] J Rosenberg H Schulzrinne G Camarillo et al ldquoSIP SessionInitiation Protocolrdquo IETF Std RFC3261 2002 httpwwwietforgrfcrfc3261txt


[9] A Niemi ldquoSession Initiation Protocol (SIP) Extension for EventState Publicationrdquo IETF Standards RFC3903 October 2004httpwwwietforgrfcrfc3903txt

[10] ldquoSession Initiation Protocol (SIP) Extension for Instant Mes-sagingrdquo IETF RFC3428 2002 httpswwwietforgrfcrfc3428txt

[11] MQTelemetry Transport (MQTT) V31 Protocol SpecificationIBM Developer Works 2014 httpgoogl3tLZVj

[12] MQTT For Sensor Networks (MQTT-SN) Protocol Specifica-tion Version 12 2013 httpgoogleDqIRQ

[13] CoAP RFC 7252 Constrained Application Protocol CoAPTechnology 2014 httpcoaptechnology

[14] AMQP AdvancedMessage Queuing Protocol 2015 httpswwwamqporg

[15] DDS Data Distribution Service The Proven Data ConnectivityStandard for the IoT 2015 httpportalsomgorgdds

[16] Extensible Messaging and Presence Protocol (XMPP) CoreIETF RFC 6120 2011 httpstoolsietforghtmlrfc6120

[17] N Komninos E Philippou and A Pitsillides ldquoSurvey insmart grid and smart home security issues challenges andcountermeasuresrdquo IEEECommunications Surveys andTutorialsvol 16 no 4 pp 1933ndash1954 2014

[18] GitHub SyMPHOnY (Smart Multi-Purpose Home Gateway)httpsgithubcomSyMPHOnY-Smart-Home-Gatewaywiki

[19] Y Lai J Kang and R Yu ldquoEfficient and secure resource man-agement in homeM2M networksrdquo International Journal of Dis-tributed Sensor Networks vol 2013 Article ID 849572 12 pages2013

[20] M M Islam J H Lee and E-N Huh ldquoAn efficient model forsmart home by the virtualization of wireless sensor networkrdquoInternational Journal of Distributed Sensor Networks vol 2013Article ID 168735 10 pages 2013

[21] M Sneps-Sneppe andDNamiot ldquoAboutM2MstandardsM2Mand open APIrdquo in Proceedings of the 7th International Confer-ence onDigital Telecommunications (ICDT rsquo12) pp 111ndash117MontBlanc France April-May 2012

[22] Z M Fadlullah MM Fouda N Kato A Takeuchi N Iwasakiand Y Nozaki ldquoToward intelligent machine-to-machine com-munications in smart gridrdquo IEEE Communications Magazinevol 49 no 4 pp 60ndash65 2011

[23] World Wide Web Consortium (W3C) httpwwww3org[24] The Internet Engineering Task Force (IETF) httpswwwietf

org[25] ldquoIEEEmdashThe worldrsquos largest professional association for the

advancement of technologyrdquo httpswwwieeeorgindexhtml[26] ETSImdashEuropean Telecommunications Standards Institute

httpwwwetsiorg[27] D Locke ldquoMQ Telemetry Transport (MQTT) v 31 protocol

specificationrdquo IBM Developer Works Technical Library httpgoogl3tLZVj

[28] N Gligoric T Dimcic D Drajic et al ldquoCoAP over SMS per-formance evaluation for machine to machine communicationrdquoin Proceedings of the 20th Telecommunications Forum (TELFORrsquo12) pp 1ndash4 Belgrade Serbia November 2012

[29] W Colitti K Steenhaut N De Caro B Buta and V DobrotaldquoEvaluation of constrained application protocol for wirelesssensor networksrdquo in Proceedings of the 18th IEEE Workshop onLocal and Metropolitan Area Networks (LANMAN rsquo11) pp 1ndash6Chapel Hill NC USA October 2011

[30] M T Jones ldquoMeet the Extensible Messaging and PresenceProtocol (XMPP)rdquo DeveloperWorks 2009

[31] PWaher and Y DoiXEP-0322 Efficient XML Interchange (EXI)Format 2013

[32] T Kamiya and J Schneider Efficient XML Interchange (EXI)Format 10 World Wide Web Consortium RecommendationREC Exi-20110310 2011

[33] J L Fernandes I C Lopes J J P C Rodrigues and S UllahldquoPerformance evaluation of RESTful web services and AMQPprotocolrdquo in Proceedings of the 5th International Conference onUbiquitous and FutureNetworks (ICUFN rsquo13) pp 810ndash815 IEEEDa Nang Vietnam July 2013

[34] Data Distribution Services Specification V12 httpwwwomgorgspecDDS12

[35] C Esposito S Russo and D Di Crescenzo ldquoPerformanceassessment of OMG compliant data distribution middlewarerdquoin Proceedings of the 22nd IEEE International Parallel and Dis-tributed Processing Symposium (IPDPS rsquo08) pp 1ndash8 Miami FlaUSA April 2008

[36] D Thangavel X Ma A Valera H-X Tan and C K-Y TanldquoPerformance evaluation of MQTT and CoAP via a commonmiddlewarerdquo in Proceedings of the 9th IEEE International Con-ference on Intelligent Sensors Sensor Networks and InformationProcessing (ISSNIP rsquo14) pp 1ndash6 IEEE Singapore April 2014

[37] N De Caro W Colitti K Steenhaut G Mangino and G RealildquoComparison of two lightweight protocols for smartphone-based sensingrdquo in Proceedings of the 20th IEEE Symposium onCommunications and Vehicular Technology in the BeNeLux(SCVT rsquo13) pp 1ndash6 Namur Belgium November 2013

[38] J Hosek P Masek D Kovac and F Kropfl ldquoM2M gateway thecenterpiece of future homerdquo in Proceedings of the 6th Inter-national Congress on Ultra Modern Telecommunications andControl Systems and Workshops (ICUMT rsquo14) pp 190ndash197 StPetersburg Russia October 2014

[39] S-M Kim H-S Choi and W-S Rhee ldquoIoT home gateway forauto-configuration and management of MQTT devicesrdquo inProceedings of the IEEE Conference on Wireless Sensors (ICWiSersquo15) pp 12ndash17 IEEE Malacca Malaysia August 2015

[40] GoogleDevelopers ldquoProtocol Buffersrdquo httpsdevelopersgooglecomprotocol-buffers

[41] C Ortega-Corral L E Palafox J A Garcıa-Macıas J Sanchez-Garcıa and L Aguilar ldquoEnd-to-end message exchange in adeployable marine environment hierarchical wireless sensornetworkrdquo International Journal of Distributed Sensor Networksvol 2014 Article ID 950973 18 pages 2014

[42] T Bray ldquoThe JavaScript Object Notation (JSON) data inter-change formatrdquo RFC 7159 IETF 2014 httpstoolsietforghtmlrfc7159

[43] Introducing JSON ECMA-404 the JSON Data InterchangeStandard 2015 httpwwwjsonorgjson-enhtml

[44] JSON-Schema The Home of JSON Schema 2015 httpjson-schemaorg

[45] JSON (JavaScript Object Notation) 10 Example of JSON Files2015 httpwwwsitepointcom10-example-json-files

[46] W3Schools JSON Syntax 2015 httpbitly1QmCrLm[47] J Hosek P Masek M Ries D Kovac M Bartl and F Kropfl

ldquoUse case study on embedded systems serving as smart homegatewaysrdquo in Recent Advances in Circuits Systems and Auto-matic Control pp 310ndash315 EUROPMENT Budapest Hungary2013

[48] OSGi Alliance httpwwwosgiorg[49] Port Project for theMIPSArchitecture httpmailopenjdkjava

netmailmanlistinfomips-port-dev


[50] Official and not-so-official thoughts on Java oracle announcesplans for Java on MIPS httpbitly1YVKC50

[51] OpenWRT Wireless Freedom Barrier Breaker httpwikiopenwrtorgdocbarrierbreaker

[52] JAIN-SIP API The Source for Java Technology Collaborationhttpsjsipjavanet

[53] The SIP INFOMethod IETF RFC 2976 2000 httpswwwietforgrfcrfc2976txt

[54] Reliability of Provisional Responses in the Session InitiationProtocol (SIP) IETF RFC 3262 2002 httpswwwietforgrfcrfc3262txt

[55] IETF ldquoSession initiation protocol (SIP)-specific event notifica-tionrdquo RFC 3265 IETF 2002 httpswwwietforgrfcrfc3265txt

[56] The Session Initiation Protocol (SIP) UPDATE Method IETFRFC3311 2002 httpstoolsietforghtmlrfc3311

[57] ldquoThe Reason Header Field for the Session Initiation Protocol(SIP)rdquo IETF RFC3326 2002 httpstoolsietforgrfcrfc3326txt

[58] Session Initiation Protocol (SIP) Extension for Instant Messag-ing IETF RFC3428 2002 httpswwwietforgrfcrfc3428txt

[59] ldquoThe Session Initiation Protocol (SIP) Refer Methodrdquo IETFRFC3515 2003 httpswwwietforgrfcrfc3515txt

[60] An Extension to the Session Initiation Protocol (SIP) forSymmetric Response Routing IETF RFC3581 httpswwwietforgrfcrfc3581txt

[61] ldquoSession Initiation Protocol (SIP) Extension for Event StatePublicationrdquo IETF RFC3903 2004 httpswwwietforgrfcrfc3903txt

[62] X-Lite ldquoSIP-based softphones server applications and FixedMobile Convergence (FMC) solutionsrdquo httpwwwcounter-pathcomx-lite

[63] ZoiPer Unified VoIP Communications httpwwwzoipercomen

[64] Asterisk an open source telephony switching and privatebranch exchange service for Linux httpwwwasteriskorg

[65] Common Format and MIME Type for Comma-SeparatedValues (CSV) Files IETF RFC 4180 2005 httpstoolsietforghtmlrfc4180

[66] EN ldquoCommunication systems formeters and remote reading ofmetersmdashpart 4 wireless meter readout (radiometer reading foroperation in the 868MHz to 870MHz SRD band)rdquo EN 13757-42005 2005

[67] WepTech ldquoHumidity and temperature sensor WEP OMSF-868Ardquo httpswwwweptechdeproductsoms-humidityand-temperature-sensor-wep-omsf-868ahtml

[68] Bonega ldquoUltra-Antimagnetic Water-Metersrdquo httpbitly1prr8cu

[69] Pikkerton Wireless M-Bus Smart Cable Meter MBS-112httpbitly1Uwa8gk

[70] KNX Association httpwwwknxorgknx-enindexphp[71] List of standard OBIS codes and COSEM objects httpbitly1

KTdYYg

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


Research ArticleImplementation of True IoT Vision Survey onEnabling Protocols and Hands-On Experience

Pavel Masek1 Jiri Hosek1 Krystof Zeman1 Martin Stusek1 Dominik Kovac1

Petr Cika1 Jan Masek2 Sergey Andreev3 and Franz Kroumlpfl4

1Department of Telecommunications Brno University of Technology Technicka 12 616 00 Brno Czech Republic2Institute of Structural Mechanics Brno University of Technology Technicka 12 616 00 Brno Czech Republic3Department of Electronics and Communications Engineering Tampere University of Technology Korkeakoulunkatu 1033720 Tampere Finland4Telekom Austria Group Lassallestraszlige 9 1020 Vienna Austria

Correspondence should be addressed to Pavel Masek masekpavelfeecvutbrcz

Received 7 January 2016 Accepted 15 February 2016

Academic Editor Piedad Garrido

Copyright copy 2016 Pavel Masek 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

Internet ofThings (IoT) is expected to become a driver in an emerging era of interconnected world through the advanced connec-tivity of smart devices systems and services IoT goes beyond a broad range of Machine-to-Machine (M2M) communicationtechnologies and covers a wide variety of networking protocols There exist solutions like MQTT or SIP collecting data fromsensors CoAP for constrained devices and networks or XMPP for interconnecting devices and people Also there is a plethoraof standards and frameworks (OSGi AllJoyn) bringing closer the paradigm of IoT vision However the main constraint of mostexisting platforms is their limited mutual interoperability To this end we provide a comprehensive description of protocolssuitable to support the IoT vision Further we advocate an alternative approach to already known principles and employ the SIPprotocol as a container for M2M data We provide description of data structures and practical implementation principles of theproposed structures (JSON and Protocol Buffers are discussed in detail) transmitted by SIP as a promising enabler for efficientM2M communication in the IoT world Our reported findings are based on extensive hands-on experience collected after thedevelopment of advanced M2M smart home gateway in cooperation with the operator Telekom Austria Group

1 Introduction

Presently the world around us is humming with data fromsmart meters sensors or actuators Everyday devices likeenergy meters water meters or environment sensors areno longer isolated entities performing their tasks offline Incontrast the goal of smart devices is to make our personaland business lives easier and more efficientmdashtoday we cansee a wide variety of smart devices (eg smart meterssensors and actuators) coming on the market in waves andtargeting to bring intelligent behavior into todayrsquos households[1] All kinds of such devices are interconnected within onecommunication paradigm named Internet of Things (IoT)where the tremendous volumes of measured data need to betransmitted

Following the fact that over the last decade the IoThas attracted an enormous interest from numerous industrydomains [1] the number of Machine-to-Machine (M2M)connections will grow to over 3 billion in 2019 Hencethere is a crucial need to develop appropriate communi-cation protocols for M2M (together with appropriate datastructureformat) to manage data from different sourcesmdashstoring organizing and analyzing data to enrich the newbusinesses with novel revenue streams and valuable services(frameworks) [1 2]

Envisioning the future of M2M communication thetelecommunication operators will play a key role in providingand supporting the communication infrastructure betweenend devices Today the 4G and beyond cellular networks(Long Term Evolution LTE) increasingly introduce support

Hindawi Publishing CorporationInternational Journal of Distributed Sensor NetworksVolume 2016 Article ID 8160282 18 pageshttpdxdoiorg10115520168160282








2 IoT Protocols



















Subscriber 1

Subscriber 2









CoAP clients


Internet

CoAP domain


1

2

3







16 31T OC

0 1 2 3Code

85 6 7 15










Gateway

Internet


1

234

Server 1 Server 2



ltpresencegt

ltbodygtltmessagegt

ltquerygtltiqgt

ltstreamgt

ltstreamgt








AMQP broker

Publisher

Subscriber 1


Queue

Queue


Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message










SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF


Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL


Internet

Datavalues

Datavalues
















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation
















2 IoT Protocols



















Subscriber 1

Subscriber 2









CoAP clients


Internet

CoAP domain


1

2

3







16 31T OC

0 1 2 3Code

85 6 7 15










Gateway

Internet


1

234

Server 1 Server 2



ltpresencegt

ltbodygtltmessagegt

ltquerygtltiqgt

ltstreamgt

ltstreamgt








AMQP broker

Publisher

Subscriber 1


Queue

Queue


Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message










SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF


Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL


Internet

Datavalues

Datavalues
















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation























Subscriber 1

Subscriber 2









CoAP clients


Internet

CoAP domain


1

2

3







16 31T OC

0 1 2 3Code

85 6 7 15










Gateway

Internet


1

234

Server 1 Server 2



ltpresencegt

ltbodygtltmessagegt

ltquerygtltiqgt

ltstreamgt

ltstreamgt








AMQP broker

Publisher

Subscriber 1


Queue

Queue


Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message










SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF


Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL


Internet

Datavalues

Datavalues
















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation












16 31T OC

0 1 2 3Code

85 6 7 15










Gateway

Internet


1

234

Server 1 Server 2



ltpresencegt

ltbodygtltmessagegt

ltquerygtltiqgt

ltstreamgt

ltstreamgt








AMQP broker

Publisher

Subscriber 1


Queue

Queue


Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message










SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF


Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL


Internet

Datavalues

Datavalues
















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










AMQP broker

Publisher

Subscriber 1


Queue

Queue


Hea

der

Deli

very

anno

tatio

ns

Mes

sage

anno

tatio

ns

Prop

ertie

s

Appl

icat

ion

prop

ertie

s

Appl

icat

ion

data

Foot

er

Bare message

Annotated message










SizeDOFF Type4

0

8 Extended header

Framebody

Frame Header (8B)

ltType-Specificgt

ltType-Specificgt

ltType-Specificgt

4lowast

DO

FF


Publisher

DataWriter

Subscriber

DataReader

Subscriber

DataReader

Data object

Datavalues

DLRL


Internet

Datavalues

Datavalues
















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation



















Internet

Registrar server

SIP proxy server

SIP redirect server

Location server













0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation












0 3 4 15 16 23 24 31










Client Server

CON [0x8b56]

ACK [0x8b56]


Client Server

NON [0x8b57]



Client Server

CON [0x8c51]

ACK [0x8c51]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

ldquoNot foundrdquo

404 not found

CON [0x8c51]

ACK [0x8c51]

(token 0x22)

(token 0x22)

GETmdashtemperature

(b)












ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation













ACK [0x4d45]

ACK [0x4d45]

CON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(a)

Client Server

NON [0x4d45]

NON [0x4d45]

(token 0x21)


ldquo218Crdquo

GETmdashtemperature

(b)






(sink)

Subscribe (topic)




Unregister


401 unauthorized


SIP client

Unregister

401 unauthorized


200OK






Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










Message (request)


Message (request)

TransactionDialog









UAC

Clie

nt tr

ansa

ctio

n

Proxy

Clie

nt tr

ansa

ctio

n

UAS

Serv

er tr

ansa

ctio

n

Serv

er tr

ansa

ctio

nRequest

Response

Request

Response











JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










JSONobject

string value


[ ]

value

JSONarray













string

number

object

array

true

false

null

JSONvalue


ldquo rdquo

JSONstring



b

f

n

r

t

u


Reverse solidus

Backspace

Formfeed

Newline

Carriage return

Horizontal tab


JSONnumber

0

Digit

Digit

Digit

e

EDigit

minus

minus

+

1ndash9

middot




double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










double

float

int3264

uint3264

sint3264

fixed3264

sfixed3264


bool

string

bytes










SIP bundle

DB bundle

TCPIP bundle

UPnPDLNA bundle

Image bundle

WM-BUS bundle

ZigBee bundle

Cloud-APIbundle

JSON bundle Core









Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation











Core Bundle

setProfile

Register

Registered

sendMessage

IncomingSIP message

Yes No

Yes No














MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










MTCG

IMSSIP network

Public network

3rd-party services

MQTT

CoAP

SIP

MQTT client

CoAP client

SIP client

Electricitymeter

Watermeter

Alarmsystem

Smartbulbs

Possibleuse cases


Photovoltaic panel

















system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










system

type SH-GW

location


format DD

latitude 4729

longitude 1621

data [

name Current Time

value 2015-10-15T153256+0100

name Status


]

device

type Smart Meter


id [

name Serial Number

value 013146520004-1

objectCode 0-09610


value TAG000000000000000000000000000001

objectCode 0-096110

]

timestamp 2015-10-15T153256+0100

data [


value 12465

units kWh


objectCode 1-0180


value 12

units kWh

objectCode 1-01290

]

Algorithm 1







syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation










syntax = proto2

package vutbr






Algorithm 2

message System




Algorithm 3

message Device



repeated Id id = 3



Algorithm 4







message Location





Algorithm 5

message SystemData




enum Method

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 6

message Id




Algorithm 7

message DeviceData






enum Method

null = 0

get = 1

set = 2

response = 3


enum ResponseResult

null = 0

ok = 1

notAllowed = 2

error = 3

unknown = 4


Algorithm 8












Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation




















Competing Interests


Acknowledgments


References









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation









































































KTdYYg



RoboticsJournal of





Journal of



RotatingMachinery





VLSI Design



Shock and Vibration







Journal of



Volume 2014


SensorsJournal of





Propagation































KTdYYg



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

Implementation of True IoT Vision - TUT · Implementation of True IoT Vision: ... that SIP represents a lightweight communication protocol ... use MQTT protocol may go to sleep state