2018 Global Internet of Things Summit (GIoTS)
Comparison of CoAP and MQTT Performance
Over Capillary Radios
Anna Larmo, Felipe Del Carpio
Ericsson Research,
Ericsson Oy,
Jorvas, Finland
{anna.larmo, felipe.del.carpio}@ericsson.com
Abstract—The IoT protocols used in the application layer,
namely the Constraint Application Protocol (CoAP) and Message
Queue Telemetry Transport (MQTT) have dependencies to the
transport layer. The choice of transport, Transmission Control
Protocol (TCP) or the User Datagram Protocol (UDP), on the
other hand, has an impact on the Internet of Things (IoT)
application level performance, especially over a wireless medium.
The motivation of this work is to look at the impact of the protocol
stack on performance over two different wireless medium real-
izations, namely Bluetooth Low Energy and Wi-Fi. The use case
studied is infrequent small reports sent from the sensor device
to a central cloud storage over a last mile radio access link. We
find that while CoAP/UDP based transport performs consistently
better both in terms of latency and power consumption over both
links, MQTT/TCP may also work when the use requirements
allow for longer latency providing better reliability. All in all, the
full connectivity stack needs to be considered when designing an
IoT deployment.
Keywords-IoT, CoAP, MQTT, TCP, UDP, BLE, 802.11ah.
I. I NTRODUCTION
The idea of IoT is to use the Internet Protocol, mainly IPv6,
to communicate between connected devices and the cloud. A
plethora of standards addressing the IoT on different levels of
the protocol stack are available today and may be combined
in different ways.
The IoT umbrella covers a large number of use cases. Here
we focus on use cases where small data transmissions are
expected from and to a large number of sensors and actuators.
Such use cases are for example connected lighting, connected
home sensors and actuators, smart metering, smart agriculture,
etc.
Most of the popular IoT applications today use either the
Internet Engineering Task Force (IETF) standardized Con-
straint Application Protocol (CoAP) or the OASIS specified
Message Queue Telemetry Transport (MQTT) as the data
transfer of choice. Other examples of IoT application layer
transfer protocols are the Hyper Text Transfer Protocol, Data
Distribution Service and Advanced Message Queuing Protocol
[1].
The requirements of the use case set boundary conditions
to the reliability and latency of the communication link. If
the use case involves collecting large amounts of sensor data
978-1-5090-5873-0/17/$31.00
/18/$31.00 ©2018 IEEE
Pontus Arvidson, Roman Chirikov
Ericsson Research,
Ericsson AB,
Stockholm, Sweden
{pontus.arvidson, roman.chirikov}@ericsson.com
for statistical purposes and traffic is mostly from the sensor
to the cloud, it may be acceptable to lose a report here and
there. Even in such scenarios, however, reliable transport may
be required on occasion when firmware updates or security
patches are done on devices.
The physical layer and the medium access control, i.e., L1
and L2, may differ greatly depending what kind of access
technology is used. In the end to end path of an IoT application
data flow, there may be fast fiber links, Ethernet cabling, as
well as radio access links over a cellular network, and finally
the last mile over a short range radio access technology in
the capillary domain such as Bluetooth Low Energy (BLE) or
Wi-Fi. In this paper, we focus on the aforementioned capillary
domain technologies.
II. P REVIOUS WORK
Previous work on comparing CoAP and MQTT has been
done in the form of small scale trials over an unnamed
radio technology [2] and by analytical means [3]. In [2], a
healthcare use case was realized with prototype hardware. The
performance of the two protocols was then measured when a
set of medical sensor data was transferred over an unspecified
wireless link. It was found that unpredictable packet loss is
handled poorly by CoAP but better by MQTT due to use
of TCP. In [3], the performance of the two protocols was
studied over very lossy links. It was found that by tuning
CoAP parameters, the performance can be greatly improved
and CoAP often performs better than MQTT due to the lower
overhead, although some level of packet loss needs to be
accepted when UDP is used. Our contribution to the discussion
is to study the performance over realistically modeled actual
PHY and MAC protocols and see how the combination of the
protocols all the way from the application layer down to the
physical layer impacts the application performance.
Both BLE and Wi-Fi are traditionally deployed in a star
or point to point topology and designed to handle two-way
communication. Also, both technologies have recently evolved
for longer range. Thus, they provide an interesting comparison
[4], [5]. IEEE 802.15.4 systems are typically designed mainly
for one-way data streams and to function in a mesh topology.
While it is true that IEEE 802.15.4 systems may also be
c 2018 IEEE
 2018 Global Internet of Things Summit (GIoTS)
