Implementation of IoT System for Securing
Telecommunications Infrastructure Based on
LoRaWAN Operator's Network
Marko Lj. Jovanovi
Department of Telecommunications, Department of Telecommunications,
School of Electrical Engineering, School of Electrical Engineering,
University of Belgrade University of Belgrade
Telekom Srbija (2nd Affiliation)
Belgrade, Serbia
marexgatuzo@yahoo.com
Abstract—This paper considers a practical IoT (Internet of
Things) solution implemented in a LoRaWAN (Long Range
Wide Area Network) network of the Serbian
telecommunications operator Telekom Srbija. The IoT solution
was developed to secure the operator’s infrastructure located
in manholes and prevent stealing. The paper presents methods
and techniques, which telecommunications operator has used
to incorporate LoRaWAN technology into the existing
IP/MPLS (Internet Protocol/Multi-Protocol Label Switching)
network. The results of this technology implementation are
shown and significance of it is pointed out.
Keywords—base stations, Internet of Things, long range, low
power, LoRaWAN, LPWAN, M2M, radio planning, sensor,
server.
I. INTRODUCTION
The IoT (Internet of Things) refers to the billions of
physical devices around the world which are connected to the
Internet collecting and sharing data. This term is mainly used
for gadgets that would not usually be expected to have an
Internet connection. Therefore, desktop and notebook
computers, or smartphones, would not be considered as the
IoT devices. On the other hand, smartwatch or some other
wearables could be counted as an IoT device. The leader in
network engineering, the company Cisco Systems, predicts
that there will be 500 billion devices connected to the
Internet by 2030. This forecast shows the importance of the
IoT development and a future progress in electronics
(because of the IoT devices development),
telecommunications (because of need for evolving new types
of network and protocols suitable for low energy
consumption) and cloud computing (because of application
services and information about devices that should be always
available for the user).
The Serbian telecommunications operator Telekom Srbija
has faced with a challenge regarding the stealing its
infrastructure. Because of an extensive and widespread
telecommunications infrastructure, this became quite big
issue requiring to be solved in the most efficient way. For
this reason, the operator decided to use LoRaWAN (Long
Range Wide Area Network) to secure its infrastructure. The
paper considers a practical IoT solution implemented in a
LoRaWAN operator's network. It is explained why the
telecommunications operator has chosen this technology and
not any other. It is important to point out that this solution
also served as a pilot project for a future IoT services which
School of Electrical Engineering, University of Belgrade.
 
Mladen Koprivica Nataša Neškovi
Department of Telecommunications,
School of Electrical Engineering,
University of Belgrade
Belgrade, Serbia Belgrade, Serbia
kopra@etf.rs natasha@etf.rs
should be implemented in the upcoming period over the
operator’s network.
The paper is organised as follows. The second section
brings a discussion about LoRaWAN technology and
benefits of using it instead other LPWA (Low Power Wide
Area) technologies. The next section is referred to the
implementation per se. It is divided into three parts, where
are described topology, radio planning and application
services. The following section presents results of LoRa
implementation and its positive outcome. Last section gives
conclusion about LoRaWAN technology and its
implementation.
II. THE NETWORK TECHNOLOGY
With the IoT development, the traditional Internet has
been revolutionized: objects got an opportunity to connect
and communicate through the Internet. Hence, services
outspreaded to machine-to-machine and not only human-
centric services [1]. That implies the possibility of (almost)
every gadget is going to be connected to the Internet.
Comparing the Internet with the IoT [2], a younger brother
has got everything with smaller amount: smaller bandwidth,
less memory, few processing power. That is why the IoT
should avoid using classical Wi-Fi and cellular networks and
turn to something which consumes less energy. Also, many
wireless technologies are short-ranged like Zigbee. Because
of all that, LPWA technologies became very popular. It is
important to distinct two main groups of these technologies.
The first one consists of standards that use a licensed
spectrum, therefore more expensive than rest.
Representatives of these standards are: NB-IoT (Narrow
Band – IoT), LTE-M (Long-Term Evolution – Machine-to-
machine) and EC-GSM (Extended Coverage – Global
System for Mobile communications). On the other hand,
group of LPWA standards which utilize unlicensed spectrum
consist of LoRa (Long Range) and Sigfox technologies.
Not only telecommunications operator does not have to
pay for spectrum utilizing, but the costs of equipment and
LPWA network realization are significantly less. For
instance, price for one LoRa gateway is between $100 and
$1000, while for one NB-IoT base station is needed to get
out of pocket $15000 [3]. But now, there is a question: which
one to use LoRa or Sigfox? Talking about finances, Sigfox
does not allow installing your own base station and are
limited to where the stations are set up. Therefore, operator
has no possibility to use its existing network and yet has to
pay for building a new one because Sigfox technology is not
 
 1
