PDF of module number 4 of Internet of Things subject of Mumbai University

Internet of Things

2. Content
•TheTransportLayer
•IoTApplicationTransportMethods
•ApplicationLayerProtocolNotPresent
•SCADA-BackgroundonSCADA,AdaptingSCADAforIP,TunnellingLegacySCADAoverIPNetworks,
SCADAProtocolTranslation,SCADATransportoverLLNswithMAP-T
•GenericWeb-BasedProtocols
•IoTApplicationLayerProtocols–CoAPandMQTT

3. The Transport Layer
•InthecontextofIoTnetworks,withtheTCP/IPprotocol,twomainprotocolsarespecifiedforthetransportlayer:
•TransmissionControlProtocol(TCP):Thisconnection-orientedprotocolrequiresasessiontogetestablished
betweenthesourceanddestinationbeforeexchangingdata.
•UserDatagramProtocol(UDP):Withthisconnectionlessprotocol,datacanbequicklysentbetweensourceand
destination—butwithnoguaranteeofdelivery.Thisisanalogoustothetraditionalmaildeliverysystem,inwhicha
letterismailedtoadestination.Confirmationofthereceptionofthisletterdoesnothappenuntilanotherletteris
sentinresponse.
•TCPisthemainprotocolusedatthetransportlayer.
•Thisislargelyduetoitsinherentcharacteristics,suchasitsabilitytotransportlargevolumesofdataintosmaller
setsofpackets.Inaddition,itensuresreassemblyinacorrectsequence,flowcontrolandwindowadjustment,and
retransmissionoflostpackets.
•Thesebenefitsoccurwiththecostofoverheadperpacketandpersession,potentiallyimpactingoverallpacketper
secondperformancesandlatency.

4. The Transport Layer
•Incontrast,UDPismostoftenusedinthecontextofnetworkservices,suchasDomainNameSystem(DNS),
NetworkTimeProtocol(NTP),SimpleNetworkManagementProtocol(SNMP),andDynamicHostControl
Protocol(DHCP),orforreal-timedatatraffic,includingvoiceandvideooverIP.
•Inthesecases,performanceandlatencyaremoreimportantthanpacketretransmissionsbecausere-sending
alostvoiceorvideopacketdoesnotaddvalue.
•WhenconsideringthechoiceofatransportlayerbyagivenIoTapplicationlayerprotocol,itisrecommended
toevaluatetheimpactofthischoiceonboththelowerandupperlayersofthestack.
•Forexample,mostoftheindustrialapplicationlayerprotocols,areimplementedoverTCP,whiletheir
specificationsmayoffersupportforbothtransportmodels.Thereasonforthisisthatoftentheseindustrial
applicationlayerprotocolsareolderandweredeployedwhendatalinklayerswereoftenunreliableand
calledforerrorprotection.
•WhenusingTCP,eachpacketneedstoaddaminimumof20bytesofTCPoverhead,whileUDPaddsonly8
bytes.TCPalsorequirestheestablishmentandpotentialmaintenanceofanopenlogicalchannel.

5. The Transport Layer
•LowPowerandLossyNetworks(LLNs)arecomprisedofembeddeddeviceswithlimitedpower,memory,and
processingresourcesinterconnectedbyavarietyoflinks.ThistechniqueiswidelyusedinIoTwithapplication
areas,including,industrialmonitoring,buildingautomation(heating,ventilation,andairconditioning(HVAC),
lighting,accesscontrol,fire),connectedhome,healthcare,environmentalmonitoring,urbansensornetworks,
energymanagement,assetstracking,andrefrigeration.
•Asit’snatureisnotrobust,LLNsmaynotcopewellwithsupportinglargenumbersofTCPsessions.
•HencenewIoTapplicationprotocol,suchasConstrainedApplicationProtocol(CoAP),almostalwaysusesUDPand
industrialapplicationlayerprotocolsmaycallfortheoptimizationandadoptionoftheUDPtransportlayerifrun
overLLNs.
•Withmulticast,asinglemessagecanbesenttomultipleIoTdevices.ThisisusefulintheIoTcontextforupgrading
thefirmwareofmanyIoTdevicesatonce.MulticastexclusivelyusesUDPonly.
•Insummary,TCPandUDParethetwomainchoicesatthetransportlayerfortheTCP/IPprotocol.The
performanceandscalabilityofIoTconstraineddevicesandnetworksisimpactedbywhichoneoftheseisselected.

