Ultra-dense LoRaWAN: Reviews and challenges

: Internet of Things (IoT) is one of the most cited terms within the communication research communities. Next generation wireless networks technologies are expected to have massive-connections of tens of billions of devices. Such a huge number of devices raised a number of concerns in regards to how much accessible resources are available and what are the best technologies for managing those resources, all in order to avoid shutdowns/collapses in every means. In terms of wireless networks, and in regards to energy being the backbone of IoT devices, Low Power Wide Area Networks (LPWAN) technologies are considered to be a potential solution for IoT applications. In particular, this study reviews Long-Range (LoRa) technology and advances in the literature of LoRaWAN protocol to date. Furthermore, it discusses the challenges in LoRaWAN and diverts the attention towards applying Ultra-Dense Network concept on LPWAN.


Introduction
The world is anticipating hundreds of billions [1] of low-powered (battery supplied) devices, such as sensors, to be used across a range of applications such as smart agriculture, smart cities, smart environment, smart healthcare, smart homes and buildings, smart industrial control, smart metering, smart supply chain & logistics and smart street lightening. These devices that transmit and receive data have been classified as Internet of Things (IoT). A number of protocols have been designed for Low Power Wide Area Networks (LPWAN). LPWAN protocols include SigFox, NarrowBand-IoT (NB-IoT) and LoRa. LoRa is gaining popularity over NB-IoT and SigFox due to support by the industry such as LoRa Alliance, IBM, CISCO and more, providing bitrate from 100 to 10,000 bit/s, providing long range coverage (>10 km), having simple and effective MAC, low cost, having less complex modulation and in return less power consumption, mobility support and providing separate operation style (can be integrated in any network as 'do it yourself style') [2].
A massive-IoT scenario [3] revealed 10,000 households with connected devices such as water, electricity and gas meters, within each household in an area of one kilometre square. Other devices such as vending machines, rental bike monitors and car accelerometers are deployed in the same area. Typical data size per each of the aforementioned IoT devices range between 250 and 300 bytes (including payload, MAC layer overhead and higher layer overhead) which can be ideally served by LPWAN technologies [3,4]. IoT is expanding and LoRaWAN is one of the best IoT serving protocols.
However, the burst in IoT massive-connections indicates the future need for Ultra-Dense Network (UDN) to be adapted efficiently by any technology meant for serving IoT devices. A network with more than 1000 access points distributed within 1 km 2 can be referred to as UDN [5][6][7]. In this regard, Rizzi et al. [8] carried out evaluations and demonstrations of LoRaWAN for dense systems. Due to LoRa's simple modulation with Chirp Spread Spectrum (CSS) physical layer, LoRaWAN [2] has higher immunity to interference in comparison to other LPWAN technologies. UDN has to be exploited to provide the solution to elevate the IoT rapid expansion.
The efficiency of deploying LoRa is maximised where data reporting and control may be needed, being indoors or outdoors or being urban or rural areas. However, Haxhibeqiri et al. [9] reported that LoRa Packet loss is 20% for indoor mobile applications whilst for indoor fixed applications for the same distances, loss is less than 2%. This is due to the fact that mobile end-devices may encounter bad reception conditions. Within the last 5 years, applications that deploy LoRaWAN have grown tremendously. Three well known areas of such applications are medical [10], agriculture monitoring [11], and smart city [12].
Specifically, LoRa attracted quite a few applications in remote areas. Li and Zhu [13] have reported the shortcomings for first generation Sailing Monitoring System by using 3G. These shortcomings are limited coverage and power consumption. They have redesigned the system mainly to use LoRa technology. They have used LoRa settings with SF 7 and 125 kHz BW in the new Sailing Monitoring System. The results have met the trade-off of data rate, coverage and link budget. Applications using LoRaWAN is increasing proving that LoRaWAN is the most efficient LPWAN technology.
However, more gateways and certainly more end-devices deployment within a certain area, i.e. UDN scenario, the more interferences occur which result in more collisions and hence more delays. In addition, collisions minimise battery life.
The paper reviewed all possible topologies that could form UDN and presented a structured topology that can be scaled up. A structured-topology between LoRa gateways and end-devices mean structured timing for transmitting and receiving data packets and hence, reduce the collision rate. This requires a novel network topology and this paper presents a mathematical and graphical topology model.
The paper focuses on discussing the details behind LPWAN and reveals LoRa modulation scheme, the orthogonality of a plurality of signals, software & hardware emulators and simulators. In addition, it discusses problems and challenges within LoRaWAN protocol. The organisation of the paper is as follows: Section 2 provides an overview of LoRa modulation. Section 3 presents a review to the latest development of LoRaWAN, its associated problems and counteracts methods. Currently, the majority of applications that are adopting LoRa are mapping millions of nodes in one network. Hence, it is forming a challenge for LoRa densification. This is discussed in Section 4. To evaluate an application with such a large scale of nodes, there is a need to use software and hardware tools for simulation and emulation IET Commun., 2020, Vol. 14 Iss. 9 purposes. This is encompassed in Section 5. Finally, the paper ends with a conclusion in Section 6.

