Repositorio Institucional

Low-Power Wide Area Networks (LPWAN) for Communications of Mobile Sensor Data



Sebastian Barillaro*,†

Engineering Laboratory National Institute of Standards and

Technology Gaithersburg MD USA sebastian.barillaro@nist.gov barillaro@inti.gob.ar

Raghu Kacker††

Information Technology Laboratory National Institute of Standards and

Technology Gaithersburg MD USA raghu.kacker@gmail.com



Sokwoo Rhee†

Engineering Laboratory National Institute of Standards and

Technology Gaithersburg MD USA sokwoo.rhee@nist.gov

Lee Badger††

Information Technology Laboratory National Institute of Standards and

Technology Gaithersburg MD USA

lee.badger@nist.gov



Gustavo Escudero*

Departamento de validación de dispositivos y sistemas electrónicos

Instituto Nacional de Tecnología Industrial

Buenos Aires, Argentina gescudero@inti.gob.ar

D. Rick Kuhn††

Information Technology Laboratory National Institute of Standards and

Technology Gaithersburg MD USA

d.kuhn@nist.gov



ABSTRACT

There are multiple options for communication of data to and from mobile sensors. For tracking systems, Global Navigation Satellite System (GNSS) is often used for localization and mobile-phone technologies are used for transmission of data. Low-power wide area networks (LPWAN) is a newer option for sensor networks including mobile sensors.

We developed a tracking system use case application using LPWAN as communication channel for mobile sensor data. The choice of LPWAN has pros and cons. In this paper, we discuss the differences between LPWAN and other technologies as communication channel for sensor networks. We describe the LPWAN test setup and analyze its characteristics including transmission frequency, coverage, latency and communication range.

* Department of electronic devices and systems validation, National Institute of Industrial Technology, Buenos Aires, Argentina † Smart Grid and Cyber-Physical Systems Program Office, Engineering Laboratory, National Institute of Standards and Technology, U.S. Department of Commerce †† Information Technology Laboratory, National Institute of Standards and Technology, U.S. Department of Commerce

Publication rights licensed to ACM. ACM acknowledges that this contribution was authored or co-authored by an employee, contractor or affiliate of the United States government. As such, the Government retains a nonexclusive, royalty-free right to publish or reproduce this article, or to allow others to do so, for Government purposes only. Official contribution of the United States government; not subject to copyright in the United States.

SCC '19, September 10–12, 2019, Portland, OR, USA © 2019 Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-6978-7/19/09 $15.00 https://doi.org/10.1145/3357492.3358629



CCS CONCEPTS

Network performance analysis, Network components, Embedded and cyber-physical systems, Sensor networks

KEYWORDS

IoT, Internet of Things, LPWAN, Tracker System, LoRa, LoRaWAN, Sensor Network

ACM Reference format: Sebastian Barillaro, Sokwoo Rhee, Gustavo Escudero, Raghu Kacker, Mark Lee Badger, D. Rick Kuhn. 2019. Low-Power Wide Area Networks (LPWAN) for Communications of Mobile Sensor Data. In Proceedings of the 2nd ACM/EIGSCC Symposium On Smart Cities and Communities (SCC 2019). ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/1234567890

1 Introduction

The emergence of low power wireless technologies has catalyzed broad adoption of Internet of Things (IoT) applications over the past several years. A typical IoT implementation includes a number of components and building blocks; one of the fundamental building blocks of IoT implementation is the communication and networking layer. Due to diverse requirements unique to each IoT application, a number of different technologies are being developed and adopted for communication and networking. For the applications involving wireless sensors and actuators, the selection of wireless communication technology becomes a critical task. There are a number of fundamental characteristics to be considered when designing a wireless communication technology for an IoT application, and it should be chosen based on a careful analysis of the application requirements. Most of the wireless communication technologies will come with some type



SCC 2019, September, 2019, Portland, Oregon, USA

