A Survey on LoRaWAN Architecture, Protocol and Technologies

Abstract

Internet of Things (IoT) expansion led the market to find alternative communication technologies since existing protocols are insufficient in terms of coverage, energy consumption to fit IoT needs. Low Power Wide Area Networks (LPWAN) emerged as an alternative cost-effective communication technology for the IoT market. LoRaWAN is an open LPWAN standard developed by LoRa Alliance and has key features i.e., low energy consumption, long-range communication, builtin security, GPS-free positioning. In this paper, we will introduce LoRaWAN technology, the state of art studies in the literature and provide open opportunities.

1. Introduction

Cost-effective Internet connectivity is an essential issue for the low power embedded devices that are dedicated to a specific task. Conventional wireless communication technologies are insufficient when considered for coverage (communication range), energy consumption and cost. LPWAN aims to solve these problems which can scale and suitable for large-scale deployments for low power end devices. Low Power Wide Area Networks are supposed to operate at low data rates to have kilometer range coverage from dense urban to suburban regions. LoRaWAN, SigFox, NB-IoT, Weightless, and other sub-GHz communication technologies are successfully providing these functionalities, however, LoRaWAN took the attention of organizations, communities, and researchers and have become a popular LPWAN technology [1].

LPWANs have some common characteristic that distinguishes these technologies within traditional communication networks [2]:

• Low power, the network and end devices should consume low energy.
• Communication, deployment and management cost is an essential issue since a large number of deployments are considered.
• From devices to the applications, the whole eco-system needs strong security mechanism.
• Built-in localization is a plus when indoor deployments are considered.
• Network deployment in dense urban areas leads radio networks to jam within same or adjacent channels. Robust (interference resistance) modulation is a must.
• End of the day, nodes generate data and this has to be handled properly.

Several LPWANs emerged on both licensed and unlicensed bands, LoRaWAN, Sigfox and, NB-IoT are widely deployed vital technologies [3].

Sigfox is an ultra-narrow band network that is patented and operated by Sigfox. Sigfox occupies 100 Hz and operates at 433MHz, 868MHz and 915MHz frequencies depending on the geographical regions. Technology has strict constraints on the number of packets (140 per day) and the packet size (12 bytes) to be sent. Also, LoRaWAN has similar policies to prevent network congestion allowing channels to be available only %1 duty-cycle for EU 868MHz (See Section 2.4.7). NB-IoT is an ultra-narrow band technology developed by the 3GPP group which can be adopted on GSM and LTE networks. It occupies 200 MHz bandwidth and can reach up to 200 kbps data transmission speed. Compared to LoRaWAN, Sigfox and NB-IoT operated by global network operators which limit deployments of the private networks [4].

An overview comparison of the three networks is shown in

Table 1. Comparison of Sigofx, NB-IoT, LoRaWAN [3] and conventional networks.

	Sigfox	NB-IoT	LoRaWAN	WiFi	ZigBee	Bluetooth
Standards	Sigfox	3GPP	LoRa Alliance	IEEE 802.11	IEEE 802.15.4	Bluetooth SIG
Modulation	BPSK	QPSK	CSS	DSSS, OFDM	DSSS, QPSK	GFSK
Frequencies	ISM: 433 MHz, 868 MHz, 915 MHz	Licensed under LTE	ISM: 433 MHz, 868 MHz, 915 MHz	ISM: 2.4 GHz, 5 GHz	ISM: 868 MHz, 2.4 GHz	2.4 GHz
Coverage	10–40 km	2–20 km	1–10 km	10–100 m	10–100 m	10–100 m
Bandwidth	100 Hz	200 kHz	125 kHz, 250 kHz	20 MHz, 40 MHz, 80 MHz, 160 MHz	2 MHz	1 MHz
TX Limit	140 Packets per Day	Unlimited	Duty Cycle Lim.	Unlimited	Unlimited	Unlimited
Max Data Rate	100 bps	200 kbps	50 kbps	Gbps	250 kbs at 2.4 GHz	2 Mbps
Private Deployments	No	No	Yes	Yes	Yes	Yes
Energy Consumption	Low	Low	Low	High	Low	Low
Security	Low	High	High	Low-High	High	Low-High

. When LPWAN characteristics are considered LoRaWAN becomes a strong candidate for both scientific and industrial uses cases.

LoRa referrer to Long Range and a physical layer technology patented by Semtech [5]. LoRaWAN is an open protocol proposed by the LoRa Alliance which enables the MAC layer for the network [6].

In this study, we will introduce the technological aspects of LoRaWAN and the state of art studies fulfilled about LoRaWAN till today. LoRaWAN protocol was first released in 2015 and had a few minor revisions, the differences in the protocol has been highlighted in the relevant subsection. In the survey, we will introduce LoRaWAN in depth both technological aspects and the use cases of its different areas. We categorized literature studies as in Figure 1. Studies are classified as two main sections; network technology and the applications, each section has own sub-branches. The majority of the work is focused on the coverage tests and applicability of the technology for different fields from large scale smart city applications to personal tracking assets. However, there are still gaps in the literature where researchers can address these problems such as post-disaster communication, decentralized networks, network management, and Adaptive Data Rate.

This paper is organized as follows; In Section 2, LoRaWAN technology is explained in detail with two main layers of the network Phy and MAC. In Section 3, different types of LoRaWAN applications are discussed and the most important use cases are highlighted. In Section 4, possible research focus areas are introduced that can help researchers to take action against and Section 5 concludes the paper.

2. LoRa & LoRaWAN Technologies

LoRa is a RF modulation and corresponds to the physical layer in OSI reference model. Whereas LoRaWAN is a MAC layer standard which coordinates the medium. In this section, we will discuss technological apects of both LoRa and LoRaWAN in detail.

2.1. Architecture

Network topology of the LoRaWAN is considered as star-of-stars and from the architectural point of view, the system has three main components (i) network servers, (ii) gateways (GWs) and (iii) end nodes. End nodes communicate with the network server (or data server) via GWs and Node-to-GW communication can be either LoRa or FSK modulation with different data rates and channels. Network servers manage the GWs through standard IP technology and data frames sent through end nodes, received by GWs and routed through the network server [7]. An overview of the LoRaWAN architecture is presented in Figure 2.

LoRaWAN is a MAC layer protocol and aims to solve management issues of the medium and network congestion. Any node using LoRaWAN protocol can benefit the following features provided by the standard;

• Channel management
• Energy efficiency
• Adaptive data rate
• Security
• GPS-Free geolocation

Next sections will discuss more details about the protocol.

2.2. OSI Reference Layers