Fig. 1. Typical IoT stack options for massive MTC use cases.
deployed in a star topology, we focus on the two newer
technologies in this evaluation.
When good battery performance is required from the access
link, the use of different kinds of sleep mechanisms often
becomes a necessity, as one of the most power consuming
modules in the radio device is the receiver. The total power
budget of the IoT device may need to be shared between
the radio module, the actual sensor and/or actuator, and a
processor.
In the remainder of this paper, we study how different
protocol stacks perform over BLE and IEEE 802.11ah last
mile short range radios. The paper is organized as follows:
first we present an overview of the IoT protocol stack with
different protocol options in the different layers, followed by
a description on basics of the CoAP and MQTT protocols. We
discuss the potential of the two chosen IoT radio connectivity
solutions, BLE and 802.11ah. Further, we explain the IoT use
case scenario and system level assumptions for our simulation
study. Finally, we analyze the IoT performance over BLE and
802.11ah in terms of uplink packet transmission delays and
battery levels of connected sensors.
III. I OT S TACK FOR M ASSIVE MTC
Several realizations of the full IoT stack have been discussed
in the industry and academia. However, it is likely that
convergence to a single option will not happen in the near
future due to different characteristics of the large variety of
use cases grouped under IoT. Figure 1 depicts different options
for the IoT stack on different layers for the massive Machine
Type Communication (MTC) use cases.
When CoAP [6] is used in the transfer layer, UDP is the
default transport assumed. It should be noted though that
in the IETF, TCP transport for CoAP is currently discussed
[7]. MQTT [8], relies on TCP on the transport layer, while
a version for UDP called MQTT-SN has been discussed as
well. More broadly, Data Distribution Service for Real-Time
Systems typically utilizes UDP, while with Hypertext Transfer
Protocol and Advanced Message Queuing Protocol, TCP is
used instead by default. To understand how different stacks
may impact application level performance and system design,
the differences between the two different transports need to be
understood.
The key differences between TCP and UDP are that UDP
is connectionless, light weight, and unreliable, whereas TCP
brings more overhead but also reliability with its connection
oriented confirmed delivery of packets. A TCP connection
requires a three-way handshake between the sensor and the
central node at the setup phase. On the contrary, a UDP data
transmission does not require any setup or bi-directionality; the
packet is simply sent from the transmitter end to the receiver
end at a suitable time. TCP fast open is a variant of the TCP
protocol, which allows data transmission along with TCP SYN
and SYN-ACK transmissions [9]. Although TCP fast open will
simplify TCP usage for IoT, we have chosen to limit our study
on the legacy TCP as it still is widely used.
Security is a key part of any IoT stack. There are different
ways to provide security and typical options for the discussed
stack are to use either Transport Layer Security (TLS) for TCP
or Datagram Transport Layer Security (DTLS) for UDP. Secu-
rity solutions typically bring overhead and may introduce extra
handshakes to the procedure as well. However, in this work
we assume that the security handshakes have already been
performed at an earlier time, e.g., out-of-bound at deployment
or manufacturing phase of the sensor life cycle.
A. Short introduction to CoAP and MQTT
CoAP is a RESTful application layer transfer protocol
specified by the IETF [6]. CoAP typically is run over UDP
connections, although work to adapt to TCP is also ongoing
[7]. CoAP may be run in two different modes, namely the con-
firmed delivery mode and the non-confirmed delivery mode.
For sensor reporting with relaxed reliability requirement the
non-confirmed mode is sufficient. Confirmations may be also
requested only for some packets.
MQTT [8] is an application layer publish/subscribe transfer
protocol specified by OASIS. In MQTT, topics are set up
between the client and the server which are then subscribed
and published to. For sensor reporting, the sensor client
registers at a server to publish sensor data, and vice versa
register for topics to receive updates when needed.
B. Power saving on the radio interface
Low power consumption is a key requirement for massive
IoT radio modules. Turning off the receiver is often referred to
as sleeping or discontinuous reception (DRX). Turning off the
transmitter may need to be done as well and this is referred
to as discontinuous transmission (DTX). When the radio is
asleep, the device will not be reachable. If sleep intervals are
short, in the order of tens of milliseconds, this may not be a
problem. However, to bring down the power consumption the
sleep periods will need to be longer [10].
Sleeping mechanisms are typically part of the Medium
Access Control (MAC) protocol. This functionality can be
realized in different ways depending on spectrum type used
and whether network control can be used.
In unlicensed spectrum, configuring sleeping cycles is not
straight forward as the network cannot guarantee a transmis-
sion opportunity for the time window where the device should
be available. This is the case for example in carrier sense
multiple access (CSMA) used for channel access in Wi-Fi. In
 2018 Global Internet of Things Summit (GIoTS)