of tradeoff among different characteristics such as data rate, power consumption, communication distance, latency, cost, reliability, robustness, and security. For example, a technology with higher data rate may need to consume more power. Another technology capable of both high data rate and low power may not be able to communicate in a long range. Because of these tradeoffs, a number of wireless technologies such as WiFi, Bluetooth, and Zigbee are discretely used in various IoT applications depending on their requirements. Low power wide area network (LPWAN) is a wireless communication technology specifically designed to focus on low power and long-range communication. LPWAN is a promising technology with a great potential to be adopted in a number of smart city applications including metering, localization, transportation, and flood monitoring. However, it is important to understand the practical limitation of its characteristics before designing it in an application. To analyze its characteristics, a LPWAN test network was implemented in the main campus of the National Institute of Standards and Technology (NIST) in Gaithersburg, Maryland, USA, with coverage extended to its vicinity area. The test setup was developed to focus on localizations and tracking application. In this paper, the setup of the test network is described, and the test results are presented.

2 LPWAN General Characteristics

LPWAN is not a single technology. It is a set of several technology options with the shared goal of fulfilling specific sensor network requirements. Commercially known as 0G [1], there are plenty of options to choose from. Although these technologies are always prioritized on wider area coverage and minimal energy consumption over data rate, it is possible to apply them to a variety of uses cases which require different degrees of data rate, communication periodicity, latency, distance, etc. Since these technologies are optimized for energy consumption, some of them cannot handle Internet Protocol (IP) Headers, hence are not IP-compliant.

2.1 LPWAN Options

There are many LPWAN options. The list is broad and its borderline is not clearly defined. It is not the intention of this paper to discuss what is, and what is not an LPWAN option nor make an exhaustive analysis about all of them. However, a noncomprehensive list is given as starting point for readers that would desire to dive deep. This list is divided according to whether a license is required or not to operate in a specific frequency.

2.1.1 Cellular LPWAN Options

• LTE Cat 1 • LTE Cat 0 • EC-GSM-IoT • LTE Cat M1 (also known as LTE-M) • LTE Cat M2 • LTE Cat NB1 (also known as NB-IoT)



• LTE Cat NB2



S. Barillaro et al.



2.1.2 Non-Cellular LPWAN Options

• Sigfox • IngeNU (formerly RMPA) • LoRa/LoRaWAN • LoRa/M.O.S.T. • LoRa/Symphony Link

Due to NIST’s IT security restrictions and policies, four main requirements, among others, were considered when selecting a technology to be tested:

• No proprietary solutions. • Built-in security in specification. • Ownership of entire platform. • No Internet connection required.

All these LPWAN options were analyzed based on available literatures. IngeNU did not meet requirements due to be a proprietary specification. Sigfox, LTE-M, and NB-IoT require Internet connection and cannot be deployed as an isolated network without Internet access. LoRa is a proprietary technology, but LoRaWAN Protocol is an open standard. It does not require Internet connection and its deployment can be done entirely on premises at The NIST Campus as a standalone system. LoRaWAN also has built-in security measures and is broadly adopted. LoRaWAN alternatives (M.O.S.T and Symphony Link) also did not meet requirements due to its nature as a proprietary technology. After considering all these options, LoRa/LoRaWAN was selected as the LPWAN option to study its characteristics.

2.2 LoRa/LoRaWAN

LoRa (short for Long Range) and LoRaWAN (LoRa Wide Area Network) refer to different meanings and concepts. LoRa is a spread spectrum modulation technique derived from chirp spread spectrum (CSS) technology with an operational frequency in the sub-GHz ISM band. The LoRa-Alliance defines regional specification according to local regulations dictated by local telecommunication authorities. The most widely adopted operating frequencies are the US915 band which includes 64 x 125 kHz width channels and 8 x 500 MHz width channels between 902.3 and 914.9 MHz; and the EU868 band, which includes 8 x 125 kHz channels and one 250 kHz channel between 863 to 870 MHz. Full detailed specification is available on the LoRa-Alliance website [2]. LoRaWAN (formerly known as LoRaMAC) is the specification for Medium Access Control (MAC). The specification [3] is maintained by LoRa-Alliance, a consortium with more than 500 members including companies, research institutions and universities. LoRaWAN is designed to minimize and make efficient use of energy by End-Nodes. It is also designed to communicate bi-directionally, although messages from End-Node to Network (uplink) are prioritized over messages from Network



LPWAN for Communications of Mobile Sensor Data

