Performance Evaluation of the LoRa Protocol in the context of Smart Meter

by   Muhammad Nouman Rafi, et al.
Universitetet Agder

In recent years, the use of Low Power Wide Area Network (LPWAN) is increasing for the Internet of Things (IoT) applications. In order to demonstrate the application of LPWAN technologies for a realistic smart metering scenario, we set-up and implement a widely used LPWAN protocol which is called LoRaWAN. In this study, the LoRaWAN is implemented by using Multitech devices (end-node and gateway) and the performance of the network is evaluated for different physical (e.g. location, distance etc.) and link parameters (e.g. data rate, transmission power etc.), under the European regulations. To evaluate the performance of the networks, we collected uplink packets in different indoor and outdoor scenarios at various locations. Our results show that LoRaWAN is easy to setup, configurable, scalable, and it performs well for real-time smart metering applications. Moreover, it is necessary to evaluate the physical conditions for the selection of the available system parameters for deploying a robust LoRaWAN network.



There are no comments yet.



A Reliable Communication Framework and Its Use in Internet of Things (IoT)

Peoples are naturally communicators but devices are not. In the Internet...

Long Range Wide Area Network: A Simulation Module for ns-3

Long Range (LoRa) is a wireless communication technology for the Interne...

BLE Beacons in the Smart City: Applications, Challenges, and Research Opportunities

The Internet of Things helps to have every individual interconnected wit...

Experimental study of link quality in IEEE 802.15. 4 using Z1 Motes

In low-power low-rate wireless networks, IEEE 802.15.4 is a standard pro...

A Reproducible Comparison of RSSI Fingerprinting Localization Methods Using LoRaWAN

The use of fingerprinting localization techniques in outdoor IoT setting...

Secure Data Timestamping in Synchronization-Free LoRaWAN

Low-power wide-area network technologies such as LoRaWAN are important f...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Nowadays, in many countries, traditional electromechanical utility meters are being replaced with smart meters [1, 2]. A smart meter (whether it is for electricity, gas, or water) is an electronic device that records the consumption of the utility and reports it back to the utility provider in a secure fashion. Furthermore, smart meters allow amr and ami to offer a multitude of benefits to both consumers and utility providers [3]. For instance, smart meters combined with in-home displays could provide consumers with real-time utility consumption information, thus giving them a better control over their utility spending and potentially contributing towards utility savings. Similarly, by analyzing the utility consumption behavior of consumers, utility providers can not only well manage the utility distribution network, but they can also monitor it in real time. Moreover, they are also cheap and report more accurate consumption [4]. Due to these benefits, the roll-out of smart meters is increasing rapidly. Until 2020, the European Union (EU) expects that almost 72% of the European consumers will have smart meters for electricity and 40% will have smart gas meters [5]. Counties in EU, like Austria, will have 95% of the smart meters rolled-out by 2020 [5].

For smart metering connectivity, cellular technologies are widely used in Europe and they fulfill the metering system requirements [6]. But these technologies are costly and have limited battery life. Whereas, other connectivity options for smart metering are plc, Ethernet, Wi-Fi, and Bluetooth. However, these technologies don’t offer long range connectivity [7]. Therefore, to meet the massive target of smart meter roll out and to deal with the connectivity issues, utility providers need to find a better alternative which is more reliable and cost effective.

Recently, a new wireless communication technology called lpwan has emerged. lpwan describes a class of wireless communication technologies which are designed for long range communication between things (connected objects) at the cost of low bit rate. Therefore, it fulfills the requirements for smart metering applications [2]. Whereas, the traditional technology networks (e.g. Cellular and plc) until now are still less favorable for transmitting short messages occasionally over a long range in a cost effective manner [8]. Fortunately, the AMI for smart meters allows integrating the lpwan technologies. Over the last five years, several proprietary and open standard lpwan technologies have been introduced in licensed and unlicensed frequency bandwidth. Among the available lpwan technologies, LoRaTM, Sigfox, and NB-IoT are the market leaders and widely used. LoRaTM and Sigfox are better in terms of cost, network capacity, and battery life-time. Meanwhile, NB-IoT offers better Quality of Service (QoS) and low latency [9]. Since its inception, LoRaTM has seen an exponential growth even though the technology is still in its beginning, it is the most adapted technology for the iot applications [10]. Therefore, in this article, we will evaluate the performance of the LoRaTM protocol under different conditions in the context of smart meter by setting up a LoRaWAN with real hardware under European regulations. The results obtained from this study can be used for better integration of the technology for smart metering applications.

Rest of the article is organized as follows, section II presents a brief overview of various other studies in which researchers have evaluated the LoRaTM protocol for different applications. A detailed overview of the LoRaTM protocol, LoRaWAN architecture, LoRaWAN end node classes, LoRaWAN security, and the European regulations are given in section III. An overview of our LoRaWAN setup and application to generate and transmit smart metering data is given in section IV. Results of the indoor and outdoor evaluations of the LoRaTM protocol are given in sections V and VI, respectively. Finally, the conclusion of this study is given in section VII.

Ii Related Work

There exist various parameters in a LoRaWAN, which need to be taken into consideration while evaluating the performance of LoRaWAN. For instance, in [11], authors studied the outdoor range of the LoRaWAN. The experiment was performed in Germany with 250 KHz bandwidth and they recorded per, snr, and rssi for different distances with 10, 50 and 100 bytes of payload length. Obtained results showed that with a payload of 10 bytes, the packets are successfully delivered with zero per up to 8 km. However, the per increases with the increase of the payload. The payload of 50 bytes resulted in invalid packets from the range of 2.3 km and with a payload of 100 bytes, the per was near zero for up to 6 km. This study was conducted by using 250 KHz bandwidth for channels, whereas, LoRaWAN typically uses 125 KHz bandwidth for the channels.