Layered network design provides seamless communication among different network elements. LoRaWAN layers can be mapped to OSI Reference for better understanding underlying technology as presented in Figure 3. Generic LoRaWAN network deployments consist of multiple end-nodes, one or more gateways and at least one network server to run a complete network. LoRaWAN networks are distinguished with classical TCP/IP communication with GWs and end-nodes. Network servers are plain application services that operate over Transport Layer however, all MAC layer functionalities of the whole network are controlled by the Network Server.

LoRa is a Physical layer technology that operates on L1, and the main function is to transmit Application layer data to the medium. LoRa is explained in detail in Section 2.3. OSI reference L2 Data Link Layer matches with the LoRaWAN protocol (Section 2.4), which defines secure medium access and end-node management strategies. Usually, end-nodes do one simple specific task to minimize energy consumption thus, end-nodes perform L1, L2, and L7 functionalities in OSI reference. GWs are the links between the end-node and the network server. Network Server is the main factor that controls the medium.

2.3. Physical Layer-LoRa

Long Range (LoRa) is a physical layer technology introduced by Semtech and intellectual property rights of the modulation are held by the company [5].

LoRa modulation extends the traditional Spread Spectrum principles to reduce the amount of energy required to transmit bits over the channel. The Data Rate (DR) in attainable communication can be computed from the bandwidth BW (Hz), the Spreading Factor (SF), and the Coding Rate (CR).

The LoRa modulation has better performance than Frequency Hopping techniques in managing interferences. The modulation can tolerate interferences of arbitrary power levels up to 30% of the symbol length with less than 6 dB sensitivity degradation [5].

SF is the key variable that ensures the quality of service. When using the lower range of SF values, the data rate is very high and air time is low. The higher SFs extend the range but limit the Quality of Service. SFs from 7 to 12 allow orthogonal communications, i.e., different networks can speak simultaneously on the same frequency band without interfering.

Table 2. LoRa SF values [8].

Spreading Factor	Chirps/Symbol	Demodulation SNR
7	128	−7.5 dB
8	256	−10 dB
9	512	−12.5 dB
10	1024	−15 dB
11	2048	−17.5 dB
12	4096	−20 dB

presents SF values against Chirps/Symbol and Demodulation SNR. SF LoRa modulation is based on the representation of each bit of information by multi-chirps information [5,8].

The data transmission rate and the SF relationship is defined as below. Symbol rate (RS), bandwidth (BW), and the spreading factor relationship are defined in Equation (1).

Equation (1) defines the data transmission rate and relationship between SF, Symbol Rate (RS), bandwidth (BW).

$$RS=\frac{BW}{2^{SF}}$$

(1)

LoRa frame format can be either implicit or explicit where explicit packet includes a short header containing information about the bytes, CRC and coding rate used in the frame. LoRa frame format is given Figure 4. In most cases, coding rate and CRC are known and don’t change, it doesn’t necessary to specify the values, this scenario is called implicit header mode.

Frame air time is an important issue for real-time applications. Given CR, SF and BW time required to transmit a LoRa frame can be computed [8], which is the sum of the transmission time of the preamble $T_{preamble}$ and the payload $T_{payload}$ as defined in Equation (2):

$$T_{frame}=T_{preamble}+T_{payload}$$

(2)

$T_{preamble}$ is depended on the $T_{sym}$ which is given by Equation (3) and programmable length of modem registers $n_{preamble}$ in Equation (6) and LoRaWAN 1.0 specifies default preamble value as 8:

$$T_{sym}=\frac{1}{RS}$$

(3)

$$T_{preamble}=(n_{preamble}+4.25)T_{sym}$$

(4)

Frame transmission time is depended on payload size $n_{payload}$ which is calculated using Packet Length $PL$ (number of bytes), Implicit Header $IH$, Low data rate optimization $DE$ and Coding Rate $CR$ = $\{1:4/5,4:4/8\}$. $IH$ is 0 if the header is enabled, otherwise 1. Implicit header reduces packet size by using predefined $CR$ and $CRC$ configurations, otherwise, these values are included in the frame header. If a low data rate is enabled $DE$ value is set to 1.

$$n_{payload}=8+max\left(ceil\left[\frac{8PL-4SF+28+16CRC-20IH}{4(SF-2DE)}\right](CR+4),0\right)$$

(5)

$$T_{payload}=n_{payload}\times T_{sym}$$

(6)

Given Equations (2)–(6) it is possible to calculate frame air time for a single LoRa frame. Using this mathematical model LoRa frame air times are evaluated using $SF=\{7,8,9,10,11,12\}$ in terms of payload size and the $BW$. The results of the simulations for different configurations are available in Figure 5, Figure 6 and Figure 7. We can conclude that LoRa frame air is highly depended on the SF values. Higher the SF values (such as $SF=12$), higer the frame air time.

To evaluate LoRa frame transmission performance we have implemented a testbed environment in our previous work [9]. The testbed includes Semtech SX1272/76 chipsets, a GW and a network server. Mathematical Equation (2) and testbed results are evaluated in terms of frame transmission times in Figure 8. Dashed lines represent the mathematical model where solid lines are real testbed results.

Obtained data proves that both testbed and mathematical models are almost identical. We can conclude that this model could be used to simulate LoRa modulation and other LoRa based systems

Related Work

Operating at ISM band frequencies, LoRa modulation attracts attention from the academic and industrial community. This led researchers to study different aspects of the LoRa modulations; such as communication range (coverage), interference, link quality, and other performance metrics.

Researchers performed LoRa coverage tests in different regions to analyze the boundaries of the modulation. Jörke et al. [10] make a LoRa analysis for 433 and 868 MHz using a testbed at Dortmund/Germany to test different frequencies and performance with field tests. Petajajarvi et al. [11] test LoRa coverage for Oulu/Finland to range limits of the modulation and aims to find an attenuation model. Results given by the study show that 80% of the frames are received successfully up to 5 km and 60% of the frames are delivered correctly up to 5–10 km. The most of frames sent over 10 km were lost. The above water surface communication range could be up to 30 km. Oliveira et al. [12] aim to measure the impact of structures for LoRa communication range, the study obtains $5.6$ km and 2 km ranges in suburban and urban areas. LoRa and FSK are compared analyzed for IoT applications for smart cities by [13]. The author presents that LoRa performs much better when compared to FSK in most scenarios and highlights of successful transmission ranges up to 10 km in suburban scenarios. Also, other researchers illustrate that LoRa can provide long ranges with different environments [14,15,16,17].