LoRa overview
LoRa is a long-range wireless communication technology proposed by LoRa Alliance and developed by Semtech [14]. It resides in Wireless Metropolitan Area Network (WMAN) using LPWAN protocol, as shown in Fig. 1. LoRa is aimed at providing wireless network services to long live battery power devices, with low data rate and long distance.
Industrial, Scientific and Medical (ISM) bands of the world are shown in Fig. 2. The band over North America is 915 MHz while over Europe is 868 MHz. LPWAN products can be approved if it is capable of providing the allowed band in a specific geographical area. Table 1 provides a comparison of products that are able to provide network connectivity to a set of sensors. This table is based on long range, low data rate, low power and cost. It indicates that 'LPWAN technology is perfectly suited for connecting devices that need to send small amounts of data over a long range, while maintaining a long battery life' [15].
Within LPWAN, there are three products that are using different modulation techniques. These are SigFox, LoRa and NB-IoT. The modulation techniques of SigFox and LoRa are proprietary while the third one is 3GPP. The list of the three products is displayed in Table 2.
IoT applications are quite few, but they could be categorised as fixed or mobile. Examples for fixed IoT applications are street lights and farming. Examples for mobile IoT are vehicles and cattle's. For fixed application SigFox, LoRa and NB-IoT are able to operate good if they are fixed. However, for fixed applications, LoRa has one interesting feature, Adaptive Data Rate (ADR) (Section 2.4).
ADR maximises battery life, range and network capacity for each end-device. SigFox and NB-IoT do not have this feature.
SigFox offers only EU 868 frequency band hence the unpopularity in the USA market.
LoRa and NB-IoT provide uplink and downlink transmissions, while SigFox provides only uplink. Therefore, SigFox cost is the lowest.
Hence, Table 2 shows that LoRa is the best candidate among other LPWAN products with reference to mobility, worldwide availability, radio module cost and uplink/downlink capabilities. Full LoRa network protocol is shown in Fig. 3 as depicted from [2]. The Sensor (end-device), which is processor based device, transmits and receives, among other details, the sensing values to LoRa gateway via the antenna physical layer. The Gateway Host, similarly receives and transmits to the end-devices via the antenna physical layer. The last block of Fig. 3 is the Network Server, routes backward and forward messages from end-devices to a specific application. In addition, the Gateway Host could be interfaced to a Network Server via Ethernet, 3G or WiFi protocols.
As shown in Fig. 4, LoRa consists of three layers [2]. First is the physical layer or modulation layer based on Chirp Spread Spectrum (CSS) technique (Section 2.1). In addition, the physical layer offers four regional ISM bands, including EU and US allowed bands. The SX1276/77/78/79 chips transceivers, produced by Semtech, form the physical layer for LoRa. Second is the Media Access Control (MAC) layer protocol (LoRaWAN) with specific access network architecture. MAC protocol manages uplink and downlink between gateways and end-devices. LoRaWAN provides three different classes; Class A, Class B and Class C devices. Class A, is the lowest power end-device system for applications where the end-devices are pure ALOHA based. Class B, where the end-device receives a time synchronised beacon from the gateway. Class C, is continuous Wireless Metropolitan Area Network where end-device use more power to operate but it offers the lowest latency for server to end-device communications. Third is the application layer.
LoRa adopts star topology, where a set of LoRa end-devices are connected wireless to LoRa gateway. End-devices communicate in their time or frequency slot with LoRa gateway. The radio link between LoRa gateway and LoRa end-devices can be very long which leads to less battery life. However, LoRa end-devices are able to rest between message transmissions, which means LoRa end-devices consumes less energy. Star topology is mainly aimed for LPWAN. It is also widely used in WiFi and mobile (cellular) networks.    LoRaWAN supports both uplink and downlink messaging. A message from LoRa end-device to LoRa gateway is an uplink message, while a message from LoRa gateway to LoRa end-device is called a downlink message.
LoRa deploys its own modified Chirp Spread Spectrum (CSS) modulation. It also deploys a Frequency-Shift Keying (FSK) modulation with higher data rate (up to 50 kbps) [12].
The SX1301/08 Digital Baseband chips for outdoor and indoor LoRaWAN gateways are produced by Semtech. LoRa is well suited to cover connectivity over, for example a large building using star network topology. However, the market is geared towards using LoRa for applications that deploy over 100 thousands of nodes to be connected to form a mesh topology, hence the term Ultra-Dense Network (UDN).

