Evaluation of communication
protocols between vehicle and
server
Evaluation of data transmission
overhead by communication protocols
TOMAS WICKMAN
K T H R O Y A L I N S T I T U T E O F T E C H N O L O G Y
Evaluation of communication
protocols between vehicle and
server
Evaluation of data transmission
overhead by communication
protocols
Tomas Wickman
2016-06-29
Master’s Thesis
Examiner
Gerald Q. Maguire Jr.
Academic adviser
Anders Västberg
KTH Royal Institute of Technology
School of Information and Communication Technology (ICT) Department of Communication Systems
This thesis project has studied a number of protocols that could be used to communicate between a vehicle and a remote server in the context of Scania’s connected services. While there are many factors that are of interest to Scania (such as response time, transmission speed, and amount of data overhead for each message), this thesis will evaluate each protocol in terms of how much data overhead is introduced and how packet loss affects this overhead. The thesis begins by giving an overview of how a number of alternative protocols work and what they offer with regards to Scania’s needs. Next these protocols are compared based on previous studies and each protocol’s specifications to determine which protocol would be the best choice for realizing Scania’s connected services. Finally, a test framework was set up using a virtual environment to simulate different networking conditions. Each of the candidate protocols were deployed in this environment and setup to send sample data. The behaviour of each protocol during these tests served as the basis for the analysis of all of these protocols. The thesis draws the conclusion that to reduce the data transmission overhead between vehicles and Scania’s servers the most suitable protocol is the UDP based MQTT-SN.
Keywords
I den här rapporten har jag undersökt ett antal protokoll som kan användas för att kommunicera mellan server och lastbil och därmed användas för Scanias Connected Services. Då det är många faktorer som är intressanta när det kommer till kommunikation mellan lastbil och server för Scania som till exempel responstid, överföringshastighet och mängden extra data vid överföring så har jag valt att begränsa mig till att utvärdera protokollen utifrån hur mycket extra data de använder vid överföring och hur detta påverkas av paketförlust. Rapporten börjar med att ge en överblick över vilka tänkbara protokoll som kan användas och vad de kan erbjuda gällande Scanias behov. Efter det så jämförs protokollen baserat på tidigare studier och protokollens specifikationer för att avgöra vilket protokoll som är bäst lämpat att användas i Scanias Connected Services. Sists så skapas ett virtuellt ramverk för att simulera olike nätverksförhållanden. Här testas varje protokoll och får sända olike datamängder för att sedan få sin prestanda utvärderad baserat på hur mycket extra data som sändes. Dessa resultat ligger sedan till grund för den analys och slutsats angående vilket protokoll som är bäst lämpat att användas av Scania. Rapporten drar slutsatsen att baserat på den information som finns tillgänglig och de resultat som ficks av testerna så skulle den UDP baserade MQTT-SN vara bäst lämpad för att minimera mängden extra data som skickas.
Nyckelord
I would like to thank Professor Gerald Q. Maguire Jr. for having written the draft thesis template to help bootstrap the writing process and for having a very helpful thesis webpage as well as providing valuable feedback which has helped immensely with the quality of the thesis.
I would also like to thank Håkan Nilsson and Ken Nordström for being very helpful supervisors that were always willing to take time to answer any questions I might have had.
My working college for this thesis project was Karl Strihagen whose thesis has the working title “Evaluation of publish/subscribe protocols”.
Finally I would like to thank Scania for providing me with the opportunity to do this thesis project.
Stockholm, June2016 Tomas Wickman
Abstract ... i
Keywords ... i
Sammanfattning ... iii
Nyckelord ... iii
Acknowledgments ... v
Table of contents ... vii
List of Figures ... xi
List of Tables ... xiii
List of acronyms and abbreviations ... xv
1
Introduction ... 1
1.1
Background ... 1
1.2
Problem definition ... 2
1.3
Purpose ... 3
1.4
Goals ... 3
1.5
Research Methodology ... 3
1.6
Network assumptions ... 3
1.7
Delimitations ... 4
1.8
Structure of the thesis ... 4
2
Background ... 5
2.1
Guarantee of delivery ... 5
2.1.1
At most once delivery ... 5
2.1.2
At least once delivery ... 6
2.1.3
Exactly once delivery ... 6
2.2
Underlying protocols ... 7
2.2.1
UDP ... 7
2.2.2
TCP ... 7
2.2.3
SCTP ... 11
2.3
Design paradigms ... 12
2.3.1
Publish/Subscribe ... 12
2.3.2
Request/Response ... 13
2.4
SCPv2 ... 13
2.4.1
Protocol background ... 14
2.4.2
Requirement specifications ... 14
2.5
MQTT ... 14
2.5.1
Methods ... 15
2.5.2
Quality of service ... 15
2.5.3
Durable subscriptions ... 15
2.5.4
Keep alive packets ... 15
2.5.5
Last will ... 16
2.5.6
MQTT Messaging overhead ... 16
2.6
MQTT-SN ... 16
2.6.1
Broker gateways ... 17
2.6.3
Topic ID registration ... 18
2.6.4
Keep alive message ... 18
2.7
CoAP ... 18
2.8
AMQP ... 19
2.8.1
AMQP Messaging overhead ... 20
2.8.2
AMQP v1.0 controversy ... 21
2.9
Related work ... 21
2.9.1
Broker comparisons ... 21
2.9.2
Comparison of MQTT and AMQP ... 22
2.9.3
Comparison of MQTT and CoAP ... 22
2.9.4
Fast and Secure Protocol (FASP) ... 23
2.9.5
Monitoring of other types of vehicles ... 23
2.9.6
SCPv2 Transmission data ... 23
2.10
Summary ... 25
3
Methodology ... 27
3.1
Research Process ... 27
3.2
Experimental Setup ... 27
3.2.1
Artificial Environment ... 27
3.3
Data Collection ... 30
3.3.1
Tests performed ... 30
3.3.2
Logging ... 30
3.3.3
Sample Size ... 31
3.3.4
Note about QoS ... 31
3.4
Experimental design ... 31
3.4.1
Test bed ... 31
3.5
Assessing the reliability and validity of the data to be
collected ... 32
3.5.1
Reliability ... 32
3.5.2
Validity ... 33
4
Test setup ... 35
4.1
Extra header data ... 35
4.2
Publisher applications ... 36
4.2.1
AMQP publisher application ... 36
4.2.2
MQTT publisher application ... 37
4.2.3
MQTT-SN publisher application ... 38
4.3
Automated scripting ... 39
5
Analysis ... 41
5.1
Major results ... 41
5.1.1
100B payload results ... 41
5.1.2
1kB payload results ... 44
5.1.3
10kB payload results ... 46
5.2
Reliability and validity ... 48
5.3
Discussion ... 48
6.2
Limitations ... 52
6.3
Future work ... 53
6.3.1
In vehicle testing ... 53
6.3.2
More protocols and brokers ... 53
6.3.3
Encryption ... 53
6.3.4
Scalability tests ... 54
6.3.5
IPv6 and header compression ... 54
6.4
Required reflections ... 54
References ... 55
Appendix A: Port configurations ... 59
Figure 1-1:
System Overview ... 2
Figure 2-1:
At most once delivery ... 5
Figure 2-2:
At least once delivery ... 6
Figure 2-3:
Exactly once delivery ... 7
Figure 2-4:
UDP header ... 7
Figure 2-5:
TCP header ... 8
Figure 2-6:
Slow start congestion window adjustment; points
represent received ACKs, adapted from [10] ... 9
Figure 2-7:
Fast Recovery Retransmission ... 9
Figure 2-8:
CUBIC growth graph ... 10
Figure 2-9:
SCTP Chunk layout ...11
Figure 2-10:
SCTP Common Header ...11
Figure 2-11:
Publish/Subscribe messaging pattern using a broker ... 12
Figure 2-12:
MQTT fixed header ... 16
Figure 2-13:
MQTT Publish variable header ... 16
Figure 2-14:
Transparent and aggregate gateway, adapted from Figure
5 of [21, p. 5] ... 17
Figure 2-15:
MQTT-SN header, adapted from [5, p. 7] ... 18
Figure 2-16:
AMQP General frame format, adapted from [24, p. 33] ... 20
Figure 2-17:
Method frame, adapted from [24, p. 34] ... 20
Figure 2-18:
Content Header and Body frames adapted from [24, p. 36] .. 21
Figure 3-1:
Artificial test environment ... 28
Figure 3-2:
Testbed overview ... 32
Figure 4-1:
Total amount of header data for each packet when
transmitting a single byte of application layer payload ... 35
Figure 5-1:
Total transmitted data for 1MB using 100B payloads and
QoS 1 ... 42
Figure 5-2:
Number of packets transmitted from client to server, 1MB
data, 100B payload, QoS 1 ... 42
Figure 5-3:
Total number of packets from server to client ... 43
Figure 5-4:
AMQP sample traffic ... 43
Figure 5-5:
AMQP TCP ACK flags ...44
Figure 5-6:
Total transmitted data for 1MB using 1kB payloads and
QoS 1 ... 45
Figure 5-7:
Number of packets transmitted from client to server, 1MB
data, 1kB payload, QoS 1 ... 45
Figure 5-8:
Number of packets transmitted from server to client, 1MB
data, 1kB payload, QoS 1 ...46
Figure 5-9:
Total transmitted data for 1MB using 1kB payloads and
QoS 1 ... 47
Figure 5-10:
Execution time for 1MB data, 10kB payload, QoS 1 ... 47
Figure 6-1:
Execution time for 1MB data, 1kB payload, QoS 1 with
10 ms retransmission time for MQTT-SN ... 52
Table 1-1:
Assumptions about network between vehicle and server
gateways ... 4
Table 2-1:
Traffic volumes for Telefonica, April 2016 ... 24
Table 2-2:
Sending rates and message sizes as specified by Scania ... 24
Table 3-1:
Desktop computer specifications ... 29
Table 3-2:
Virtual machine specifications ... 29
Table 3-3:
Summary of protocols, packet loss rates, and payload sizes
to be used for testing ... 31
ACK Acknowledgement (In the context of networks) AMQP Advanced Message Queue Protocol
BIC Binary Increase Congestion CAN bus Controller Area Network
CoAP Constrained Application Protocol cwnd congestion window
DNS Domain Name System ECU Electronic Control Unit FASP Fast and Secure Protocol FIFO First-in-first-out GPRS General Packet Radio Service
GSM Global System for Mobile Communication HTTP Hypertext Transfer Protocol
IETF Internet Engineering Task Force IoT Internet of Things
IP Internet Protocol
MQTT Message Queue Telemetry Transport
MQTT-SN Message Queue Telemetry Transport – Sensor Networks M2M Machine to Machine
MTU Maximum Transmission Unit QoS Quality of Service
OASIS Organization for the Advancement of Structured Information Standards OTA Over the Air
REST Representational State Transfer RD Remote Diagnostics
RTO Retransmission TimeOut
SASL Simple Authentication and Security Layer SCPv2 Scania Communication Protocol version 2 SCTP Stream Control Transmission Protocol SMS Short Message Protocol
SSH Secure Shell
STS Tachograph message TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol URI Uniform Resource Locator VM Virtual Machine
According to predictions made in a press release from 2014, Scania estimated that in 2015 it would have around 150 000-200 000 vehicles using its services [1]. According to a statement by Volkswagen, the current owner of Scania, Scania currently has approximately 170 000 connected vehicles sending data to Scania for processing and of these, 70 000 were added in 2015 [2]. If this growth continues, the number of Scania’s connected vehicles in 2020 is estimated to be around 600 000. This creates a demand for a scalable solution that can cope with the increasing amount of data that these vehicles (in the aggregate) will generate. Additionally, it is expected that the amount of data per vehicle will also increase over the amount transferred by a vehicle today. Currently, a vehicle is estimated to transmit approximately 91 kB per operating hour (see Table 2-2 on page 24.). While currently huge amounts of data are not being transferred, the increase in number of connected trucks and the expected increase in the number of services offered combined with the cost of transmission means that there is a substantial financial benefit for Scania in reducing the aggregate amount of transmitted data. Additionally, there is the limitation of data caps put in place by the different network providers. This data cap typically limits each truck to 10 MB of data transfer per day. As a result, the lower the protocol overhead, the more of this 10 MB/day that will be available for other services.
1.1 Background
Scania currently employs their own proprietary communication protocol called Scania Communication Protocol version 2 (SCPv2). This protocol is used for all communication between vehicles and Scania’s servers. The rapid growth in the number of connected vehicles has prompted Scania to investigate what alternative protocols are available and how they would perform in comparison to the current solution in order to ensure that they will be able to keep up with the increasing volume of traffic.
Figure 1-1 illustrates the current system. This figure gives an overview of how the communication is done. All of the sensors in a truck are connected via a Controller Area Network (CAN bus) for internal communication. The CAN busses are connected to a C200, or in newer trucks a C300, which resides in the cab of the truck. The C200/C300 is Scania’s proprietary Electronic Controller Unit (ECU). This ECU acts as a communication gateway from the truck to Scania’s servers, and to the truck from the servers. The use of a communication gateway decouples the internal and external communication protocols, thus making it easy to replace any of these communication protocols. This decoupling also allows different protocols to be used for different scenarios. The decoupling of the protocols also decouples the internal and external functionality offered by the ECU, further increasing the system’s flexibility. Improving the communication between these gateways and Scania’s server(s) through the use of new protocols will be the focus of this thesis.
With the current growth in the number of connected devices and the emergence of the so called Internet of Things (IoT), many protocols have been introduce that profile themselves as the best option for different kinds of connected devices. The two most prominent protocols are the Message Queue Telemetry Transport (MQTT) [3] protocol and the Advanced Message Queue Protocol (AMQP) [4]. Both of these protocols are being maintained by the Organization for the Advancement of Structured Information Standards (OASIS) consortium. There is also the MQTT-SN variant of the MQTT protocol which profiles itself as a communication protocol for resource constrained network connected devices [5]. Meanwhile, the Constrained Application Protocol (CoAP) has been standardized by the Internet Engineering Task Force (IETF) [6].
Each of these protocols has its own advantages and disadvantages and has been created with different use cases in mind. The result is that each protocol is more or less suitable for use for communication between Scania made vehicles and Scania’s servers. This thesis project investigates how these alternative protocols behave with regards to data transmission overhead, particularly when packet loss increases.
Figure 1-1
1.2 P
The prob data tra servers. transfer factors t payload, loss. As will be th Each requirem 1. A 2. 3. The platform vary tho packet lo and thei 1: SysteProblem de
blem to be s ansmission o While Scan speed, thei that increase , and how da a result, the he criteria by h protocol ments must b All commun Since all the packets as th the amount different enc The protoco page 6). The protocol This could a not a strict p during the t portion(s) of be re-sent w protocols w m. The test e ose variables oss, payload ir frequencie em Overviewefinition
solved is: Wh overhead due nia has expre r main focu e the amount ata transmiss overhead an y which the a offers diffe be fulfilled by nication must e investigated hey see fit. Tof data tran cryption app ol must be ab l must be abl also be suppo protocol requ transmission
f the file wer when connect will be implem
environment s that impac size, and fre s is presente hat is the be e to the pro essed an int us was to red t of data tran sion is affect nd performan alternative pr erent featur y each protoc t be secure; h d protocol op his thesis wi nsmitted, but roaches will ble to guara le to handle f orted either uirement. Th n of the file, re received an tivity is re-est mented and
for this imp ct the protoc equency that ed later in Tab est protocol otocol used t terest in red duce the am nsmitted are ted due to ret
nce over a ne rotocols will res and lev
col:
hence all of th perate on the
ill not evalua ut all protoco be discussed antee a reliab files of up to on a protoco he problem w then the re nd which we tablished. then evaluat plementation col’s perform t data is sent able 2-2 on pa with regards to communi ducing the re mount of dat the overhea transmission etwork with be evaluated vels of cust he payload d e application ate how the e ols need to s d in Chapter ble at-least-o
64 MB in siz ol level or on with large fil
ceiver and s ere lost so th ted in the co n will provid mance regar t. An exampl age 24. s to Scania’s icate betwee esponse time ta that is tra d of each pro ns performed potentially h d. tomizability, data must be level Scania encryption of support encr 5. once delivery ze. n an applicat es is that if t sender need at the entire ontext of Sca de a framewo ding data tr le of the mos desire to re en vehicles a e and increa ansmitted. T otocol, the si d as a result o high packet l but the f encrypted. a is free to en f packets mig ryption. A nu ry (see Figur tion level an the connectio to synchron e file does no ania’s commu work in which ransmission, st common m educe the and their asing the The main ize of the of packet loss rates following crypt the ght affect umber of re 2-2 on nd is thus on is lost nize what ot need to unication h we can , such as messages
The purpose of this thesis project is to evaluate several different communication protocols in terms of how well they fit Scania’s requirement regarding communication between their servers and vehicles they provide their services for. The results should allow Scania to make an informed decision about the advantages and disadvantages of alternative protocols when deciding to upgrade from their current SCPv2 protocol.
1.4 Goals
The goal of this thesis project is evaluate different communication protocols for communication between Scania’s vehicles and server. This has been divided into the following two sub-goals:
1. Create a proof of concept message platform to allow communication between a virtual machine acting as server and a client using each of the investigated protocols. This will allow us to vary one variable (such as protocol used, percentage of packets dropped, and message size) at a time.
2. Evaluate each of the protocols on the basis of how they perform regarding overhead and how packet loss affects the amount of data transmitted.
1.5 Research Methodology
The original idea was that a prototype implementation of the protocol would be developed and then evaluated using a client application running inside a vehicle with a server application running on Scania’s servers. However, the system that was first thought to be quite modular with regard to the protocol turned out to be quite interconnected. This meant that the SCPv2 protocol implementation could not be easily replaced by the new protocol implementation. The alternative was to have the SCPv2 protocol use the new protocol via a gateway. However, this would affect the validity of the experimental data since the evaluation would only reveal how the alternative protocols behave as a gateway protocol for SCPv2. Additionally, the SCPv2 protocol is quite large, as well as proprietary, so this would affect both the quality of the experimental data as well as the quality of the thesis.
For the above reasons, the approach used for testing was to set up a virtual environment with an emulated network connection (between the gateway in the vehicle and the gateway in front of the Scania server. This emulated network makes it possible to completely control the network’s behaviour (in terms of delay, error rate, congestion, etc. ), hence the protocols will be tested in this controlled environment. While this would seem to be an artificial environment which is quite far from the network conditions that the actual Scania trucks are subject to, it allows for a more exact reasoning about how different network conditions affect the protocols. The main parameter we will focus on emulating is packet loss, since packet loss can be directly controlled and it impacts the amount of data transmitted by the different protocols. This test environment enables us to draw reliable conclusions based on the experimental data about how the protocols behave as the packet loss rate varies.
1.6 Network assumptions
According to internal measurements by Telefonica, a GSM network provider for Scania, during the month of April 2016 the average packet retransmission rate was around 0-4% depending on how packet loss is counted. Based on the number of outgoing ACK/NACK from the server to the vehicle the packet loss will be around 4% NACK’s, however a NACK could be due to a late packet or an indication of mismatched encryption keys and does not necessarily indicate packet loss. So if the number of packets sent from the c300 is instead compared to the number of ACK/NACKS sent from the server the packet loss rate is about one every ten millionth packet. In the end though any retransmission results in more traffic being sent over the network. So whether a retransmission is due to a late packet,
a packet loss or erroneous encryption keys does not matter for our experiments so the assumption will be that for the communication networks that Scania uses has a retransmission rate of about 4% on average. However, according to Scania the number of retransmissions is not the only network impairment that affects the communication between the vehicles and the servers. Another thing to consider is that trucks often operate in remote areas, such as mines, where the connection might be unstable or non-existent. Finally, the amount of data that can be transferred in a day is limited to 10 MB due to restrictions by the network provider. Table 1-1 summarizes the assumptions made about the network for the purposes of this thesis project. More about the SCPv2 background can be read in section 2.4.1.
Table 1-1: Assumptions about network between vehicle and server gateways GPRS transmission
Unstable connection High packet loss Limited amount of data
1.7 Delimitations
There exists a multitude of protocols that are marketed as solutions for networks where limiting the amount of data transmitted is a priority. However, due to the limited time available for this project the most well-known and widely adopted protocols for connected devices have been chosen to focus on. This choice was made because extensive research and testing has already been done on these protocols and due to an expressed interest by Scania as to the potential for cloud integration. Specifically the MQTT protocol, its sensor network variant (MQTT-SN), and AMQP have been chosen. Two additional protocols were also investigated, but were not tested: CoAP and the Fast and Secure Protocol (FASP). This latter protocol was of particular interest since the transfer of larger files over unstable networks with high retransmission rates was of interest to Scania.
1.8 Structure of the thesis
Chapter 2 introduces the basic terminology and principles of the investigated network messaging protocols. It describes how the underlying protocols work and how the design choices of these protocols affect their performance. This will allow the reader to understand and follow the reasoning regarding the results presented later in the thesis.
Chapter 3 explains the experimental setup that will be used and how the protocols will be evaluated using this experimental setup. Chapter 4 describes how the experimental setup and each of the protocols were implemented. Chapter 5 looks at the experimental results and discusses them in terms of what these results might mean for Scania. Finally, Chapter 6 concludes the thesis and suggests future work.
W re in ov tr ea T T p p al F
2
G re re gr re m 2 A d of F q se is re Fi li d When evaluat esponse time nterest, the m verhead is ransmissions ach different This chap Transmission Transmission rotocol stack aradigm and ll the protoco The curre Following this2.1 Guara
Guaranteeing e-transmissio esponse time reater the le eliably delive most once del.1.1 At mo At most once delivering dat f reliability. Figure 2-1). I quickly since ender to wai s unavailable eached its de igure 2-1: “At most inks, since da data was lost.
ting each of t e, transmissi main focus in directly rela s that each ad t level of deli pter also look n Control P n Protocol (SC k are affecte d the request ols to be con ent Scania C s there will b
antee of d
g reliable da ons or using e and/or tra evel of reliab er data, the livery, at leas ost once delive delivery, a ta, unless the At most onc If the receive there was n it for an ackn e or the data estination. At most on once” delive ata would be the protocols on speed, an n this thesis ated to the dditional lev ivery guarant ks at the fun rotocol (TC CTP) and ho ed by this fu t/response p sidered follo Communicat be section dis
elivery
ata delivery g error corr ansfer rate, d bility, the gr protocol can st once delive very also known e underlying ce delivery s er is able to no need for nowledgemen is lost along ce delivery ery could belost and the
s there were nd data trans project is th level of re vel of guarant tees affect th nctionality o CP), User D ow the perfor unctionality. paradigm wo ow one of the tion Protocol scussing each incurs add recting codin due to the o reater the d n achieve one ery, or exactl as “fire an g transport pr simply sends successfully any addition nt (ACK) tha g the way, the
e a problem ere is no way three main p smission over e reduction o eliability tha tee entails. T he transmissi of the underl Datagram Pr rmance and r Section 2.3 ork. This is e ese two parad l SCPv2 will h of the proto ditional over ng. A reliabl overhead ass data transmi e of the follo ly once deliv d forget”, e rotocol, such s data to the receive this nal overhead at data has b en we have n if the comm of knowing w properties th rhead. While of overhead. at is desired This chapter w ion of data. ying transpo rotocol (UDP reliability of p describes ho essential back digms. l be briefly ocols that wil
rhead: for e le protocol ociated with ssion overhe owing types ery. Each of nsures noth h a TCP or SC e receiver an data, then t d. Moreover, been received no way of kno munication ta which data w hat Scania is e all of these Moreover, t d, due to th will discusse ort protocols P), and Str protocols hig ow the publ ckground kno discussed in ill be evaluat example, in comes at th h ensuring re ead. When a of delivery g these is desc hing in term CTP, provide nd hopes for this method , there is no d. However, i owing that o akes place ov was lost or ev interested in criteria are o the amount o he additiona es exactly how s (specifically ream Contro gher up in th lish/subscrib owledge sinc n Section 2.4 ed. the form o he expense o eliability. Th attempting t guarantees: a cribed below ms of actuall es a guarante the best (se delivers dat o need for th if the receive our data neve
ver unreliabl ven how muc n: of of al w y, ol he be ce 4. of of he to at . ly ee ee ta he er er le ch
2 In re se b m Fi so h o d re 2 T d co re “d in d 2.1.2 At lea n order to en eached the d ender to not etween proto may send cum
igure 2-2: There is olution is to has been be r ptionally inc It is impo datagrams. In efers to. .1.3 Exact The highest l delivered exa ombination eceived this d To enforc double send” n order to fi double send is This doub 1. When 2. If the messa 3. The s receiv 4. The r sends succe
ast once deliv nsure “at leas destination a
tify it that th ocols, as som mulative or se
At least onc also the que have a time received. Wh creasing the w ortant to note
n our later d
tly once deliv level of relia actly once re of timeouts data previou ce this exactl ” with ID-tag lter out dup s similar to a ble send (sho n the sender e receiver re age back to t sender respon ved message receiver relea s a transfer c essfully comp very st once” deli at least once he data was me protocols elective ACK ce delivery estion about out starting hen the timeo
waiting time e that the AC discussion of very ability ensur equires that and retransm usly (if so it ca ly once mess gged message plicate messa a two-phase c own in Figure sends a mess eceives the m he sender co nds with a re was seen an ases the me completed m pleted. ivery there n e. This is usu received (a may send an Ks. t how to det when the da out occurs, th with each m CKs can be ac f each of the
res that data we deliver t missions) an an discard th sage delivery es to keep tr ages. This is commit in da e 2-3) works sage it stores message, the ontaining thi elease messa nd that the sto
essage-ID an message to the needs to be so ually done by s shown in n ACK for ev termine that ata was sent he sender re missed ACK. cknowledgem protocols, w a is delivered the data to nd that the re he duplicate y semantics rack of which a variation atabases. as follows: s the messag n it stores t s message-ID age to the rec
ored messag nd deletes its e sender to i ome way of k y the receive Figure 2-2). very unit of d t data was n until when i esends the da ments of sequ we will specif d exactly on the receiver eceiver can k data). both MQTT h messages h of “Strategy
e and its asso the message-D. ceiver which e-ID can be r s copy of the ndicate that knowing tha er sending a The ACK p data received not delivered it is resent u ata and resta uential bytes, fically note w nce. Ensuring r (this can b know if it ha and AMQP have already y 3” describe ociated mess -ID and sen h tells the rec
released. e stored me the message t the data ha an ACK to th process differ d, while other d. A commo unless an AC arts the time , messages, o what the AC g that data i be done via as successfull use a kind o been receive ed in [7]. Thi sage-ID. nds a receive ceiver that th ssage, then e transfer wa as he rs rs on K r, or K is a ly of ed is ed he it as
Fi
2
D F IP tr b IP ex ov 2 U d an Fi in w la h d 2 T fe T igure 2-3:2.2 Unde
Due to specif For our investPv6, but afte ransition will een chosen i P header. W xamine wha verhead. .2.1 UDP UPD is a b delivery [8]. T n optional ch igure 2-4: The main nformation, a with low over
ayer. Howeve has the poten described in S .2.2 TCP TCP provides eatures than TCP header is Exactly onc
rlying pro
fications from tigations we er discussing l happen soo it would not We will consi at effect each est effort d The header o hecksum eac UDP heade n appeal of t apart from th rhead. The d er, since we ntial to be o Section 2.9.4 s an ordered when using s shown in Fi ce deliveryotocols
m Scania all will perform g with Scani oner or later. affect the co ider three d h of these pr delivery, con of a UDP pac ch consisting rthe UDP pro he data we w drawback is can chose ex ptimized for 4. d, reliable by the UDP pro igure 2-5.
of protocols m all our test
ia they had . It should als omparison of different tran rotocols has nnectionless cket consists of 16 bits as otocol is its want to send that we will xactly what f r a specific u yte stream b otocol, but it s need to run s using IPv4 no plans fo so be noted t f the protoco nsport proto on the later protocol th of a source shown in Fi simplicity. S , it allows us l have to pro features we w use case. Fo between two t comes at th n on top of th . We could h r moving to that even if th ols since all o
cols: UDP, T r tests in ter hat offers n port, a desti gure 2-4. Since it inclu s to send a lo ovide reliabi want to inclu r example, U hosts. Usin he cost of inc the Internet have chosen e o IPv6 yet -
the larger IPv of the protoco TCP, and SC rms of data
no guarante ination port,
udes very lit ot of data ver ility ourselve ude, a UDP b UDP is used ng TCP we g creased mess Protocol (IP either IPv4 o although thi v6 header ha ols include a CTP. We wi transmissio ees regardin a length, an ttle additiona ry quickly an es at a highe based solutio d by FASP, a et a lot mor sage size. Th P). or is ad an ill on ng nd al nd er on as re he
Fi w igure 2-5: The minim worth conside 1. Conn Since seque rando This i of fal numb a so-c to leg segm 2. Retra When from data data, now r there delive and c 3. Conge To av with “slow is dou a con each either cut to starts * The increase TCP header mal sized, i.e ering when u nection orient e TCP is a c ence numbe omly selected is done throu lse connectio ber, but with called “SYN” gitimate use ents. ansmission of n TCP transm the receiver has been rec
as it does n reported its c is a newer ered before d could have un estion contro void overloa a congestion w start phase” ubled on rece ngestion avoi ACK* until i r case, when o half the cur s over. This m e is by 1/cwnd + 1/ r e., without a using TCP in ted protocol connection b r, hence the d sending by ugh a three-w ons [9], that h a malicious attack, wher ers or to cau f missing byt mits a TCP s r. This cumu ceived. How not matter w current value value. Unfo delivering th ndesired con ol
ding the net n window (cw ” (as shown i eiving each A dance mode t loses a seg n a segment l rrent thresho may result in /8 of segment size any options, T the context o based byte o e sender an yte sequence way handsha t is, that som s payload. Ho re false initia use resource tes segment it st ulative ACK i wever, reliabl whether a pre e. For examp ortunately, T he new data. nsequences in twork TCP e wnd). This a in Figure 2-6 ACK. Then, e e, which utili gment, or it l loss is detect old and the c n a TCP sessio e each time an AC TCP header of this projec oriented pro nd receiver n e numbers w ake. This han meone sends owever, this al synchroniz e exhaustion
ores the segm indicates tha le ordered by evious senso ple, an old pr TCP will wai . This proble n the context employs a c algorithm ha 6). In this ph either it hits zes a linear i loses a segm
ted, then the congestion w on almost ne K is received. is 20 bytes. ct: otocol the by need to syn when a TCP ndshake is de s a packet w three-way h zation segme n of the dev ment and wa at this data yte delivery r value was ressure senso it until all p em is called t of this thesi ongestion co s several pha hase the size
a threshold increase of t ent before re e congestion window will b ever operatin The followin
ytes are ord nchronize the
connection designed to re
with the corr handshake is ents are set to
vice receivin
aits for a cum and all of th is undesirab lost when th or report has previous byt “head of qu is project. ontrol algori hases and sta of the conge which cause the congestio eaching this n control thre be reset and ng at full capa ng aspects ar dered using eir respectiv is initialized educe the ris rect sequenc vulnerable t o deny servic ng these SYN mulative AC he proceedin
ble for senso he sensor ha s little value tes have bee
eue blocking ithm togethe arts out in th estion window es it to go int on window o threshold. I eshold will b the algorithm acity. re a ve d. sk ce to ce N K ng or as if en g” er he w to on In be m
Fi Fi igure 2-6: Anoth in Fig segm assum thresh other TCP a succe indica send If the three sende imme igure 2-7: Slow start c her mechani gure 2-7). T ent, and if t med to be lo hold will be r than conges avoids reduc essfully recei ating the seq
this same va e sender does ACKs indica er knows th ediately re-se Fast Recov congestion win sm for conge TCP decides the receiver ost. If this h halved – how stion.
cing the thres ive other seg quence numb alue for each
s not receive ating that the hat this segm
ends the miss
very Retransmi
ndow adjustme estion contro whether a s does not res happens, the wever, this i shold when gments. In t ber of the ne new segmen an ACK for a e receiver is ment was l sing segmen ssion
ent; points rep ol is called “F segment was spond with en the conge is undesirabl a segment is this case, th ext byte that nt it receives. a segment wi still waiting lost for a r nt and does n resent received Fast retransm s lost is by k an ACK in t estion windo le if the segm s lost and the
e receiver w it is expecti ithin a specif for the same reason other not reduce th d ACKs, adapt mission reco keeping a ti time, then th ows will be r ment was los
e receiver is will respond ing and it wi fied time, bu e numbered r than cong he congestion ted from [10] overy” (show
imer for eac he segment i reset and th st for a reaso continuing t with an AC ill continue t ut has receive next byte, th gestion, so n threshold. wn ch is he on to K to ed he it
2 T co co C si p si (1 q ( th D m th E p th 2.2.2.1 CUB There have b ongestion co ontrol algori CUBIC will be The aim implifying th rotocols. CU impler, two-p In the CU 1) Steady St quickly incre , then he growth re During the p moves away fr One of th he BIC algori quation 1 Here C is lotted, the g hat shown in F BIC conges been multip ontrol algorit ithm [11], an e the congest of CUBIC i he congestio UBIC does th phase cubic g UBIC algorith ate Behaviou ases the con it starts to ra eaches zero, a probing phas from . he improvem ithm with th CUBIC grow s a constant s raph of the c n Figure 2-8. Figure 2-8: tion control ple improve thms. The al n improvem tion control t is to mainta on window c his by replac growth funct hm the algor ur and (2) P ngestion win apidly decrea after which t se it once ag ents over the e CUBIC gro wth function [1 scaling facto congestion w CUBIC gro l algorithm ements to h lgorithm cur ment of the B tested during ain the stabi control func cing the com tion.
rithm has tw Probing. In ndow until i ase the grow the algorithm gain starts to e BIC algorit owth function = = 11, pp. 4, fig 1.2 or and T is th window incre owth graph how TCP ha rrently used Binary Increa g all of our ex ility and sca ction and in mplex three-p wo phases wh the Steady it starts to wth of the con m enters the o accelerate thm is that C n described i − + 2] he elapsed tim eases as a fun andles conge in the C300 ase Congesti xperiments. alability of t ncreasing TC phase growt hen adjusting State Behavi approach th ngestion win second phas the congest CUBIC replac n Equation 1 me since the nction of tim estion by u 0 is the CUBI ion (BIC) al the BIC algo CP’s friendlin th function o g the conges viour phase t he window s ndow. This co
se, i.e., the P tion window ces multitud 1 : e algorithm s me and will lo using smarte IC congestio lgorithm [12 orithm, whil ness to othe of BIC with stion window the algorithm size threshol ontinues unt robing phase w growth as e functions i started. Whe ook similar t er on ]. le er a w: m ld til e. it in en to
W C w m th p w S 2 A d tr fi A w o
While not uti Control Tran works in term multiple strea hat an SCTP roblem). Ad with burst er ignalling Sys 2.2.3.1 SCT An SCTP pac destination p ransmit mul ield, flags and A list of differ where the mo riented comm 1. Multi For S of att delive to kno 2. Mess Unlik transm ilized in any smission pro ms of deliverin ams – hence
host and clie dditionally, S rrors. SCTP stem 7. TP vs TCP a cket consists port as well a tiple chunks d a length fie rences betwe ost relevant munication, ihoming SCTP, multih tachment. Th er the messa ow a differen age oriented ke TCP but li mits X numb Figu Figu of the inves otocol. Unlik ng ordered b e avoiding he
ent can auto CTP support was designe and UDP of a commo as a verificat s seen in Fig eld. een the SCTP for this case multihomin homing mean his means th ges. Since th nt route was d communica ike UDP , SC ber of bytes, ure 2-10: ure 2-9: stigated prot ke UDP whi bytes, SCTP o ead of queue omatically fai ts selective a ed to be use on header se tion tag and gure 2-9 whi P protocol an e is the SCT ng and SYN co ns that the se hat if one of his works on even used. ation CTP is a me then the rec
SCTP Commo SCTP Chunk ocols it coul ich works in operates on m e blocking. S il-over to an acknowledge ed to reliabl een in Figure d a check su ich contains nd the TCP a TP avoidance ookies. ender and re the endpoin a transport l essage orient ceiving appli on Header layout d still be wo terms of da messages and SCTP suppor alternate net ments – so t ly deliver m e 2-10 which m. After the the actual p and UDP pro e of
head-of-eceiver can s nts fail anoth
level the app
ed protocol. ication can r orth to look atagrams an d was design rts multi-hom twork addre that it can e messages, for h contains th e header the payload as w otocol can be -queue block specify multi her one can plication leve This means read X numb at the Stream nd TCP whic ned to suppor med hosts (s ss if there is fficiently dea r example fo he source an e protocol ca well as a typ e seen on [13 king, messag ple endpoint be utilized t el never need s that if SCT ber of bytes i m ch rt so a al or nd an pe 3] ge ts to ds TP in
2
T re 2 In su b to it w Fi fo one r guara 3. Head TCP SCTP to avo wait f 4. Four To es were conne conne2.3 Desig
Two common equest/respo .3.1 Publis n the publi ubscribers. B etween the p opic either d ts messages w will forward t igure 2-11: The publi or dissemina read. While antees. SCTP d-of-queue bl guarantees t P also offersoid the head for the last tr way handsha stablish a new the receive ection unless ection. This p
gn paradig
n communic onse. Each of sh/Subscribe sh/subscribe Between the publisher an directly to the when it send this message Publish/Sub ish/subscribe ating data. UDP also o P on the other locking avoid that the pacdelivery gua d-of-queue b ransmission ake w connection er of the co s it can prov prevents a co
gms
cation patte f these will b e e pattern se publisher an d the subscr e publisher o ds them. Wh to all of the s bscribe messa e pattern has offers this ty r hand has a dance ckets are reli arantees but blocking that to be ACK’d n SCTP perf onnection wi ve that it is t ommon attacerns that are be described b
enders assum nd the subsc riber (see Fig or to the bro hen a publish subscribers w aging pattern u s two major ype of trans guarantee o iably deliver with no gua t can occur f before being forms a four ill not reser the IP addres ck against TC e widely us below. me the role criber is ofte gure 2-11). T oker. A topic her publishe who have sub
using a broker advantages mission, it d f delivery. red in the or rantees abou for TCP were g able to tran way handsh rve any reso ss from whic CP known as ed today ar e of publish en a broker w The subscribe is a tag that s a message bscribed to th over a tradit does so with rder that th ut ordering. e the transm nsmit the nex
hake with a ources for t ch it is tryin
SYN floodin
re publish/s
her and rec who acts as er subscribes t the publish to the broke this topic. tional client/ h no deliver ey were sen This allows mission has t xt set of bytes signed cooki the incomin g to initiate ng [14] subscribe an ceivers act a a middlema s for a certai her attaches t er, the broke
/server desig ry nt. it to s. ie ng a nd as an in to er gn
synchronization [15]. This means that the publisher does not need to know who is listening, the subscriber and publisher do not need to be active at the same time and the publisher is not blocked while producing a new event. This is in contrast to a traditional server/client solution where the sender and receiver are tightly coupled and the server cannot send if the client is not receiving. This makes it ideal for disseminating data to subscribers via an unreliable and/or intermittent network connectivity where providing a guarantee that the other party is listening can be difficult.
Second, publish/subscribe is scalable due to its tree-based structure, since if the system needs to be scaled up more brokers can be added and the topics split between them, thus reducing the load on individual brokers.
However, there are disadvantages to using the publish/subscribe paradigm. One is that, even though it is loosely coupled regarding time, space, and synchronization; it is tightly coupled with regards to the published data. If a change is to be made in how the published data is represented, then the programmer will need to modify all the subscribers. Souleiman Hasan, Sean O'Riain, and Edward Curry are researching how to achieve decoupling with regards to data semantics by using approximate matchings [16].
2.3.2 Request/Response
The request/response (or request-reply) paradigm is a basic communication method between pairs of computers. It works by having one computer send a request to another computer. When the second computer receives the request it sends a response. The most well-known application of this design is the HTTP protocol in which a client requests a webpage from a server and the server responds with the requested document.
This paradigm is flexible in that it only requires a point-to-point communication channel over which the client sends a request to the server and the server responds to that client. However, HTTP could also use the publish/subscribe paradigm if requests and responses are sent to all interested parties [17].
The request/response model supports two modes for when the client waits for a response from the server. The first mode uses synchronous blocking, thus the sender sends a request to the server and then waits for a response. This allows a simple implementation, but can become problematic - since if a client crashes it will be problematic to re-establish the blocked thread*.
The other mode uses an asynchronous call-back where the client sends requests to the server and then sets up call-backs for the server. The client keeps one thread listening for reply messages from the server and one thread to serve the responses. This way, when a reply is received, the response invokes the call-back that was previously established. A client that uses this approach can easily recover if it were to crash by simply restarting the reply thread and continuing. This makes the asynchronous call-back more suitable than the synchronous approach when there is a need to be resilient to crashes; for example, when operating in a remote environment where a reset of the computer might be difficult to perform.
2.4 SCPv2
SCPv2 is the current communication protocol deployed by Scania for communication between the gateway in vehicles and the gateways at their server. A good understanding of the requirements of this protocol will be beneficial when comparing how other protocols perform in comparison with it.
Unfortunately, this protocol is proprietary, hence the protocol description will be brief (and lack any specific details).
However, there is a specification that Scania wants the new protocol to fulfil (see Section 2.4.2). Each of the protocols will be evaluated against this list of requirements to ensure that there no required feature is missing.
2.4.1 Protocol background
The original Scania Communication Protocol version one only supported sending data via Global System for Mobile Communication (GSM) using the Short Message Service (SMS) protocol. SMS supports messages of up to 160 characters (including header and error detection code). However, as the amount of data being transferred between the vehicle and server grew, the need for a new protocol became evident. The two major requirements for version two of this protocol were:
1. Send a large amount of data in a single UDP packet to achieve low communication cost and 2. The choice of communication infrastructure should be independent of the data being sent
from one application to another.
In the second version of the protocol, SMS was only used to wake up the system after which the vehicle gateway connected to one of Scania’s Domain Name System (DNS) Servers to obtain an IP address of one of Scania’s servers. Subsequently all communication to/from this server was done over UDP using General Packet Radio Service (GPRS).
2.4.2 Requirement specifications
Scania’s requirements for version two of the protocol and all subsequent implementations are: 1. All communication must be done over a secure encrypted connection.
2. The protocol should be able to handle files of up to 64MB in size. This includes being able to resume transmission of such a large file should connectivity be lost.
3. The protocol shall guarantee at-least-once delivery.
For each protocol that will be evaluated in this thesis these requirements will be verified. It should be noted that except for requirement 3, these requirements are not necessarily provided by the protocol itself – as the functionality could be provided by a lower layer transport protocol or the application layer; however, while not a metric for our evaluation, the discussion will talk about how difficult it was to set up each of the protocols along with its respective broker.
2.5 MQTT
MQTT is a publish/subscribe protocol running on top of TCP and was originally developed in 1999. In 2013, it was turned over to the OASIS organization. The current OASIS standard version of MQTT is 3.1.1 and this version was approved on the 29th of October 2014 [18].
MQTT was designed to be a light-weight, open, simple, and easy to implement protocol which would make it ideal for use in the context of Machine to Machine (M2M) communication and IoT [3]. MQTT has been deployed for a number of real world applications. These applications, most notably Facebook messenger and Amazon Web Services IoT, show that MQTT delivers on its promises [19, 20].
In accordance with MQTT’s aim to be easy to implement, the number of methods defined by MQTT for interacting with a specific resource are only five*:
Connect After a network connection has been established between a client and a server the first message must be a CONNECT packet that sends identifying information about the client to the server.
Keep alive Specifies how long the client can go without publishing a message before being disconnected. Set on connect.
Disconnect Waits for the client to finish its work and for the TCP session to terminate. Subscribe Sends a SUBSCRIBE message from the client to the server to create
subscriptions for one or more topics.
Unsubscribe Sends a UNSUBSCRIBE message from the client to the server to unsubscribe from one or more topics.
Publish Sends a PUBLISH message from client to server or from server to client to transport a message.
2.5.2 Quality of service
MQTT allows the user to specify different Quality of Service (QoS) levels depending on what is needed. The protocol defines three QoS levels that correspond to three different levels of delivery guarantees. Sending a message with a QoS of zero will result in a message with “at most once” delivery (there is no follow up of the sent message). A message sent with a QoS of one will result in a message with an “at least once” delivery guarantee with an ACK being sent for each message delivered. Finally, a QoS level of two will result in “exactly once” delivery. To offer actual “exactly once” delivery MQTT uses the message ID to filter out duplicate messages as discussed in [7] and illustrated in Figure 2-3 on page 7.
2.5.3 Durable subscriptions
It is possible for the client to specify when it connects whether its connection is a durable or a non-durable connection by setting a “Clean session” flag in the CONNECT message (setting the flag to false will enable a durable connection). If the client chooses to use a durable connection, then the broker will store undelivered messages if the client disconnects and the broker will subsequently try to deliver these saved messages as soon as the client connects again.
In contrast, for a non-durable connection the lifetime of the subscription is limited to the time the client is connected to the broker
2.5.4 Keep alive packets
When a client connects to a server it specifies a Keep Alive value. This is a 16-bit value that specifies, in seconds, how long a client can go without either publishing a message to the server or sending a PING request. If the client does not do one of these operations within one and a half times the Keep Alive value, then the server will consider the client disconnected and remove all of its subscriptions.
2 T b n au 2 M va sh m in p Fi p h 2 re fe m p p h Fi
2
M th T M * O .5.5 Last w The client ma yte length-fi not published utomatically .5.6 MQTT MQTT messa ariable part t The fixed hould be kep message shou ndicates how ayload. This igure 2-12: For our t ublish ACK header for th -13). The len equired to re ewer bytes n message iden ublished RE ublished AC header beside igure 2-13:2.6 MQTT
MQTT-SN* is hrough a ser TCP. In 200 MQTT-SN wa 1. MQTT This i pre-e funct Originally, this wa will ay also specif ield defining d any messag y disconnect t T Messaging ages have tw that varies d d part consis pt (in memor uld be retain w many octe fixed header MQTT fixed ests we are m message sin he publish m ngth field in epresent the needed for e ntifier. If Qo EC packet to CK message. es a two octet MQTT PublT-SN
s a variant of ies of change 08, Hunkeler as developed T-SN should is so that it xisting MQT ionality that as named MQTT-S fy a Last Will the length o ge during on the client an g overhead o header par epending on sts of two by ry) until ackn ned after it ha ets remain o r is shown ind header mainly inter nce these are message conta the header c topic name ach publishe oS 2 is used o realize the The publish t field to indi ish variable he f the MQTT es, most nota
r, Truong, a to address [ d be as close t requires min TT broker. MQTT supp
S, but was rename
l when it con of the messag ne and a hal nd publish its rts, one fixe n the message
ytes and spe nowledged, w as been deliv of the messa n Figure 2-12 rested in the e the messag ains a topic consists of tw that follows ed message. d, there is on e at least-on h ACK messa icate what m eader protocol tha ably that the and Stanfor 21]: to MQTT as nimal integr As a resul ports.
ed to avoid any con
nnects. This c ge followed b lf times the s last will mes
d part that i e being sent. ecifies the ty what the QoS
vered to its r age which in 2.
e variable he ges that will m
name as we wo bytes and s the two byt
The topic n ne additiona nce guarante age contains message is ack at aims to be e underlying rd-Clark liste possible ration effort t, the MQT
nfusion that the S
consists of to by the actual Keep Alive t ssage on the is necessary pe of messa S should be f recipients. T ncludes the
ader for the most frequen ell as a mess indicates th tes. So the sh name is then al packet tha e. This pack no addition knowledged. e more optim transport pr ed the follo to use the M TT-SN proto
stood for “Securit
opic string fol message. If time, then th
specified top
for all mess age being sen
for the messa The remainin variable he publish mes ntly be sent. sage identifie he number of horter the to n followed b at will be se ket looks ide nal fields bey
mized for sen rotocol is UD owing design MQTT-SN pr ocol support ty” [46]. llowed by a 2 the client ha he server wi pic. sages and on nt, whether age, and if th ng length fiel eader and th ssage and th . The variabl er (see Figur f octets that i opic name th by a two octe ent a lot: th entical to th yond the fixe
nsor network DP rather tha n points tha rotocol with ts almost a 2-as ill ne it he ld he he le re is he et he he ed ks an at a all
2 T b th b Fi The p when broke 3. Desig Wirel short IEEE physi secur each that c Head this th .6.1 Broke To allow for e roker and th he incoming roker. This c 1. Trans The tr conne to the While simpl maint numb 2. Aggre In co and t transp does n igure 2-14: 3. Multi Since unrel conne protocol is d never any com er to minimiz gned for wire
less network er maximum E 802.15.4 wi ical layer [2 rity, etc., so u packet signif can be deploy der Compress hesis howeve er gateways easy integrat he client. Thi g MQTT-SN can be done i sparent gatew ransparent g ection. Then e broker. e this offers ly translated tained betwe ber of clients egate gatewa ontrast, an ag the broker. W parent gatew not have to s Transparen iple gateway e MQTT-SN liable and h ections via d designed to mplex proces ze the client s eless network ks are expect m message ireless stand 1]. This incl using UDP in ficantly. It sh yed to reduc sion (ROHC/ er no compre
tion with exis is gateway us messages fr in two differe way gateway arch for each MQ s a straight-d to a MQTT een the brok are simultan y
ggregate gat While the im way, the bene support as m nt and aggrega support is designed have high li different gate be able to ssing needs t side load as m ks ted to have h e payload s dard provide cludes heade nstead of TC hould be not ce the amoun /ROHCv2) [ ession algori sting MQTT sually runs o rom the clien ent ways [21, hitecture conn QTT-SN conn
-forward imp T message, th ker and the neously conn teway mainta mplementatio efit is that th many MQTT c ate gateway, ad to work we ink failure r eways in orde run on ver to be done it much as pos higher failure sizes than s a maximum er data for t CP means we ted that ther nt of header d [22, 23] for I thms will be brokers, MQ on the same nts to MQTT , p. 5] (as sho nects each cl nection the g plementation he number o e gateway cr nected. ains one MQ n of such a g his approach connections t
dapted from Fig
ell over wirel rates, MQTT er to have a f ry resource should be d sible. e rates, lowe fixed netwo m of 128 by the network e could reduc re are header data transmi IPv4 and 6L investigated QTT-SN utili platform as T just before own in Figur lient to the ga ateway main n where eac of MQTT con reates scalab QTT connect gateway is a scales a lot b to the broker gure 5 of [21, p less network T-SN suppor fall back con
constrained done by the g
er transmissi orks. For e ytes for each k protocol, M
ce the heade r compressio itted. For exa LoWPAN for d. izes gateway the broker a e passing th re 2-14): ateway with ntains a MQT ch MQTT-SN nnections th bility issues tion between a bit more co better - sinc r. p. 5] ks where con rts maintain nnection in c devices, an gateway or th ion rates, an example, th h frame at th MAC addres er overhead o on algorithm ample Robus IPv6 [24]. I s between th and translate hem on to th an MQTT-SN TT connectio N message i hat have to b when a larg n the gatewa omplex than ce the gatewa nnections ar ning multipl case of failure nd he nd he he s, of ms st In he es he N on is be ge ay a ay re le e.
al tr th 2 B 4 p m si 2 O to lo b w a it w to th 2 S re w w k re
2
C si co S This thus a Since the lways operat ransmitting t he increased .6.2 MQTT By design, the octets depen The reaso ayload size i message leng imply describ .6.3 Topic One of the th o use a 2 oct ogin process roker then r way it is possi topic string ts topic strin way is to use opic IDs. For hat for the se .6.4 Keep ince MQTT-eceiving the would respon when there is keep-alive tim eceiver of the2.7 CoAP
CoAP is a pro imple device ontrolled via tate Transfer also allows t avoids conge e gateway wi te on the me the larger M size does no T-SN Messa e messaging nding on howon for the var is less than gth, thus the bes what typ c ID registrati hings that MQ et Topic ID i where the c esponds with ible to go fro the sender h ng to the bro pre-defined r our tests we ervices Scani alive messa -SN is a conn messages is nd with an AC s packet loss mer that tells e ping will th
P
oposed IETF es to commu a standard i r (REST) arc Figure 2-15: the clients to estion in the g ll translate t essage just b MQTT messag ot matter (as aging overhea overhead of w large the m riable length 256 octets. header size pe of message ion QTT-SN doe instead of a p client sends h a 2 octet ID om a 31 octethas two optio oker and the d topic IDs w e will only us a will be usin age nectionless p s still there w CK to tell the even this AC s the sender hen respond w standard and unicate over t internet app chitectural sty MQTT-S o spread the gateway. the MQTT-S before they a ges and only
much). ad f MQTT-SN i message. This h is that MQT However, fo e can be con e it is accordi s to reduce n plain text top a registratio D number th
topic string ons. Either p broker resp where the bro
se pre-define ng the topic I protocol it ne when using e sender that CK may be lo how long it with a ping A d aims to pro the Internet plications. Th tyle of the we SN header, ada eir network SN message t are passed to y use the MQ s very small. s header is sh TT-SN allows or use cases nsidered to a ing to the pro
network traff pic string. Th on packet w hat is subsequ to a 2 octet t performs a r ponds with th
oker and pub ed topic IDs IDs will be k
eeds some w a QoS level t the message ost. The way
should wait ACK and then
ovide a requ [6]. CoAP is his is achiev eb. apted from [5, p traffic over m to a MQTT m o the broker QTT format p . The header hown in Figu s the use of 1 the payloads always be 4 otocol specif ffic compared he topic strin ith the desir uently used t topic ID. To u egistration n he correspon blisher both since it is no nown before way to keep t of 1 or high e was succes y MQTT-SN s before sendi n the transm est/response s designed to ved by utiliz p. 7] multiple con message the r. This is so t prior to the r can consist ure 2-15. 1 octet for th s will not us octets. The fication [5, p d to the othe ng is only us red topic as to identify th use the topic negotiation w nding topic I have a set o ot unreasona e transmissio track of whet her. Normally ssfully delive solves this is ing a keep-a missions may e protocol th o allow node zing the Rep
nnections an e gateway wi that we avoi broker wher t of either 2 o e length if th se the shorte message typ . 7]. er protocols i sed during th a string. Th hat topic. Thi c ID instead o where it send ID. The othe of pre-define able to assum
on starts.
ther the part y the receive red; howeve s by keeping live ping. Th
resume.
hat allows ver es to easily b presentationa nd ill id re or he er pe is he he is of ds er ed me ty er r, a he ry be al
POST, PUT, and DELETE methods. CoAP is designed to easily translate to HTTP. There are even guidelines from IETF on how to map CoAP to HTTP [25]. However, although CoAP is designed to resemble HTTP in many ways, it differs in many others due to the requirements that a constrained device puts on it.
The biggest difference between HTTP and CoAP is that CoAP is a UDP based protocol. This is to avoid the overhead that TCP entails (which a constrained device wants to avoid).
CoAP offers two options regarding delivery guarantees. These are “at-most once delivery” and “at-least once” delivery. These are referred to as “non-confirmable” messages and “confirmable” messages in the CoAP specification. Confirmation requires the receiver of a message to send an ACK when it receives the message.
2.8 AMQP
AMQP is a protocol that communicates via publish/subscribe and operates on top of TCP. It was originally developed in 2003 by John O’Hara at JPMorgan Chase and iMatix with aim of creating an interoperable message system that was non-proprietary and could be used as a standard messaging protocol for investment banks [26].
Unlike MQTT, AMQP was not designed to have a small code footprint or an easy to use interface, but rather AMQP was designed to be feature rich and high performance. Additionally, it is not simply a messaging protocol, but also defines its own type system to ensure interoperability between client and server.
Since AMQP was created to be used as a standard messaging protocol for a wide range of different users it supports a wide variety of messaging applications and communication patterns through a common interface. As a consequence, AMQP is a large protocol that is feature rich and allows for a lot of customization. However, going into detail about each feature of this protocol is outside the scope of this thesis. A short summary of the functionality that AMQP offers follows [4, p. 2]:
Types AMQP has its own type system that defines a set of primitives that can be used to ensure interoperability between sender and receiver. These primitive values can then be associated with semantic information when sent in a message that tells the receiver how to interpret the value. For example, a string could be sent with the associated information that it is to be interpreted as a URL.
Transport The conceptual model of an AMQP network is that it is a network of nodes connected via links. These nodes can either be sender, relays, or receivers. The link between nodes is a unidirectional communication channel which connects to the node’s “terminus”. This terminus can be either a source or a target depending on the role of the node.
Each node is responsible for the safe storage and delivery of messages to the next node. The link protocol between the nodes ensures that the message and responsibility are correctly transferred between nodes.
The nodes exist within containers which can, for example, be brokers or clients. For example, a broker container can consists of many queue nodes that store messages. These messages are subsequently relayed to the appropriate client container, which in turn contains a consumer node and a queue node.