to End-Nodes (downlink). According to LoRa-Alliance, LoRaWAN supports geo-localization of End-Nodes by the Network Server [4]. However, its feasibility is still being discussed [5]. As shown in Figure 1, there are at least 5 main components in any LoRa/LoRaWAN Topology. They are described in sections 2.2.1 to 2.2.5. Section 2.2.6 describe the dynamic of communications.

Figure 1: Lora/LoRaWAN Topology

2.2.1 End-node An End-Node could be any electronic device, which are generally sensors, although they may be actuators as well. An End-Node has a radio module to transmit (up-link) and to receive (down-link) data through LoRa RF Link to/from Cloud. Communication is half-duplex in a specific frequency at a time. An End-Node first encrypts the payload (usually sensor data) using Application Session Key (AppSKey). Then, it encrypts the entire message, including headers and the encrypted payload with Network Session Key (NetSKey). After these two encryption processes, the End-Node transmits the message in a LoRa packet.

2.2.2 Gateway The Gateway is an interface between LoRa End-Nodes and the backhaul network. A LoRa interface radio module in a Gateway is used to communicate with End-Nodes through the LoRa RF Link. The LoRa interface radio module in a Gateway is more complex than its counterpart in an End-Node. It is composed of sophisticated and sensitive integrated chips, combining one or more transceivers with at least one Digital Signal Processor (DSP) capable of receiving radio signals in several channels simultaneously. Gateways are usually equipped with a Global Navigation Satellite System (GNSS) sensor which adds timestamps to the messages received. Gateways do not interpret messages. They do not have any security key to decrypt messages. They only check packet integrity and forward the messages to the Network Server, which is connected to Gateways through a regular IP Network usually



SCC 2019, September, 2019, Portland, Oregon, USA

implemented over an Ethernet or cellular link. The process is reversed for messages that go from the Network Server to EndNodes.

2.2.3 Network Server The Network Server is the manager of network. There is only one Network Server per LoRa Network. It registers End-Nodes, Gateways, and Application Servers. The Network Server receives LoRa frames wrapped in IP packets from gateways, and sort out and discard possible duplicate messages that may be received by more than one gateway connected to the same network. It decrypts LoRa frame using NetSKey and passes the encrypted payload to the respective Application Server. When the network traffic flows in the other direction, the Network Server encrypts messages, including headers and payloads (which are already encrypted with AppSKey, by Application Servers) using NetSKey and assigns them to a gateway to be forwarded to an End-Node. Because AppSKey and NetSKey are different, the Network Server does not have access to the encrypted payloads.

2.2.4 Application Server Application Servers (there may be more than one per network) are the final destination of encrypted payloads from End-Nodes in the LoRa system. It is worth noting that the payload transmitted and received by the LoRa system may continue its way through the cloud to a final destination where it becomes useful, such as a database or dashboard. However, that part of the IoT System is out of scope of the LoRa/LoRaWAN architecture although it can be conceptually aggregated in an Application Server. Application Servers have the AppSKey to decrypt payloads.

2.2.5 Join Server Join Server plays a role at the beginning of communications which handles Join-Request from End-Nodes during activation stage. Join Server was added in LoRaWAN Specification [3] v1.1 to support the segregation of key management. A deep analysis of the modifications made in v1.1 can be found in [6].

There might be more components. For example, LoRaWAN v1.1 includes Home Server, Forwarding Server and Serving Server to support Roaming between networks [7].

2.2.6 Protocol Operation LoRa/LoRaWAN protocol operation may be divide in 2 stages: Activation and Communication. Activation is a process to authorize a device to communicate in the network. A successful activation will result in a valid session. Communication occurs while the session remains valid.

2.2.6.1 Activation Stage The goal of activation stage is to have End-Nodes and Servers (both Network and Application) agree on Session Keys. This goal can be achieved through two different methods: Activation by Personalization (ABP) or Over the Air Activation (OTAA).



SCC 2019, September, 2019, Portland, Oregon, USA