Comparative coverage analysis is also studied and cross-technology comparisons are performed. Vejlgaard et al. [18] simulate LoRa link budget using existing 2G, 3G coverage data and compare results with Sigfox, NB-IoT. Also, in the study, a model is presented to estimate uplink probabilities. It is highlighted that LoRa has lower blocking probabilities than Sigfox, however, Sigfox has better uplink performance. Similar cross-technology coverage studies are performed by Lauridsen et al. [19], in Denmark for Sigfox, LoRa, GPRS, and NB-IoT. In the study, all compared LPWAN technologies have less than 1% outage for outdoor deployments.

As show from studies from 2 km to 30 km point to point LoRa communication is possible and this results in approximately 12.5 km${}^2$ to 2827.4 km${}^2$ area of coverage.

Dimayuga et al. [20] develop an error detection technique for LoRa based sensor nodes and model is implemented on MSP430 processors.

A physical layer study for implementing a power amplifier for LoRa [21] and LoRa compatible CMOS design is presented by the authors [22].

Finding an optimum configuration for the LoRa to increase performance is a challenging task, with the studies carried by Bor and Roedig [23] aim to find optimum tx power for nodes to optimize node energy consumption. Qin and McCann [24] performed a LoRa uplink analysis, channel assignment and power allocation issues with a model. Also, similar link analyses addressed by different researchers [25] and evaluated with simulations.

LoRa is a sub-GHz technology and it has many application areas, authors [26] aim to analyze fading and path loss of the technology for smart animal tracking.

LoRa is a Chirp Spreading Spectrum (CSS) technology that provides LoRa to be resistant to interference, this feature is analyzed by the paper [27] to illustrate how the gain of the chirps can be set independently with the number of orthogonal chirps. Also, it is shown that orthogonal CSS is more flexible for various applications.

Since IoT deployments are increasing both urban sub-urban areas, LoRa deployed IoT-nodes will face high interference. Angrisani et al. [28] take attention to the issue and aim to analyze protocol performance. It is shown that even high interference scenarios LoRa provides robust communication links. Mikhaylov et al. [29] present a work to validate channel orthogonality within different SF values using testbed experiments. Also, LoRa GFSK mutual interference is evaluated by the study. Also, interference studies carried out for different regions in North America—915 MHz and it is proven that 915 MHz in North America can achieve higher throughput than EU 863–870 MHz [30].

ISM frequency bands give researchers, hobbyists and makers flexibility to use and develop RF protocols. This advantage brings a downside to co-existing communication technologies for interference. Orfanidis et al. [31] inspect the IEEE 802.15.4 and LoRa for cross-technology interference using different BW and SFs. Respectively LPWAN and other sub-GHz radio technologies operating at the near frequency can cause interference to each other these issues addressed by works of the authors [32,33].

Performance of the LoRa technology is analyzed for different types of application scenarios such as Smart Grids. Barriquello et al. [34] evaluate LoRa for rural smart grid application for network coverage and path losses. According to the study, it is reported that the packet success ratio ranges from 0.9–0.95 which is a feasible technology in most Smart Grid applications.

An interesting signal measurement is performed by Radcliffe et al. [35], where authors track human movements (mainly walking) within an area with LoRa. According to the study, it is not feasible to track a person on the streets in an Urban area. Unlike the theoretical range 25 km, the authors claim that 200 m is the successful packet reception range and packet loses start at 600 m.

A prorogation analysis presented by Xue-fen et al. [36] using LoRa for underground soils and, the electrical conductivity of soil is evaluated. It is shown that rain has effects on the successful packet reception ratios and also, the performance of the system decreases during heavy rains.

A spread spectrum analysis performed at $2.45$ GHz using LoRa modulation by Wendt et al. [37].

868 MHz & 915 MHz require $8.1$ cm and $7.9$ cm long antenna to have proper signal reception and transmission. Researchers address this issue to provide compact [38], wearable [39,40] and electrically configurable patch [41] antenna solutions.

$\mu$PnP is a plug and plug system for IoT platforms.Ramachandran et al. [42] aim to add LoRa technology to provide sensor based IoT platform.

While a large number of studies focus communication range in LoRa, indoor performance analysis is a fact that to be considered. Researchers Ayele et al. [43] and Erturk [44] address this issue and provides LoRa metrics for indoor use cases for various indoor scenarios. Gregora et al. [45] evaluates indoor signal propagation and it is shown that packet loses increase when the building or structures get complicated.

Radio-based wake receivers are evaluated by Aoudia et al. [46] to eliminate idle listening. Authors present a scheme to solve latency and power consumption and analytical results show that 3000 times energy savings.

Since LoRa modulation is patented this resulted in the search of alternative modulation methods to replace LoRa [47]. Thus, the authors offer a FSK mathematical model that aligns with LoRa which is intended to be an open alternative.

2.4. MAC Layer—LoRaWAN

LoRaWAN is a layer two protocol to provide LoRa end devices Adaptive Data Rate (ADR), Security, GPS-free Geolocation, Channel Access and Energy Saving functionalities. LoRaWAN is introduced by LoRa alliance [7,48,49,50,51]. By version 1.1 LoRaWAN supports roaming and adds additional security features to Class B (see Section 2.4.1 for LoRaWAN classes). Regional parameters are specified by a companion document [52].

LoRa and other narrowband technologies have to be efficient that’s any overhead will cost more energy or latency (frame air time Figure 8). To overcome this problem LoRaWAN uses a quite simple channel management strategy to keep end devices to be cost-effective. LoRaWAN adopts pure Aloha [7] with additional ACK mechanisms to simplify medium access control. MAC layer protocol defines one mandatory and two optional classes for different possible use cases and an overview of this class representations is presented in Figure 9.

2.4.1. LoRaWAN - Classes

LoRaWAN has three main channel access strategies grouped as Class A, B and, C. Class A is mandatory and all end devices have to implement protocol specification defined by [7].

Table 3. LoRaWAN class comparison.

Class	Battery Consumption	Description
A	Most energy efficient	Must be supported by all the End-Nodes. DL after TX
B	Efficient with controlled DL	Slotted communication synchronized with beacon frames
C	Least efficient	Devices listen continuously. DL without latency.

presents a brief info about the classes.

LoRaWAN adopts ALOHA-type random access to keep network complexity as simple as possible and maximize energy saving. In Class A devices, downlink (DL) is controlled by the end node and devices don’t have an active DL receive windows. Only two DL receive windows are activated after an uplink (UL) transmission performed. Any packet to be transmitted from GW to the node have to wait next UL message. Thus, Class A devices are the most energy efficient.

Class B devices control the receive windows with pre-determined time slots and end devices open DL windows only scheduled times. End-node timers are controlled Beacon frames by the gateway.

Class C devices are the least efficient devices since DL receive windows are always active. Class A and B devices are higher latency when compared to Class C nodes.