In [12], the troughs water level is monitored by using LoRaWAN with 915 MHz band. Their outdoor experiment results show that the location of the end-nodes has a major impact on the network performance. Additionally, the quality of transmission is poor, when end-nodes are placed closer to the ground. Their simulated results of 100 nodes networks showed that increasing the dr of 5 nodes within the network, the delivery of valid packets drops by 17%. The experiment was done in the ism band of the USA, which does not have the same regulation like the ism band of EU (in USA band, there is no duty cycle limitation).

Wixted et al. [13] performed an outdoor evaluation of LoRaWAN and LoRaTM using three gateways in Glasgow. Outdoor testing documented rssi, GPS location, and reliability of receiving the ack after transmitting. Reliability testing showed that cellular connections of gateways experience disconnected periods, because of inactive policies of the cellular networks. Continuously pinging the gateways increased the connectivity rate of LoRaWAN from 70 to 95%. A coverage range test was also conducted with two LoRaTM transceivers. In one direction, connectivity test was successful till 2.2 km and in the other direction, the range was 1.6 km due to a hill between the end-node and gateway. [13].

Another study [14] was conducted in Finland in order to check the LoRaTM range capabilities by using a mobile end-node (boat and car). The rssi values, packet loss, and GPS location were recorded up-to 30 Km. The end-node had a dr 0, while transmission power was fixed to 14 dBm. The measurement results of the car showed that within the range of 2 km from the gateway or base station, the rssi value was mostly greater than -100 dBm and 12% transmitted packets were lost. The packets lost were increased with the increase of distance from the gateway. whereas in the boat, 15% of the packets were lost within the range of 2–5 km. Lastly, path loss exponents were also measured for the car and boat.

In [15], the authors evaluated the coverage range of LoRaTM network for different drs. The gateway was located at the top of a tall building (19 floors) with antenna gain 0. The packets ware received up-to 2 km, but the authors felt that the range should be assumed 1.2 km due to variations in the link budget.

The researchers of [16] tested the network range of LoRaTM in the urban area of Paris, France. During the test, transmission power was fixed to 14 dBm and vary the dr 0, 3 and 5. The maximum range was achieved with a dr 0 up-to 3.4 km and 38% packets were delivered. However, the closest location (650 m) of the test revealed that with a dr 0, 100% of the packets can be delivered and this value drops to 84% when a dr 5 is used. During the test, the ack was disabled.

An indoor LoRaTM network deployment evaluates the indoor performance of LoRaWAN[17]. Tests results show that due to EU limitation of the duty cycle, with dr 0 and with a maximum size of the packet, an end-node should wait for approximately 4 minutes and 30 sec before generating a new transmission. Even with no data in dr 0, an end-node waits for 2 minutes between consecutive transmissions. On the other side, with dr 5 or sf 7, the delay is minimized to 2 seconds. Also, their results show that rssi values are not changed by changing the dr, but the snr values are changed. The transmission test was repeated with a dr 2 and found that if the end-nodes are near to the gateway, then packets duplications and bad crc packets were increased [17].

Another study [18] was conducted in Prague for an indoor penetration of LoRaWAN signal. In this study, an end-node was placed in different locations and floors inside the building and recorded the end-nodes rssi values. The gateway was placed on the rooftop. For each location, 10 packets were sent with a larger payload, which contains information of snr and rssi etc. Tests were performed with IMST iU880A LoRaTM node, which does not have an external antenna feature. The power was fixed at 20 dBm. The authors concluded the result from recorded rssi that the gateway placing on the rooftop provides more coverage range as compare to the basements.

In [16], the authors study the signal strength levels for message packets, which were transmitted from an end-node to the gateway. The end-node was located outdoors and the gateway was located indoors. In this experiment, the transmission power was fixed at 2 dBm. The results of the experiment show that the maximum coverage range is 100 m. while rssi didn’t decrease with the increase of sf. It was also noted that decrease in the rssi value had increased the snr.

The authors analyzed the LoRaWAN capacity limits for smart metering applications using the network simulator for both the uplink communication and downlink communication in [8]. The results showed that, for a case where smart meters are located deep indoor, the network covering 17 km of an area with 19 gateways, which will be located 1 km from each other. It could be sufficient for achieving 98% quality of service if considering only uplink communication. On the other hand, if both the uplink communication and downlink communication are taken into consideration, the network capacity will dramatically decrease.

Fig. 1: LoRaWAN network architecture [19].

Iii LoRa and LoRaWAN

LoRaTM is the phy protocol designed and implemented by It operates in unlicensed sub-GHz ism bands (i.e. 868 MHz in Europe, 915 MHz in North America, and 433 MHz in Asia.), and it is based on css modulation technique [19, 20]. Like the fsk modulation technique, the css modulation technique maintains the same low power characteristics, but it has an increased wireless communication range [21].

There exist various parameters in the LoRaTM modulation technique like spreading factors (SF7 to SF12), channel bandwidth, and coding rate (CR). These parameters can be used to adapt the data rate and range trade off. For instance, a low spreading factor allows a short range communication link but offers high data rate, whereas, a high spreading factor offers a long range communication link at the cost of low data rate. The data rate of the LoRaTMprotocol is between 300 bps and 5000 bps. Further, messages transmitted using different spreading factors are practically orthogonal to each other, therefore, they do not affect each other, thus they can be received simultaneously by a LoRaTM gateway [19, 21].

The main advantage of LoRaTM is long range. A base station or the single gateway can cover several kilometers of distance. The range highly depends upon the obstructions or environment of the location, but LoRaTM offers a greater link budget compared to other wireless communication technologies. The maximum link budget of LoRaTM is 157 db [21].