Fig. 2. TCP three-way handshake for uplink sensor report.
frequency hopping systems, such as BLE, interference may
happen just when the device is awake and thus a similar
problem as with CSMA exists. Channel access may also be
limited with duty cycles and depending on time window over
which duty cycles are calculated, communication in either
direction may be constrained.
Massive IoT use cases in IoT are often expected to be uplink
oriented and carrying just small amounts of data. However, if
TCP is used, the communication will flow in both directions
and furthermore, the TCP protocol puts time constraints on
how fast the next packet needs to be delivered for congestion
control features to kick in.
C. TCP over sleepy MAC
The TCP three-way handshake begins with sending a SYN
message to open a connection. This is a followed with a SYN-
ACK from the other end, after which the second SYN is
acknowledged and data may be sent over the newly established
connection. Analyzing the three-way handshake for sensor
type uplink oriented traffic shows the points in time when
the device should be awake as depicted in Figure 2.
The communication is initiated by the device. We assume no
DTX mechanism is used and thus the device may initiate data
transmission immediately when the packet is available and
channel access scheme used in the system allows transmission.
The problematic points in the communication become the
instants in time, when DL messages arrive. In case a DRX
mechanism is in place in the MAC layer, the packets will be
queued in the radio node on the network side until device is
available for DL reception.
IV. C APILLARY R ADIO ACCESS
Capillary networks are IoT networks where the last mile
access is realized typically with an unlicensed low power radio
technology [11]. Typical use cases addressed with capillary
networks fall into the massive IoT category. Other technical
solutions for massive IoT are low power wide area IoT
technologies such as NB-IoT and LoRa. A capillary gateway is
used as a connection point towards the Internet with backhaul
realized for example with a 3GPP radio link such as LTE. In
this paper, we study two different options for the last mile
radio, namely BLE and IEEE 802.11ah aka low power Wi-Fi.
A. Bluetooth Low Energy
BLE, also known as Bluetooth Smart [12], is a low power
radio technology developed for the IoT. The technology is
based on the Bluetooth technology, but has been further
developed to allow for operation on devices powered only
by coin cell batteries or even through energy harvesting.
The protocols of BLE have been specifically designed with
low energy consumption in mind and allow for very low
duty cycles. BLE operates in the 2.4 GHz ISM band and
utilizes an adaptive frequency hopping scheme to co-exist with
other technologies, for example, Wi-Fi. The BLE standard is
developed by the Bluetooth special interest group and BLE is
part of the Bluetooth specification versions 4.0 and higher.
BLE supports both connection oriented data transfers,
as well as a connection-less mode. For connection-oriented
mode, a connection is first established and each subsequent
over-the-air transmission is explicitly acknowledged. For the
connection-less mode, transmissions are performed in a broad-
casting manner.
Sleeping in BLE may happen both when the device is
connected and when it is not connected. In the simplest
case, all time outside of a connection is sleeping. Within a
connection the device may sleep between connection events.
The interval between connection events may vary from a few
milliseconds to a few seconds. A connection is closed when
there is no more data to exchange.
B. IEEE 802.11ah aka low power Wi-Fi
IEEE 802.11ah amendment [13] is intended to operate in
sub 1 GHz bands to provide longer transmission range com-
pared to legacy Wi-Fi and support large number of associated
stations (STAs) with a single Access Point (AP). 802.11ah
uses Carrier-Sense Multiple Access with Collision Avoidance
(CSMA/CA) like other members of the 802.11 family with
improved energy saving mechanisms. 802.11ah introduces
Traffic Indication Map (TIM) segmentation, extension of the
sleep cycle up to 5 years, a new class of sensor type STAs,
target wake time, and support of shorter operating channel
bandwidths of 1 MHz and 2 MHz. Access point may divide
large number of STAs to different TIM groups, thereby effi-
ciently indicating the availability of downlink buffered traffic
to a specific group at a time. A DTX mechanism is specified
for 802.11ah in the form of the restricted access windows
(RAW). This mechanism will impact the latency negatively
for any user that is blocked from transmitting in the system
when the load is low. When the load is high, on the other
hand, the latency may benefit from RAW. RAW is not part of
the current evaluation as we focus on low load.
V. S IMULATOR M ODEL
The evaluations discussed in the following were performed
using an Ericsson internal event based radio network system
 2018 Global Internet of Things Summit (GIoTS)