6. IoT Application Transport Methods
•BecauseofthediversetypesofIoTapplicationprotocols,therearevariousmeansfortransportingtheseprotocols
acrossanetwork.
•ThefollowingcategoriesofIoTapplicationprotocolsandtheirtransportmethodsareexploredinthefollowing
sections:
•Applicationlayerprotocolnotpresent:Inthiscase,thedatapayloadisdirectlytransportedontopofthelower
layers.Noapplicationlayerprotocolisused.
•Supervisorycontrolanddataacquisition(SCADA):SCADAisoneofthemostcommonindustrialprotocolsinthe
world,butitwasdevelopedlongbeforethedaysofIP,andithasbeenadaptedforIPnetworks.
•Genericweb-basedprotocols:Genericprotocols,suchasEthernet,Wi-Fi,and4G/LTE,arefoundonmany
consumer-andenterprise-classIoTdevicesthatcommunicateovernon-constrainednetworks.
•IoTapplicationlayerprotocols:IoTapplicationlayerprotocolsaredevisedtorunonconstrainednodeswitha
smallcomputefootprintandarewelladaptedtothenetworkbandwidthconstraintsoncellularorsatellitelinksor
constrained6LoWPANnetworks.MessageQueuingTelemetryTransport(MQTT)andConstrainedApplication
Protocol(CoAP),coveredlaterinthischapter,aretwowellknownexamplesofIoTapplicationlayerprotocols.

7. Application layer protocol not present
•Class0devicessendorreceiveonlyafewbytesofdata.
•Formyriadreasons,suchasprocessingcapability,powerconstraints,andcost,thesedevicesdonotimplementa
fullystructurednetworkprotocolstack,suchasIP,TCP,orUDP,orevenanapplicationlayerprotocol.
•Class0devicesareusuallysimplesmartobjectsthatareseverelyconstrained.Implementingarobustprotocol
stackisusuallynotusefulandsometimesnotevenpossiblewiththelimitedavailableresources.
•Forexample,considerlow-costtemperatureandrelativehumidity(RH)sensorssendingdataoveranLPWA
LoRaWANinfrastructure.Temperatureisrepresentedas2bytesandRHasanother2bytesofdata.
•Therefore,thissmalldatapayloadisdirectlytransportedontopoftheLoRaWANMAClayer,withouttheuseof
TCP/IP.
•Whilemanyconstraineddevices,suchassensorsandactuators,haveadopteddeploymentsthathaveno
applicationlayer,thistransportationmethodhasnotbeenstandardized.
•Thislackofstandardizationmakesitdifficultforgenericimplementationsofthistransportmethodtobesuccessful
fromaninteroperabilityperspective.

8. Application layer protocol not present (Cont…)
•Consideranexample:
•Imaginedifferentkindsoftemperaturesensorsfromdifferentmanufacturers.
•Thesesensorswillreporttemperaturedatainvaryingformats.Atemperaturevaluewillalwaysbepresentin
thedatatransmittedbyeachsensor,butdecodingthisdatawillbevendorspecific.Scalethisscenarioout
acrosshundredsorthousandsofsensors,theproblemofallowingvariousapplicationstoreceiveand
interprettemperaturevaluesdeliveredindifferentformatsbecomesincreasinglycomplex.Thesolutionto
thisproblemistouseanIoTdatabroker.
•AnIoTdatabrokerisapieceofmiddlewarethatstandardizessensoroutputintoacommonformatthatcan
thenberetrievedbyauthorizedapplications.

9. Application layer protocol not present (Cont…)
Fig: IoT Data Broker

