194 IEEE NETWORKING LETTERS, VOL. 4, NO.

4, DECEMBER 2022

Experimental Evaluation of End-to-End Delay in a Sigfox Network

Jouni Ikonen , Niklas Nelimarkka, Pedro H. J. Nardelli , Senior Member, IEEE, Niko Mattila,
and Dick Carrillo Melgarejo , Member, IEEE

Abstract—This letter presents an experimental evaluation of

end-to-end delay in Sigfox networks, considering measurements
from the transmitter to the server. We carried out two types
of cases. The first was a static experiment with a typical deliv- Fig. 1. Sigfox uplink MAC frame.
ery time ranging between 2.5 and 4.5 seconds, with a 100%
delivery rate. The second considers mobility, with the experi-
ments carried out in mostly rural environments in which the (which can be up to 12 bytes) per day and use an uplink data
transmitter is inside a car. In this case, we observed a deliv-
rate of 100 bits/s [5] in Europe with RC1. Messages are not
ery rate of 20% and an end-to-end delay of up to eight seconds.
Our evaluation empirically indicates performance limitations that acknowledged and are sent three times on different frequencies
application developers should consider. to maximize the probability that they will be received by the
Index Terms—Sigfox, Internet of Things, LPWAN, test bed.
backbone network [6]. A downlink service allows four eight-
byte messages per day; this technology can be classified as
a low-power, wide area network (LPWAN). The structure of
the uplink medium access control (MAC) frame is presented
I. I NTRODUCTION
in Fig. 1. The size of each field in bytes is presented in
HERE are different types of wireless network solutions
T for the Internet of Things (IoT), especially for massive
machine-type communications. The study we conducted in
parentheses in the figure. The maximum frame size is 26
bytes [2].
The payload of Sigfox messages can vary from 0 to 12 bytes
this letter focuses on a specific solution, Sigfox, and our aim for uplink messages and 0 to 8 bytes for downlink messages;
is to analyze its end-to-end performance in terms of delay. however, the Sigfox protocol has predefined message sizes of
Some of the other alternative IoT network technologies include 1, 4, 8, and 12 bytes for uplink messages and 8 bytes for down-
Long Range Wide Area Network (LoRaWAN) and narrow- link messages. The length is always one of these predefined
band IoT (NB-IoT). Sigfox and LoRaWAN both operate on lengths. If a given payload is between these lengths, protocol
unlicensed industrial, scientific and medical (ISM) frequency padding is added to reach a predefined length. For example,
bands, whereas NB-IoT operates on licensed frequencies, if the payload length is 6 bytes, then 2 bytes of padding will
which are exclusively allocated for Global System for Mobile be added before sending [7].
Communications (GSM) and long-term evolution (LTE) cel- In this letter, our focus is on reporting two types of exper-
lular networks [1]. The advantages of Sigfox technology are iments (static and mobile) for Sigfox networks in terms of
its long range and low power consumption in comparison to end-to-end delay, a subject that has not been adequately inves-
traditional cellular technologies [2], [3]. Operation on the ISM tigated in the literature. Our contribution is to present our
frequencies means that there are no licensing costs related to measurements to build a better understanding of the end-to-
the use of these frequencies. end delays IoT application developers can expect when using
Sigfox’s technology is a proprietary cell-based form of Sigfox. The rest of this letter is organized as follows. Section II
ultra-narrowband communication [2], [4]. Globally, network provides an overview of the literature. Section III introduces
specifications are divided into seven radio configurations the static experimental setup used here, and Section IV presents
(RCs), which define the allowed frequencies, bit rates, and the results for mobility. Section V concludes this letter.
recommended equivalent isotropically radiated powers (EIRP).
These specifications allow devices to send 140 messages
II. R ELATED W ORK
Manuscript received 10 June 2022; revised 7 August 2022; accepted To understand current research related to Sigfox networking
22 August 2022. Date of publication 5 September 2022; date of cur-
rent version 21 November 2022. This work was supported in part by the technology, we conducted a literature review using the IEEE
Academy of Finland through the FIREMAN Consortium under Grant CHIST- Xplore and Association for Computing Machinery (ACM) dig-
ERA/n.326270; in part by the EnergyNet Research Fellowship under Grant ital library databases. In the review, we analyzed all papers
n.321265/n.328869; and in part by the JAES Research Foundation through
STREAM Project. The associate editor coordinating the review of this arti- mentioning Sigfox. The typical research topics identified
cle and approving it for publication was C. Alcaraz. (Corresponding author: include connection quality and reliability [3], [8], [9], [10],
Jouni Ikonen.) mobility [3], [8], [9], [11], send latency [12], [13], power effi-
Jouni Ikonen, Niklas Nelimarkka, and Niko Mattila are with the
Software Engineering, Lappeenranta–Lahti University of Technology, 53850 ciency [14], [15], [16], [17], [18], and localization [10], [19],
Lappeenranta, Finland (e-mail: [email protected]). [20], [21].
Pedro H. J. Nardelli and Dick Carrillo Melgarejo are with the We were not able to find any experimental-oriented papers
Electrical Engineering, Lappeenranta–Lahti University of Technology, 53850
Lappeenranta, Finland that presented end-to-end delay measurements using the
Digital Object Identifier 10.1109/LNET.2022.3203799 Sigfox network. Wang et al. [11] compared different IoT
This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
IKONEN et al.: EXPERIMENTAL EVALUATION OF END-TO-END DELAY IN A SIGFOX NETWORK 195