In OTAA method, the End-Node and Network Server exchange a series of random numbers signed and encrypted with pre-shared keys, i.e., Network Key (NetKey) and Application Key (AppKey). After a successful handshake, both sides derive identical Session keys that will be used in Communication Stage. Session keys derived are known as Network Session Key (NetSKey) and Application Session Key (AppSKey). In the ABP method, derived Session Keys (NetSKey and AppSKey) are pre-implanted in both sides before deploying EndNodes. There is no handshake to derive Sessions Keys. When using the ABP method, it is unlikely that Session keys will ever change, making the sessions valid for unlimited time. Although implementation is easier, ABP method is considered less secure.

2.2.6.2 Communication Stage Once End-Nodes are activated (with ABP or OTAA), they are authorized to communicate with Servers. With few exceptions, communications are initiated by End-Nodes, determined by the class of device. For Class A devices, an End-Node starts communication by transmitting a LoRa Packet. After a successful transmission, the End-Node opens a short receiving window to allow the Network to send a response. If no message is received, a second receiving window, which is longer, is opened. After that, it is up to the End-Node to decide when to re-start Communication Stage. It is assumed that End-Nodes are in sleep mode most of the time, with no way to receive any message from the Network during the sleep. If Network wants to communicate with EndNodes, it has to wait until End-Nodes decide to start communication again, which may result in undetermined latency for down-link messages. Class B devices vary from Class A devices in that an End-Node opens up receiving windows periodically. Since it is assumed that End-Nodes has no accurate Real Time Clock (RTC) and they sleep during no-transmission, their receiving window timing should be synchronized by beacons sent by Gateways. Class B devices keep a balance between downlink latency and End-node energy consumption. The Class B category of devices was announced at the beginning of LoRaWAN Specification but implemented in version 1.1. Finally, Class C implements an always-open receiving window on EndNodes. In this manner, latency can be reduced at the expense of End-Node’s power consumption.



S. Barillaro et al. Figure 3 and Figure 4, this shuttle bus was used as a mobile object for the experiment and was equipped with a GSNN sensor. A Gateway and its antenna were installed on the roof of the tallest building (11 stories) on the NIST campus and in the vicinity area. Then, Network and Application server were installed on a laptop. Another computer with a large screen were used to show the location of the shuttle bus.

Figure 2: Simulated aerial view of the NIST Shuttle route area. The high-rise building in the foreground is where the gateway was deployed. In the background, the landmark

points where the Shady Grove metro station is.

3.1 NIST LPWAN Facility Infrastructure

NIST LPWAN Facility was deployed using a LoRa/LoRaWAN Infrastructure. This deployment had been made before of LoRaWAN v1.1 specification was released. Thus, no Join-Server was deployed. A detail of infrastructure is described in Figure 3 and following sub-sections.



3 LPWAN Experiments at NIST

The LPWAN technology is designed for extreme efficiency in both distance and power consumption over the data rate. However, the data rate can be improved if the energy source is not limited. An experiment was designed to challenge the coverage and the data rate without restriction of energy source. NIST has a shuttle service that transports people between the Shady Grove Metro Station and the NIST campus. The Shady Grove Metro Station is located 4.89 km (3.04 mi) as the crows flies from the NIST campus, as shown in Figure 2. The shuttle bus travels 10 km (6.2 mi) in 15 minutes each way. Most of the path is on local highways at speeds up to 90 km/h (60 mi/h). As shown in



Figure 3: NIST LPWAN Testing Facility Infrastructure



LPWAN for Communications of Mobile Sensor Data

3.1.1 End-Node Each End-Node was assembled by combining a development module, Pycom FiPy, with an expansion board including a GNSS sensor Pycom PyTrack (see Figure 4). An End-Node was connected to the vehicle power source of the shuttle bus, which eliminated the issue of limitation of power supply. The antenna attached to the End-Node was a 4 dBi water-proof omnidirectional antenna with magnetic base and 1.5 m cable passing through the driver’s window. End-Node software was coded in micro-Python. End-Nodes transmit in any of the 64 channels allowed in ISM US-915 specification by default. The End-Nodes were configured to use only the transmission channels covered by The Gateway. Application ID (APPEUI) and Application Key (AppKey) were also set in the End-Node software configuration. After configuration, each End-Node executed a join handshake via Over-The-Air-Authentication (OTAA) until it received a join confirmation. Finally, it ran an infinite-loop where it calculated the GPS coordinates using the GNSS location sensor and transmitted it through LoRa/LoRaWAN.