10. Application layer protocol not present (Cont…)
•Inpreviousfigure,SensorsX,Y,andZarealltemperaturesensors,buttheiroutputisencodeddifferently.
•TheIoTdatabrokerunderstandsthedifferentformatsinwhichthetemperatureisencodedandisthereforeabletodecodethis
dataintoacommon,standardizedformat.
•ApplicationsA,B,andCinshowninpreviousfigurecanaccessthistemperaturedatawithouthavingtodealwithdecoding
multipletemperaturedataformats.
•IoTdatabrokersareutilizedfromacommercialperspectivetodistributeandsellIoTdatatothirdparties.Companiescan
provideaccesstotheirdatabrokerfromanothercompany’sapplicationforafee.
•ThismakesanIoTdatabrokerapossiblerevenuestream,dependingonthevalueofthedataitcontains.
•Insummary,whiledirectlytransportingdatapayloadwithoutastructurednetworkstackclearlyoptimizesdatatransmission
overlow-data-ratenetworks,thelackofadatamodelimpliesthateachapplicationneedstoknowhowtointerpretthedata-
specificformat.
•Thisbecomesincreasinglycomplexforlargernetworksofdeviceswithdifferentdatapayloadformats.
•Furthermore,itmakestheIoTapplicationenvironmentchallengingintermsofevolution,development,interoperability,andso
on,andoftencallsforstructureddatamodelsanddatabrokerapplications.

11. SCADA
BackgroundonSCADA:
•supervisorycontrolanddataacquisition(SCADA)isanautomationcontrolsystemthatwasinitiallyimplemented
withoutIPoverseriallinks,beforebeingadaptedtoEthernetandIPv4.
•SCADAnetworkingprotocolsarewellstructuredprotocolsrunningdirectlyoverserialphysicalanddatalinklayers.
•Atahighlevel,SCADAsystemscollectsensordataandtelemetryfromremotedevices,whilealsoprovidingthe
abilitytocontrolthem.SCADAsystemsallowglobal,real-time,data-drivendecisionstobemadeabouthowto
improvebusinessprocesses.
•SCADAmainlyconcentratedintheutilitiesandmanufacturing/industrialverticals.Withinthesespecificindustries,
SCADAcommonlyusescertainprotocolsforcommunicationsbetweendevicesandapplications.
•Forexample,Modbusanditsvariantsareindustrialprotocolsusedtomonitorandprogramremotedevicesviaa
master/slaverelationship.Modbusisalsofoundinbuildingmanagement,transportation,andenergyapplications.

12. SCADA (Cont…)
AdaptingSCADAforIP:
•Inthe1990s,therapidadoptionofEthernetnetworksintheindustrialworlddrovetheevolutionofSCADA
applicationlayerprotocols.
•Forexample,theIECadoptedtheOpenSystemInterconnection(OSI)layermodeltodefineitsprotocol
framework.OtherprotocolusergroupsalsoslightlymodifiedtheirprotocolstorunoveranIPinfrastructure.
•BenefitsofthismovetoEthernetandIPincludetheabilitytoleverageexistingequipmentandstandards
whileintegratingseamlesslytheSCADAsubnetworkstothecorporateWANinfrastructures.
•TofurtherfacilitatethesupportoflegacyindustrialprotocolsoverIPnetworks,protocolspecificationswere
updatedandpublished,documentingtheuseofIPforeachprotocol.

13. SCADA (Cont…)
AdaptingSCADAforIP:
•ThisincludedassigningTCP/UDPportnumberstotheprotocols,suchasthefollowing:
•DNP3(adoptedbyIEEE1815-2012)specifiestheuseofTCPorUDPonport20000fortransportingDNP3
messagesoverIP.
•TheModbusmessagingserviceutilizesTCPport502.
•IEC60870-5-104istheevolutionofIEC60870-5-101serialforrunningoverEthernetandIPv4usingport
2404.
•DLMSUserAssociationspecifiedacommunicationprofilebasedonTCP/IPintheDLMS/COSEMGreenBook
(Edition5orhigher),orintheIEC62056-53andIEC62056-47standards,allowingdataexchangeviaIPand
port4059.

14. SCADA (Cont…)
AdaptingSCADAforIP:
•ThisincludedassigningTCP/UDPportnumberstotheprotocols,suchasthefollowing:
•DNP3(adoptedbyIEEE1815-2012)specifiestheuseofTCPorUDPonport20000fortransportingDNP3
messagesoverIP.
•TheModbusmessagingserviceutilizesTCPport502.
•IEC60870-5-104istheevolutionofIEC60870-5-101serialforrunningoverEthernetandIPv4usingport
2404.
•DLMSUserAssociationspecifiedacommunicationprofilebasedonTCP/IPintheDLMS/COSEMGreenBook
(Edition5orhigher),orintheIEC62056-53andIEC62056-47standards,allowingdataexchangeviaIPand
port4059.
•TheselegacyserialprotocolshaveadaptedandevolvedtoutilizeIPandTCP/UDPasbothnetworkingand
transportmechanisms.