the send request took. This log information is later com-

bined with other collected data. The Sigfox messages sent
by Arduino are received by SigFox cell towers (and can be
received by multiple cell towers) and forwarded (3) to SigFox
middleware. The Sigfox network requires devices to be regis-
tered in order to use it, and through its middleware, messages
from a specific device can invoke different rules for a cus-
tomer. These rules can include message content rewriting to a
human-readable format, addition of transmission data (signal
strength, timestamp, etc.) to the message, and sending of the
outcome to an email address or forwarding of the message to
an Internet server. In this letter messages were forwarded both
Fig. 2. Research setup for the fixed-size message delivery experiment. to a Web server (4) and sent to an email (5). Additionally,
SigFox middleware was set to add a timestamp to each
technologies and reported delays from an end device to the message.
Sigfox backend (gateway) to have an average of 3.63 s. Their The receiving Web server was implemented in a virtual
results are not directly comparable to ours, as their study is Ubuntu 18.04 server run in a cloud by the IT Center for
conducted in the RC4 region, which has a data rate of 600 bit/s. Science and located in Finland. The receiving Web server was
Ribeiro et al. [8] examined mobility in rural areas. In implemented using Node.js, which recorded the time of receipt
their experiment, a Sigfox end device sent messages from a and the message content into a database. Google’s Gmail
car moving on a motorway using RC2, which has a higher service was used as the receiving email server. The email
send rate of 600 bit/s and a higher transmission power of messages received were later downloaded, and the received
24 dBm. They reported that 68% of the message transmis- message content and email timestamp were recorded in a
sions were unsuccessful. In a study by Wang et al. [11], database. In the experiments, information was collected in
73% of messages sent from a moving car were lost, but a three places: a transmission log on the RPi, a reception on
moving drone at an altitude of 60 m was able to send all a Web server, and e-mail. The data were combined by trans-
the messages successfully. Their experiments were conducted ferring them to the same server and merging them into based
in RC4. on the message number. IoT messages received in e-mail
were obtained by retrieving the entire e-mail box with Internet
Message Access Protocol (IMAP), from which the script then
III. I MPACT OF M ESSAGE S IZE ON D ELAY parsed the IoT messages and arrival times into its own file
M EASUREMENTS and from which they were later combined with the data from
We designed multiple sets of experiments to gain insight other logs.
into how the Sigfox network behaves as a data channel. Our Trial arrangements were run for two weeks, and 2,087 mes-
focus is on testing the end-to-end delays that IoT applications sages were sent through the SigFox network during experi-
can encounter in practical use cases. The first set of experi- ments. A message transmission interval of 10 minutes was
ments was conducted with fixed-size messages in a semi-urban used, which is the minimum transmission interval to comply
environment. IoT messages were delivered to a Web and mail with RC1 duty cycle requirements.
server, and their delays were measured. In the second set The results are documented as a dataset with a transit
of experiments, the message size was varied to examine its time from the sender, the middleware, the e-mail, and the
impact, and in the third set, the messages were transmitted in Web server. Table I provides an example of the data col-
a moving car. In these experiments, we used a Raspberry Pi lected, in which the first field is the message number, the
(RPi) computer with Arduino MKR FOX 1200 to send Sigfox second is the reception time in the Web server (Unix time,
messages. converted to milliseconds), the third is the e-mail reception
timestamp, the fourth the timestamp on the IoT middleware
server (MW), the fifth is the send time from RPi, and the
A. Delay Measurements With Fixed-Size Messages sixth field is the calculated end-to-end delay from the RPi to
The research setup was built in such a way that it could Web server. The other metrics, such as the Sigfox middleware-
be run non attended for a long period of time. The research to-server [s], sender-to-Sigfox middleware [s], sender-to-email
setup is illustrated in Fig. 2. The base of the setup is an [s], and Sigfox middleware-to-email [s], can be calculated
RPi computer which runs the test sets. In these test sets, from the transit times between different points in seconds. For
RPi make requests via serial (1) to the Arduino MKR FOX example, for message 1805, we have 3 s, 1 s, 4 s, and 3 s,
1200 board, which has the capability to send messages to respectively.
the SigFox network (2). The arduino board does not have an A more detailed study included 1,553 messages on the
onboard real-time clock, so the use of RPi eases the experiment ground that some server issues were excluded from the study.
arrangements. Cronyd command is used for time synchro- Based on the analysis, the minimum time it took from the start
nization in the RPi and Web server. For each send request, of sending a message to receiving it in the Web server was
RPi records the timestamp, the message number and the time 2.396 s and the maximum was 19.944 s. All messages sent
196 IEEE NETWORKING LETTERS, VOL. 4, NO. 4, DECEMBER 2022