Figure 4: a) NIST Shuttle. b) Pycom FiPy + PyTrack Location Sensor

3.1.2 Gateway The Gateway was built with a LoRa Gateway Module RisingHF RHF0M301 on top of a Raspberry Pi, as shown in Figure 5. The LoRa Gateway Module was equipped with SX1301 + 2x SX1257, capable of covering one sub-band (8 + 1 channel) of 8 sub-bands (64 + 8) channels available in the ISM US-915 specification. The same type of antenna was used by both EndNode and Gateway. Packet-forwarder was provided by Gateway manufacturer, based on an implementation by Semtech. PacketForwarder was configured to communicate with Network Server. The Packet-forwarder was configured to use the operating frequency (US-915) and sub-band 1: channels 8 to 15 in 903.9 905.3 MHz frequency. Raspberry Pi OS (Raspbian) configuration was modified to meet the NIST IT Security policies. After that, the device was approved by NIST IT Security Officer and connected to the NIST-Net LAN Network. This Gateway was installed inside a weather-proof box on the roof of the Administration Building which is eleven stories tall.

3.1.3 Network Server The selection process of a Network Server was based on the same criteria as the choice of the LPWAN technology, i.e., no



SCC 2019, September, 2019, Portland, Oregon, USA

proprietary solutions, built-in security, possibility of ownership of the entire platform, and execution without Internet connection.

Figure 5: a) Gateway Module. b) Antenna (not in scale)

LoRa Server was selected as Network Server to be consistent with the criteria. LoRa Server software was deployed in a virtualized instance of Linux running on a Macbook Pro laptop. Some confusion may arise from the nomenclature of LoRa Server components. Two main components in the LoRa Server project named Network Server and Application Server make up what LoRaWAN specification calls Network Server. In order to avoid ambiguity on nomenclature, “LoRaServer-” prefix is added when referring to LoRa Server project components. The functional responsibility of the network-server component (LoRaServernetwork-server) is to de-duplicate and process uplink frames received by the gateway(s), to handle the LoRaWAN mac-layer, and to schedule downlink data transmissions [8]. LoRaServerApplication-Server is responsible for the device “inventory” part of a LoRaWAN infrastructure, handling join-requests as well as handling and encryption of application payloads [9]. All the administration and configuration are done via a web interface, as shown in Figure 6. Basic configuration includes: Registration and parametrization of Gateway(s), End-Node(s), and their integration to handle communication with LoRaWANApplication-Server (the Application Server, according to the LoRaWAN specification nomenclature).

3.1.4 Application Server The selection process of an Application Server software was based on the same criteria as the Network Server. InfluxDB [10] for data storage, combined with Grafana [11] for data visualization, were deployed in another virtualized instance of Linux, in the same Mac Laptop Host. Most of the InfluxDB configuration was done via the command-line interface except all the Grafana Configuration which was done using a web interface. A Grafana Worldmap Panel [12] was installed to show End-Point location in the map.

3.1.5 Tracking System Dashboard A computer with a web-browser displayed on a large screen was demonstrated at SIM Week in September 2018 [13].



SCC 2019, September, 2019, Portland, Oregon, USA



S. Barillaro et al.

the location at the time it was displayed on the map? To answer this question, the location of the shuttle on the map was checked when the shuttle was approaching the Administration Building, while both the NIST shuttle and the map could be observed at the same time. It was confirmed that the location of the shuttle on the map was correctly displayed during this test. This was a special situation where the shuttle was moving very slowly. But it was impossible to answer that question while the NIST shuttle was traveling on highway and was out of sight. Although there are many steps involved between acquisition of the geographic coordinates by the GNSS sensors and display of the orange dot on the map, the current test solely focused on the end-to-end latency of the system as a whole.



Figure 6: Gateway Status in LoRaServer. Altitude shows a wrong value due lack of GNSS sensor. Bottom graph shows

frames received per day.

3.2 Experimental Tests

All tests were exploratory. The intention was to learn about LPWAN technologies from first-hand experiences, over and beyond technical references and marketing brochures. All the test should be considered preliminary and their results cannot be considered as conclusive.