LoRa physical layer
For ease of understanding, design, programming and simulation/ modelling of LoRa technology, terminologies such as Chip, Symbol, Chirp, Spreading Factor SF, Coding Rate CR and Data Rate DR are described here.
2.1.1 Chips, symbols, chirps and spreading factor: A chip is a pulse that sweeps from f Low (−BW/2) to f High (+BW/2), BW is bandwidth. The number of chips forms a symbol. For example, assume a symbol value is between 1 and 128, this number would be one of the combinations of 2 7 = 128 chips. Fig. 5 illustrates an example of symbol values within 128 chips.
The chip rate (R c ) and symbol rate (R s ) are expressed in the following equations: The chip is equivalent to one pulse of the BW. Hence where SF = {7, 8, 9, 10, 11, 12}. There are 2 SF combinations of symbols that can be transmitted over the BW. Therefore, the (R s ) from (2) can be expressed in terms of BW as shown in the following equation: To estimate the processing gain of R c and R s , the term Spreading Factor (SF) was emerged. LoRa has been designed for symbols with group of sizes N of chips N ∈ {128, 256, 512, 1024, 2048, 4096}. Equation (5) shows SF in terms of N SF = log 2 (N) To gain the highest throughput with the lowest power consumption but for short distances, SF should be set to 7 [2]. At SF12, the distance is at maximum but data rate is at the lowest [2]. LoRa modulation deploys CSS. In CSS technique, first developed for radar applications in the 1940's [16], the frequency of the generated chirps varies linearly with time to provide low cost, low power and resilience to interference based solution. So chirp (sweep) is a signal of continuously increasing frequency (upchirp), a ramp from frequency minimum f min = 0 kHz to frequency maximum f max = 127 kHz as shown in Fig. 6, or continuously decreasing frequency (down-chirp) f max = 127 kHz to f min = 0 kHz as shown in Fig. 7. Fig. 8 is an example of cyclically-shifted up-chirp data Symbol 96, which requires SF of 7, as it is one of the combinations of 2 7 .
The symbol example in Fig. 8, 96 decimal = 1, 100, 000 binary is a modulated data. The number of raw bits that can be encoded by this symbol is 7, which means SF = 7. The sweep signal is divided in 2SF = 2 7 = 128 chips. The symbol starts from chip 96 and ends with chip 128 and cyclically-shifted from chips 0 to 95.

Coding rate and data rate:
Due to interference, some of the data bits are lost. Error correction bits recover the original lost data bits. LoRa uses Forward Error Correction (FEC) scheme to avoid a costly re-transmission. FEC requires error correction bits (redundant bits) to be added to the data. Though FEC reduces data throughput but increases the sensitivity of the receiver. LoRa defined set of values which are referred to as Code ∈ {1, 2, 3, 4} to calculate the Coding Rate (CR) based on the following equation: Hence CR = {4/5, 4/6, 4/7, 4/8}. So for SF7, Fig. 9 shows the redundant bits relative to the data bits. CR could maximise the data rate if less code bits are used. However, more redundant bits sent to the receiver, LoRa will consume more power [17].
DR is defined in the following equation: The values of DR for bandwidths from 125 to 500 kHz with SF7 to SF12 are discussed in details in LoRa Patent [18]. Table 3 shows the orthogonality and non-orthogonality combinations of LoRa. Ultra-dense LoRa is designed to implement various topologies including mesh topology with minimum collision rate (Section 4). The collision rate is directly proportional to the orthogonality of LoRa as listed in Table 3.

LoRa packet structure
The LoRa modem employs two types of packet formats, explicit and implicit modes and comprises of three elements; preamble, optional header and data payload. Figs. 10 and 11 show the explicit and implicit header modes, respectively. Both modes are discussed in details in [17].
If the payload, coding rate and CRC presence are fixed or known in advance, the implicit mode could be deployed. This mode reduces the transmission time. Fig. 11 shows the implicit header mode. More in-depth details on this mode can be found in [17].

LoRa packet time-on-air (ToA)
ToA is a unit to measure the transmission time of LoRa packet, as shown in Fig. 12. Fig. 13 shows uplink and downlink chirps that contains preample and payload. A LoRa packet consists of preamble and payload symbols. Hence, packet ToA (T packet ) is the sum of preamble duration (T preamble ) and payload duration (T payload ).
T preamble is a function of T s and by using (1), the symbol period can be defined as shown in the following equation: , T preamble is given below: The length of preamble (n preamble ) is programmable. The data sheet of [17] describes two registers; RegPreambleMsb and RegPreambleLsb, and shows that their functions in LoRa mode is dedicated to store the length of preamble. Again from [17], T payload is extracted as shown in the following equation: From the same reference [17], n payload can be calculated using the following equation: where PL is the number of bytes of payload and SF is the spreading factor. IH is the implicit header mode when (0) or explicit header mode when (1). DE is Low data rate, disabled when (0) or enabled when (1). CRC is not present in payload when (0) or CRC is present in payload when (1). CRC is the programmed coding rate from 1 to 4. Therefore, the total packet time on air T packet is given below:

Adaptive data rate
Adaptive data rate (ADR) is an interesting feature and crucial for IoT infrastructure. It allows for high network performance and enforces scalability. With ADR, LoRa network is able to maximise battery life, range and network capacity for each end-device. This particular LoRa's feature is effective to the proposed project ultradense scheme (Section 4). 'LoRa network allows the end-devices to individually use any of the possible data rates and TxPower. This feature is used by the LoRaWAN to adapt and optimise the data rate and TxPower of static end-devices.' [2]. The ADR mechanism involves set of LoRa commands and parameters. ADR commands are LinkADRReq and LinkADRAns. ADR parameters are ADRParamSetupReq and ADRParamSetupAns. These commands and parameters are embedded in LoRa frame format as shown in Fig. 14. Fig. 14 shows that LoRa protocol consists of layers to include physical layer, MAC layer and application layer. LinkADReq and LinkADRAns are MAC commands as specified by the LoRaWAN specifications [2]. However, each Req/Ans has the same command identifier (CID). They differ if the message is uplink or downlink as shown in Table 4. So, one of them should be used at one time.
FOpts shown in Fig. 14 is used to piggyback MAC commands on a data message. Args are the optional arguments of the command.
For a better explanation, this paper shows ADR procedure as shown in Fig. 15. The network server (via LinkADRReq command) requests an end-device to perform a rate adaptation.
From Fig. 15, an end-device (via LinkADRAns command) answers to the LinkADRReq command with acknowledgment. Bits 1 and 2 for LinkADRAns indicate if TxPower and DataRate have been set or not. Therefore, when the bits 1 and 2 set to (0), the command is discarded and the end-device state is not changed. When set to (1), the data rate and TxPower were successfully set.
Note that the LinkADRReq is used for two purposes. The first is for ADR (requesting data-rate and TxPower). The second is for channel-reconfiguration. Algorithm 1 (see Fig. 16) shows an ADR algorithm with a procedure to calculate the margin by the network server if an enddevice requested ADR. If ADR algorithm is executed, the network server will be able to enhance the data rate and power consumption of the sending device by adapting the most efficient data rate.
In Algorithm 1, NS is the network server and SNR is the signalto-noise ratio. The margin is the range of the expected SNR value on which assigning a new ADR is based.

Related work
This section reviews a set of papers addressing capacity, scalability, reliability, latency, coverage, interference and packet collisions of LoRa.
LoRaWAN and LoRa end-devices use class A, class B and class C modulations. Analysing these classes reveals capacity and scalability issues as described in Section 3.1. In Section 3.2, a mathematical model has been reported to measure throughput to determine the reliability packets transmission within LoRaWAN. LoRa is known with the issue of collision and Section 3.3 reviews the impact of adapting ADR technique and LoRa's different modulation classes on latency. LoRaWAN deploys CSS to offer high immunity to interference. However, Section 3.4 explores studies for LoRa that has been carried out in urban areas and in rural areas and reviews a mathematical model of collision behaviour. The revelation of using higher spreading factor or smaller spreading factor to transmit fixed number of packets over the same distance is apprehensive, this is reviewed in Section 3.5.

Capacity and scalability
Aloÿs et al. [12] carried analysis of LoRaWAN class B enddevices. Reliability is achieved by acknowledgment (ACK) received for data frames received. In LoRaWAN specifications [19] transmitting data frames take place over one of the two receiving windows (RX1 and RX2). This means a delay as a result of the time-off period following each transmission receive window. Such behaviours in LoRaWAN network raise the question of how feasible are class A and class B end-devices for ultra-relible services using LoRaWAN. Aloÿs et al. [14] deployed a technique to avoid the delay happening as a result of waiting for the receiving windows by not sending packets more than the smallest maximum payload size (which was 36 bytes according to their simulation parameters). However, such a solution has a severe impact on the capacity, resulting in lower throughput and higher ToA. Of course class C end-devices provide a constant listing behaviour but at the expense of very high-power consumption.
Mikhaylov et al. [20] carried out analyses on the capacity and scalability of LoRa network. Referring to one of a number of scenarios, LoRaWAN gateway using 3 × 125 kHz channels can serve several millions end-devices. End-devices with a shorter distance to the gateway (up to 2.4 km using DR5) have more data transmission rate (2 kbit/s UP) where further end-devices have a lower transmission rate (100 bit/s). Note that LoRaWAN adheres to end-device duty cycle restrictions (EU regulations [21]). More LoRaWAN scalability scenarios and numeric figures are published in [21,22].