simulator with detailed models of application, IP, transport,
network and link layers for both BLE and Wi-Fi. This in-
ternal simulator is similar in structure and capabilities to the
commonly used NS3 simulator.
Sensor reports were randomly generated by means of a
Poisson process. For TCP, the session is terminated after each
sensor report was received in the other end of the connection,
however, the termination procedure of a TCP connection has
not been explicitly modelled. A simplified physical layer
was used for both technologies, with a detailed model of
the MAC layer, as well as the IP, TCP, and UDP layers.
The CoAP and MQTT layers were simplified with a simple
payload size model on top of the transport. More details on
the technology specific models are discussed in sub-sections.
IP header compression was not modelled in the simulation.
Varying the payload is used instead.
Buffer limitations of the devices have also not been mod-
elled. The devices are also assumed to be in close vicinity of
one another so that no, or at least very few packets, should be
lost over the air, except for those lost due to collisions.
A. BLE modeling
The simulator contains detailed models of all parts relevant
to the evaluation according to revision 4.2 of the Bluetooth
specification.
In these evaluations the connection-oriented mode is utilized
as two-way communication is necessary, at least for the TCP
parts. A new BLE connection will be established for each new
data transfer. This means that for a typical transaction, the
sensor will wake up upon generation of data to transmit, try
to establish a new connection to a central device and transmit
the data within the connection.
Connection events are configured to happen every 7.5 ms
thus giving the sleeping cycle for a BLE connection. The
connection is initiated by the sensor who enters the connection
as slave. Each connection event is initiated by the master,
which in this case is the central device.
B. IEEE 802.11ah modeling
The simulator contains detailed models of all parts relevant
to the evaluation according to draft 8.0 of the IEEE 802.11ah
specification.
Stations (STAs) are assumed to be in power save mode,
and may wake up whenever there is uplink data to transmit.
In power saving mode, DL data transmission from the Access
Point (AP) to STA works such that the AP generates beacon
frames at periodic times given by the Target Beacon Transmis-
sion Time (TBTT). A Traffic Indication Map (TIM) frame in
the beacon is used to indicate the availability of the downlink
data. If the beacon indicates availability of downlink data for
a particular STA, then this STA transmits a Power-Save poll
(PS-poll) to the AP to inform the AP it is available in DL
to retrieve the data. In return, the AP transmits the DL data
to the corresponding STA. Also, as STAs are in power-save
mode, a STA may go to sleep, if the TIM element within the
beacon frame does not indicate that DL data is available.
TBTT interval for beacon transmission is modelled as 100
ms in the current simulation. The channel bandwidth for
the Wi-Fi transmissions is assumed to be 2 MHz with the
carrier frequency of 864 MHz. The antenna is assumed to be
omnidirectional.
C. Simulation scenario
We simulate a scenario in which wireless sensors are
connected to the central device or gateway in a star topology.
We assume that all the devices are within communication
range from the central device.
The sensors communicate with a cloud server in the Internet
and we assume Internet delays to be 40 ms one way. This value
is chosen to reflect a server that is deployed reasonably close
to the sensor.
In the scenario devices generate sensor reports with packet
sizes of 25, 150 and 400 bytes as transport layer payload.
These values are chosen to show the impact of increasing
payload and to show that, e.g., header compression would
have very little impact. We assume the transfer layer protocol
headers for CoAP and MQTT respectively to be included in
this payload as well any needed object representation overhead
from, e.g., Light Weight Machine to Machine and security. The
average report intensity is 5 packets per second. This means
that in the network 5 packets are generated in total in a second.
VI. P ERFORMANCE E VALUATION
Simulations of CoAP with UDP and MQTT with TCP trans-
fer layer over both BLE and IEEE 802.11ah were performed to
study the impact of the transport layer protocol over different
MAC layers. The main aspects studied are the extra delay
and the extra power consumption caused by TCP usage when
compared to using UDP. We focus on simple sensor report
traffic in the uplink direction. When using CoAP, this type
of traffic can be sent non-confirmed, while with the MQTT
stack TCP will provide reliability. We simulate also the CoAP
confirmed case to show it has very little if no impact. By
utilizing two different link layers, we also gain understanding
on how different sleeping mechanisms on the MAC layer
impact the performance.
A. Packet delay evaluation
The packet delays on the application layer from the time
instant of packet creation and packet reception from the TCP
and UDP layers in the receiver end are shown in Figure 3 for
both BLE and 802.11ah in cumulative distribution function
format (CDF).
As can be seen in the BLE results, the difference between
CoAP (UDP) and MQTT (TCP) over the BLE connection ba-
sically corresponds to the three-way handshake that increases
the number of messages that need to be exchanged. With the
Internet delay of 40 ms one-way, the difference to UDP is at
least 80 ms. The connection event interval used is 7.5 ms,
adding an average delay of 2.75 ms to each DL oriented
message. The spread in the delays for the packets that do not
make it across at the first attempt depends on the BLE central
 2018 Global Internet of Things Summit (GIoTS)