TABLE I
S AMPLE OF THE DATA C OLLECTED IN THE DATABASE C ONSIDERING THE S IGFOX M IDDLEWARE (MW) AND THE S ERVER (S)

TABLE II TABLE IV
E ND - TO -E ND T RANSMISSION D ELAY F ROM RP I TO A W EB S ERVER T RANSMISSION D ELAY F ROM THE S ENDER TO THE E MAIL S ERVER

the Sigfox middleware and the Web server, loss of messages

TABLE III (transmission control protocol (TCP) retransmissions), or slow
T RANSMISSION D ELAY F ROM THE S ENDER TO THE M IDDLEWARE speed of the virtual machine running the Web server.
The time which it takes to receive an IoT message in an
email server is also studied because in many cases, IoT notifi-
cations can be sent as email notifications. The setup has many
variables, which are beyond our control, like 1 s email receipt
timestamp resolution, so readers should treat these results as
an example of a case study. The distribution of message trans-
mission times from the send command in RPi to the receipt
of the message in an email server is presented in Table IV.
were successfully received. The distribution of message tran- According to the results, 87% of the messages arrived on the
sit times is shown in Table II, in which it is shown that 26% email server in less than 4 s.
of the messages were received in less than 2.5 s and 62% of
messages in less than 3 s. In about one percent of the cases, B. Impact of Message Size
it took more than 6 s to receive the message. We designed a set of experiments to evaluate the impact of
The time elapsed from the transmission command given by message size on the transmission time, connection quality and
RPi to the time receipt reported by the SigFox middleware connection reliability using a similar setup as in the earlier
was calculated and the distribution of message transit times is experiments. This setup is illustrated in Fig. 2, but this time
shown in Table III. The middleware reports the time receipt the sending of messages to a mail server was not included.
of a message with an accuracy of only 1 s, which limits the Similar to the first experiment the transmission log was kept
accuracy of the study. In this case, 98 percent of the messages on the RPi, which was later combined with the information
were received in less than 3 s. from the backend server. Messages were sent with a payload
The test application was sending 5-byte messages, which sizes of 1, 2, 4, 8, and 12 bytes. When a 1-byte message was
were then padded to 8 bytes and packed within Sigfox mes- sent an unsigned integer was used as the message payload.
sage protocol. The maximum size of the Sigfox frame is 26 For all other message sizes, the message payload contained
bytes. If we assume that the frame header has a fixed size and the message number. For these tests, we upgraded our Ubuntu
we have 8 bytes of data to transmit then we will obtain an server to 20.04 LTS in the IT Center for Science’s cPouta
estimate for the time it takes to send the frame over the air. cloud hosting service. The receiving server was implemented
The transmission time equals (header size in bits + payload using Node.js and MongoDB Atlas for the storage of message
in bits) / 100 bits/s, which gives us (14*8 + 5*8 + 3*8) / 100 data. A total of 562 messages were sent during the experiment.
= 1.76 s aligned with the 1.75 s stated in [7]. The average transmission times were evaluated from the
It should be further noted that we do not have information messages sent to the cPouta backend. The average end-
on the synchronization of middleware clocks, and the time to-end transmission times and the minimum and maximum
resolution provided by the middleware is 1 s, which causes transmission times are illustrated in Fig. 3. For the average
uncertainty in the results. From these findings, it can be con- transmission times the standard deviation is drawn as error bars
cluded that messaging from the middleware to the server in the figure. For example, for 1-byte messages, the standard
has resulted in longer delays for several messages. The rea- deviation was 427 ms, which is marked in both the positive
son these may be the congestion of Internet traffic between and negative directions in the chart. On average, 66–78% of
IKONEN et al.: EXPERIMENTAL EVALUATION OF END-TO-END DELAY IN A SIGFOX NETWORK 197