3.2.1 Transmission frequency test (pre-deployment test) This test consisted of transmitting empty packets (no payload) from the End-Node without requesting acknowledgement or delay between cycles in the loop. It was possible to receive a message almost every second under nearly ideal condition. For this test, the Gateway and the End-Node were placed inside the same room with metal walls.

3.2.2 NIST Shuttle route coverage test Second test showed that the NIST shuttle bus could be tracked throughout almost the entire route. There were some blind spots where the transmissions were lost, possibly due to ground conditions, bridges, electrical transformers, etc. Figure 7 shows all locations where signal was received during a work day. Unlike the first test, the frequency of reception of messages decreased – once every 2 seconds to 4 seconds, if not more.

3.2.3 Latency Test Another interesting characteristic to consider was the responsiveness of the system (Latency). Packets were received from a number of locations, but was the NIST shuttle actually at



Figure 7: Accumulated locations received from the NIST Shuttle, including from unanticipated alternative routes.

In an LoRa/LoRaWAN infrastructure, the timestamp is assigned to a message by packet-forwarder software running in the gateway that receives the message. The gateway clock is synchronized with GNSS time, or with the Network Time Protocol (NTP) server in case that there is no GNSS Sensor. LoRa/LoRaWAN does not require end-nodes to have an RTC. This way, the endnodes can be more inexpensive and more power efficient. If needed, an end-node may have an RTC to add a timestamp to sensor data. But this timestamp should be transmitted as part of the payload, which makes messages longer. Our end-node was equipped with GNSS which could be used to add a timestamp to the location data. Unfortunately, Location Library offered by Location Sensor Manufacturer did not offer GNSS Time [14]. New libraries were developed by Pycom’s user community to solve this problem, but they were not ready at the time of this test. Another option was to add a hardware RTC, but that would make the end-node more complex. The problem was easily solved by using a separate reference system. A passenger equipped with a smartphone aboard the NIST Shuttle volunteered to help the study and reported independent real-time location data using a smart-phone LTE connection. The End-Node transmitted its location through the LPWAN setup in the NIST Facility as designed. Both location data sets were observed at the same time on the same screen. With the exception



LPWAN for Communications of Mobile Sensor Data

of some lost messages, it was possible to observe a good correlation between the two data sets, as shown in Figure 8.



SCC 2019, September, 2019, Portland, Oregon, USA

i.e., transmission frequency, coverage, latency, and communication range. However, there are a number of additional characteristics that may have a significant impact on the overall performance of the IoT system based on the LPWAN technology. Examples includes, but not limited to, scalability, power consumption, robustness against interference, and co-existence with other types of wireless technologies. The timescale used in the latency test in this experiment was in the order of minutes and the measurement was done based on qualitative human observation. Future experiments may need to employ more quantitative measurement methods using more accurate references.



Figure 8: Side-by-side comparison. On the left, real-time location received through LTE connection. On the right, location received through the NIST LPWAN infrastructure. The upper orange dot shows the last received location, coinciding with same location reported through LTE link at

that time.

3.2.4 Range test Typical marketing brochures and white papers about wireless communications specify communication range in terms of physical distance. However, comparison of different technologies should use link-budget as the main parameter. Even with the same link-budget, communication range is seriously affected by terrain shape, weather condition, and existence of physical objects like buildings and trees that affect propagation of signal. A range test would tell us more about the context of the deployment than the technology itself. The last test was conducted to check the communication range of a device in the LPWAN infrastructure at NIST which was deployed to cover the suburban area of Gaithersburg, MD. The End-Node was attached to a vehicle that drove around during a weekend in the vicinity of the NIST Campus. An analysis of the data during the test showed that a message from the farthest distance was received when the car was traveling on I-270 just before crossing Fall Rd Bridge, which was 8 km (5 mi) away from the gateway. Due to the characteristics of the landscape, most of the messages before that were lost even when they were transmitted at a shorter distance than the farthest location that a message was received from. The map in Figure 9 was configured to show all historical data, not just the last data point. As can be seen in Figure 9, an orange area covered almost the entire path of the Shuttle. The system ran continuously for a week.

4 Discussions

The paper described a tracking system using a LPWAN setup developed to analyze characteristics of the wireless technology. The experiment focused on a subset of important characteristics,