In 2015, a LoRaTM protocol based wireless communication network called “Long Range Wide Area Network” LoRaWAN was created by the LoRaTM alliance in cooperation with IBM, Semtech, Microchip, and Actility [22]. LoRaWAN defines the wireless communication protocol and the architecture of the network. The architecture of the network and the protocol have the most impact on determining the capacity of the network, battery life of the node, service quality, and security [19].

Iii-a LoRaWAN Architecture

The overall LoRaWAN consists of 4 blocks: an end-node, a gateway, a network server, and an application server, as shown in Fig. 1. LoRaWAN is normally laid out in a star topology in which end-nodes are connected with a single or multiple gateways via the single-hop LoRaTM link [22].

End-nodes form the base of the LoRaWAN, they are low power sensors or actuators that send a small amount of data to the network server via a concentrator/gateway. A gateway is connected to a public or private network server via standard ip (either Ethernet, wifi, satellite or cellular). In LoRaWAN, end-nodes or motes are not required to send data to a particular gateway, but the end-node broadcasts its data to every gateway within the network. The gateway acts as a bridge and sends packets to the network server by adding additional information about the quality of the packets [19].

The network server filters unwanted and duplicate packets and replies to the end-nodes through certain in-range gateways. Communication in the LoRaTM network is bi-directional. Communication from an end-node to the network server via a gateway is called uplink communication and its vise versa is called downlink communication. The network server has information for every node in the entire network, so it knows specifically where to send the downlink packets. The network server manages the whole network and the adr mode can automatically manage the sf for all end-nodes with the adr scheme [23, 15]. Finally, the application server is responsible for the end-node “inventory” part of the LoRaWAN, handling join-requests and decryption of application payloads.

Iii-B LoRaWAN End-node Classes

LoRaWAN defines three different classes of end-nodes (i.e. Class A, Class B, and Class C) to support a variety of iot applications [9]. All these classes of end-nodes allow bidirectional communication, however, the basic difference is in their downlink communication.

For instance, in Class A, every uplink transmission is pursued by two short time receive windows for the downlink communication [22]. A class A type end-node is used for low power actuators or sensors without latency constraint. Mostly, this type of end-nodes are used to measure the temperature, the metering data, and for the tracking etc.

A Class B type end-node opens extra receive windows for the downlink communication compared to a Class A type end-node. Receive windows in Class B end-nodes are opened at scheduled times [22]. In order to schedule a receive window to open, the end-node receives a time synchronized beacon from the gateway, allowing the network server to determine when the end-node is listening. These type of end-nodes can be most useful for battery devices like controlled reading with sensors and alarm sensors etc.

Class C type of end-nodes continuously listen for downlink transmission after uplink transmission [22]. End-node of class C consumes more power than class A and class B, but the latency rate is lower for communication between the server and the end-node.

Iii-C LoRaWAN Network Security

Security is a major prerequisite in every wireless communication network. The same security prerequisite has also been planned for the LoRaWAN network. To personalize the end nodes in LoRaWAN network, every end-node is customized with an aes-128 bit appkey and deveui based on IEEE EUI-64. The appkey and deveui are obtained from the network server [24].

Numerous properties are strengthened to guarantee the LoRaWAN security, for example, integrity protection and mutual authentication. Mutual authentication is set up in the network security section between end-node and the network server. This authentication guarantees that only recognized end-node can join the network [22]. Consequently, two security keys are determined, the first nwkskey is used for mac protection and the second appskey is used for end-to-end encryption of the payload. nwkskey is shared in the network which is in between the node and the network server in order to authenticate LoRaTM message packet. Whereas, appskey is shared in the application layer between the node and the application server to encrypt and decrypt the application payload [24, 25].