Fig. 5. Mobility measurement system on a car dashboard.

Fig. 3. End-to-end message transmission times.

Fig. 6. Example of a mobility experiment shown on a map.

current velocity. In the experiments, the Sigfox transmitter and

antenna were placed on the dashboard of the test vehicle as
Fig. 4. End-to-end message transmission time in a CDF chart. illustrated in Fig. 5. The setup does not create optimal antenna
placement but simulates a situation in which the IoT system
is not installed permanently in a vehicle. Experiments were
the message transmission times were within a single standard conducted in southern Finland. The message payload size in
deviation of the average transmission time. the experiments was 8 bytes.
To illustrate the distribution of the message transmission The collected position data were visualized with Qgis soft-
times, a cumulative distribution function (CDF) chart of the ware [22], which enabled us to tag transmission positions
transmission times was drawn. The chart is shown in Fig. 4, based on transmission time. Fig. 6 shows an experiment in
indicating, for example, that at 3 s, about 40% of 1-byte mes- where a car has traveled 260 km, and our system attempted to
sages have arrived. This plot is drawn based on the actual send 19 messages (one message every ten minutes). In the
observed end-to-end transmission times. The connection reli- figure, successful transmissions are indicated with a green
ability in the experiment was found to be excellent, as all marker. The estimated vehicle speed is marked for every
sent the messages arrived successfully at the backend server. attempted transmission.
Out of all messages sent, 89.6% were received by three or Three mobility experiments were conducted for a total of
four base stations. On average, the messages were received 518 km traveled. The routes mostly included rural areas in
by 3.04 base stations. The average Received Signal Strength Southern Finland. These involved a large portion of motorways
Indication (RSSI) value between base stations was found to and other bigger roads. The average speed of the vehicle in
be about −124 dBm. the experiments was 80.3 km/h.
In the experiments, a total of 39 message transmissions
IV. M OBILITY E XPERIMENTS were attempted, eight which were successful, with the delivery
As IoT devices are extensively used in logistics, better times varying from 3.47 s to 7.89 s. This means that in the
understand of the performance of Sigfox technology in mobile experiments, 20.5% of the transmissions were successful. It
setups is also important. Motivated by this, we have carried was also observed that three of the eight successfully received
out a series of tests in which we placed our measurement messages had noticeably higher transmission times than the
system in a car to determine how mobility impacts message average transmission time observed in the static experiments.
delivery times, connection quality, and reliability. During the It was assumed that Sigfox sends messages three times on
experiments the driven route was recorded with a separate separate frequencies, and the first or second transmission is
Global Positioning System (GPS) application with a 1 s res- not received by Sigfox network, accounting for the observed
olution. Route information was combined with the time the result. All the three messages with higher transmission times
messages were sent using timestamps, so we obtained the GPS were received by a single base station. The delay distribu-
coordinates of the transmission locations and calculated the tion of the experiments is presented in Table V. The studies
198 IEEE NETWORKING LETTERS, VOL. 4, NO. 4, DECEMBER 2022