2.4.2. Physical Message Formats

UL messages are transmitted from end nodes to the medium and received by the all GW in range. The network server eliminates duplicate frames and the single packet is processed.

UL messages use explicit mode in LoRa modulation as described in Section 2.3. UL frame format is shown in Figure 10.

DL messages are sent from the network server to the devices through the GW. DL messages are sent to one single end node. LoRaWAN is a single hop protocol and does not support routing or multi-hop packet delivery. DL frame format is shown in Figure 11.

Receive windows is a slotting access control initiated via a UL message from the end-nodes. First DL receive window RX1 is opened until RECEIVE_DELAY1 seconds (+/−20 microseconds) using the same channel as shown in Figure 12. RX2 has a configurable data rate and frequency via MAC commands.

2.4.3. MAC Message Formats

LoRaWAN frame format is given in Figure 13. MAC Header field (MHDR) has MType field to distinguish different MAC messages given in

Table 4. LoRaWAN MAC Message Types.

MType	Description
000	Join Request
001	Join Accept
010	Unconfirmed Data Up
011	Unconfirmed Data Down
100	Confirmed Data Up
101	Confirmed Data Down
110	RFU
111	Proprietary

.

Join Request and Accept messages are used by the Over The Air Activation (OTAA) process. Data messages can be either MAC Commands or Data messages. Unconfirmed messages do not require any Acknowledgment (ACK) mechanisms to check message delivery.

2.4.4. MAC Commands

LoRaWAN protocol runs a simple control mechanism to coordinate the medium and end-devices through the commands presented in

Table 5. LoRaWAN MAC Commands.

CID	Command	Transmitted By	Description
0x02	LinkCheckReq	Node	Connection validation.
0x03	LinkCheckAns	GW	Reply to LinkCheckReq.
0x03	LinkADRReq	GW	Adjust node data rate, tx power, rx rate or channel
0x04	LinkADRAns	Node	Response to LinkADRReq.
0x04	DutyCycleReq	GW	Set tx duty cycle.
0x04	DutyCycleAns	Node	Response DutyCycleReq.
0x05	RXParamSetupReq	GW	Set rx slot parameters.
0x05	RXParamSetupAns	Node	Response RXParamSetupReq.
0x06	DevStatusReq	GW	Request status of node.
0x06	DevStatusAns	Node	Response to DevStatusReq with battery level ad demodulation margin.
0x07	NewChannelReq	GW	Setup/modify new radio channel.
0x07	NewChannelAns	Node	Response to NewChannelReq.
0x08	RXTimingSetupReq	GW	Set reception slot timing.
0x08	RXTimingSetupAns	Node	Response to RXTimingSetupReq.
0x08-0xFF	Proprietary	Node/GW	Reserved further extensions.

. MAC commands are identified by an octet identifier called CID (Command Identifier). Each command has a predefined length and has to be identified implicitly by the implementation.

$LinkCheckReq$ command is used by end-device to validate network connectivity. $LinkCheckAns$ is replied by the GW including GwCnt indicating the number of GWs received the request successfully.

$LinkADRReq$ is sent from GW through the nodes to adopt a data rate. ADR (Adaptive Data Rate) message contains DataRate and Tx output power TXPower with region specific values. Also, usable uplink channels are encoded using ChMask field in the message. $LinkADRAns$ is sent by end-devices indicating that weather requested DataRate, Tx Power and requested channel states are discarded or successfully implemented.

Maximum aggregated (Equation (7)) Duty Cycle is controlled through the $DutyCycleReq$ request and message contains MaxDCycle in range [0:15] field to be implemented for all sub-bands as. 0 indicated that there is no duty cycle limitation and 255 is off switch to turn off the remote device immediately.

$$Aggreageddutycycle=\frac{1}{2^{MaxDCycle}}$$

(7)

$DutyCycleAns$ is a reply to $DutyCycleReq$ without any payload.

$RXParamSetupReq$ controls the second receive window (RX2) data rate and the frequency for each uplink. $RXParamSetupAns$ contains status bits indicating that configuration is successful or invalid.

$DevStatusReq$ is an empty message is used to check the status of end-devices. End-device replies the message with battery level, modulation margin of SNR ratio with $DevStatusAns$.

The Network Server can modify an existing channel or add a new one with $NewChannelReq$ request. The message contains central frequency and range of usable data rates as shown in Figure 14. According to the protocol end-devices have to handle 16 different channels indexed through 0 to N − 1 where N is the number of default channels. ChIndex is the index of the channel being configured. Freq field is 24 bit unsigned integer to refer actual frequency (100× Freq). Below 100 MHz reserved for future use cases so, the frequency can be set through 100–1670 MHz with 100 Hz steps. if Freq value set to 0, the channel is disabled. DrRange subfield (in Figure 15) in $NewChannelReq$ specifies the permitted data range for the given channel with 4 bit indexes. DrRange field has min and max data rates referred to as MinDR, MaxDR. DrRange = 0 × 50 refers to DR0/125 kHz–DR5/125 kHz are available.

End-device sends an ACK frame ( Figure 16 ) indicating the status of the $NewChannelReq$ request either successful or not.

The delay between uplink Tx and the first reception window is configured with $RXTimingSetupReq$ message. The second reception window is opened after one second of the first window.

2.4.5. Class B: Synchronized Reception Window

Class B device specification aims to solve limited DL message in Class A by using a synchronized reception slot. In Class B, GWs transmit a broadcast message to the nodes a timing reference. End-nodes use this reference to open the reception window which is called "ping slots" to initiate DL reception process.

All nodes in the network have to implement Class A and start the network with the same joining process. If an end-device decides to operate as Class B devices it has to follow these steps:

• The node makes a request to operate as Class B mode and searches for a beacon. The beacon can be found $BEACON\_LOCKED$ or not $BEACON\_NOT\_FOUND$ with the help of BeaconTimingReq message.
• The node selects an appropriate ping slot data rate and slot period depending on the signal strength and battery level.
• Class B mode is controlled over FCTRL field of every UL frame transmitted by end-device.
• End-device periodically reports its location and DL route to the network server.
• If no beacon frame received for given time [7], devices fall back to Class A device.

Beacon periods and timing references are briefly presented in Figure 17. Class B MAC commands are described in

Table 6. LoRaWAN Class B MAC Commands.