Fig. 2 demonstrates the two keys that are used for authentication and encryption in the network server and the application server [24]. Both session keys (nwkskey and appskey are unique for every end-node, and for every session. End-nodes can either join the network dynamically (Over the Air Activation (OTAA)) or statically (Activation by Personalization (ABP)) [24]. In the case of dynamic activation, both session keys are regenerated every time an end node joins the network by using the appkey. In the case of static activation, both session keys stay the same until one manually changes them.

Fig. 2: Authentication and encryption in LoRaTM network.
Fig. 3: A 96 bytes smart meter datagram for SFs 6, 7, and 8.
(a) First packet
(b) Second packet
Fig. 4: Two 51 bytes smart meter datagrams for SFs 9, 10, and 11.

Iii-D European Regulation

Although the LoRaTM protocol operates in unlicensed frequency bandwidth, there are some regulations to use the LoRaTM network. These regulations may vary from region to region and are set at the following three levels [26]:

  1. at the national level,

  2. at the European (EU) level, which is set by the European Commission,

  3. at the global level, which is set by the itu.

For instance, in the EU region, the LoRaWAN operates in 863-870 MHz unlicensed frequency band and according to the etsi, three sub-GHz channels 868.1 MHz, 868.3 and 868.5 must be used in LoRaWAN [27, 28]. The duty cycle and erp limitation are shown in Table I [28, 29].

Frequency BW Duty Cycle Max ERP
868.1 125 kHz 1% 14 dBm
868.3 125 kHz 1% 14 dBm
868.5 125 kHz 1% 14 dBm
868.85 125 kHz 0.1% 14 dBm
869.05 125 kHz 0.1% 14 dBm
869.525 125 kHz 10% 27 dBm
TABLE I: Limitation of LoRaWAN channels [27, 26].

Iv System Setup

This study is aimed to evaluate the performance of the LoRaTM protocol for smart metering application under the guidance of European regulations using real hardware. Therefore, we explain the hardware and software details of our LoRaWAN setup.

The architecture of our LoRaWAN consists of a MultiConnect mDot222 (end-node), a MultiConnect conduit gateway333 , an open source and public network called “”. ttn gives us a network server as well as all the components which are required for coupling all the devices [30], as shown in Fig. 5. In the first step, both end-node and gateway are configured to connect and communicate with each through the LoRaTM physical layer. After that, both end-node and gateway are set up with ttn console.

Fig. 5: Block diagram of our LoRaWAN setup.

To capture the uplink packets, a Node.js application is created with the help of Node.js Application SDK for the ttn. This applications is nothing but a logger. It connects to the ttn by using the ttn application access key and after connecting it stores uplink packets with their metadata in a local database in format.

Iv-a Application for end-node to generate the dummy data

In our LoRaWAN setup, the end-node (mDot) acts as a smart meter. The smart metering application requires 96 bytes to transmit the data as shown in Fig. 3. For testing a smart metering scenario, a C++ application is developed for end-node by using Multitech The end-node uses this application for transmitting data packets to the gateway and ttn application. The end-node periodically transmits the LoRaTM physical payload frames of 109 bytes for sf 7, 8, 9 (dr 5, 4, 3) and 64 bytes for sf 10, 11, and 12 (dr 2, 1, 0), respectively.

For sf 7, 8, and 9, a 96 bytes dummy payload is used whereas a 51 bytes dummy payload is used for the last three sfs, which is the maximum allowed payload for sfs 10, 11, and 12. Therefore, for the last three sfs, the end-node application divides the 96 bytes data packet into two 51 bytes data packets as shown in Fig. 4 and sequentially transmits them. The ttn application combines these two 51 bytes packets to a single 96 bytes packet by using the packet identifier field once received by the ttn network server. The remaining 13 bytes for all sfs were for other fields of physical payload in the frame. These fields are mhdr (1 byte), mac Payload (8 bytes) and a mic (4 bytes).

V Results of the Indoor evaluation of the LoRaTm protocol

For indoor testing, we selected the Science Park 3 building, located in the Johannes Kepler of Linz, Austria. The infrastructure of this building is made of steel and hard concrete, and it consists of 9 floors including the basement. The dimensions of the building are as follows, the length is 84 m, width is 21.5 m including walls and the height is 27.5 m including the basement. We are using MultiTech products. MultiTech claims deep penetration of signal inside the building and we are using an isotropic antenna. So, we placed our MultiTech gateway in the middle of the building on the 2 floor and selected 9 different positions in the building at different floors and locations. The location of the gateway and different positions, where end-node was placed inside the building are shown in Fig. 6.

Fig. 6: Indoor location of the gateway and different end-node positions.
Fig. 7: Wait time for different payloads at 1% duty cycle.
Fig. 8: Total data sent per day for different DR and payloads at 1% duty cycle.

At each position, we recorded data for 6 hours (1-hour for each sf (sf7–sf12)). Altogether, we recorded data for 54 hours for our indoor scenario. Moreover, we have also performed the following tests for our indoor scenario. These tests were performed at different time and days.

  • Limitation of Sub-Band/channel Utilization.

  • Received Signal Strength Indication (RSSI).

  • Signal-to-Noise Ratio (SNR).

  • Packet Error Rate (PER).

  • LoRaTM network capacity.

  • Impact of different LoRaWAN classes on Acknowledgment (ACK).

V-a Limitation of Sub-Band/Channel Utilization

Due to the limitation of sub-band/channel utilization of 1% from the European regulation, the end-node must wait for a sufficient amount of time between two consecutive transmissions. It means that the end-node can only use 1% of the total time to transmit data on the sub-band. Different drs and frame sizes can take different toa for transmission.

Fig. 7 shows the wait time after packet transmission for each dr and payload size.

From Fig. 7, it can be observed that with dr 0 or sf 12 and with a maximum size of the packet, an end-node should wait for approximately 4 minutes and 30 sec before generating new transmission. Even with no data in dr 0, the end-node waits for 2 minutes between consecutive transmissions. On the other side, with dr 5 or sf 7, the delay is minimized to 2 seconds. According to the application needs of smart metering, the dr should be selected carefully in order to increase the scalability of the network.

Fig. 8 illustrates the maximum amount of data an end-node can send per day over a single channel with 1% duty cycle. We can see that the amount of data in dr 0 is limited. However, in dr 5, we can exchange data up to 550 kilobytes per day. As an outcome, dr 5 seems more suitable for sensitive applications. After all, the different drs help to decrease collision between various end-nodes. Fig. 7 and 8 represent the limitation of the LoRaTM network. The performance of the LoRaTM network can be increased by increasing the number of channels or increasing the duty cycle.

V-B Received Signal Strength Indication (RSSI)

rssi is a very important parameter for wireless communication. This parameter indicates the signal strength received by the antenna after cable losses in wireless communication. Since rssi indicates the level of power, the signal is the strongest when the value of rssi is the highest. Usually, the rssi value is represented in negative form so an rssi value close to 0 indicates better signal strength. rssi normally depends on the distance, transmission power, and antenna gain [31]. We performed various tests in order to evaluate the behavior of rssi in the entire network. For each test, one hour of readings were acquired of the parameters being tested.

V-B1 Impact on RSSI by changing the transmission power

The end-node (mDot) allows a range of transmission power from 1 dBm to 30 dBm. However, European regulation allows maximum transmission power up to 14 dB in the LoRaTM network. Therefore, for testing purposes, the range from 1 dBm to 14 dBm was used. This test was performed with a fixed dr of dr 5 and the gain was fixed to 3 dBi. All readings were taken at the same location. The x-axis represents the transmission power. Fig. 9 shows the behavior of rssi with the change in transmission power. The colored portion in each box represents 25% to 75% of values of rssi. The outside whiskers show the complete range of the values. The mean value is represented by the clear square and the median is represented inside each box as a thick line. The outlying values are shown by the diamond shape.

A clear trend can be observed that the signal strength increases with the increase in transmission power.

Fig. 9: RSSI values by changing the transmission power.
Fig. 10: RSSI values by changing the gain.

V-B2 Impact on RSSI by changing the gain

The end-node (mDot) allows a gain of -128 dBi to 127 dBi. For this test, dr and transmission power was fixed at dr 5 and at 14 dBm respectively. All the readings were taken at the same location. The x-axis represents the value of gain used for testing. Fig. 10 shows that 3 dBi gain has the strongest signal because with isotropic antenna and 3 dBi gain the signal is transmitted in all directions. It can be observed that the rssi values decrease with either the increased or decrease in gain from 3 dBi. This occurs because, with the increase or decrease of gain from 3 dBi, the signal is transmitted in a particular direction. Thus, the conclusion can be reached that 3 dBi gain should be recommended for use in LoRaWAN.

V-B3 Impact on RSSI by changing the DR in the same location

This test was performed with different drs. During this test, transmission power was fixed (14 dBm) and also antenna gain was fixed (3 dBi).

Fig. 11: RSSI values measured on the 2 floor at 42 meters distance from the gateway.

Fig. 11 shows the rssi values measured for each dr at 42 meters distance from the gateway on the same floor. dr is represented on the x-axis ranging from dr 5 to dr 0. From Fig. 12, the rssi values for all drs are almost same. The values of rssi for different drs are in between -80 dBm to -90 dBm. Further, it can be observed that the different dr does not have an impact on rssi.

So higher drs would be preferable in order to achieve better performance regarding latency and bit rate without losing the indoor long range coverage for metering applications.

V-B4 Impact on RSSI by changing the DR at left and right side from the gateway on the same floor

Again for this test, transmission power was fixed (14 dBm) and also antenna gain was fixed (3 dBi). Fig. 12 shows the rssi values measured for each dr at left ( 42 meters) and right ( 43 meters) side from the gateway on the same floor. In Fig.12, the x-axis represents dr while the first group shows position 3 and the second group shows position 4. Position 3 and 4 represent left and right of the gateway respectively. From the results shown in the figure, the behavior of the system is the same on the left and right side on the same floor. The rssi on both sides for each dr is almost equal. This test also concludes that the signal transmitted in all directions has the same strength with 3 dBi gain. Furthermore, the signal strength is the same in all directions when an isotropic antenna is used with 3 dBi gain.

Fig. 12: RSSI values measured on 2 floor at left ( 42 meters) and right ( 43 meters) side of the gateway.

V-B5 Impact on RSSI by changing different floors

Generally, the value of rssi rapidly decreases in an indoor situation. For this test once again transmission power was fixed at 14 dBm and the gain was fixed at 3 dBi. Table II shows the distance between the end-node and the gateway. The positions represent the locations shown in Fig. 6. The gateway was located on the 2 floor. Fig. 13

confirms the results of the first test, i.e. different dr does not impact rssi values even when the floors are changed. The variance in dr values shown in this figure is negligible.

Floor Position
Distance from
the Gateway (m)
6 1 51  10
4 2 45  10
2 3 40  3
ZG 5 48  10
G 6 20  5
Basement 7 26  5
TABLE II: End-node distances from the gateway.
Fig. 13: RSSI values on different floors.

Because the gateway was on the 2 floor when the end-node was placed on the same floor the value of rssi is higher than the other floors. However, when the end-node was placed on floor 4 and 6 the values of rssi were lower because the distance between the gateway and end-node has increased. When the end-node was placed on floor G, the values of rssi were higher because this was in the line of sight and there were no obstacles between the end-node and gateway. The rssi value decreased for the floor ZG because of an increase in the distance. Lastly, in the basement, the rssi value is the lowest not because of the distance (which is almost similar to floor G), but because of the obstacles and concrete structure between the two floors.

V-C Signal-to-Noise Ratio (SNR)

snr defines the ratio between the signal power and the noise power. snr is measured in decibels (dB). The quality of an audio signal and transmission channel over the network can be measured by snr. It is easier to identify, eliminate and isolate the source of noise if the snr value is greater. An original signal cannot be separated from the unwanted noise if the snr value is zero. For snr there is another abbreviation S/N [32].

If an snr value is greater than 0 dB, it indicates more signal than noise. snr is often used metaphorically to point out the ratio of relevant information to incorrect or irrelevant data in an exchange or a conversation [32].

As the tests performed for rssi, the same tests are performed in order to evaluate the behavior of snr in the network. For each test, one hour of readings were obtained of the parameters being tested. As expected, the number of packets received by the gateway are increased with the increase in dr. In all of the below figures the snr is always represented on the y-axis. The complete details of all the tests are given as follows.

Fig. 14: SNR values measured on 2 floor at 42 meters distance from the gateway.

V-C1 Impact on SNR by changing the DR in the same location

This test was performed to assess the impact of dr on snr. The transmission power was fixed at 14 dBm and antenna gain was fixed at 3 dBi during the test. Location was also not changed for all dr during the test and the end-node was on the same floor as the gateway. dr is represented on the x-axis and as in the previous section V-B3

, the colored part represents 25% to 75% of the values with the whiskers showing the complete range of values. The small clear square represents the mean, while the line inside each of the box represents the median. The outliers are represented by the diamond shape outside the whiskers.

Fig. 14 shows the value of snr with the changes in dr. It can be observed that the changes in dr bring minor changes in snr specifically the snr is higher with dr 3. Other than this there are no big changes occurred with changing the dr. The range of snr falls between 7.5 to 12.5 dB. It can be concluded from this test that changes in dr have an impact on snr.

V-C2 Impact on SNR by changing the DR at left and right side from the gateway on the same floor

For this test, once again transmission power was fixed at 14 dBm and the gain was fixed at 3 dBi. The distance of the gateway from the end-node was 42 meters to the left and 43 meters to the right. The x-axis represents the dr and the first group shows position 3 and the second group shows position 4. Position 3 and 4 represent the left and right of the gateway respectively. Fig. 15 shows that the performance of the network is same on both sides of the gateway. This test further concludes that the snr remains same in all directions with 3 dBi gain.

Fig. 15: SNR values measured on the 2 floor at left (approx. 43 meters) and right (45 meters) side of the gateway.

V-C3 Impact on SNR by changing different floors

The distance between the gateway and the end-node along with floor location is shown in Table II. For this test once again transmission power was fixed at 14 dBm and the gain was fixed at 3 dBi.

Because the gateway was located on the 2 floor the signal quality is best on the same floor. However, 4 floor shows that snr values have decreased due to increase in distance and obstacles. Since the end-node located on the G floor was in the line of sight, the snr value here is also very well similar to the end-node located on 2 floor. Floor ZG has an increased distance which is almost comparable to 4 and 6 floor but the snr value is almost as high as floor G. Although, the distance has increased there are less physical obstacles between the gateway and the end-node. The snr value is lowest at basement and 6 floor due to the fact that there is an increased distance on the 6 floor but in the basement, there is a lot of hindrance because of the concrete structure. It can be concluded from these results that the networks in the basement and for long distances should be configured with special attention.

Fig. 16: SNR values on different floors.
Fig. 17: SNR values by changing the transmission power.

V-C4 Impact on SNR by changing the transmission power

As previously explained in section V-B2 the end-node allows a transmission power of 1 dBm to 30 dBm. During the test, the range from 1 dBm to 14 dBm of power transmission was used. The test was performed with a fixed dr of dr 5 and gain of 3 dBi. Fig. 17 shows a clear trend of increase in signal strength with the increase in transmission power. Because of this increase in signal strength, the original signal becomes stronger in comparison to the noise and thus produces a better snr value.

V-C5 Impact on SNR by changing the gain

As explained previously in section V-B2 the end-node allows a gain of -128 dBi to 127 dBi. For this test, dr and transmission power was fixed at 14 dBm respectively. All the readings were taken at the same location. As always x-axis represents the value of gain. Fig. 18 shows that with 3 dBi gain the best snr values is achieved. This is due to the fact that 3 dBi gain transmits equal strength signal in all directions. However, with the increase or decrease in gain, the signal is transmitted in a specific direction. Because of this, the quality of signal weakens and the noise level increases, which in turn produces a lower snr value.

Fig. 18: SNR values by changing the gain.

V-D Impact of different LoRaWAN classes on Acknowledgment (ACK)

This test was performed to check the behavior of different LoRaWAN classes in terms of downlink communication. As described in section III-B, a class A type end-node opens two short windows for downlink communication and class C type end-node continuously listens for downlink communication until next uplink packet. For this test, all the parameters were same for dr 5 and dr 4 only class type was changed.

End-node Class
Acknowledgment (ACK) missed
5 A 50
5 C 23
4 A 42
4 C 21
TABLE III: Acknowledgment (ACK) received with different LoRaWAN classes.

As a result of Table III, it can be seen that for class C end-node received 50% more ack than class A. So class C end-node would be preferable in low latency application.

V-E Packet Error Rate (PER)

The per refers to the packets, which are not received by the gateway. The results are summed up in Table IV. In Table IV, we list the distance between the gateway and each end-node location as well as position number that has been given to that location. The location of positions is shown in Fig. 6. Lastly, the table shows the per of each position for different drs. During this test, transmission power was fixed (14 dBm) and also antenna gain was fixed (3 dBi).

Packet Error Rate (%)
Distance from the Gateway(m)
DR 5 DR 4 DR 3 DR 2 DR 1 DR 0
6 1 51  10 65 2 0 0 0 0
4 2 45  10 2 1 8 1 0 0
2 3 40  3 0 4 0 2 0 0
2 4 42  3 0 0 0 0 0 0
ZG 5 48  10 2 4 1 0 0 0
G 6 20  5 0 0 0 1 0 0
B 7 26  5 90 28 10 5 15 11
B 8 60  10 100 100 100 100 100 100
B 9 55  10 100 100 100 100 100 100
TABLE IV: Packet Error Rate (PER) of different data rate from different positions.

On average per is 0 to 4% except for the basement. On the 6 floor and in the basement, 65% and 95% of packets are missed respectively for dr 5 due to long distance and obstacles. Thus for long distances, higher sf is preferable to minimize the per. In the basement, the last two positions did not receive any packets due to the concrete structure and the long distance. From these results, it can be concluded that with the decrease of dr the per will also decrease. That is why the selection of dr is important in order to maximize the performance of the network.

V-F LoRaTm Network Capacity

Practically it is impossible to find out network capacity with a single end-node and gateway. This is the limitation of our study, we have calculated LoRaTM network capacity theoretically.

In a LoRaTM network, the class A devices open two short windows for downlink communication at 1 sec and 2 sec after uplink communication. In order to calculate the LoRaTM network capacity, let’s assume it will take 2 sec to send one packet and get a response from the network server. Therefore, in 1 hour, there are () or 1800 packet opportunities. This puts the daily capacity of the network traffic at 43200 packets. The Nodes at the edge of the network needs more time to transmit the packets, so double time is required for counting the edge nodes [33]. Now if the gateway has one channel then the total number of nodes can be connected per day to the gateway.

Number of nodes= NR = 43200R + ER ×2

  • R - Packets per day requiring a response.

  • ER - Edge packets per day requiring a response.

However, in our case, we are using the MultiConnect Conduit gateway. This gateway can receive 8 packets simultaneously if these packets are sent using different frequencies and sfs. So, for the Conduit gateway, the total number of nodes are NR= 345600R + ER ×2 These are just base numbers, variability still exists in the dr and the size of data to be sent. Nodes at a further distance will need more toa and transmission power to send the same number of bytes, due to the long distance.

From equation V-F if 14400 nodes require ack and each node sends 24 packets per day than 100% of the network will be used. If we send 10 packets per node per hour. Usually, for 1 day, we can send 240 packets per node per day. So maximum 1440 nodes can be connected to our Conduit gateway.

From the above results, we can conclude that the network capacity of LoRaTM depends upon several parameters like the number of channels of the gateway, if ack is needed or not, and the number of packets required per day.

Vi Results of the Outdoor evaluation of the LoRaTm protocol

We conducted outdoor testing at the University of Applied Sciences888 Hagenberg Campus, Austria. We placed the gateway in a laboratory (PL3) located at the top floor in the FH 2 building. The location of the gateway for the outdoor scenario is shown in Table LABEL:ch5_t_5. The gateway was placed in the lab, but its antenna was mounted outside the window with the help of an extension cable. We selected this location because the university is located on higher ground as compared to the surrounding area. Other advantages of this location are that on one side of the university there are many buildings and obstacles, and on the other side, there is a straight line of sight.

Location FH-OOE
Latitude 48°22’5.00”N
Longitude 14°30’46.70”E
Sea Level 458.12
TABLE V: Location of the gateway for outdoor

For outdoor testing, the end-node was placed at three different locations which were provided generously by some colleagues at their homes. We used the same application for the end-node to generate the dummy data, which is described in section IV-A. Different tests have been performed at different times and days. The outdoor tests are as follows.

Vi-a LoRaWAN Coverage

One of the most important aspects of wireless technologies is to determine their coverage. This is very crucial for the cost estimation of the network. For this purpose, we performed a range test of LoRaWAN in Hagenberg, Austria. The aim of this test was to check the range of LoRaWAN with a single gateway for the smart metering application. We selected 3 different locations around the gateway with three different distances as shown in Fig 

10. The coordinates and distance of each location from the gateway is shown in Table VI.

Location Co-ordinates
Dist. from
the Gateway
Height from
Sea Level
1 48°22’6.24”N 14°30’53.81”E 151.14 463.9
2 48°21’50.60”N 14°31’8.80”E 635.8 402.64
3 48°22’18.60”N 14°31’22.30”E 845 472.44
TABLE VI: End-node locations and distances from the gateway.
Fig. 19: Outdoor locations of the gateway and

The transmission power was fixed at 14 dBm, while antenna gain was fixed at 3 dBi. The results of our experiment show that the maximum coverage of a single gateway is about 1.70 km in radius. When the end-node was placed on location 1 (closest location), the gateway received all the packets with dr 0–5. However, when the end-node was placed on maximum distance (location 3), the gateway received fewer packets with dr 2 and 3 but with dr 0, the gateway received almost all the packets. The distance of location 2 was less than location 3, but the gateway only received the packets with dr 0, due to the obstacles, which included buildings and lots of trees.

From the above results, we can conclude that network coverage of LoRaWAN depends upon several parameters like transmission power, antenna direction, height and obstacles etc.

Vi-B 863–870 MHz Band Usage

For this test, one hour of reading was acquired for each dr. Altogether, we took 6 hours of recording the data with dr 0-5. During 6 hours, a total number of 773 packets were received by the gateway.

In the EU region, LoRaWAN operates in 863-870 MHz band. In our case, we are using the MultiConnect Conduit gateway. This gateway can receive 8 packets simultaneously if they are using different frequencies and drs. Fig. 20 shows the frequencies, which were encountered in the test. The 3 mandatory frequencies/channels 868.1 MHz, 868.3 and 868.5 were used the most. The other 5 frequencies are supporting frequencies in order to increase the capacity of the network.

Fig. 20: Histogram of 863-870 MHz band usage (total packets 773).

Vii Conclusion

In this paper, a LoRaWAN is implemented with Multitech devices (end-node and gateway) in order to evaluate the performance of the network for indoor and outdoor realistic scenarios, under the European regulations. From our experiences, LoRaWAN is easy to setup and configure for real-time smart applications like smart meter. Our results show that a single gateway with eight sub-band channels is able to receive different uplink and downlink packets simultaneously with different DRs and frequencies within a radius of 1.70 km. As smart meter sends 96 bytes of data during different times in a day, thus we can easily receive data from thousands of smart meters, with a single gateway. In other words, a gateway can handle thousands of smart meters at a very low cost. While deploying the networks in the urban area one should pay special attention to the DR, position, and the height of the antenna in order to increase the performance and range. It can also be concluded from our research, different DRs do not have an impact on the signal strength. The quality of the signal depends on the distance from the gateway, the number of obstacles, transmission power, antenna type, antenna height, and antenna gain. Furthermore, for scenarios where a lot of concrete buildings and obstacles are present, based on our results we recommend to use an isotropic antenna with the maximum allowed transmission power value. If the end-node is very close to the gateway, then low transmission power is preferable in order to achieve better signal strength.


The authors would like to thank building management of the Johannes Kepler University, and the University of Applied Sciences Upper Austria for giving us access to the buildings and allowing us to conduct the studies.


  • [1] “Benchmarking smart metering deployment in the EU-27 with a focus on electricity,” European Comission, 2014, report. [Online]. Available:
  • [2] J. Laveyne, G. Van Eetvelde, and L. Vandevelde, “Application of LoRaWAN for smart metering: an experimental verification,” in Proceedings of Energy for Tomorrow, 2017.
  • [3] R. van Gerwen, S. Jaarsma, K. Rob Wilhite et al., “Smart metering,” 2006.
  • [4] E. McKenna, I. Richardson, and M. Thomson, “Smart meter data: Balancing consumer privacy concerns with legitimate applications,” Energy Policy, vol. 41, pp. 807 – 814, 2012, modeling Transport (Energy) Demand and Policies. [Online]. Available:
  • [5] “Smart metering deployment in the european union,” European Commission. [Online]. Available:
  • [6] S. Erlinghagen, B. Lichtensteiger, and J. Markard, “Smart meter communication standards in europe — a comparison,” Renewable and Sustainable Energy Reviews, vol. 43, pp. 1249–1262, 2015.
  • [7] H. Schmidbauer. (2016, 4) Can the internet of things lower ami solution cost? Semtech Corporation. [Online]. Available:
  • [8] N. Varsier and J. Schwoerer, “Capacity limits of LoRaWAN technology for smart metering applications,” in Communications (ICC), 2017 IEEE International Conference on.   IEEE, 2017, pp. 1–6.
  • [9] K. Mekki, E. Bajic, F. Chaxel, and F. Meyer, “A comparative study of LPWAN technologies for large-scale iot deployment,” ICT Express, 2018. [Online]. Available:
  • [10] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui, and T. Watteyne, “Understanding the limits of LoRaWAN,” IEEE Communications Magazine, vol. 55, no. 9, pp. 34–40, 2017.
  • [11] M. Aref and A. Sikora, “Free space range measurements with semtech LoRa™ technology,” in Wireless Systems within the Conferences on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS-SWS), 2014 2nd International Symposium on.   IEEE, 2014, pp. 19–23.
  • [12] W. A. Tanumihardja, E. Gunawan et al., “On the application of iot: Monitoring of troughs water level using wsn,” in Wireless Sensors (ICWiSe), 2015 IEEE Conference on.   IEEE, 2015, pp. 58–62.
  • [13] A. J. Wixted, P. Kinnaird, H. Larijani, A. Tait, A. Ahmadinia, and N. Strachan, “Evaluation of LoRa and LoRaWAN for wireless sensor networks,” in SENSORS, 2016 IEEE.   IEEE, 2016, pp. 1–3.
  • [14] J. Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanninen, and M. Pettissalo, “On the coverage of LPWANs: range evaluation and channel attenuation model for lora technology,” in ITS Telecommunications (ITST), 2015 14th International Conference on.   IEEE, 2015, pp. 55–59.
  • [15] M. Centenaro, L. Vangelista, A. Zanella, and M. Zorzi, “Long-range communications in unlicensed bands: The rising stars in the iot and smart city scenarios,” IEEE Wireless Communications, vol. 23, no. 5, pp. 60–67, 2016.
  • [16] 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.
  • [17] P. Neumann, J. Montavont, and T. Noël, “Indoor deployment of low-power wide area networks (lpwan): A LoRaWAN case study,” in Wireless and Mobile Computing, Networking and Communications (WiMob), 2016 IEEE 12th International Conference on.   IEEE, 2016, pp. 1–8.
  • [18] L. Gregora, L. Vojtech, and M. Neruda, “Indoor signal propagation of lora technology,” in Mechatronics-Mechatronika (ME), 2016 17th International Conference on.   IEEE, 2016, pp. 1–4.
  • [19] “A technical overview of LoRa and LoRaWAN,” LoRa Alliance, 11 2015, white Paper. [Online]. Available:
  • [20] A. Berni and W. Gregg, “On the utility of chirp modulation for digital signaling,” IEEE Transactions on Communications, vol. 21, no. 6, pp. 748–751, 1973.
  • [21] SX1272/73 - 860 MHz to 1020 MHz Low Power Long Range Transceiver, Semtech Corporation, 03 2017, data Sheet. [Online]. Available:
  • [22] N. S. (Semtech), M. L. (Semtech), T. E. (IBM), T. K. (IBM), and O. (Actility), “LoRaWAN specification,” LoRa Alliance, 07 2016, technical Report. [Online]. Available:
  • [23] E. Ruano Lin, “LoRa protocol. evaluations, limitations and practical test,” 2016.
  • [24] “LoRaWAN™ security,” LoRa Alliance, 02 2017, white Paper. [Online]. Available:
  • [25] “LoRaWAN™ security frequently asked questions,” LoRa Alliance, 07 2016. [Online]. Available:
  • [26] “LoRaWAN 1.0.2 regional parameters,” LoRa Alliance, 02 2017, technical Report. [Online]. Available:
  • [27] SEMTECH, ETSI Compliance of the SX1272/3 LoRa Modem AN1200.10, Semtech Corporation, 07 2013, application Note. [Online]. Available:
  • [28] “Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range Devices (SRD); radio equipment to be used in the 25 mhz to 1000 MHz frequency range with power levels ranging up to 500 mW”,” European Telecommunications Standards Institute, 01 2012, technical characteristics and test methods. [Online]. Available:
  • [29] “ERC 70-03 relating to the use of Short Range Devices (SRD),” CEPT- Electronic Communications Committee, 05 2017, technical Report. [Online]. Available:
  • [30] J. Stokking. (2017, 05) The things network architecture. The Things Network. [Online]. Available:
  • [31] M. Sauter, From GSM to LTE: an introduction to mobile networks and mobile broadband.   John Wiley & Sons, 2010.
  • [32] D. H. Johnson, “Signal-to-noise ratio,” Scholarpedia, vol. 1, no. 12, p. 2088, 2006, revision #91770.
  • [33] M. Cattani, C. A. Boano, and K. Römer, “An experimental evaluation of the reliability of lora long-range low-power wireless communication,” Journal of Sensor and Actuator Networks, vol. 6, no. 2, p. 7, 2017.