Embed Size (px)
Citation preview
978-1-5386-4980-0/19/$31.00 ©2019 IEEE
Leveraging LoRaWAN to Support IoBT in Urban Environments
James Michaelis U.S. Army Research Laboratory
Adelphi, MD, U.S.A. [email protected]
Alessandro Morelli Florida Institute for Human and
Machine Cognition Pensacola, FL, U.S.A.
Adrienne Raglin U.S. Army Research Laboratory
Adelphi, MD, U.S.A. [email protected]
Deryck James
U.S. Army Research Laboratory Adelphi, MD, U.S.A.
Niranjan Suri
U.S. Army Research Laboratory Adelphi, MD, U.S.A.
Abstract — Continued advances in IoT technology have prompted new investigation into usage of Commercial-off-the-Shelf (COTS) technologies for military operations. Key to these efforts have been expanded empirical research on the coverage of IoT communication protocols in the presence of dense urban infrastructure. Through use of a supporting COTS IoT architecture, a LoRaWAN data collect was conducted in the city of Montreal aimed at testing device coverage over roadways in the downtown area. For this data collect, LoRa performance was compared for different data rate values on the North American Industrial, Scientific, and Medical (ISM) 915 MHz band. This work is seen as a key initial step in supporting expanded usage of civilian IoT communication protocols within tactical C2 systems for urban deployment.
Keywords — LoRa/LoRaWAN, Internet of Battlefield Things (IoBT), Commercial-off-the-Shelf (COTS) Technology
I. INTRODUCTION
Continued advances in IoT technology have prompted new investigation into its usage for military operations [1]. This emerging area of research, termed the Internet of Battlefield Things (IoBT), has sought to assess viability of Commercial-off-the-Shelf (COTS) IoT technology to augment and complement existing military sensing assets [2]. Towards supporting the IoBT vision, expanded research on the reliability of IoT communication protocols in urban settings becomes necessary.
The LoRaWAN protocol has gained significant adoption through combined support for low power, long range transmission [3], thereby supporting Low-Power Wide Area Networking (LPWAN) within IoT infrastructures. LoRaWAN’s growing usage in urban environments, mainly due to low deployment costs paired to good receiver sensitivity, has prompted recent investigation on its potential usage within military systems for supporting urban operations (e.g., [4], [5]). However, continued advancement of LoRaWAN’s usage in such IoBT systems requires expanded empirical research on its performance around dense urban infrastructure (e.g., skyscrapers).
Through use of an IoT architecture for tactical C2 support, based on work described in [5], a LoRaWAN data collect was conducted in the city of Montreal aimed at testing device
coverage in the downtown area. For this data collect, LoRa performance was compared for data rates on the North American Industrial, Scientific, and Medical (ISM) 915 MHz band. This work is seen as a key initial step to better understand suitability and applicability of civilian IoT communication protocols within tactical C2 systems for urban deployment.
Section II provides background on LoRa and LoRaWAN, followed by a review of related work. Section III discusses the supporting infrastructure and experimental setup used, focusing on both hardware/software configuration and data collection procedures followed. Section IV provides an analysis of results obtained from the data collect, while Section V concludes with a summary of planned future work.
II. BACKGROUND
A. LoRa / LoRaWAN Basics
LoRa (Long Range) is a proprietary physical layer specification that defines a radio modulation scheme for long-range, low energy, and low data-rate wireless transmissions in the ISM 915 MHz band in North America and the ISM 868 MHz in the EU [6]. The term LoRaWAN refers to an LPWAN protocol that spans the MAC, network, and application layers of the ISO/OSI model (layers 2, 3, and 7, respectively) [7], building on top of the physical layer defined by LoRa. It defines the communication protocol that enables LoRa devices to connect to local area network gateways and the system architecture that provides packets routing, security, and an interface for applications in the LoRaWAN network.
Fig. 1. The LoRaWAN system architecture.
207
Fig. 1 depicts the LoRaWAN system architecture. At the network edge, IoT/IoBT sensors and other devices use LoRa to directly connect (1-hop) and send messages to one or more local gateways, which in turn are connected to a centralized network server via some backhaul (typically cellular, SATCOM, Wi-Fi, or Ethernet). The result is a star-on-star network topology, where the network server and the gateways are the centers of the stars. The network server is responsible for handling duplicated packets coming from multiple gateways and selecting the best gateway through which to send packet acknowledgements and payloads to a specific end device, whenever downlink communication is required. In addition, the network server performs security checks and can control some parameters of end devices, including data rate (when adaptive data rate (ADR) is enabled on the devices), the channel used for transmission (to optimize medium utilization and reduce collisions), and other receiver parameters [8]. Finally, applications servers connect to the network server to receive payloads from and deliver them to end devices.
LoRaWAN devices support up to three different classes of operation [9]. Class-A is designed mainly for uplink transmissions, where devices remain in sleep mode until they have a packet to transmit and have a small downlink transmission window immediately after. Class-A allows LoRa devices to achieve the greatest battery lifetime among all classes of operation, but it does not permit applications to know or estimate the latency associated to packet delivery, which depends uniquely on the end devices’ transmission rate. Conversely, Class-B devices establish downlink reception windows by negotiating a so-called “ping interval”, during which it will activate its receiver to listen for incoming packets. Class-B provides a trade-off between battery efficiency and downlink packet delivery latency. Finally, Class-C devices operate with the receiver always on, enabling gateways to perform downlink transmissions at almost any time, except for during uplink transmissions. The Class-C operation mode is designed for devices directly connected to a power supply, as the energy consumption caused by keeping the receiver on at all times is significant.
B. LoRa Message Encoding
LoRa employs a proprietary spread spectrum modulation scheme that is derived from Chirp Spread Spectrum (CSS) modulation [10], which uses a linear variation in the frequency over time to encode information. One consequence of using CSS modulation is the possibility to achieve high receiver sensitivity with low manufacturing costs.
The most important parameters that affect the bitrate of the modulation and the receiver sensitivity are: bandwidth (BW), spreading factor (SF), and coding rate (CR) [11]. The BW refers to the width of the band occupied by the modulated carrier signal, which in LoRa is the same as the chirp rate (one chirp per second per Hertz of bandwidth). SF is defined as the base-2 logarithm of the number of chirps per symbol. This means that each symbol is composed of 2SF chirps, which can effectively encode SF bits of information. As a consequence, these parameters impact the modulation significantly: increasing the SF by one while keeping the same BW will divide the bandwidth of a single chirp in half and double the duration of the symbol,
effectively reducing the bit rate (but it will not halve it, as one extra bit per symbol will be transmitted); conversely, any change in the BW will have linearly proportional effects on the symbol rate and the bit rate. Finally, LoRa uses a Hamming Forward Error Correction (FEC) code that permits the recovery of bits of information due to corruption by interference at the costs of introducing an overhead in the transmitted bits. Hamming FEC is defined as 4/N, where N ∈ {5,6,7,8}; here, N-4 gives the number of bits dedicated to error detection/correction. This allows us to define the useful bit rate (Rb) as:
Rb = SF × BW/2SF × CR (1)
SF, BW, and CR also affect the receiver sensitivity. In general, increasing the BW reduces the sensitivity as signal interferences are more likely to occur; increasing the SF has a positive effect on the receiver sensitivity; finally, reducing the CR (which translates into increasing N in the Hamming FEC definition given above) also increases the receiver sensitivity, as it increases the number of bits devoted to FEC. As reported in [12], the receiver sensitivity (S) can be approximated by:
S = -174 +10log10(BW) + NF + SNR (2)
In (2), the first term represents the thermal noise in 1 Hz of bandwidth and is only affected by the temperature of the receiver; NF is the receiver noise, a fixed term that depends on the given hardware implementation; finally, SNR represents the signal to noise ratio, which is affected by the modulation parameters.
One key factor of LoRa is that its modulation scheme can provide high receiver sensitivity and very long range with very small power consumption and low manufacturing costs. Another is the ability to demodulate multiple simultaneous signals at the same frequency, provided that they use different data rates, which result in orthogonal SFs. This significantly increases the capacity of LoRa gateways, which can handle a large number of devices [13]. These characteristics, paired with an extremely high energy efficiency that permits battery-operated sensors to achieve lifetimes of up to several years [14], [15], make LoRa a promising choice for IoT/IoBT applications.
Table 1 lists LoRa data rates on the North American ISM 915 MHz band [16] with corresponding values for SF and BW, highlighting differences in supported message payload size. Note that, in addition to impacting payload size, higher SF values and lower BW values provide longer transmission ranges.
TABLE I. LORA DATA RATE SPECIFICATION, NORTH AMERICAN ISM 915 MHZ BAND
Data Rate
Spreading Factor (SF) / Bandwidth (BW)
Data rate(bits/s)
Payload Size (bytes)
DR0 SF10 /125KHz 980 11
DR1 SF9/125 KHz 1760 53
DR2 SF8/125KHz 3125 129
DR3 SF7/125KHz 5470 242
DR4 SF8/500KHz 12500 242
208
C. Related Work
To date, a handful of research efforts have focused on empirical testing of LoRaWAN in proximity to urban environments [11], [17], [18], [19]. Several of these efforts have focused on validation of LoRa coverage at varying fixed distances from base stations (e.g., [11], [20]), while others performed mobile data coverage testing through use of both cars and boats (e.g., [18], [19]). For such efforts, limited focus appears to have been placed on coverage gap analysis for areas with dense urban infrastructure (as noted in [19]). Additionally, to our knowledge, limited prior research has focused on comparing LoRaWAN coverage across different data rates in urban environments.
Narrowband IoT (NB-IoT) and Sigfox represent particularly interesting alternatives to LoRaWAN, as they also provide long-range wireless communications with low throughput and low energy consumption. NB-IoT, which was standardized by the 3rd Generation Partnership Project (3GPP) in June 2016, operates in the LTE licensed spectrum and borrows several aspects from the LTE design specifications [21]. It uses a bandwidth of 180 kHz, offering a maximum data rate of 250 Kbps in download and 200 Kbps in upload and a maximum latency of ~ 10 s. NB-IoT covers up to 8 Km in urban scenarios and up to 25 Km in suburban environments [22], [23] and can accommodate up to ~55k connected devices per cell [24]. To date, NB-IoT experimental evaluations and studies appear to be scarce and limited to simulated environments [21], [25], [26].
Sigfox is a proprietary end-to-end solution for IoT connectivity optimized for long range and low power consumption. The Sigfox network has many similarities with LoRaWAN, such as star topology, the presence of gateways in the territory, and a centralized cloud service. Message transmissions occur over ultra-narrowband channels of 100 or 600 Hz (depending on the region) in the ISM 868 MHz band in EU and the ISM 902 MHz band in North America, using D-BPSK modulation for uplink transmissions and GFSK modulation for downlink transmission [27]. Devices are limited to 140 uplink and 4 downlink messages per day, with a payload of up to 12 bytes and a total of 26 bytes per message, including packet headers; the maximum data rate is limited to 500 bps downlink and 100 bps uplink. Sigfox can cover an area with a radius of up to 10 Km and 50 Km in urban and rural environments, respectively [28]. A few experimental studies have been conducted on the coverage of Sigfox and LoRa in urban and suburban scenarios [27], [29], which do not seem to show significant differences.
III. EXPERIMENTAL SETUP
To support LoRaWAN data collection activities in an urban environment, a COTS IoT architecture for tactical C2 support was utilized, based on work from [5]. Using this architecture, two data collection experiments were conducted: one focused on data rate DR0, and another on comparing data rates DR1 and DR2. Details on the hardware and software setup used in the supporting architecture are described below.
1 https://pycom.io/product/lopy4/ 2 https://pycom.io/product/pysense/
A. Supporting Hardware
LoRa Nodes: A set of LoRa nodes were assembled using PyCom LoPy4 microcontrollers 1 equipped with sensors for transmitting varying forms of information, including GPS coordinates, passive infrared readings, and ambient environmental conditions (as featured on the PySense expansion board2). Fig. 2 shows three GPS-equipped nodes actively used during data collection.
LoRaWAN Gateway: A MultiConnect Conduit IP67 Base Station 3 was utilized, which was configured to support processing of incoming LoRa messages through the pre-installed Node-RED development framework. The base station was deployed on the roof of the Royal Canadian Hussars Armory (4185 Côte-des-Neiges Rd, Montreal, QC H3H 1X2), situated on a hill overlooking Montreal and located approximately 2.5 Km from the downtown area. Fig. 3 shows the location of the base station placement and antenna direction, which was oriented in the direction of the downtown area.
LoRa Node Setup: For data collection, three LoRa nodes were used, each equipped with a LoPy4 microcontroller and GPS sensor (depicted in Fig. 2). These nodes were each attached to the roof of a sedan in two configurations (diagrammed in Fig. 4): one with a LoRa node transmitting at data rate DR0 (Setup 1), and another with two LoRa nodes transmitting at data rates DR1 and DR2, respectively (Setup 2). Initial testing with DR3 and DR4 was conducted, but coverage outside the armory grounds could not be reliably established.
Fig. 2. LoRa nodes, built with LoPy4 microcontrollers and GPS sensors.
Fig. 3. LoRa gatweay position on Royal Canadian Hussars armory roof.
3 https://www.multitech.com/brands/multiconnect-conduit-ip67
209
Fig. 4. Mockup of LoRa node positioning on sedan roof, for both Experiment 1 (Setup 1) and Experiment 2 (Setup 2).
B. Software Configuration
Route Logging: To support logging of routes covered during data collection, GPS tracking software4 was enabled on an Android smartphone, which logged a position for the vehicle once every 3 seconds.
LoRa Node PyCom Code: Each LoRa node was configured with PyCom code depicted in Fig. 5. This code was configured to send dummy GPS values (Latitude: 0, Longitude: 0) if the GPS signal were lost. In such cases, the position of the message could be determined by cross-referencing transmission time with route logs collected separately on the smartphone. Under normal operating conditions, one message was sent by each LoRa node every 9-10 seconds. For each data rate tested, the message payload encoded GPS coordinate entries using 11 bytes.
This code was configured to use the default values for running in LoRaWAN mode in the ISM 915 MHz band. As a consequence, in our tests, ADR was disabled, sensors operated in Class-A, and they performed one single transmission attempt for each message (missing acknowledgements would not trigger re-transmissions), while the coding rate was handled automatically by the LoRaWAN stack [30].
Fig. 5. PyCom code for LoRaWAN GPS sensors.
4 https://play.google.com/store/apps/details?id=com.ilyabogdano- vich.geotracker
C. Data Collection Procedure
During the data collect experimentation, a series of 8 routes were driven through different sections of Montreal, 4 for Experiment 1 (focued on DR0) and 4 for Experiment 2 (focused on DR1 and DR2). As part of our route selection, we attempted to obtain as comprehensive a degree of coverage as possible for streets in and around the downtown area. However, additional data was also collected in Mount Royal Park, as well as from the surrounding suburbs.
Fig. 6 shows tracks (in blue) followed during the data collect, and depicts an aggregation of all 8 routes followed. The circles (in red) denote the following distances from the LoRa gateway: 1 Km, 2 Km, 3 Km, and 5 Km. The furthest distance driven from the LoRa gateway was approximately 8 Km. However, most driving took place within a 5 Km radius of the LoRa gateway.
IV. RESULTS
Tables II and III provide statistics for Experiments 1 and 2, respectively, on messages sent by each LoRa node versus quantity received by the LoRa gateway, grouped by transmission distance. Fig. 7 provides a visual plot of Experiment 1 results, depicting locations of DR0 messages received by LoRa gateway. Likewise, Fig. 8 provides visual plots of Experiment 2 reults, depicting locations of DR1 and DR2 messages received.
Based on findings from Experiment 1, messages could be received as far as 5.5 Km from the gateway, with similar reception in the 1 to 5 Km range. For Experiment 2, DR1 consistently outperformed DR2 at all ranges, with messages for both rates received as far as 4.8 Km from the gateway.
In both Experiments 1 and 2, LoRaWAN coverage could be established in sections of downtown Montreal with significant amounts of potentially obstructing infrastructure (located on average 2.5 Km from the LoRa gateway). However, since different routes were followed for Experiments 1 and 2, a direct comparison of their results cannot easily be conducted.
Fig. 6. Tracks logged during data collection, corresponding to the 8 routes driven across Experiments 1 and 2.
210
Fig. 7. Visual plot of Experiment 1 results, depicting locations of DR0 messages received by LoRa gateway.
Fig. 8. Visual plots of Experiment 2 results. Top: Locations of DR1 messages received by LoRa gateway. Bottom: Locations of DR2 messages received by LoRa gateway.
TABLE II. EXPERIMENT 1 STATISTICS: MESSAGES SENT AND RECEIVED FOR LORA DATA RATE 0
Location Msg. Sent Msg. Received Percent Received
< 1 Km 407 230 56.51%
> 1 Km & < 2 Km 1061 81 7.63%
> 2 Km & < 3 Km 1974 180 9.12%
> 3 Km & < 5 Km 870 65 7.47%
> 5 Km 311 1 < 0.01 %
TOTAL 4623 557 12.05 %
TABLE III. EXPERIMENT 2 STATISTICS: MESSAGES SENT AND RECEIVED FOR LORA DATA RATES 1 AND 2
Location Data Rate
Msg. Sent
Msg. Received
Percent Received
< 1 Km DR1 385 266 69.09%
DR2 386 230 59.59%
> 1 Km &
< 2 Km
DR1 1004 188 18.73%
DR2 1008 80 7.94%
> 2 Km &
< 3 Km
DR1 1867 292 15.64%
DR2 1875 111 5.92%
> 3 Km &
< 5 Km
DR1 1241 84 0.07%
DR2 1247 13 0.01 %
> 5 Km DR1 295 0 0 %
DR2 296 0 0 %
TOTAL DR1 4792 830 17.321 %
DR2 4812 454 9.435 %
V. CONCLUSION
Through use of an IoT architecture for tactical C2 support, based on work described in [5], a LoRaWAN data collect was conducted in the city of Montreal aimed at testing device coverage over most roadways in the downtown area. Based on initial findings from the Montreal data collect, several directions for follow-on research present themselves.
Expanded Dataset Analysis: Focus for this data collection effort was placed on driving around downtown Montreal, in the presence of significant urban infrastructure (including several buildings over 100 meters tall [31]). To date, limited research has been conducted on LoRaWAN's coverage capabilities in Central Business Districts [19], including identification of areas where coverage gaps may likely occur. As such, follow-on analysis of this data collect will be conducted which further accounts for both infrastructure concentration and building heights. Supplemental datasets detailing height of infrastructure (e.g., LIDAR coverage for the Island of Montreal [32]) will be assessed for supporting this effort.
Expanded Comparison of LoRaWAN Configurations: During this data collect, focus was placed on comparing three LoRa data rates (DR0, DR1, and DR2) on the North American ISM 915 MHz band with ADR disabled. Additionally, for each
211
data rate tested, an 11 byte payload was used for transmitting GPS coordinate entries. In future data collects, LoRaWAN coverage will be compared with ADR enabled vs. disabled. Additionally, varying payload sizes will also be used (as supported by each data rate tested) to assess impact on data rate performance.
Comparison of LoRaWAN with Military and Commercial Alternatives: Towards incorporating LoRaWAN into tactical C2/IoBT systems, comparison of its coverage in dense urban settings to alternative protocols becomes desirable. Towards this end, future data collects will be planned that compare LoRaWAN's coverage with existing military technologies, such as BAIS (Battlefield Anti-Intrusion System) [33] and EUGS (Expendable Unattended Ground Sensors) [34]. Similarly, comparisons of LoRaWAN coverage will be conducted with commercial IoT protocols, such as NB-IoT and SigFox.
REFERENCES [1] A. Kott, A. Swami, and B. J. West, “The internet of battle things,” IEEE
Computer, vol. 49, no. 12, pp. 70-75, Dec. 2016.
[2] N. Suri, M. Tortonesi, J. Michaelis, P. Budulas, G. Benincasa, S. Russell et al., “Analyzing the applicability of internet of things to the battlefield environment,” In 2016 International Conference on Military Communications and Information Systems (ICMCIS), pp. 1-8. IEEE, 2016.
[3] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui, and T. Watteyne, “Understanding the limits of LoRaWAN,” IEEE Communications Magazine, vol. 55, no. 9, pp. 34-40, 2017.
[4] F.T. Johnsen, Z. Zieliński, K. Wrona, N. Suri, C. Fuchs, M. Pradhan, J. Furtak et al. “Application of IoT in military operations in a smart city,” In 2018 International Conference on Military Communications and Information Systems (ICMCIS), pp. 1-8. IEEE, 2018.
[5] B. Jalaian, T. Gregory, N. Suri, S. Russell, L. Sadler, and M. Lee, “Evaluating LoRaWAN-based IoT devices for the tactical military environment,” In Internet of Things (WF-IoT), 2018 IEEE 4th World Forum on, pp. 124-128. IEEE, 2018.
[6] European Telecommunications Standards Institute (ETSI), “EN 300 220-1 v2.4.1,” Jan. 2012. [Online]. Available: https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/02.04.01_40/en_30022001v020401o.pdf [Accessed Feb. 27, 2019].
[7] LoRa Alliance, “LoRaWAN – What is it? A technical overview of LoRa and LoRaWAN”, Nov. 2015. [Online]. Available: https://lora-alliance.org/sites/default/files/2018-04/what-is-lorawan.pdf [Accessed Feb. 27, 2019].
[8] LoRa Alliance, “LoRaWAN™ 1.1 Specification,” Oct. 11, 2017. [Online]. Available: https://lora-alliance.org/resource-hub/lorawantm-specification-v11 [Accessed Feb. 27, 2019].
[9] LoRaServer Website, “LoRaServer – Features Overview,” [Online]. https://www.loraserver.io/loraserver/features/ [Accessed Feb. 27, 2019].
[10] SEMTECH, “AN1200.22 – LoRa Modulation Basics, Revision 2, Wireless, Sensing and Timing Products,” [Online]. Available: https://www.semtech.com/uploads/documents/an1200.22.pdf [Accessed Feb. 27, 2019].
[11] A. Augustin, J. Yi, T. Clausen, W. M. Townsley, “A study of LoRa: long range & low power networks for the internet of things,” Sensors, vol. 16, no. 9, pp. 1-18, Sep. 2016.
[12] SEMTECH, “SX1272/3/6/7/8: LoRa modem – designer’s guide – AN1200.13 – Revision 1,” Jul. 2013. [Online]. Available: https://www.semtech.com/uploads/documents/LoraDesignGuide_STD.pdf [Accessed Feb. 27, 2019].
[13] SEMTECH, “Real-world LoRaWAN network capacity for electrical metering applications,” Sep. 2017. [Online]. Available: https://blog.semtech.com/understanding-the-lorawan-capacity-whitepaper [Accessed Feb. 27, 2019].
[14] L. Casals, B. Mir, R. V. Ferré, C. Gomez, “Modeling the energy performance of LoRaWAN,” Sensors, vol. 17, no. 10, Oct. 2017.
[15] R. S. Sinha, Y. Wei, S.-H. Hwang, “A survey on LPWA technology: LoRa and NB-IoT,” ICT Express, vol. 3, no. 1, pp. 14-21, Mar. 2017.
[16] Multi-Tech Systems, “Introduction to LoRa,” [Online]. Available: http://www.multitech.net/developer/software/lora/introduction-to-lora/ [Accessed Feb. 27, 2019]
[17] A.J., Wixted, P. Kinnaird, H. Larijani, A. Tait, A. Ahmadinia, and N. Strachan, “Evaluation of LoRa and LoRaWAN for wireless sensor networks,” IEEE Sensors, pp. 1-3. IEEE, 2016.
[18] J. Petajajarvi, K. Mikhaylov, A. Roivainen, T. Hanninen, and M. Pettissalo, “On the coverage of LPWANs: range evaluation and channel attenuation model for LoRa technology,” in 14th International Conference on ITS Telecommunications, Dec. 2015, pp. 55–59.
[19] P.J. Radcliffe, K.G. Chavez, P. Beckett, J. Spangaro, and C. Jakob, “Usability of LoRaWAN technology in a central business district,” In 2017 IEEE 85th Vehicular Technology Conference (VTC Spring), pp. 1-5. IEEE, 2017.
[20] T. Søndrol, B. Jalaian and N. Suri, “Investigating LoRa for the internet of battlefield things: a cyber perspective,” In IEEE Military Communications Conference (MILCOM), Oct. 2018.
[21] A. Adhikary, X. Lin, Y.-P. E. Wang, “Performance evaluation of NB-IoT coverage,” 2016 IEEE 84th Vehicular Technology Conference (VTC-Fall), Montreal, QC, pp. 1-5, 2016.
[22] J. Chen, K. Hu, Q. Wang, Y. Sun, Z. Shi, S. He, “Narrowband internet of things: implementations and applications,” in IEEE Internet of Things Journal, vol. 4, no. 6, pp. 2309-2314, Dec. 2017.
[23] Y. Li, X. Cheng, Y. Cao, D. Wang, L. Yang, “Smart choice for the smart grid: narrowband internet of things (NB-IoT),” in IEEE Internet of Things Journal, vol. 5, no. 3, pp. 1505-1515, Jun. 2018.
[24] R. S. Sinha, Y. Wei, S.-H. Hwang, “A survey on LPWA technology: LoRa and NB-IoT,” ICT Express, vol. 3, no. 1, pp. 14-21, 2017.
[25] M. El Soussi, P. Zand, F. Pasveer, G. Dolmans, “Evaluating the performance of eMTC and NB-IoT for smart city applications,” 2018 IEEE International Conference on Communications (ICC), Kansas City, MO, pp. 1-7, 2018.
[26] M. Lauridsen, H. Nguyen, B. Vejlgaard, I. Z. Kovacs, P. Mogensen, M. Sorensen, “Coverage comparison of GPRS, NB-IoT, LoRa, and SigFox in a 7800 km² area,” 2017 IEEE 85th Vehicular Technology Conference (VTC Spring), Sydney, NSW, pp. 1-5, 2017.
[27] K. E. Nolan, W. Guibene, M. Y. Kelly, “An evaluation of low power wide area network technologies for the internet of things,” 2016 International Wireless Communications and Mobile Computing Conference (IWCMC), Paphos, pp. 439-444, 2016.
[28] M. Centenaro, L. Vangelista, A. Zanella, M. Zorzi, “Long-range communications in unlicensed bands: the rising stars in the IoT and smart city scenarios,” in IEEE Wireless Communications, vol. 23, no. 5, pp. 60-67, Oct. 2016.
[29] M. Lauridsen, B. Vejlgaard, I. Z. Kovacs, H. Nguyen, P. Mogensen, "Interference measurements in the european 868 MHz ISM band with focus on LoRa and SigFox", 2017 IEEE Wireless Communications and Networking Conference (WCNC), San Francisco, CA, pp. 1-6, 2017.
[30] PyCom, “LoRa Pycom documentation,” [Online]. Available: https://docs.pycom.io/firmwareapi/pycom/network/lora.html [Accessed Feb. 27, 2019]
[31] Skyscraper Source Media, “Montreal Skyscraper Map,” [Online]. Available: http://skyscraperpage.com/cities/maps/?cityID=22 [Accessed Feb. 27, 2019]
[32] XEOS Imagerie inc., “LiDAR Aérien 2015,” Apr. 2018. [Online]. Available: http://donnees.ville.montreal.qc.ca/dataset/lidar-aerien-2015 [Accessed Feb. 27, 2019]
[33] L3 Communication Systems-East, “AN/PRS-9A Battlefield Anti-Intrusion System (BAIS),” Aug. 2013. [Online]. Available: https://www2.l3t.com/cs-east/pdf/bais.pdf [Accessed Feb. 27, 2019]
[34] Applied Research Associates, “Pathfinder Sensing,” [Online]. Available: https://www.ara.com/pathfinder [Accessed Feb. 27, 2019]
212