CID	Command	Transmitted By	Description
0x10	PingSlotInfoReq	Node	Periodic ping unicast message.
0x10	PingSlotInfoAns	GW	Reply to PingSlotInfoReq.
0x11	PingSlotChannelReq	GW	Sets ping channel for node.
0x11	PingSlotFreqAns	Node	Response to PingSlotChannelReq.
0x12	BeaconTimingReq	Node	Request to next beacon timing and channel.
0x12	BeaconTimingAns	GW	Response BeaconTimingReq.
0x13	BeaconFreqReq	GW	Configuration of beacon broadcast frequency.
0x13	BeaconFreqAns	Node	Response BeaconFreqReq.

.

2.4.6. Class C: Continuous Listening Nodes

Class C devices implement mandatory Class A reception window mechanism and these devices keep reception windows open after seconds delay RECIEVE_DELAY2. This process is shown in Figure 18.

2.4.7. Channel Access

LoRaWAN controls how devices access to the medium by duty-cycle limitation. Each sub-band has to wait for $Tof{f}_{subband}$ duration to transmit the next frame. Nodes can still use different sub-band while waiting for previously available sub-band.

$$Tof{f}_{subband}=\frac{FrameAirTime}{DutyCycl{e}_{subband}}-FrameAirTime$$

(8)

For 868 MHz duty-cycle limitation, 1% and it corresponds to 36 s. The first three channels 868.1, 868.3 and 868.5 reserved for control commands and should be implemented by all end nodes.

The protocol has two activation processes for nodes to participate in the network; (i) Activation By Personalization (ABP) and (ii) Over The Air Activation (OTAA) which will be discussed in Section 2.6.

2.4.8. Adaptive Data Rate (ADR)

The protocol supports a built-in Data Rate control mechanism which enables end-nodes to be configured with different data rates depending on the network condition. However, the protocol doesn’t define an algorithm to control node transmission rates, the network server has to implement depending on the conditions.

Aim of ADR to reduce frame transmission time since nodes closer to GWs can use lower SF values and have higher transmission rates that will reduce channel usage and energy consumption.

ADR Process is initiated by $LinkADRReq$ command given parameters in Figure 19.

An ADR mechanism is illustrated by The Things Network (TTN is introduced in Section 3.2) [53]. The method is publicly available [54], and calculates the optimum data rate through 20 most recent UL measurements. It includes a frame counter, SNR and number of GWs that UP link received. When ADR is determined, the system starts a new measurement process to determine the next ADR value.

ADR is an important feature in LoRaWAN networks to control coverage, interference and energy consumption. However, ADR hasn’t been investigated fully by the researchers yet.

2.4.9. GPS-Free Positioning

LoRaWAN networks support geolocation without any hardware dependency using Received Signal Strength (RSSI) or Time Difference of Arrival (TDOA) methods from 200 m to 20 m resolution. It is not necessary to have any specific frame or protocol message, any data frame received by at least 3 GWs are enough to determine the location of the end-node.

An overview of the architecture is shown in Figure 20. Since GPS coordinates of the GWs are known and fixed, by using TDOA node location can be extracted by GeoLocation solver.

Since GPS modules are energy hungry and have additional hardware costs, LoRaWAN’s builtin GeoLocation functionality becomes an efficient alternative. The resolution of the system is highly depended on the GW deployment density.

2.4.10. LoRaWAN v1.0–1.1

First stable version of the protocol (LoRaWAN v.1.0) released in 2015 [7]. In the following years, LoRa alliance released a few minor updates to the standard [48,49]. The two most important updates are LoRaWAN v1.0.3 [50] adds full support of unicast & multicast Class B devices and LoRaWAN v1.1 which enables handover roaming and enhancements in security [51].

Security enhancements are handled in Over-the-Air Activation (OTAA) procedure by JoinAccept MIC to prevent replay attacks. Also, new Session keys, ReJoin-Request messages are introduced.

Roaming is a key feature introduced in version 1.1 which enables LoRa nodes to benefit from multiple Network Servers. In addition to the protocol specification, LoRa Alliance introduced LoRa Backend Interfaces Specification document [55]. Since multiple network servers are involved in the roaming process, the document addresses Over The Air Activation and Roaming procedures of end-nodes. These include;

• Passive and Handover Roaming for existing sessions
• Activation of New Roaming based on Passive and Handover Roaming

2.5. Energy

LPWANs built on the communication range and energy efficiency, this has been investigated among other narrowband technologies. LoRaWAN Class A devices are designed to be the most energy efficient modes of the protocol. Since DL procedure is initiated by successful UL transmissions, end-nodes don’t require power during sleep mode for network operations. Class A devices intended to send a few packets (i.e., 3 packets per day), LoRa transceivers are not active frequently. Despite efficient protocol design, energy consumption highly depended on the hardware implementations.

Semtech SX1272/76 transceivers are the first market-ready chips that have been actively used LoRa end-node manufacturers. According to the datasheets, SX1276 has 100 mW constant RF output at +20 dBm and can have high sensitivity down to −148 dBm [8]

2.6. Security

LoRaWAN has built-in security to protect network protocol and user data. Data through node-to-application and note-to-network-server are protected by AES 128 encryption by four components:

• DevAddr: a 32 bit device identifier.
• AppEUI: an Application unique identifier which as IEEE UI64 address space.
• NwkSKey: a Network session key used to encrypt end-device to network-server communication.
• AppSKey: an Application session key (AES-128 key) used to protect application specific data.

LoRaWAN supports two main end-device activation methods (i) Over-the-Air Activation (OTAA) and (ii) Activation by Personalization (ABP).

2.6.1. Over-the-Air Activation (OTAA)

End-devices require to join the network before the application specific data transmission stage. End nodes initiate the activation process with an unencrypted Join Request, with AppEUI (8 octets), DevUI(8 octets) and a DevNonce (2 octets). DevNonce is a randomly generated and GW keeps tracks of these values for each end-node.

If the network server replies to the Join Request with a Join Accept, end-node is allowed to join the network. Unanswered messages yield that end-node cannot participate in the network.

Join Accept message contains; a random AppNonce (3 octets), Network Identifier—NetID (3 octets), an end-node address—DevAddr (4 octets), a delay RxDelay between TX and RX(1 octet), DL configuration parameters DLSettings (1 octet) and optional channel frequency list CFList.

Initial Join Request message sent from a node is unencrypted, however, the response message from Network Server (Join Accept message) is encrypted with AppKey. NwkSKey and AppSKey are calculated as follows:

$$NwkSKey=ases128\_encrypt(AppKey,0x01|AppNonce\left|NetID\right|DevNonce\left|pa{d}_{16}\right)$$

$$AppSKey=ases128\_encrypt(AppKey,0x02|AppNonce\left|NetID\right|DevNonce\left|pa{d}_{16}\right)$$

2.6.2. Activation by Personalization (ABP)