Reliability
Within LoRaWAN, a packet transmission has a serious drawback to the technology. In regards to transmission drawback, Sørensen et al. [23] proposed analytical models that estimate the impact of offered loads on packet error rate. Their models evaluate and estimate the maximum throughput and maximum loads for reliable packets transmission within LoRaWAN.
Aloÿset al. [14] carried out a study of LoRa for IoT. In their study, LoRa's physical and data link layers performance was evaluated by field tests and simulations. From the perspective of a single device maximal throughput, they conducted a test with six 125 kHz channels using a spreading factor of 7-12. Considering a size of 13 bytes MAC header, 51 bytes packet size was the maximum payload allowed to be transmitted between the enddevice and the network server. The diagnoses revealed the receive windows as limiting factors as the device following the initial transmission has to wait for the two downlink receive windows to be done before attempting to send another packet. Thus, this limits the core service behind LoRaWAN, which is allowing a large number of devices to send data from time to the other. The proposed solution to the aforementioned limitation is to avoid sending more than the smallest maximum payload size (36 bytes in their simulation). However, such solution has a severe impact on LoRaWAN capacity and results in lower throughput.

Latency
Since LoRaWAN technology performance depends on the resource allocation and so it employs ADR where each device selects the minimum SF for communicating with the gateway. Cuomo et al. [24] proposed two approaches aiming to enhance the network performance by suggesting allocation schemes of SFs to the network devices and trade the ToA. The two approaches are named as EXPLoRa-SF and EXPLoRa-TA. EXPLoRa-SF equally allocates more than needed SFs to end-devices by means of lower SF to devices with better Received Signal Strength Indicator (RSSI). High SFs provide long range coverage at the expense of increased ToA, which results in more interferences and collisions. Their second approach EXPLoRa-TA aims to equalisation of ToA for each device using the same channel by the means of 'ordered waterfiling'. Both approaches, in particular EXPLoRa-TA result in distinct pros in comparison to ADR especially in improving throughput at high loaded systems (2000 end-devices distributed over 200 m from the gateway).
Delobel et al. [25] carried out a study on the downlink communication delay (performance) for LoRaWAN class B. They proposed Markov chain-based analytic model in which they computed the expected transmission delays. In their work they shed light on a number of limitations within LoRaWAN class B namely gateway duty-cycle limitation, conflict between classes A and B and delay before ACKs sub-band availability. Although duty-cycle limitation that prevents the gateway from sending ACKs in the case of a large number of confirmed uplinks which results in delays (up to 98.13 s before the use of the next ping slot) was highlighted by Delobel et al. [25], but they assumed all data frames can be acknowledged by gateways in which all ping slots can be used.
One more limitation in LoRaWAN specifications [2] is that it does not deter class A devices from sending during ping slots or gateway beacon transmissions which forms conflicts between class A and B devices. Delobel et al. [25] assumed blocking class B enddevices from transmitting during beacon transmission time and ping slots. Moreover, using a Markov chain model for class B confirmed downlink communications, they showed that increasing the data-rate results in reduced frames ToA. In addition, they have also reduced the delay by increasing the number of sub-bands as larger sub-band numbers allows more frames transmissions. Delay was also reduced significantly by increasing the ping periods.