15. SCADA (Cont…)
AdaptingSCADAforIP:
•DNP3isonesuchlegacyserialprotocol.
•TheDistributedNetworkProtocol(DNPorDNP3)wasintroducedin1993asanimmediatelydeployablesolution
formonitoringinfrastructurestatusandtoallowreliableremotecontrol.Sincethenthisprotocolhasachieved
generalacceptanceandisnowusedbymultipledifferentmanufacturersinmanyapplications.
•DNP3isbasedonamaster/slaverelationship.
•Thetermmasterinthiscasereferstowhatistypicallyapowerfulcomputerlocatedinthecontrolcenterofa
utility,andaslaveisaremotedevicewithcomputingresourcesfoundinalocationsuchasasubstation.
•DNP3referstoslavesspecificallyasoutstations.Outstationsmonitorandcollectdatafromdevicesthatindicate
theirstate,suchaswhetheracircuitbreakerisonoroff,andtakemeasurements,includingvoltage,current,
temperature,andsoon.
•Thisdataisthentransmittedtothemasterwhenitisrequested,oreventsandalarmscanbesentinan
asynchronousmanner.Themasteralsoissuescontrolcommands,suchastostartamotororresetacircuitbreaker,
andlogstheincomingdata.

16. SCADA (Cont…)
AdaptingSCADAforIP:
Fig: Protocol Stack for Transporting
Serial DNP3 SCADA over IP

17. SCADA (Cont…)
AdaptingSCADAforIP:
•TheDNP3protocolisfurthermodifiedtoadapttoruneitheroverTCP(recommended)orUDPusingIEEE1815-2012
specification.
•ConnectionmanagementlinkstheDNP3layerswiththeIPlayersinadditiontotheconfigurationparametersandmethods
necessaryforimplementingthenetworkconnection.
•TheIPlayersappeartransparenttotheDNP3layersaseachpieceoftheprotocolstackinonestationlogicallycommunicates
withtherespectivepartintheother.ThismeansthattheDNP3endpointsordevicesarenotawareoftheunderlyingIP
transportthatisoccurring.
•ThemastersideinitiatesconnectionsbyperformingaTCPactiveopen.Theoutstationlistensforaconnectionrequestby
performingaTCPpassiveopen.Dualendpointisdefinedasaprocessthatcanbothlistenforconnectionrequestsandperform
anactiveopenonthechannelifrequired.
•MasterstationsmayparsemultipleDNP3datalinklayerframesfromasingleUDPdatagram,whileDNP3datalinklayerframes
cannotspanmultipleUDPdatagrams.
•SingleormultipleconnectionstothemastermaygetestablishedwhileaTCPkeepalivetimermonitorsthestatusofthe
connection.KeepalivemessagesareimplementedasDNP3datalinklayerstatusrequests.
•Ifaresponseisnotreceivedtoakeepalivemessage,theconnectionisdeemedbroken,andtheappropriateactionistaken.

18. SCADA (Cont…)
TunnellingLegacySCADAoverIPNetworks:
•TransportoftheoriginalserialprotocoloverIPcanbeachievedeitherbytunnelingusingrawsocketsover
TCPorUDPorbyinstallinganintermediatedevicethatperformsprotocoltranslationbetweentheserial
protocolversionanditsIPimplementation.
•ArawsocketconnectionsimplydenotesthattheserialdataisbeingpackageddirectlyintoaTCPorUDP
transport.Asocketinthisinstanceisastandardapplicationprogramminginterface(API)composedofanIP
addressandaTCPorUDPportthatisusedtoaccessnetworkdevicesoveranIPnetwork.
•FigureshowsrawsocketscenariosforalegacySCADAservertryingtocommunicatewithremoteserial
devices.

19. SCADA (Cont…)
TunnellingLegacySCADAoverIP
Networks:
Fig: Raw Socket TCP or UDP Scenarios
for Legacy Industrial Serial Protocols