In ABP mode, end-devices store DevAddr, NwkSKey, and AppSKey to eliminate Join Request/Join Response stages. These devices can directly communicate with the Network server with given keys. Storing and securing critical keys is a vital task, any hardware attack can compromise these keys and unwanted network access may occur. Also, ABP strictly binds end-nodes to the specific Network Server where these types of devices cannot benefit roaming features available since LoRaWAN v1.1.

2.6.3. LoRaWAN Simulation

LoRaWAN designed to simplify Medium Access Control (MAC) to reduce complexity on the network and the end-nodes. However, this approach may lead to performance issues when a high number of active nodes participate in the network. For these reasons, we have implemented a MAC layer simulation of the protocol using Matlab to test efficiency. Simulation is configured as follows;

• Each node is configured to simulate only Class A devices.
• Each node is configured to send packets ranging from 10 to 50 bytes (plus 14 bytes protocol overhead).
• Each node is configured with random 7–12 SF values.
• Nodes has always a packet to transmit after $Tof{f}_{subband}$ time if there are no collisions. Equation (8).
• Frame air time is computed using Equation (2).
• Nodes are distributed to have a communication range with the GW. Ex. Figure 21.
• The GW is placed in the center of the simulation area. Ex. Figure 21.
• Simulation runs with single GW and it has 4 different sub-bands $\{1,3,6,12\}$ configuration.
• Simulation is configured to simulayte a complete year (365 days).

Also, we assume that the network runs only unconfirmed messages and nodes activated using ABP with predefined keys. Obtained results are presented in Figure 22. According to the simulation data, the node count directly affects the successful packet transmissions. This outcome can be improved by partitioning the network with small cells with multiple GW.

2.7. Related Work

In this section, we will discuss the state of art MAC layer researches.

Adelantado et al. [56] summarize LoRa, LoRaWAN application scenarios with open search areas. Similar studies exist to overview the technology [57] and to highlight the bottlenecks [58].

LoRa channels are orthogonal and provide interference-free communication using the same channel with different SF values. Georgiou and Raza [59] focuses on interference which is unique to LoRa networks which they call co-spreading factor interference. In the study, using single GW a mathematical tool is presented the evaluate UL and coverage of the network. Authors use Stochastic Geometry to model uplink coverage with a spatial distribution of the end-nodes. It is shown that LoRa networks are resistance to cumulative interferences. And, Ferrari et al. [60] analyze interframe spacing and interference with co-channel in LoRa. Using the same SF with min overlapping and PER is evaluated up-to 100%.

LoRaWAN link capacity is studied with a single node by Mikhaylov et al. [61] and in detail, results are shared. The study shows that UL capacity is limited to 2 kbit/s and highly related to the distance between node and GW.

An interference modeling using frequency and time domain is presented by Li et al. [62] to compare LWPANs. Model is based on card toasting and in the study, Sigofx and LoRaWAN are selected and analyzed. Given the model in the study, it can be used to solve LPWAN deployments and MAC layer problems.

The MAC layer of the protocol has been investigated by researchers to model channel access strategies for different LoRaWAN Classes. Since Class A is mandatory for all LoRaWAN devices, performance evaluation of the channel is highly investigated. By Centenaro et al. [63], Class A, uplink message performance is analyzed and the presented model is compared with ALOHA for model validation. Sørensen et al. [64] analyze the LoRaWAN Class A, UL performance in-terms of collision latency in a regulated duty cycling. A realistic Class A, MAC layer bounds analysis is performed by the authors [65] to model the channel. Also, Accettura et al. [66] developed an ALOHA based channel access model and tested with Python based simulation(LoRaWAN-sim) for model validation with realistic duty-cycle restrictions. ALOHA based mathematical models help to estimate error rates for LoRaWAN including Acknowledgment mechanisms [67].

Delobel et al. [68] analyze and outline the limitations of the Class B devices. The communication delay is evaluated with different parameters and a Markov Chains DL model is presented.

A realistic traffic generation is studied by Gupta et al. [69] for LoRaWAN networks. Using generated traffic, interference in node-to-GW radio communication is evaluated. According to the study, sudden data burst affects the GW.

LoRaWAN’s built-in ADR (Section 2.4.8) is extended with SNR margin estimation algorithms. The presented model evaluated with The Things Network (Open Source LoRaWAN infrastructure provider) coexisting algorithms.

LoRaWAN is considered as star-of-stars network topology and only a single relay (which is GW) is used to access nodes. Alternative approaches are still under consideration to extend this behavior. Liao et al. [58] aim to bring multi-hop networking LoRa for better performance indoor uses cases for CT (concurrent transmissions) flooding mechanism. In the study, the authors analyze the physical layer effects of CT scenarios. Cross technology integration is an alternative approach to provide new MAC functionalities. A LoRa - WiFi bridge for flexible use cases are presented by Oliveira et al. [70]. Multi hope mesh network design has been studied [71,72,73] by many researchers and alternative methods presented for content forwarding [74] and distributed channel access [75].

Beside multi-hop MAC layer studies, more interoperability work efforts exit to integrate 6LowPAN and IPv6 [74,76]. In [77], a Contiki OS based implementation is evaluated for IPv6 efforts.

A Delay Tolerant Network perspective is investigated with LoRa and WiFi by the authors [78]. Both wireless technologies are analyzed in terms of latency, packet delivery ratio, buffer usage and message TTLs (Time To Live).

An experimental study is carried on LoRaWAN networks to handle sensor data as a backhaul network [79]. Using Tx and Rx timing, packet arrivals are measurements to evaluate proposed system stability.

2.7.1. Security

There are only a few studies address the LoRaWAN security [80,81]. Studies focus on the most important and the least secure stages of the LoRaWAN network protocol which is activation process [82]. Na et al. [83] penetrate the network to gain network access with sniffing unencrypted join requests in OTAA and replaying these packets to the GW. Also, Join Procedure misusage can lead to the network server to be unavailable for a time period (Denial of Service - DoS). Tomasin et al. [84] present that DoS attacks can be performed when considered the randomness of the DevNonce. An attack can keep an end-node to out of service by using this approach.

Lee et al. [85] aim to attach extra information LoRaWAN payloads without decrypting messages using bit-flipping attacks. According to the study, Message Integrity checks can be bypassed using brute-force. Alternatively, a shifting method is presented to prevent bit flipping.

LoRa itself can be used as a plain radio communication which has no security procedures. Kim and Song [86] present an architecture for point-to-point LoRa communication.

A distributed digitalized ledger technology Blockchain has an increasing momentum store any kind of data in a secure manner. Blockchain and IoT integration have been studied and an alternative architecture is presented by Özyılmaz and Yurdakul [87]. The authors aim to integrate Blockchain to LoRaWAN infrastructures.