Collision rate
In terms of latency, Sørensen et al. [23], with Markov model of the jockeying queue, they created a matrix A, which contains all state transition probabilities. Matrix A can be used to evaluate the steady-state probabilities, P, by solving the linear system A ⋅ P = 0. Matrix A facilitated the adoption of a Markov model for LoRaWAN device behaviour in the sub-band selection. For the sake of simplicity, they assumed a model of only class A devices which transmit fixed payload size. In addition, all devices are assumed to successfully join the network in which there will be no acknowledgement messages needed (downlink) and hence no retransmissions.
Furthermore, for simplicity, they adopted queuing theory of M/M/c queue in their model taking into account that the mean queue length within M/M/c is twice that of M/D/c. In addition, they adopted jockeying M/M/c queue and carried a comparison of their model in terms of latency against the use of only M/D/c queue. Their approach showed lower latency results.
Following LoRaWAN capacity evaluation, Aloÿs et al. [14] carried a simulation of 500 K packets transmission at a single data point. The results show that the maximum use is 18% of the channel capacity for 0.48 link load. 60% of packets dropped due to collisions (collisions happen when two packets transmission time overlaps). Confirmed messages sent by devices as collisions solution is not practical, as it will result in retransmitting packets several times and thus more delay.
Huang et al. [26] mentioned that regulatory and aggregated duty cycling limitation within LoRaWAN uplink was investigated from the perspectives of latency and collision rate. The proposed models tend to analyse the latency and collisions of packets taking into account sub-channel selection and combining. Results show that sub-band with highest duty cycle provide low latency even in the case of very high loads but with very high collision rate. Vice versa, sub-band with the lowest duty cycle results in high latency even in the case of low loads but very low collision rate. They conclude with the disproportionate relation between latency and collision rate, meaning enhancing one could have severe impact on the other.
Although LoRaWAN is designed for serving large number of devices with minimal need of packets transmissions per day, Rizzi et al. [8] carried an industrial scenario experiment using LoRaWAN. They adapted a similar approach to Time Slotted Channel Hopping (TSCH) where using different SFs were used in the same timeslot. Their approach results in providing each device with one communication opportunity per minute and minimised collision rate due to the accurate time and channel scheduling of TSCH.
Although Mikhaylov et al. [27] empirically investigated that SFs used within LoRaWAN is not orthogonal but the transmission can take place successfully when its power is greater than any other interfering power. Sørensen et al. [23] set out a simple rule in their model that all channels and SFs are orthogonal meaning any two or more transmissions take place over the same channel, SF and time cause a collision. For that reason, their schemes have multi-channel ALOHA random access (same as the case in [12,14,20]) representing LoRaWAN six SFs in six ALOHA channels (orthogonal) within a sub-band. Again for simplicity, they neglected acknowledgement messages meaning there is no downlink and hence no retransmissions. Using their scheme, they were able to quantify the outage caused by collisions by calculating the traffic load and hence the collision probability.
Neumann et al. [28] ran an experiment based on an indoor deployment of a gateway and single LoRa Mote (LoRa tool designed to demonstrate specific LoRa modems capabilities). Both packet loss and packet error where measured based on the mote data transmission from various locations (different floors over different distances). In terms of packet loss and packet error, results vary based on the end-device location. Results showed that devices with lowest data rate (DR0) located on different floors have packet loss decreasing as the device moves further from the gateway. The gateway experienced packet loss of 25% when the device used DR0 at close distance. Vice versa, using higher data rates (DR5) showed an increase of the packet loss at further distances. The gateway experienced packet loss of 27% when the device used DR5 at further distance (the building basement).
One of the issues with LoRa is the collisions as reported by Bor et al. [29]. This paper defined a set of parameters and formalised a model of collision behaviour, C(x, y), for LoRa network between node x and node y: • Carrier frequency, C freq (x, y): The condition when two transmissions collide on CF C freq defined as where f x and f y are the centre frequencies of transmission x and y, and f threshold is the minimum tolerable frequency offset. • Spreading factor, C sf (x, y): The condition when two receptions collide on SF C sf defined as • Power, C pwr (x, y): The condition when packet x collides with packet y on received signal strength defined as where p x is the received signal strength of transmission x and p y is the received signal strength of transmission y and P threshold is the power threshold.
• Timing, C cs (x, y): Packet x collides with packet y when it overlaps in its critical section x cs defined as where the interval for transmission x as x cs = (a x + T sym Δ (N pp − 5), b x ), where T sym is the symbol time and N pp is the number of programmed preamble symbols.

Effect of different SFs on collision rate:
A simulator has been developed and written to simulate C cs , a parameter of (13), using the list of orthogonal and non-orthogonal combinations of SF with BW that was shown in Table 3. The simulation is applied on 1500 LoRa end-nodes EN.
The simulation results are shown in Fig. 17. It shows six SF values to serve LoRa end-nodes EN = {100, 200, 300, …, 1500} randomly distributed around a LoRa gateway using a star topology scheme.
From Fig. 17, if the number of nodes deployed for one LoRa gateway is 100, the collision rate for SF12 is low and it is around 9%. On the other hand, if the number of nodes deployed for one LoRa gateway is 1500, the collision rate for SF12 increases up to 78%.

Coverage and interference
In LoRa, trading-off the coverage range together with the message duration results in the data rate (290 bps-50 kbps) allowed to be transmitted. In [30], LoRaWAN has a coverage range of 2-10 km in urban areas and up to 45 km in rural areas. Of course, further the end-device is from the gateway the lower date rate offered. Again, such behaviour raises concerns of how feasible this technology is for high-reliable services. Due to Chirp Spread Spectrum (CSS), LoRa is known to have very high immunity to interferences [24]. Since LoRa gateways use LoRa CSS physical layer for transmitting data between the end-devices and the network server, Aloÿs et al. [14] carried out a real-time experiment showing that higher SFs results in higher transmitting probability for longer distances (80 out 100 packets were successfully transmitted over a 2800 m coverage distance) than using lower SFs (zero packets were transmitted on the same distance).
Neumann et al. [28] ran an experiment for evaluating enddevices connectivity to a gateway using LoRaWAN. Their model consists of one network server, one gateway and one end-device in indoor deployment style, with the packets transmission size of no more than 17 bytes. Measurements taken based on various locations ranging from 0.5 up to 60 m from the gateway and on different heights (different floors from where the gateway is deployed). Again, the end-device was only set to be class A. In terms of RSSI, results showed a slight effect in regards to further distances but still data packets were successfully transmitted at their furthest experimental distance of 60 m. Moreover, data rates have no effect on the RSSI but only vary in bit rates and latency. Furthermore, in terms of SNR evaluation, results showed no effect as long as the end-device is located at the same floor of the gateway. The SNR was effected when end-device locations changed to different floors. This is due to non-line-of-sight (NLOS) propagation. Placing the end-device in the basement showed an even imploding effect on SNR which results in poor connectivity.
Research studies, experiments and results mainly target the local physics aspects of LoRa. A research study into a large number of connectivity is required and should be ongoing research challenges.