20. SCADA (Cont…)
TunnellingLegacySCADAoverIPNetworks:
•InallthescenariosinFigureabove,routersconnectviaserialinterfacestotheremoteterminalunits(RTUs),which
areoftenassociatedwithSCADAnetworks.
•AnRTUisamultipurposedeviceusedtomonitorandcontrolvarioussystems,applications,anddevicesmanaging
automation.Fromthemaster/slaveperspective,theRTUsaretheslaves.
•OppositetheRTUsineachscenarioisaSCADAserver,ormaster,thatvariesitsconnectiontype.
•InScenarioA,boththeSCADAserverandtheRTUshaveadirectserialconnectiontotheirrespectiverouters.The
routersterminatetheserialconnectionsatbothendsofthelinkanduserawsocketencapsulationtotransportthe
serialpayloadovertheIPnetwork.
•ScenarioBhasasmallchangeontheSCADAserverside.ApieceofsoftwareisinstalledontheSCADAserverthat
mapstheserialCOMportstoIPports.ThissoftwareiscommonlyreferredtoasanIP/serialredirector.TheIP/serial
redirectorinessenceterminatestheserialconnectionoftheSCADAserverandconvertsittoaTCP/IPportusinga
rawsocketconnection.
•InScenarioC,theSCADAserversupportsnativerawsocketcapability.InScenarioCtheSCADAserverhasfullIP
supportforrawsocketconnections.

21. SCADA (Cont…)
SCADAProtocolTranslation:
•AnalternativetoarawsocketconnectionfortransportinglegacyserialdataacrossanIPnetworkisprotocol
translation.Withprotocoltranslation,thelegacyserialprotocolistranslatedtoacorrespondingIPversion.
•Forex,FigurebelowshowstwoseriallyconnectedDNP3RTUsandtwomasterapplicationssupportingDNP3over
IPthatcontrolandpulldatafromtheRTUs.
•TheIoTgatewayinthisfigureperformsaprotocoltranslationfunctionthatenablescommunicationbetweenthe
RTUsandservers,despitethefactthataserialconnectionispresentononesideandanIPconnectionisusedon
theother.
Fig: DNP3 Protocol Translation

22. SCADA (Cont…)
SCADAProtocolTranslation:
•Byrunningprotocoltranslation,theIoTgatewayconnectedtotheRTUsinFigureaboveisimplementinga
computingfunctionclosetotheedgeofthenetwork.
•AddingcomputingfunctionsclosetotheedgehelpsscaledistributedintelligenceinIoTnetworks.
•ThiscanbeaccomplishedbyofferingcomputingresourcesonIoTgatewaysorrouters,asshowninthis
protocoltranslationexample.
•Alternatively,thiscanalsobeperformeddirectlyonanodeconnectingmultiplesensors.Ineithercase,thisis
referredtoasfogcomputing.

23. SCADA (Cont…)
SCADATransportoverLLNswithMAP-T:
•DuetotheconstrainednatureofLLNs,theimplementationofindustrialprotocolsshouldataminimumbedone
overUDP.ThisinturnrequiresthatboththeapplicationserversanddevicessupportandimplementUDP.
•TodeployLLNssubnetworkswhichworksonIPv6only,onIPv4,atransitionmechanismMAP-T(Mappingof
AddressandPortusingTranslation,RFC7599),needstobeimplemented.
•FigurebelowdepictsascenarioinwhichalegacyendpointisconnectedacrossanLLNrunning6LoWPANtoanIP-
capableSCADAserver.ThelegacyendpointcouldberunningvariousindustrialandSCADAprotocols,including
DNP3/IP,Modbus/TCP,orIEC60870-5-104.
Fig: DNP3 Protocol
over 6LoWPAN
Networks with MAP-T

24. SCADA (Cont…)
SCADATransportoverLLNswithMAP-T:
•Inthisscenario,thelegacydevicesandtheSCADAserversupportonlyIPv4.However,IPv6(with6LoWPANand
RPL)isbeingusedforconnectivitytotheendpoint.
•Inthissituation,theenddevices,theendpoints,andtheSCADAserversupportonlyIPv4,butthenetworkinthe
middlesupportsonlyIPv6.
•ThesolutiontothisproblemistousetheprotocolknownasMAP-T.MAP-Tmakestheappropriatemappings
betweenIPv4andtheIPv6protocols.
•ThisallowslegacyIPv4traffictobeforwardedacrossIPv6networks.Inotherwords,olderdevicesandprotocols
cancontinuerunningIPv4eventhoughthenetworkisrequiringIPv6.
•InFigureabovetheIPv4endpointontheleftsideisconnectedtoaCustomerPremiseEquipment(CPE)device.The
MAP-TCPEdevicehasanIPv6connectiontotheRPLmesh.
•Ontherightside,aSCADAserverwithnativeIPv4supportconnectstoaMAP-Tbordergateway.TheMAP-TCPE
deviceandMAP-TbordergatewayarethusresponsiblefortheMAP-TconversionfromIPv4toIPv6.