Xu et al. [88] address PKI (Public Key Infrastructure) issues on resource constrained environments and offer alternative wireless key generation schemes to the problem. According to the results of the study, the presented schema can achieve 128-bit key generation up to 18 bit/s in stationary and 31 bit/s in mobile situations. Authors do not consider how network congestion will affect key generation methods.

Blockchain technology has become an important player in cybersecurity and traditional centralized methods replaced with decentralized techniques. One of the projections of Blockchain applications is presented by Ozyilmaz and Yurdakul [89] which study tells us, LoRa enabled IoT data can be stored in a secure distributed system which will ensure distributed denial of service attacks (DDOS).

2.7.2. Energy

Morin et al. [90] evaluate IoT communication technologies (802.154/e, BLE, 802.11, 802.11 ah, LoRa and Sigofx) for battery consumption with a realistic energy models. The considered network is limited with single hope and 802.1ah and Bluetooth Low Energy (BLE) multi hope scenarios are ignored. The model accounts for frame retransmissions due to collisions or external effects on the network. Study accounts TX, RX, and sleep modes of IoT platforms while calculation of the devices. To keep calculation simple, the authors omit security and other MAC overheads. Results revile when BLE offers the best performance when high traffic applications and LoRa has better performance ultra-low traffic. Kurtoglu et al. [91] compare ZigBee and LoRaWAN energy efficiency and it is highlighted that LoRaWAN networks are a higher advantage and can be run with solar energy since the presented network uses 6 Joules per day.

LoRaWAN Class A devices optimize the energy with controlling the DL receive windows. In most cases selected TX parameter directly affects the battery usage of the end-devices. Haghighi et al. [92] present a game theoretical approach to selecting the configuration to decrease energy consumption while maximizing the throughput.

Costa et al. [93] aim to calculate frame transmission cost in terms of Joule and present a model for channel based energy consumption. It also offers a calculation for a lifetime of a LoRa battery. The model is not validated with a real testbed.

Researchers working on different aspects of energy efficiency such as amplifier design [94], on/off switches to save energy for remote systems [95], tracking systems [96], solar power monitoring systems [97] and running end-devices energy gained through bridge seismographic movements [98]. Spectrum usage, bandwidth and battery usage analysis are evaluated among LPWAN technologies; LoRa, Sigfox, Weightless, LTE-M, NB-IoT [99].

Mikhaylov et al. [100] combine Multiple Radio Access Technologies (RAT)on a single IoT board to provide energy efficient IoT platform which can be used for general purpose applications. NB-IoT and LoRaWAN are selected and radio modules can be configured to transmit data sequentially or in parallel. Both single and combined use cases of the RAT evaluated in terms of energy consumption. The result indicates that Multi RAT platform is more efficient where, the total energy consumption of single RATs has 1005.56 mW, parallel Multi RAT has 941.58 mW and sequential Multi RAT has 738.5 mW.

A Far-Field Wireless Power Transfer (WPT) sensor node is developed and integrated into a LoRa based system to measure temperature and humidity remotely [101]. It is shown that battery free sensor implementations will increase the use of cases of LPWAN. LoRaWAN fits well with real battery constrain applications both for UL and DL data transmissions.

3. Applications

LoRaWAN aims at becoming the de facto wireless connectivity standard for the Internet of Things (IoT) applications. Providing services that span areas ranging kilometers and to be implementable in devices that operate requiring very low energy is promising among industry and academia.

In our previous work [9] have introduced how e-Health application can be adopted with LoRaWAN and evaluated the performance of the time critic data transmissions. Since the protocol released in 2015 [7], a high number of IoT application has been powered by the LoRaWAN protocol. In this section we will cover a variety of LoRaWAN based applications and Network Servers available today.

3.1. LoRaWAN Applications

It is not limited but, Smart Cities, Smart Farming, Environmental Monitoring, Smart Grids, and e-Health are the most common application areas for the LPWAN technologies.

IoT monitoring applications are becoming an important part of our lives since most of the systems rely on these network data. When deployment costs are considered having a long life LoRaWAN equipped IoT devices becomes a feasible solution. Lee et al. [102], a LoRa based application for monitoring environmental changes presented. The designed system is capable of keeping track of floating-point cases for rivers and the seas. Guibene et al. [103] share the results of the LoRa river monitoring system with air and water temperature, river depth, solar/battery performance, and barometric pressure. Almeida et al. [104] aim to solve multi-technology environmental monitoring in Smart Cities such as both static and moving elements, such as cars, bicycles, aquatic and aerial drones. Air pollution monitoring for Smart Cities is illustrated by the authors Rossi and Tosato [105] and Liu et al. [106]. By Li et al. [107], LoRa is analyzed for sailing monitoring systems and PER are evaluated. Obtained results show that, while moving with 20 km/h average speed, the frame loss rate is 0.34% within the range of 400 m. Wotherspoon et al. [108], a wildlife monitoring system has purposed using LoRa and shown that it can achieve up to 2% frame loss with a 5.5 km range with a power of 20 dBm. Also, other monitoring studies such as landslide [109,110], anomaly monitoring and detection in infrastructures [111]

Bellini and Amaud [112] presents a Smart Farming application to detect the heat of the cattle using LoRA. According to the study developed system can stay online up to 5 years with 400 mAh over 10 km range. An agricultural use cases for monitoring crops [113], rice fields [114] and plant water controlling systems are [115,116,117,118] discussed. Kontogiannis [119] purpose a low power Beekeeping system to monitor temperature, humidity and control security of the hives through LoRaWAN.

Car parking and monitoring [120], traffic lights [121] and traffic light congestion [122] monitoring systems are purposed as Smart City applications. Loriot et al. [123] make field test for a Smart Campus application in North France called SunRise with outdoor and indoor usages. A solid waste management system and its is implementations are discussed by Bharadwaj et al. [124] and it is argued that RF Mesh networks can be useful for private scenarios, however, when inter-probability is in mind LoRaWAN is the feasible solutions. iCar [125], is another Smart City application focused on public and driver safety by tracing diagnostic information of the car. A cost-effective bus tracking system can be implemented using LoRa over Wi-SUN [126].

LoRaWAN also took the attention of the industry, where Smart Grid applications and LoRaWAN integrations are evaluated in recent studies. Terashmila et al. [127] analyze LoRa, Radioteletype, and VHF wireless technologies for controlling remote SCADA systems in an energy efficient manner. Results of the show that LoRa is the only feasible solution. A technological comparison of RF Mesh and LoRaWAN has presented by [128]. Also, it is possible to track electrical vehicle charging stations using LoRa [129].