TABLE V
E ND - TO -E ND T RANSMISSION D ELAY IN M OBILITY E XPERIMENTS [4] A. Augustin, J. Yi, T. Clausen, and W. M. Townsley, “A study of LoRa:
Long range & low power networks for the Internet of Things,” Sensors,
vol. 16, no. 9, p. 1466, 2016.
[5] “Sigfox Configuration.” Accessed: Apr. 25, 2022. [Online]. Available:
https://build.sigfox.com
[6] C. Dow and P. Lea, Mastering IoT. London, U.K.: Packt, 2019.
[7] “Sigfox Payload.” Accessed: Jun. 3, 2022. [Online]. Available: https:
//build.sigfox.com/payload
[8] G. G. L. Ribeiro, L. F. D. Lima, L. Oliveira, J. J. P. C. Rodrigues,
C. N. M. Marins, and G. A. B. Marcondes, “An outdoor localization
system based on SigFox,” in Proc. IEEE 87th Veh. Technol. Conf. (VTC
Spring), Jun. 2018, pp. 1–5. [Online]. Available: https://ieeexplore.ieee.
by [8], [11] also reported a significant number of lost messages org/document/8417853/
in mobile experiments, which is consistent with our results. [9] L. Oliveira, J. J. P. C. Rodrigues, S. A. Kozlov, R. A. L. Rabêlo, and
V. Furtado, “Performance assessment of long-range and Sigfox protocols
with mobility support,” Int. J. Commun. Syst., vol. 32, no. 13, Sep. 2019,
V. C ONCLUSION Art. no. e3956. [Online]. Available: https://onlinelibrary.wiley.com/doi/
In this letter we analyzed the Sigfox network as a messaging 10.1002/dac.3956
[10] K. Mikhaylov et al., “Communication performance of a real-life wide-
channel for applications. In the stationary experiments, mes- area low-power network based on Sigfox technology,” in Proc. IEEE Int.
sages were delivered reliably. The typical message delivery Conf. Commun. (ICC), Jun. 2020, pp. 1–6. [Online]. Available: https:
times from a sending device to a server in the Internet varied //ieeexplore.ieee.org/document/9148645/
from 2.5 s to 4.5 s depending on the message size. However, [11] S.-Y. Wang, J.-E. Chang, H. Fan, and Y.-H. Sun, “Performance compar-
isons of NB-IoT, LTE cat-M1, Sigfox, and LoRa moving at high speeds
mobility tests revealed that the message delivery time could be in the air,” in Proc. IEEE Symp. Comput. Commun. (ISCC), Rennes,
notably longer in non-optimal situations. We assumed that this France, Jul. 2020, pp. 1–6. [Online]. Available: https://ieeexplore.ieee.
was due to the design, in which the message is sent three times org/document/9219557/
[12] D. Patel and M. Won, “Experimental study on low power wide area
on different frequencies, and to whether earlier transmission networks (LPWAN) for mobile Internet of Things,” in Proc. IEEE
is lost and later received, causing an increase in end-to-end 85th Veh. Technol. Conf. (VTC Spring), Jun. 2017, pp. 1–5. [Online].
delay. Available: http://ieeexplore.ieee.org/document/8108501/
[13] F. C. de Oliveira, J. J. P. C. Rodrigues, R. A. L. Rabelo, and S. Mumtaz,
In summary, we list what we learned from our experiments “Performance delay comparison in random access procedure for NB-IoT,
in the following: LoRa, and SigFox IoT protocols,” in Proc. IEEE 1st Sustain. Cities
• The typical end-to-end delay, with a static sender and a Latin America Conf. (SCLA), Aug. 2019, pp. 1–6. [Online]. Available:
https://ieeexplore.ieee.org/document/8905443/
server in Internet in semi-urban environment with 8-byte
[14] D. M. Hernandez, G. Peralta, L. Manero, R. Gomez, J. Bilbao, and
message, is less than 3.5 s. Our application server in C. Zubia, “Energy and coverage study of LPWAN schemes for industry
the Internet received 26% of the messages in less than 4.0,” in Proc. IEEE Int. Workshop Electron. Control Meas. Signals Appl.
2.5 s, 62% in less than 3 s, and 88% in less than 3.5 s. Mechatron. (ECMSM), May 2017, pp. 1–6. [Online]. Available: http:
//ieeexplore.ieee.org/document/7945893/
However, there were cases in which delivery took notably [15] B. Al Homssi, A. Al-Hourani, K. G. Chavez, S. Chandrasekharan, and
more time, but these were assumed to be caused by the S. Kandeepan, “Energy-efficient IoT for 5G: A framework for adap-
general nature of Internet traffic. tive power and rate control,” in Proc. 12th Int. Conf. Signal Process.
Commun. Syst. (ICSPCS), Dec. 2018, pp. 1–6. [Online]. Available:
• Message size affects the message transmission time. Each https://ieeexplore.ieee.org/document/8631733/
message is padded to a size of 1, 4, 8, or 12 bytes, which [16] A. Ikpehai, B. Adebisi, and K. Anoh, “Effects of traffic character-
the developer should be aware of. In our experiments, istics on energy consumption of IoT end devices in smart city,” in
Proc. IEEE Global Inf. Infrastruct. Netw. Symp. (GIIS), Thessaloniki,
message size affected the average end-to-end delay to Greece, Oct. 2018, pp. 1–6. [Online]. Available: https://ieeexplore.ieee.
a server in the Internet with respect to message size of org/document/8635744/
3.1 s, 3.5 s, 3.8 s and 4.1 s. [17] J. Tomlain, O. Teren, and J. Tomlain, “Communication technolo-
• Mobility can have a drastic impact on message delivery gies and data exchange possibilities for smart energy solutions,” in
Proc. IEEE New Trends Signal Process. (NTSP), Liptovský Mikuláš,
reliability, as only 20% of the messages were delivered Slovakia, Oct. 2018, pp. 1–6. [Online]. Available: https://ieeexplore.ieee.
successfully in our experiments. However, the results org/document/8524097/
could be different if the antenna was located on the roof [18] Y. Lykov, A. Paniotova, V. Shatalova, and A. Lykova, “Energy effi-
ciency comparison LPWANs: LoRaWAN vs Sigfox,” in Proc. IEEE Int.
or if the experiments were run in an urban environment. Conf. Probl. Infocommun. Sci. Technol. (PIC S T), Kharkiv, Ukraine,
• The user cannot expect that the message is delivered Oct. 2020, pp. 485–490. [Online]. Available: https://ieeexplore.ieee.org/
reliably. The Sigfox network can provide four down- document/9468026/
[19] H. Sallouha, A. Chiumento, S. Rajendran, and S. Pollin, “Localization in
link messages per day, so acknowledging the messages ultra narrow band IoT networks: Design guidelines and tradeoffs,” IEEE
is generally not an option. Internet Things J., vol. 6, no. 6, pp. 9375–9385, Dec. 2019. [Online].
Available: https://ieeexplore.ieee.org/document/8778774/
[20] T. Janssen, M. Aernouts, R. Berkvens, and M. Weyn, “Outdoor finger-
R EFERENCES printing localization using Sigfox,” in Proc. Int. Conf. Indoor Position.
[1] K. Mekki, E. Bajic, F. Chaxel, and F. Meyer, “A comparative study of Indoor Navig. (IPIN), Sep. 2018, pp. 1–6. [Online]. Available: https:
LPWAN technologies for large-scale IoT deployment,” ICT Exp., vol. 5, //ieeexplore.ieee.org/document/8533826/
no. 1, pp. 1–7, 2019. [21] M. Aernouts, B. Bellekens, R. Berkvens, and M. Weyn, “A compari-
[2] “Sigfox.” Accessed: Apr. 25, 2022. [Online]. Available: https://www. son of signal strength localization methods with Sigfox,” in Proc. 15th
sigfox.com/en Workshop Position. Navig. Commun. (WPNC), Oct. 2018, pp. 1–6.
[3] R. Brotzu, P. Aru, M. Fadda, and D. Giusto, “Urban SigFox-based [Online]. Available: https://ieeexplore.ieee.org/document/8555743/
mobility system,” in Proc. IEEE Int. Symp. Broadband Multimedia Syst. [22] “QGIS.” Accessed: Jun. 2, 2022. [Online]. Available: https://www.qgis.
Broadcast. (BMSB), 2021, pp. 1–4. org/en/site/