Packet delays for sensor reports over BLE, 5 reports per second Packet delays for sensor over 802.11AH, 5 reports per second
100 100

90 90

80 80

70 70

60 60
CDF [%]

CDF [%]
50 50
25 B, MQTT 25 B, MQTT
40 25 B, CoAP 40 25 B, CoAP
25 B, CoAP + ACK 25 B, CoAP + ACK
30 150 B, MQTT 30 150 B, MQTT
150 B, CoAP 150 B, CoAP
20 150 B, CoAP + ACK 20 150 B, CoAP + ACK
400 B, MQTT 400 B, MQTT
10 400 B, CoAP 10 400 B, CoAP
400 B, CoAP + ACK 400 B, CoAP + ACK
0 0
10-2 10-1 10-1
Packet delay [s] Packet delay [s]
(a) (b)
Fig. 3. Packet delays for BLE and 802.11ah for varying packet sizes and a fixed arrival rate of 2 packets per second.

device being busy serving another user. In the TCP case, this
delay may in turn cause TCP timeouts introducing further
delays. It should be noted that the BLE central device that
is modelled only supports one concurrent connection, which
is significantly less than for a typical device. These results
may thus be somewhat pessimistic.
The Wi-Fi results look rather different. Due to the 100
ms TIM interval, the first DL oriented transmission will take
on average 50 ms longer than an uplink transmission with a
uniform distribution over the 100 ms TIM period. The delay
spread from 150 ms to 250 ms can be clearly seen in the
graph.
B. Power consumption performance
Power consumption is affected by the choice of transfer and
thus transport layer protocol. The results are consistent and
reflect the time needed to perform the actual data transfer,
which in case of MQTT (TCP) requires more messaging over
the air (Figure 4).
The larger difference between ah and BLE comes from the
beacon model used in Wi-Fi. There is no periodic wake up to
check for DL data in BLE, whereas in Wi-Fi this is inbuilt
to the MAC protocol. The ah results are thus affected by the
periodic wake up to listen the beacon every 100 ms. For a
fairer comparison in the UDP case, the sensor devices could
be configured to non-TIM devices meaning that they would
not need to wake up to listen to the beacon. This would yield
a more similar power consumption to the BLE case. For TCP
use, however, TIM operation is required, as the device would
otherwise not be capable of two-way communication.
C. Discussion
In the evaluated scenario, BLE and 802.11ah have compa-
rable performance. However, all disadvantages are not clear
from the simulation results. When the end device acts as a
master in the BLE connection, we optimize sleep for the sensor
device. However, the sensor devices becomes unavailable to
the network, whenever a connection is not open. Thus, this
model does not work well when the packet route has long
latency on the end to end path or when actuation is performed,
unless the connection would be opened periodically to poll for
DL data in the other end of the radio connection. In case such
periodic polling would be performed, a similar degradation in
power consumption should be expected as is seen in the case
of 802.11ah as the polling would introduce a function similar
to the beacon reception in Wi-Fi.
Adding header compression to the evaluation would have a
very small impact on the performance due to reduced number
of bits transmitted over the air, as can be seen from the
difference between the different payloads.
VII. C ONCLUSIONS AND FUTURE WORK
In this paper we studied the performance of sensor reporting
over CoAP and MQTT with UDP and TCP transport protocols
respectively running on top of two different radio interfaces,
namely BLE and IEEE 802.11ah. Unlike UDP, TCP includes
a handshake procedure to establish a session. This leads to
additional exchange of packets and therefore affects the delay
of packets and battery lifetime of IoT devices. Furthermore,
TCP acknowledgements used to ensure reliability need to be
later received in the transmitter to avoid retransmissions.
Delays are comparable for UDP between BLE and
802.11ah. They are dictated mainly by the time it takes to
transfer data over the air. When TCP is used, however, the
TIM model in 802.11ah brings a built in minimum delay cor-
responding to the TIM configuration to the communication. In
these results, the delay spread further reflects the chosen TIM
interval of 100 ms, a typical interval configured for beacons in
Wi-Fi networks today. However, to optimize for device battery
lifetime in IoT deployments, longer TIM intervals may be
configured.
 2018 Global Internet of Things Summit (GIoTS)