Our previous work focused on developing an e-Health device to test if LoRaWAN is the right solution for the e-Health application [9]. As outlined in the paper Frame Air Times and moderated duty-cycles are a critical bottleneck for real-time patient tracking. However, this communication technology can be enough to keep track of measured data on a timely basis such as glucose levels or weight ... etc. Another work has been published by [130] and communication ranges are tested in the study up-to 33 km${}^2$ coverage areas are reached in rural test cases. Mentally disordered patients can be tracked using LoRa based communication technology [131]. Also, Petäjäjärvi et al. [132] address the health and well being monitoring systems using testbeds. Study shows that sent frames are received by GW with a ratio of 96%.

Different work effort put such as generic sensor framework [133] for IoT, analysis of LoRa for smart metering [134,135], undermine and soils [136,137,138,139], propagation analysis of indoor (Smart Buildings) [140] and campuses [141], industrial use cases [142,143], aerospace [144] and satellite communications [145], verticular smart city applications [146], remote on/off switches [147], multi hop monitoring system [148] and enegery efficient monitoring systems [149], military use cases for troop tracking [150] and public use case for tracking kids [151].

3.2. LoRaWAN Network Server

The Network Server is the heart of the LoRaWAN protocol, where all MAC functionality controlled by the Network Server. Network Server is the termination point of the LoRaWAN MAC layer for the end-nodes and responsible for [51,55];

• Managing all MAC layer functionality,
• Managing Join Request and Join Responses and Roaming
• End-node address control,
• Frame counter and authentication controls,
• Acknowledgment mechanism,
• Data rate adoption (or ADR)
• Data delivery to Application Servers,
• Data delivery to end-devices from Application Servers.

This section will embrace different LoRaWAN Network Servers and tools available today.

Growth in the IoT ecosystem led the increase in the communities where individual volunteers share their knowledge, interest, infrastructure (internet connection) and other resources ... etc. with public usage. The Things Network (TTN) is one of the well known IoT community which aims to build open global LoRa community to provide wide coverage [53].

TTN has both free and commercial solutions, however, providing free Network Server took the attention of hobbyists, researches and makers to dive into LoRaWAN quickly. The community has help and support documents, forums and volunteers that help each other. Also, TTN Network Server is available as open source [152] to start private LoRaWAN Networks.

An alternative open protocol OpenChirp is presented by Dongare et al. [153], which has a purpose to provide simplified LoRaWAN network services such as; data serialization, meta-data, and time series data storage.

A flexible open source LoRaWAN Network Server project is sponsored by CableLabs [154], which has Web user interfaces and also RestFul API support for network management.

Besides open soruce solutions, there are serveral commertial products available through companies Actility [155], Ublsoftware [156] and LORIOT [157].

4. Future Work & Research Directions

In previous sections, we have introduced the LoRaWAN and related work is done until today. It is obvious that the most majority of the researches are performed on coverage test and how far a LoRaWAN frame can be transmitted. We can conclude that modulation is proven and other research paths should be followed.

LPWANs are fairly new and there are challenging issues awaiting to be addressed. We have covered the LoRaWAN protocol in previous sections. The protocol is driven from Aloha which is fairly simple to implement however, it has some drawbacks when using an increasing number of network elements are involved. When the size of the network increases, packet transmission attempts will increase and successful packet delivery ratios will dramatically decrease. This would be a vital problem when real-time or critical services rely on LoRaWAN infrastructures. The problem of, efficient successfully packet delivery on unreliable medium should be investigated.

Another related research direction would be controlling the ADR with application-specific domains. The protocol itself doesn’t provide an algorithm for ADR however, it gives necessary MAC commands to control it. Applications having frequent data transmission may be configured to with (depending on the distance) lower SFs and higher data rates to utilize the channel more effectively. Also, controlling the ADR will affect energy consumption and the costs which could lead the problem to be more complicated.

With LoRaWAN v1.1 network servers are able to support roaming and network backends should be coordinated through a standard. LoRaWAN Backend Interfaces v1.0 introduces roaming related management problems (OTA) however, higher network level management issues are not addressed such as; monitoring, configurations, and management of the GW and the nodes. Detecting multifunctional devices on the network, and maintaining all devices are important in enterprise level solutions.

LoRaWAN networks best fit for outdoor IoT solutions such as smart city, airport, and farming ... etc. Besides outdoor usage, there is a gap in indoor deployments and solutions. Signal propagations and other network problems will raise for indoor application scenarios for different home users.

We are in an Information Age and the way information is driven has dramatically changed towards humans to machines, from centralized to decentralized from closed to open. LoRaWAN is an open platform that enables m2m to connectivity however, it is not a fully decentralized network. Daily usage of Blockchain technology is getting hits and studies aiming LPWAN and Blockchain integration would be a game changer.

It is also possible to benefit from transmission ranges of modulation on emergency conditions such as post-disaster communications and surveillance systems.

As explained in previous sections, LoRaWAN has key features such as; GPS-free Positioning, Long Range data transmission, ADR, different classes for different use cases, low energy consumption. These functionalities enhance the protocol and provide flexibility however, profile or policy-based approaches are needed in the long term. A profile based configuration could help application developers quick start and network operators could utilize the network and medium more effectively.

5. Conclusions

LPWA Networks have become a de facto communication standard for IoT since, power consumption, coverage are key features. Being an open platform LoRaWAN has become an important protocol among the LPWA Networks. In this study, we introduced LoRaWAN architecture and design details with state of the art literature review of the protocol. LoRa is RF modulation which enables very long from 2 km (urban) to 20 km (rural areas) data transmission ranges. LoRa signals can penetrate through walls and receivers can extract data from very weak signals. LoRa is a closed modulation however, LoRaWAN is an open standard developed to prevent consumption and moderate the network effectively. LoRaWAN Classes introduce TX and RX policies to control medium access and energy consumption of the end-nodes.

When compared with other communication technologies, LoRaWAN has advantages on being an open standard, builtin security, GPS-free geolocation, ability to have long range communication, low energy consumption, and options to have private deployments. Besides it is advantages, low data rate and duty cycle constraints limit LoRaWAN networks for real-time applications. LoRaWAN best fits scenarios where data transmissions are rare (a few packets in a day) and the size of the payload is around 10–50 bytes. Smart city, smart grids, smart farming, and remote monitoring systems are the areas of the example where LoRaWAN could be best beneficial.

The majority of the LoRaWAN studies are focused on the data transmission ranges and applicability of the protocol of different application scenarios. The technology is fairly new and there are still open research fields are available to concentrate on such as optimization of high dense LoRaWAN deployments, ADR, Network Management, interoperability of applications and the networks.