25. Generic Web-Based Protocols
•Web-basedprotocolareusefulfordevelopingIoTapplications,services,anddevicesinordertoeasethe
integrationofdataanddevicesfromprototypingtoproductionastheyhavebecomecommonbetweenconsumers
andenterprise.
•Toselectthemostappropriateprotocol,constrainednodesandnetworksmustbeanalyzed.
•Onnon-constrainednetworks,suchasEthernet,Wi-Fi,or3G/4Gcellular,wherebandwidthisnotperceivedasa
potentialissue,datapayloadsbasedonaverbosedatamodelrepresentation,includingXMLorJavaScriptObject
Notation(JSON),canbetransportedoverHTTP/HTTPSorWebSocket.Thisallowsimplementerstodeveloptheir
IoTapplicationsincontextssimilartowebapplications.
•TheHTTP/HTTPSclient/servermodelservesasthefoundationfortheWorldWideWeb.
•Recentevolutionsofembeddedwebserversoftwarewithadvancedfeaturesarenowimplementedwithverylittle
memory.Thisenablestheuseofembeddedwebservicessoftwareonsomeconstraineddevices.
•WhenconsideringwebservicesimplementationonanIoTdevice,thechoicebetweensupportingtheclientor
serversideoftheconnectionmustbecarefullyweighed.

26. Generic Web-Based Protocols (Cont…)
•IoTdevicesthatonlypushdatatoanapplication,mayneedtoimplementwebservicesontheclientside.
TheHTTPclientsideonlyinitiatesconnectionsanddoesnotacceptincomingones.
•SomeIoTdevices,suchasavideosurveillancecamera,mayhavewebservicesimplementedontheserver
side.
•Interactionsbetweenreal-timecommunicationtoolspoweringcollaborativeapplications,suchasvoiceand
video,instantmessaging,chatrooms,andIoTdevices,arealsoemerging.
•ThisisdrivingtheneedforsimplercommunicationsystemsbetweenpeopleandIoTdevices.Oneprotocol
thataddressesthisneedisExtensibleMessagingandPresenceProtocol(XMPP).
•Insummary,theInternetofThingsgreatlybenefitsfromtheexistingweb-basedprotocols.Theseprotocols,
includingHTTP/HTTPSandXMPP,easetheintegrationofIoTdevicesintheInternetworldthroughwell-
knownandscalableprogrammingtechniques.
•However,tofullyaddressconstraineddevicesandnetworks,optimizedIoTprotocolsarerequired.

27. IoT Application Layer Protocols –CoAP and MQTT
•Whenconsideringconstrainednetworksand/oralarge-scaledeploymentofconstrainednodes,verbose
web-basedanddatamodelprotocols,maybetooheavyforIoTapplications.
•Toaddressthisproblem,theIoTindustryisworkingonnewlightweightprotocolsthatarebettersuitedto
largenumbersofconstrainednodesandnetworks.TwoofthemostpopularprotocolsareCoAPandMQTT.
•FigurebelowhighlightstheirpositioninacommonIoTprotocolstack.
Fig: Example of a High-Level IoT Protocol Stack for CoAP and MQTT
•In Figure next, CoAP and MQTT are naturally at the top of
this sample IoT stack, based on an IEEE 802.15.4 mesh
network.

•While there are a few exceptions, you will almost always
find CoAP deployed over UDP and MQTT running over TCP.

28. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
•ConstrainedApplicationProtocol(CoAP)resultedfromtheIETFConstrainedRESTfulEnvironments(CoRE)
workinggroup’seffortstodevelopagenericframeworkforresource-orientedapplicationstargeting
constrainednodesandnetworks.
•TheCoAPframeworkdefinessimpleandflexiblewaystomanipulatesensorsandactuatorsfordataordevice
management.TheIETFCoREworkinggrouphaspublishedmultiplestandards-trackspecificationsforCoAP,
includingthefollowing:
•RFC6690:ConstrainedRESTfulEnvironments(CoRE)LinkFormat
•RFC7252:TheConstrainedApplicationProtocol(CoAP)
•RFC7641:ObservingResourcesintheConstrainedApplicationProtocol(CoAP)
•RFC7959:Block-WiseTransfersintheConstrainedApplicationProtocol(CoAP)
•RFC8075:GuidelinesforMappingImplementations:HTTPtotheConstrainedApplicationProtocol(CoAP)

29. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
•TheCoAPmessagingmodelisprimarilydesignedtofacilitatetheexchangeofmessagesoverUDPbetweenendpoints,including
thesecuretransportprotocolDatagramTransportLayerSecurity(DTLS).
•CoAPmessageiscomposedofashortfixed-lengthHeaderfield(4bytes),avariable-lengthbutmandatoryTokenfield(0–8
bytes),Optionsfieldsifnecessary,andthePayloadfield.
•FigurebelowshowstheCoAPmessageformat,whichdeliverslowoverheadwhiledecreasingparsingcomplexity.
•CoAPmessageformatisrelativelysimpleandflexible.
•ItallowsCoAPtodeliverlowoverhead,whichiscriticalforconstrainednetworks,whilealsobeingeasytoparseandprocessfor
constraineddevices.
Fig: CoAP Message Format

30. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
CoAP Message FieldDescription
Ver (Version) IdentifiestheCoAPversion.
T (Type) Definesoneofthefollowingfourmessagetypes:Confirmable(CON),Non-confirmable(NON),
Acknowledgement(ACK),orReset(RST).
TKL (Token Length)Specifiesthesize(0–8Bytes)oftheTokenfield.
Code Indicatestherequestmethodforarequestmessageandaresponsecodeforaresponsemessage.
Forexample,inFigure6-9,GETistherequestmethod,and2.05istheresponsecode.
Message ID Detects message duplication and used to match ACK and RST message types to Con and NON
message types.
Token With a length specified by TKL, correlates requests and responses.
Options Specifies option number, length, and option value. Capabilities provided by the Options field include
specifying the target resource of a request and proxy functions.
Payload Payload Carries the CoAP application data. This field is optional, but when it is present, a single byte
of all 1s (0xFF) precedes the payload. The purpose of this byte is to delineate the end of the Options
field and the beginning of Payload.

31. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
Fig;CoAPCommunicationsinIoTInfrastructures

32. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
•CoAPcommunicationsacrossanIoTinfrastructureviavariouspaths.
•Connectionscanbebetweendeviceslocatedonthesameordifferentconstrainednetworksorbetween
devicesandgenericInternetorcloudservers,alloperatingoverIP.
•Proxymechanismsarealsodefined,andRFC7252detailsabasicHTTPmappingforCoAP.
•AsbothHTTPandCoAPareIP-basedprotocols,theproxyfunctioncanbelocatedpracticallyanywhereinthe
network,notnecessarilyattheborderbetweenconstrainedandnon-constrainednetworks.
•JustlikeHTTP,CoAPisbasedontheRESTarchitecture,butwitha“thing”actingasboththeclientandthe
server.
•Throughtheexchangeofasynchronousmessages,aclientrequestsanactionviaamethodcodeonaserver
resource.
•Auniformresourceidentifier(URI)localizedontheserveridentifiesthisresource.

33. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•CoAP:
•Theserverrespondswitharesponsecodethatmayincludearesourcerepresentation.
•TheCoAPrequest/responsesemanticsincludethemethodsGET,POST,PUT,andDELETE.
•CoAPdefinesfourtypesofmessages:confirmable,non-confirmable,acknowledgement,andreset.
•Methodcodesandresponsecodesincludedinsomeofthesemessagesmakethemcarryrequestsor
responses.
•CoAPcode,methodandresponsecodes,optionnumbers,andcontentformathavebeenassignedbyIANA
asConstrainedRESTfulEnvironments(CoRE)parameters.

34. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•MessageQueuingTelemetryTransport(MQTT):
•MessageQueuingTelemetryTransport(MQTT)protocolisstandardizedbytheOrganizationforthe
AdvancementofStructuredInformationStandards(OASIS).
•AnMQTTclientcanactasapublishertosenddata(orresourceinformation)toanMQTTserveractingasan
MQTTmessagebroker.
•IntheexampleillustratedinFigurebelow,theMQTTclientontheleftsideisatemperature(Temp)and
relativehumidity(RH)sensorthatpublishesitsTemp/RHdata.TheMQTTserver(ormessagebroker)accepts
thenetworkconnectionalongwithapplicationmessages,suchasTemp/RHdata,fromthepublishers.
•Italsohandlesthesubscriptionandun-subscriptionprocessandpushestheapplicationdatatoMQTTclients
actingassubscribers.
•TheapplicationontherightsideofFigurebelowisanMQTTclientthatisasubscribertotheTemp/RHdata
beinggeneratedbythepublisherorsensorontheleft.

35. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•MessageQueuingTelemetryTransport(MQTT):
Fig:MQTTPublish/SubscribeFramework

36. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•MessageQueuingTelemetryTransport(MQTT):
•Thismodel,wheresubscribersexpressadesiretoreceiveinformationfrompublishers,iswellknown.
•AnexampleisthecollaborationandsocialnetworkingapplicationTwitter.
•WithMQTT,clientscansubscribetoalldata(usingawildcardcharacter)orspecificdatafromthe
informationtreeofapublisher.Inaddition,thepresenceofamessagebrokerinMQTTdecouplesthedata
transmissionbetweenclientsactingaspublishersandsubscribers.
•Infact,publishersandsubscribersdonotevenknow(orneedtoknow)abouteachother.Abenefitofhaving
thisdecouplingisthattheMQTTmessagebrokerensuresthatinformationcanbebufferedandcachedin
caseofnetworkfailures.Thisalsomeansthatpublishersandsubscribersdonothavetobeonlineatthe
sametime.
•MQTTcontrolpacketsrunoveraTCPtransportusingport1883.TCPensuresanordered,losslessstreamof
bytesbetweentheMQTTclientandtheMQTTserver.

37. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•MessageQueuingTelemetryTransport(MQTT):
•MQTTisalightweightprotocolbecauseeachcontrolpacketconsistsofa2-bytefixedheaderwithoptionalvariableheaderfields
andoptionalpayload.Acontrolpacketcancontainapayloadupto256MB.FigurebelowprovidesanoverviewoftheMQTT
messageformat.
•MQTTcontainsasmallerheaderof2bytescomparedto4bytesforCoAP.ThefirstMQTTfieldintheheaderisMessageType,
whichidentifiesthekindofMQTTpacketwithinamessage.
•FourteendifferenttypesofcontrolpacketsarespecifiedinMQTTversion3.1.1.Eachofthemhasauniquevaluethatiscoded
intotheMessageTypefield.Notethatvalues0and15arereserved.

38. IoT Application Layer Protocols –CoAP and MQTT (Cont…)
•MessageQueuingTelemetryTransport(MQTT):
•ThenextfieldintheMQTTheaderisDUP(DuplicationFlag).Thisflag,whenset,allowstheclienttonotatethatthe
packethasbeensentpreviously,butanacknowledgementwasnotreceived.
•TheQoSheaderfieldallowsfortheselectionofthreedifferentQoSlevels.
•ThenextfieldistheRetainflag.OnlyfoundinaPUBLISHmessage,theRetainflagnotifiestheservertoholdonto
themessagedata.Thisallowsnewsubscriberstoinstantlyreceivethelastknownvaluewithouthavingtowaitfor
thenextupdatefromthepublisher.
•ThelastmandatoryfieldintheMQTTmessageheaderisRemainingLength.Thisfieldspecifiesthenumberofbytes
intheMQTTpacketfollowingthisfield.
•MQTTsessionsbetweeneachclientandserverconsistoffourphases:sessionestablishment,authentication,data
exchange,andsessiontermination.EachclientconnectingtoaserverhasauniqueclientID,whichallowsthe
identificationoftheMQTTsessionbetweenbothparties.
•Whentheserverisdeliveringanapplicationmessagetomorethanoneclient,eachclientistreatedindependently.