Sensor battery lifetime [years], BLE Sensor battery lifetime [years], AH

25 1.2
1 minute report interval 1 minute report interval
10 minutes report interval 10 minutes report interval
1
20

0.8
15

0.6

10
0.4

5
0.2

0 0
P

K
TT

TT

P
K

TT

TT

TT

TT
oA

AC

AC

oA

AC

AC
oA

oA

oA

oA
AC

AC
Q

Q
Q

Q
C

C
C

C
M

M
M

M
+

+
+

+
B,

B,
B,

B,

B,

B,
B,

B,
B,

B,

B,

B,
P

P
P

P
oA

oA

oA

oA
oA

oA
25

25
0

0
25

25
0

0
15

40

15

40
15

40

15

40
C

C
C

C
B,

B,

B,

B,
B,

B,
0

0
25

25
15

40

15

40
(a) (b)
Fig. 4. Battery lifetime for BLE and 802.11ah for packets being generated with an inter-arrival time of 1 and 10 minutes for different packet sizes and
transport protocols. Please note different y-axis scales showing battery lifetime in years.

Regarding the battery lifetime, TCP uses more energy due [10] T. Tirronen, A. Larmo, J. Sachs, B. Lindoff, and N. Wiberg, “Machine-
to more packets sent, than UDP. The proportion between TCP to-machine communication with long-term evolution with reduced de-
vice energy consumption,” Transactions on Emerging Telecommunica-
and UDP remains for BLE and 802.11ah, but BLE device’s tions Technologies, vol. 24, no. 4, pp. 413–426, 2013.
battery lifetime is 17 times longer compared to 802.11ah. This [11] J. Sachs, N. Beijar, P. Elmdahl, J. Melen, F. Militano, and P. Salmela,
is due to the recurring wake-up to listen to the Wi-Fi beacon “Capillary networks–a smart way to get things connected,” Ericsson
Review, September, vol. 9, 2014.
every 100 ms even when there is no traffic to be received. [12] “Bluetooth Core Specification 4.2,” Bluetooth SIG, Standard, 2014.
The study confirms, the previous results where CoAP out- [13] “P802.11ah, Draft 10.0, Wireless LAN Medium Access Control (MAC)
performs TCP in latency. The study also shows differences in and Physical Layer (PHY) Specifications,” IEEE, Draft, 2016.
the different radios. While Bluetooth air interface is faster in
general, the Wi-Fi air interface provides lower latency when
the network is loaded.
R EFERENCES
[1] A. Al-Fuqaha, A. Khreishah, M. Guizani, A. Rayes, and M. Moham-
madi, “Toward better horizontal integration among IoT services,” IEEE
Communications Magazine, vol. 53, no. 9, pp. 72–79, 2015.
[2] Y. Chen and T. Kunz, “Performance evaluation of IoT protocols under
a constrained wireless access network,” in Selected Topics in Mobile
& Wireless Networking (MoWNeT), 2016 International Conference on.
IEEE, 2016, pp. 1–7.
[3] M. Collina, M. Bartolucci, A. Vanelli-Coralli, and G. E. Corazza,
“Internet of Things application layer protocol analysis over error and
delay prone links,” in Advanced Satellite Multimedia Systems Conference
and the 13th Signal Processing for Space Communications Workshop
(ASMS/SPSC), 2014 7th. IEEE, 2014, pp. 398–404.
[4] P. D. Marco, R. Chirikov, P. Amin, and F. Militano, “Coverage analysis
of Bluetooth Low Energy and IEEE 802.11ah for office scenario,” in
Personal, Indoor, and Mobile Radio Communications (PIMRC), 2015
IEEE 26th Annual International Symposium on, Aug 2015, pp. 2283–
2287.
[5] F. D. Carpio, P. D. Marco, P. Skillermark, R. Chirikov, K. Lagergren, and
P. Amin, “Comparison of 802.11ah and BLE for a home automation use
case,” in Personal, Indoor, and Mobile Radio Communications (PIMRC),
2016 IEEE 27th Annual International Symposium on, Sep 2016.
[6] Z. Shelby, K. Hartke, and C. Bormann, “The constraint application
protocol (CoAP),” Internet Requests for Comments, RFC 7252, 2014.
[7] C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, and
B. Raymor, “CoAP (Constrained Application Protocol) over TCP, TLS,
and WebSockets,” IETF draft, December 2017.
[8] “MQTT, version 3.1.1,” OASIS Standard, October 2014.
[9] Y. Cheng, J. Chu, S. Radhakrishnan, and A. Jain, “TCP fast open,”
Internet Requests for Comments, RFC 7413, 2014.