Figure 9: NIST LPWAN Infrastructure range test. The furthest received message was transmitted 8 Km far from the

Gateway. Location of the Gateway is drawn on the map.

ACKNOWLEDGMENTS

Special Thanks to: • Dhananjay DJ Anand, for invaluable help and support to set-

up these experiments on time. • Charles Prado, for his assistance to set up a demo. • Jorge Carrasco, for his willingness to supervise the end-node

while driving the NIST Shuttle. • Maria Betania Antico, for sharing her smart-phone real-time

location while traveling in NIST Shuttle as a volunteer passenger, and constant support in my professional development, and life. • Nanita Yeboah, for carrying end-node during entire weekend to test LPWAN NIST Infrastructure range. • Gurmindersingh Gini Khalsa, for his inspiring safety restrictions, source of inventiveness and creativity that guided me to find LPWAN.



SCC 2019, September, 2019, Portland, Oregon, USA

• Héctor Laiz and Osvaldo Jalon, for trusting my professionalism to represent INTI with world-class excellence abroad.

DISCLAIMER

Official contribution of the United States government; not subject to copyright in the United States. Certain commercial products may be identified in order to adequately specify the procedure; this does not imply endorsement or recommendation by the National Institute of Standards and Technology, nor does it imply that such products are necessarily the best available for the purpose.

REFERENCES

[1] A. Ross, "Information Age's guide to the low-power wide area network (LPWAN) landscape," 27 June 2019. [Online]. Available: https://www.information-age.com/low-power-wide-area-network-lpwan123483151/. [Accessed 25 July 2019].

[2] LoRa Alliance Technical Committee Regional Parameters Workgroup, "LoRaWAN 1.1 Regional Parameters," January 2018. [Online]. Available: https://lora-alliance.org/sites/default/files/201804/lorawantm\_regional\_parameters\_v1.1rb\_-\_final.pdf. [Accessed 25 July 2019].

[3] LoRa Alliance Technical Committee, "LoRaWAN 1.1 Specification," October 2017. [Online]. Available: https://lora-alliance.org/sites/default/files/201804/lorawantm\_specification\_-v1.1.pdf. [Accessed 27 July 2019].



S. Barillaro et al.



[4] LoRa Alliance Strategy Committee, "Geolocation Whitepaper," January 2018.



[Online].



Available:



https://docs.wixstatic.com/ugd/eccc1a\_d43b3b29dfff4ec2b00f349ced4225



c4.pdf. [Accessed 25 July 2019]



[5] B. Ray, "LoRa Localization," 30 6 2016. [Online]. Available: https://www.linklabs.com/blog/lora-localization. [Accessed 25 July 2019].



[6] I. Butun, N. Pereira and M. Gidlund, " Analysis of LoRaWAN v1.1 Security," in MobiCom Mobile Computing and Networking, Los Angeles, 2018.



[7] I. Butun, N. Pereira and M. Gidlund, "Security Risk Analysis of LoRaWAN and Future Directions," in 4th ACM MobiHoc Workshop on Experiences with the Design and Implementation of Smart Objects, Los Angeles, California, 2018.



[8] "Loraserver



documentation,"



[Online].



Available:



https://www.loraserver.io/loraserver/overview/. [Accessed 25 July 2019].



[9] "Loraserver-Application-Server,"



[Online].



Available:



https://www.loraserver.io/lora-app-server/overview/. [Accessed 25 July



2019].



[10] "InfluxDB," [Online]. Available: https://www.influxdata.com/time-seriesplatform/. [Accessed 25 July 2019].



[11] "Grafana," [Online]. Available: https://grafana.com. [Accessed 25 July 2019].



[12] "Grafana



Worldmap



Panel,"



[Online].



Available:



https://grafana.com/grafana/plugins/grafana-worldmap-panel. [Accessed



25 July 2019].



[13] "SIM Week," September 2018. [Online]. Available: https://simmetrologia.org/2018/09/21/sim-week-2018-gaithersburg-september-24-282018/. [Accessed 25 July 2019].



[14] Pycom,



"PyTrack



Documentation,"



[Online].



Available:



https://docs.pycom.io/pytrackpysense/apireference/pytrack/. [Accessed 25



July 2019].