Requirements for LoRaWAN in UDN
The conditional factors for establishing UDN and ultimately insuring its success for large LoRa scale applications. These factors are, indemnifying delivery of packets with their specified time and frequency slot, minimising collision rate and maximising battery life. This requires a novel network topology and this section is presenting and discussing mathematical and graphical topology model.
UDN is a network topology where all gateways reside in a particular area and communicate with each other. All types of bidirectional communications network topologies are shown in Fig.  18. This section come up with Fig. 18 to simplify the ultra-dense LoRa network.
The simplest connection is direct network, as shown in Fig.  18a. The node communicates directly with the gateway. By default is very expensive if there is a large number of nodes. Fig. 18b shows star topology. This is much more economical than direct connection. The number of nodes is defined by the capability of the gateways to transmit and receive data with the end-devices. LoRaWAN protocol dictates star network as stated by IEEE 802.15.4. Hence, for one large building, deploying LoRa system is cost effective. Cluster topology is shown in Fig. 18c. It requires master gateway and slave gateway (cluster heads). The cluster heads do not communicate with each other, so cluster topology is limited to some applications. The cost is relatively higher than star network. Multipurpose connectivity is shown in Fig. 18d and it is called mesh topology. In mesh topology, gateway-nodes are able to communicate to each other as well as with the main gateway. Although the cost is higher, it can serve a very large number of end-devices over large geographical areas. This is a core subject of UDN and can be achieved via LoRa with protocol modifications. Table 5 is an extraction from [31] pros and cons discussion of mesh topology network in terms of scalability, robustness, complexity, network planning, latency, power consumption and coverage area, followed by an explanation of each term in regards to each network topology.
In star topology, messages can be bi-directional transmitted from the nodes to the gateway and vice versa. A similar route is to be followed in cluster topology. Where in mesh topology, messages can be transmitted using any of the available nodes. Such behaviour makes mesh topology much more scalable in comparison to star and cluster topologies (star and cluster topologies are scalable up to the maximum available bandwidth).
Star topology is a default feature for LoRa. To scale up LoRa star network is possible if more LoRa gateways are added to the network. To scale up LoRa cluster, there is a need to have repeater node and this is not available. If we ignore the cost, LoRa mesh topology can be easily scaled up if each node is LoRa gateway.
In star and cluster topologies, the unavailability of the main gateway or the cluster heads result in the whole network being down. This is not the case in mesh topology as the messages can be transmitted through other available nearby nodes. In other words, mesh topology, normally, re-routes its path if one of the gateways/ nodes is not responding or slow. For that reason, mesh topology appears to be more robust in comparison to star and cluster topologies as the network robustness is known as an indicative to the quality of the healing technique or fault tolerance.
Adding more nodes/end-devices within mesh topology network result in other nodes having to deal with more messages hopping. This behaviour makes mesh topology more complex in comparison to star and cluster topologies. Hence, network planning is relatively harder in cluster and mesh topologies than star topology.
Latency and power consumption are low with LoRa star topology, but it is higher in LoRa cluster topology and the highest in mesh topology.
The deployment in terms of coverage area with star topology is a large building size while LoRa mesh can easily cover a city.
Network topology complexity N TC can be measured by the number of devices deployed to achieve its desired objectives. The simplest network topology is the direct topology shown in Fig.  18a, where it only consists of a gateway G W and an end-device node E DN . The network topology complexity N TC for direct topology is represented in the following equation: Star topology shown in Fig. 18b consists of one main gateway G W and n number of end-devices nodes E DN . The following equation formalises the star topology complexity deploying n (provided n > 1) sensors: For example, in a one floor building there are one main gateway, one wall thermostat and three lights. Hence, using (20), the total number of nodes required for star topology is N TC-Star = 1 + 1 + 3 = 5 total nodes Cluster topology shown in Fig. 18c consists of one master gateway G W , m gateways (cluster heads) and a set of end-devices nodes E DN . The following equation formalises cluster topology complexity deploying n sensors: By applying (20) into (21) N TC-Cluster can be expressed in the following equation: For example, in two floors building with a master gateway, each floor has one gateway (cluster head), one wall thermostat and three lights. Hence, using (22), the total number of nodes required for cluster topology is N TC-Cluster = 1 + 2 + 2 × (1 + 3) = 11 total nodes Mesh topology Fig. 18d consists of one master gateway G W , a set of M gateways, and a set of N end-devices nodes E DN . The following equation formalises mesh topology complexity where M = {m 1 + m 2 + m 3 + ⋯ + m i }, N = {n 1 + n 2 + n 3 + ⋯ + n i } and i ∈ IR. For example, three buildings with two floors each, in each building, each floor has one wall thermostat and three light sensors, the thermostat and the three light sensors are connected to the floor's gateway. In each building, the two floors gateways are connected to the building main gateway. The three buildings main gateways pass the collected data to the master gateway. Hence, using (18), the total number of nodes required for mesh topology is N TC-Mesh = 1 + 3 + 2 + 3 × (2 × (1 + 3)) = 30 total nodes Using mesh topology for LoRa may result in higher latency in message delivery when comparing to star topology where the message is directly transmitted between the gateway and the enddevice. Similarly, as the nodes act as routers, power consumption is to be relatively higher than star and cluster topologies where only the gateway is responsible for exchanging messages with other gateways and end-devices. However, with tools like artificial intelligence (AI), the efficiency of the communication between the nodes could be minimised which leads to low latency and power consumption. This conclusion is paving the way to efficient UDN LoRa deployment.