an open protocol. Also, license must be paid even if it used
only peer-to-peer mode; Sigfox subscription is a must. LoRa
allows communication in this mode free of charge and
allows creating one’s own network with user-defined
network coverage. LoRa offers slightly better security
providing AES (Advanced Encryption Standard) encryption.
On the other hand, Sigfox scores longer ranges. Huge
downside of Sigfox technology is very small size of payload
which grants only 12 bytes (with a limited number of
messages per day), while that number is 243 bytes for LoRa.
Also, Sigfox has no option for downlink traffic, unlike to
LoRa [4]. No doubt, that was decisive for Telekom Srbija to
choose LoRa technology, considering that in this particular
project downstream traffic is used for sending ACKs
(acknowledgment messages) from server to sensor. This way
sensor knows that it should stop to retransmit the packet
because server has already got it. Another crucial feature that
triggered this operator to select LoRa is scalability and its
fantastic link budget results, which are better than all other
LPWA technologies [5].
Fig. 1. LoRaWAN stack.
LoRaWAN represents wireless telecommunications
network designed to provide long-distance communication
between end devices with low bitrates [6]. It comes up with
interoperability between the IoT devices without need for
complex set ups including secure bidirectional
communication, mobility and service localization. Typical
architecture contains star-of-stars topology. Usually, range
reaches 15 km in rural environments or 5 km in urban ones.
LoRa defines physical layer which enables long-distance
communication links, and is based on CSS (Chirp Spread
Spectrum) modulation that has feature of low-power
consumption just like FSK (Frequency Shift Keying)
modulation, but with significantly longer range. LoRaWAN
defines MAC (Medium Access Control) layer and
communication protocol (Fig. 1).
In a project related to this paper all devices are class A,
which means there are no latency restrictions and this is the
most energy-efficient class. Class A devices use pure
ALOHA access for the uplink. After sending a frame, class
A device listens for a response during two downlink receive
windows, while downlink transmission is only allowed after
a successful uplink transmission. Practically, sensor responds
with predefined scheduled period known as heartbeat time.
This response (which occurs every 24 hours) helps to
indicate normal operation and to synchronize the system.
During this time a channel is opened for communication,
therefore, it is possible to send message from server to
sensor. As it is earlier mentioned, ACKs are one particular
type of downlink traffic in this case. If ACK does not arrive
2
on a sensor side, sensor will retransmit message 8 times in a
row. If sensor fails to receive an ACK even after these
retransmissions, it will wait 4 hours to repeat the action.
Other type of downlink traffic considers firmware
configuration. When the window is open, whether it is
because of heartbeat or alarm-triggered reason, server has a
possibility to give an instruction to the sensor, i.e. sensor’s
parameters could be changed then. This is very useful
option, because it provides to set up parameters differently
in case they are configured as too sensitive or too robust.
Not only it’s possible to configure temperature, luminosity
or heartbeat time parameters, but there is an opportunity to
set up sensor to function optimally by spreading
optimization with ADR (Adaptive Data Rate). Enabling
ADR, it will automatically select the best SF (Spreading
Factor). SFs are in range of 7 to 12. SF7 is considered the
best one, because it needs less time than other ones for
transmitting the same message, which implies less power
consumption and longer battery life. For instance, SF7 needs
sec. to transmit a message that SF12 transmits for 1.5
sec. Usually, the nearer sensor to radio base station is,
the better SF is going to use. In case the sensor is located
under a double manhole cover, thick concrete, or special
positioning of the buildings, SF7 will not be used, even if
it is near the radio base station. Battery life of sensor is
estimated to last 10 years at least.
III. THE IMPLEMENTATION
A. Topology
This section describes topology of a LoRaWAN solution
used in the network of Telekom Srbija (Fig. 2). Because of its
purpose, which is securing telecommunications infrastructure
inside the manholes, sensors should be installed right under
the manhole cover, so they could detect a manhole cover
opening or an unauthorized person entering, or both. Also,
this device should have such a construction that the
possibility of its vandalization would be at the minimum
level. On the other side, sensor should be as thin as possible,
so it would not affect work on the field. Omniimpex, a
vendor of these sensors, decided to use rounded aluminum
profile with rounded head and flexible tip, or to be more
precise, stainless steel tube in ball bearing because rubber tip
is easy to be destroyed. The sensors send signals to LoRa
gateway(s). This communication could be scheduled or event-
based, as it is described in the previous section.
LoRa gateway is nothing else but a nexus between end
device (that is, sensor) and server. Actually, gateways are
concentrators with a function of transparent bridges
responsible for data transport from end devices (aka. nodes)
to network server. Every end device broadcasts messages
and gateways in its range accept them. One message with the
same content might be received from greater number of
gateways. Network server drops packets with the same
content solving the multiple messaging problem. However, it
is not quite a challenge, considering that the packets arrive at
more than one gateway in less than 10% cases. Unlike to end
devices, communication between gateways is possible.
Because of need for very long range and large coverage
area, related telecommunications operator has chosen to use
Ufispace macro gateway. This gateway model has got two
LoRa antennas, GPS (Global Positioning System) antenna
and LTE antenna. LTE antenna serves to enable a backup
solution for gateway connectivity. If it is not possible to
provide the Ethernet connection, gateway will communicate
through mobile network. Additionally, this gateway model
owns PoE (Power over Ethernet) adapter, which is very
convenient solution to supply gateway with power. For the
purposes of getting coverage as long as possible, antennas
should be installed as high as possible. Furthermore,
antennas must be obstacles free, especially the metal ones.
Signal travels further from gateway(s) to digital units,
which do digitalization of that signal. In this form, signal
arrives at one of two devices, so called TCU (Transmission
Control Unit) or SIU (Site Integration Unit). They represent
devices for “all-IP-zation” of radio base stations. Mentioned
network devices are Ericsson proprietary and act as an
advanced switch or some kind of router, which makes
L3VPN (Layer 3 Virtual Private Network) tunnel to its
superiors in IP/MPLS network, i.e. PE (Provider Edge)
router [7]. Considering the security aspects, this is way more
preferable and sophisticated solution than using the public
Internet, which is the most common method generally.
Fig. 2. LoRaWAN architecture deployed for Telekom Srbija network.
Related interface on PE router ought to be provided with
an appropriate configuration, where VLAN (Virtual Local
Area Network) parameters must match VLAN parameters
configured on TCU or SIU device. Additionally, interface
VLAN should be configured on PE router, if we want to
ensure sensors management. From this point, connection
between a network and an application server is provided with
static route that directs packet to its final destination. More
about application layer will be described in subsection C.
B. Radio Planning
Radio planning is the key step in creating a stable
LoRaWAN network or any other wireless network. First of
all, it is important to perceive characteristics of the
environment. In this particular case study, terrain is mostly
plain landscape, but there is a critical area near the river
which is quite densely populated with a lot of buildings.
3
The first prediction, made by Actility, has been done with
software tool LoRa Air Interface Dimensioning. This
prediction disregards the exact terrain configuration. Instead,
it uses antenna’s location height and an average attenuation
for every type of environment to predict the appropriate radio
planning. By default, there are four environment types, but
only three are used in this case study (Fig. 3): urban (red
zone with tall buildings, usually located in downtown),
suburban (blue zone with smaller buildings or blocks of them
separated with wide streets, industrial areas), rural (green
wide area with scattered houses and lots of field and forest).
Talking about the outdoor coverage, there is no problem
for whole this area. According to this calculus, four gateways
are enough to make good signal strength through the selected
zones (Fig. 4). Reason for that lays in installed antennas on
very high locations: sites 1, 6 and 8. Challenge here would be
to provide such a good signal strength under the ground, i.e.
under the manhole covers with as less as possible gateways.
It is obvious that mentioned four gateways are not enough.
Adding nine more gateways and keeping the same
parameters results with not-so-brilliant manhole coverage
(Fig. 5). Causes of such outcome are manhole covers, which
contribute with large attenuation (roughly ~ 20 dB). Because
of that, there is a need for repetition per message, which
means there should be one more transceiver. Consequently, it
will compensate the loss and enable manhole coverage with
minimal number of gateways (Fig. 6).
Fig. 3. Terrein morphology map with zones for LoRa coverage.
Fig. 4. Outdoor coverage with LoRa signal (sideview).
Ideally, LoRa antenna should be at least 3 meters above
cellular antenna or 10 meters further in horizontal plane. If
isolation cannot be accomplished by spacing, there must be
used cavity filter between antenna and gateway. This filter TABLE I. SITE LOCATIONS
represents resonant circuit for frequency filtering. According Site ID Code Priority Comment
to this prediction, 12 gateways are required to cover all
manholes from the zones at the Fig. 3 (TABLE I). 1 BG1 1 Outdoor coverage
2 BG2 1 Outdoor coverage