Development/evaluation tools and software for research and development environment
To utilise LoRa technology in various applications, the market has exhibited tools that support researchers and designers to develop complete LPWAN and evaluate its performance. Bor et al. [32] have presented a performance and capability analysis of a currently available LoRaWAN with its nodes to demonstrate how unique features such as concurrent non-destructive transmissions and carrier detection can be employed. Since, the modulator/demodulator was produced by Semtech, evolution boards are available from few suppliers. Some provide Lora Gateway and windows/ISO software tool to configure and run LoRa network. Others come with a gateway, two nodes and windows/ISO software tool. A list of some suppliers are: (a) Mbed launched a gateway development kit at very low cost, as shown in Fig. 19c. The cost currently is at £17 and comes with a set of drives. The low cost offered the opportunity to some researchers to connect ten's of them with one gateway. (b) Microchip 915 MHz LoRa Development Kit for RN2903, as shown in Fig. 19b. This kit comes with the gateway, two nodes and the software tools. Currently, it is priced at £480. The high cost limited some to try only one gateway. (c) Orange Starter Kit LoRa, as shown in Fig. 19a. Currently, it is priced just above £70 for the Gateway. It's reasonable cost has encouraged a good number of researchers to try it.
Thus, realistic models are needed to enable proper assessment of the performance level. Most of the time IoT concept entails a large number of nodes distributed over a wide geographical area, therefore forming a high density and large-scale architecture. Tools such as MATLAB can be used to simulate some functionality of the modulation demodulation scheme. For example, LoRa Chirp modulation technique can be programmed with MATLAB environment to determine the orthogonality and non-orthogonality states.
However, to simulate collisions in LoRa networks and to analyse scalability for one particular IoT application, Thiemo Voigt, and Martin Bor, Lancaster University, 'Lancaster University -LoRaSim' [36] have developed LoRaSim which is a discreteevent simulator. LoRaSim can simulate up to 24 gateways with directional antennas and multiple networks. LoRaSim does not incorporate the MAC part.
Farooq and Pesch [37] have extended LoRaSim to simulate multiple IoT applications within the same LoRaWAN network. This is quite a useful feature to simulate UDN since the user can specify the number of nodes corresponding to each application and the data generation model for each application. Supported data generation models include exponentially distributed traffic (Poisson process), randomly distributed traffic and periodic traffic. LoRaWANSim is another extension to LoRaSim by adding a MAC protocol that is developed by Pop et al. [38]. To study the collision issue Van den Abeele et al. [39] have developed NS-3 LoRaWAN module.

Conclusion
LoRaWAN has a number of pros that make it a potential technology for handling IoT applications at large scale. This paper carried an overview of LoRa modulation and LoRaWAN protocol. Issues, problems and challenges within LoRa are also discussed in detail. Moreover, this paper discussed the feasibility of adapting UDN within LoRaWAN and provided details of Mesh-LoRaWAN topology for UDN. Furthermore, tools and software for evaluating LoRaWAN performance are also reviewed. The paper authors believe that LoRaWAN protocol has a bright future as a solution for future massive-connections and IoT applications. Since, LoRa is operating in an unlicensed radio frequency band, the future trend is that the industry will be encouraged to continue to deploy this technology to the maximum. However, unlike the licensed radio frequency which regulates the transmitted signals, the challenge for LoRa devices is on how to avoid the chaos in the air and reduce the chances of high interferences and hence reduce collisions. In future work, the authors are intending to take this work further and run experiments of Mesh-LoRaWAN in UDN based on real-world scenarios.