3 BG3 3 Outdoor redundancy

4 BG4 2 Manhole coverage

5 BG5 2 Manhole coverage

6 BG6 1 Outdoor coverage
7 BG7 2 Manhole coverage

8 BG8 1 Outdoor coverage

9 BG9 3 Outdoor redundancy
Fig. 5. Manhole coverage with one transceiver (sideview). 10 BG10 Not needed Not used, whatever the target
11 BG11 Not needed Not used, whatever the target
12 BG12 Not needed Not used, whatever the target

13 BG13 4 Manhole redundancy

14 BG14 2 Manhole coverage

15 BG15 2 Manhole coverage

The second radio planning calculus has been done by

Fig. 6. Manhole coverage with two transceivers (sideview).
Telekom Srbija. This time is used more powerful software,
Telko, which considers actual terrain configuration and
occurrences such are reflection or refraction. With this
prediction model, manhole coverage is determined more
precisely (Fig. 7), where is also calculated the lowest
possible signal level which is -105 dBm (blue color). Green
color represents area with the strongest signal level, i.e. in
range [-90, 0] dBm. The final prediction recommends exactly
30 gateways to secure ideal manhole coverage, which is way
more than the first one prediction model.

C. Application
Application server provides application services to an
end device, or to be more precise, a user of the end device.
This server manages application layer of LoRaWAN stack
and handles payloads received from nodes. Also, it serves as
data storage. Packets are arriving to mentioned server via
static route from relevant router in the IP/MPLS network.
Users can access software platform on the application server.
All they need to do is to type appropriate URL (Uniform
Fig. 7. Telko radio planning. Resource Locator). Subsequently, they will be asked for their

Fig. 8. Viewing sensor logs at the subscriber tab

4
credentials. After logging in, there will be shown a home Similarly, task was accomplished and had positive outcome
page with operator, supplier and vendor tabs. Firstly, it is (TABLE II). Of course that RSSI (Received Signal Strength
essential to add an administrator user at the operator tab. This Indicator) and SNR (Signal to Noise Ratio) parameters
way it is enabled for the user to handle all introduced tabs. scored here better results than during the drive test, because
Supplier tab contains information of base stations and mobility and velocity put obvious impact on it.
manhole sensors. Some of these pieces of information are:
base station ID, address and type of base station, connection
TABLE II. RESULTS OF WALK AND DRIVE TESTS (PART OF THEM)
method, server visibility, CPU (Central Processing Unit) and
RAM (Random Access Memory) usage, uplink/downlink NBr
RSSI SNR RSSI SNR
Gateway ID
traffic. User may view base stations on a map or sort them in (walk) (walk) (drive) (drive)
the list. It is possible to set GPS coordinates manually on the 1 -69 9.25 -111 -3.5 00000524
map or set them more precisely on LRC (LoRa Controller) 2 -81 10.25 -110 -1 00000524
after accessing to the mentioned controller. Vendor tab 3 -73 10.75 -113 -6.5 000005C7
defines subscribers and end users, and orders of theirs. 4 -91 8.75 -93 -4.5 00000524
5 -80 9 -111 -1.5 00000524
Subscribers manage the sensors and sensor logs (Fig. 8). 6 -98 7.75 -108 1.75 000005C7
7 -85 8.25 -109 -0.25 00000524
8 -86 9.75 -110 -4.5 000004C1
IV. TEST RESULTS 9 -97 7.25 -115 -7.75 00000524
10 -111 0.75 -111 -0.25 000004C1
When the implementation is finished, next step is to test 11 -106 4.25 -105 6.5 000004C1
an operability of all services. LoRa network coverage test 12 -100 4.75 -115 1 000004C1
results are shown in this section. Tests were carried out with
two of modes: as drive test and as walk test. A device that
served for the testing purposes was Adeuinis Field Test C. CPU, RF and WAN parameters tests
which imparts maximal range 15 km. Other features are:
This section reviews the results of testing base station
superb battery autonomy, very precise GPS signal, support
parameters. It is very useful, because these results can show
for accelerometer, LoRaWAN v1.0 interoperability [7].
a health and a status of base station, thus, warn an amenable
person when there is a need for some changes.

Fig. 10. CPU usage of one base station.

Fig. 9. Map with drive testing path.

A. Drive tests
Base Station was up and correctly provisioned through
GUI (Graphical User Interface). There was one LoRaWAN Fig. 11. Duty cycles for upstream and downstream of one base station.
demonstrator device connected and correctly provisioned
through GUI (Adeunis Test Field Device), with a
connectivity plan that lock the SF to SF12. This means that
each bit was encoded into 4096 (27) chirps [8], a signal that
constantly made frequency variations. It indicated lower
physical bitrate reaching only 250 b/s and longer time on air
(1318.9 ms). Drive test was performed in the area of PoC
(Proof of Concept) LoRaWAN network [9] (Fig. 9). After
logging in on the application platform as a subscriber, a goal
was to verify that gateways and test device can be located Fig. 12. Sent/Received packets of one base station.
and viewable on the map. LoRaWAN network coverage was
verified (TABLE II) and this test was marked as passed. One of four LoRa gateways (base stations) with priority 1
from section II. B. has been examined to numerous tests.
B. Walk Tests CPU test shows that there was no heavy system processes
Expectation for this kind of test was to prove a visibility considering that an average usage is 5% and the maximum
between test device and gateways through the whole trace. scores only 36% (Fig. 10). Next test deals with uplink and

5
downlink traffic. It shows that there was low downlink traffic
(Fig. 11). Last presented test in this text (Fig. 12) clarifies
that there were more sent than received packets, which is
logically because gateway sends to sensors and server, both.
V. OUTCOME OF THE IMPLEMENTATION AND ITS BENEFITS
After the implementation and successful tests, it was time
to get some statistics about real-life results, not only ones
scored in “laboratory environment”. LoRaWAN has been
officially put into operation for Telekom Srbija network at
the end of September 2018. Here is going to be presented
statistics for October and November, 2018.
Fig. 13. Graph with generated alarms submitted by categories.
Fig. 14. Graph with generated critical alarms by months.
Fig. 15. Graph with trend of critical alarms.
As it can be seen (Fig. 13), many attempts are noted to
break in manhole and steal the infrastructure. Basically,
every October day has got an average of 10 unauthorized
break-ins, while that number decreased in November by
32%. There was almost the same amount of false positives in
these two months. It is interesting that mentioned illegal
actions were more often during the working days (average
11.7 per day) than during the weekends (average 5.13 per
day) in October, while these difference was drastically
reduced in November (daily 7.45-5 in favor of working
days). It looks like thieves wanted to play on a card of non-
working days. Also, a number of potential threats is lowered
by one third in November. Very important fact is break-ins
diminishing in the following month (Fig. 14). Almost every
day in November has got less generated critical alarms
comparing to October; the exception is a tail of November.
There has been a total of 408 generated alarms in October
and that number is reduced to 274 ones in November, what is
a very decent score. It is possible to view on the next graph
(Fig. 15) a trend line (median line marked with red color)
that falls down, which proves an indication of decreasing in
the infrastructure stealing attempts. During these two
months, three persons are arrested and convicted for stealing.
This is a good indicator that LoRa was a good choice for this
case study.
VI. CONCLUSION
This paper has pointed the importance of the IoT and
M2M technologies stating differences between them and
explaining their purposes. Choice for LoRa of related
telecommunications operator does not mean other LPWA
technologies are not enough good, nor inappropriate. On the
contrary, all of them own features that could be used for the
mater of interest, whether it is bitrate, latency, distance, etc.
For example, Sigfox could have been easily set up instead
LoRa, if the operator had got the will for implementing that
kind of network. Anyway, LoRa represented itself in a good
light securing manholes and providing expected solution. A
problem with the infrastructure stealing is finally solved
thanks to this technology.
ACKNOWLEDGMENT
The authors would like to thank to Telekom Srbija and all
its partners for allowing this paper to be published.
REFERENCES
[1] O. Khutsoane, B. Isong, A. M. Abu-Mahfouz, “IoT Devices and
Applications based on LoRa/LoRaWAN”, IECON 2017 – 43rd
Annual Conference of the IEEE Industrial Electronics Society, South
Africa, 2017.
[2] A. Augustin, J. Yi, T. Clausen, W. M. Townsley, “A Study of LoRa:
Long Range & Low Power Networks for the Internet of Things”,
Sensors, Vol. 16, Issue 9, 2016. https://doi.org/10.3390/s16091466.
[3] R. S. Sinha, Y. Wei, S. Hwang, “A survey on LPWA technology:
LoRa and NB-IoT”, ICT Express, Vol. 3, Issue 1, pp. 14-21, 2017.
[4] K. Mekki, E. Bajic, F. Chaxel, F. Meyer “A comparative study of
LPWAN technologies for large-scale IoT deployment”, ICT Express,
Article in Press, 2018. DOI: 10.1016/j.icte.2017.12.005.
[5] D. Sjostrom, “Unlicensed and licensed low-power wide area
networks: Exploring the candidates for massive IoT”, Master’s
Thesis, KTH Royal Institute of Technology, School of Information
and Communication Technology (ICT), Stockholm, Sweden,
September 2017.
[6] M. A. Alereqi, F. N. Al-Wesabi, A. T. Zahary, M. N. Ali, “A Survey
of Internet of Things Services Provision by Telecom Operators”, EAI
Endorsed Transactions on Internet of Things, Vol. 4, Issue 13, 2018.
[7] Telekom Srbija, ThingPark Wireless, “Technical Solution – LPWAN
RFP”, September 2017, unpublished.
[8] N. Blenn, F. Kuipers, “LoRaWAN in the Wild: Measurements from
The Things Network”, 2017, https://arxiv.org/pdf/1706.03086.pdf
[9] Telekom Srbija, Actility, Teri Engineering, Bitgear, "Telekom Serbia
IoT Project - Interoperability PoC Test Results V1.33", December
2017, unpublished.