LoRa modulation

The LoRa® Modulation is a closed standard owned and licensed by Semtech Corporation describing only the lowest communication layer. The LoRa® transmitter utilizes a modulation based on the chirp spread spectrum (CSS) technique. The narrowband signal is modulated by chirp pulses of varying sinusoidal frequency over time making the signal resilient to interferences caused by the Doppler effect into the narrow-band interference resilience provided by the redundancy associated with the wide-band spread spectrum. The modulation ensures a phase continuity between chirp symbols in the packet preamble part. 
**packet speed as a function of SF
This feature allows using simpler timing synchronization, and thus less expensive components. A modulation configuration (data-rate, DR) is given by two parameters: a bandwidth, and a spreading factor (SF) specified by the LoRaWAN Regional Parameters specification [14]. Bandwidths range from 125 kHz to 500 kHz depending on the region. Chirp symbol duration is given by $Ts = 2SF/BW$ , where $SF \in [7, 12]$. The Time-of-Flight of the packet therefore depends exponentially on the SF. On the other hand the receiver sensitivity is proportional to the SF. Additionally, the spread spectrum technique is combined with the forward error correction (FEC) with coding rates $\in \{4/5, 4/6, 4/7, 4/8\}$. A LoRa® packet consists of a preamble, a header, a payload and a CRC fields. 

LoRaWAN

As the LoRaWAN protocol provides the security mechanisms, it also defines several keys to access your application in the network with your LoRa device (4). These keys are necessary for connection establishing and 
LoRaWAN specification identifies three classes of devices Class A, where end-devices uses pure ALOHA to access the radio network for uplink. This class is the simplest and also a most commonly used. It supports a downlink only in two receive windows (by default 1 s and 2 s) with a defined DR following an uplink transmission. Class A end-devices have the lowest power consumption. Class B devices additionally can utilize periodic beacon signals emitted by gateways to synchronize with the network and schedule an additional receive window. Class C devices are always listening to the channel when they are not transmitting. In this project, we are using Class A, which means we have to find a way how to send a data packet from our node to our gateway as our node itself does not send any data as it is not plugged to any sensor, which would generate such data. In other words, we will have to send a command from the gateway to the node to send the data packet from the node to the gateway. 
As we can understand, there are many options enabling you to establish your own LoRa infrastructure. We can assume that the feasibility of the intended LoRa localization technique depends on final network infrastructure.

Node

The node is a small battery-powered device. It can be sensor measuring temperature or humidity or gas concentration. This sensor can be part of the usual device such as the vending machine or factory machine. The output of the sensor are data processed in a data packet. Then, the sensor is connected to a LoRa RF device, which adds the necessary LoRaWAN protocol properties and transmit the payload data as an analog signal via radio environment to the gateway and further to the network server to our application, where we can evaluate the original data from the sensor. 

Gateway

The gateway is a bridge between the radio environment and the network. It connects our sensor and our application placed on the internet. The gateway receives the analog signal, process the signal into binary data packets. To accomplish such a task, the gateway is usually equipped with a LoRa RF device and a small computer like Raspberry Pi. The gateway is connected to the backhaul network usually with Wi-Fi or cable Ethernet connection. LTE data connection is also possible. 

Packet forwarder

The important part of the LoRaWAN logical architecture is packet forwarder. It is a service program running on a gateway, which is provided by a network server for a specific gateway hardware. The objective of this program is to process all the received data from the physical layer into .json format.  One of the advantages of the packet forwarder is that it has access to the most of  hardware interfaces so it can gather the values measured by the analog front-end of the gateway receiver, process them and provide the processed values as for example SNR (Signal-to-Noise Ratio) and RSSI (Received Signal Strength Indicator) values to the network server. The communication between the gateway’s packet forwarder and the network server is realized by .json format, which carries the processed data  The main advantage of this format is its clear text readability which allows easy orientation in the code and its possible modification. 

Network server

The server is an element in the network, which is responsible for managing the state of active nodes within the network and interpreting the data sent by the nodes. To provide such a service, the server needs to understand the LoRaWAN protocol and .json formatted data. Handling the LoRaWAN mac layer, the network server also schedules the downlink data transmission commands. The network server provides a connection to an external application server over a TCP socket, websocket or mostly MQTT protocol.  As the LoRaWAN protocol provides the security mechanisms, it also defines several keys to access your application in the network with your LoRa device (4). These keys are necessary for connection establishing and
These days, many public network server solutions are available – The Things Network, ResIOT, LORIOT, LoRa Server, etc. The main difference among those servers,  which we should consider at most, which protocol do they use. Some of those public servers are free, and some of them are not. Also, some of the network servers provide an option to run your application – they provide cloud where you can realize your application, however, an unpaid version provides very limited services. Last but not least, each server typically uses different packet forwarder necessary for the gateway. 
For this reason, we decided for The Things Network (TTN) (7) network server. This server provides a free-of-charge public service which should fulfill all necessities during our project. It allows creating a modest application directly on the TTN server, which can communicate with other servers by MQTT protocol. Thus, the measured data obtained from the node will be possible to transfer to our own application server.

Localization techniques

The objective of any localization technique is to obtain a position of a tracked device. In radio-electronics and telecommunications, there are many methods to accomplish such task. To estimate the position, all these methods have to process the received radio signals – their parameters or evaluate the information data coming from those signals.  
Methods such as Angle of Arrival (AoA) or Doppler Shift Target Localization (DSTL), which are widely used in Radio Detection and Ranging (RADAR) systems, are not suitable for our project as the principle of these methods is based on using directional antennas on the devices. LoRa devices (nodes and gateways) are usually equipped with omnidirectional monopole antennas, which are not suitable for AoA or DSTL techniques. However, they could be used as an improvement in the future as the devices’ antennas are easily replaceable (5) 
Time of Arrival (ToA) and Received Signal Strength (RSS) are techniques which require knowledge of the signal characteristic parameters – Time of Flight of the signal and signal strength at the transmitter and signal strength at the receiver. With these techniques, we expect it should be  feasible to estimate the distance between the node and the gateway as every LoRa device has to measure the receiving signal strength of a received packet and has to be equipped with a local oscillator, otherwise the correct setup of the analog front-end would not be possible and the LoRa device would not be able to establish a radio connection. Estimating the distance is the essential prerequisite for any future LoRa localization technique. 

Received Signal Strength distance estimation

The method uses the information of transmitted signal power, which is typically set as a fixed parameter,  and received signal power, which is measured by the receiver to maintain correct functionality/radio connection. The distance estimate can be calculated by using analytical Friis radio transmission formula: 
\(P_{rx}= P_{tx} G_{rx} G_{tx}\left(\frac{\lambda}{4\pi d}\right)^2\)
where $P_{rx}$ is received signal power, \(P_{tx}\) is transmitted signal power, \(G_{rx} \)and \(G_{tx}\) are gains of the antennas, $\lambda$ is the wavelength of the propagating signal and \(d\) is the distance in meters. Hence, the calculated estimated distance is given by: 
The final result provides a radius of the distance estimate between the transmitter and the receiver. 
The problem which will certainly affect the correct estimate is the multipath signal propagation. In such radio environment, the signal loses power with each surface reflection. Besides the multipath, attenuation loss caused by material penetration such as glass, doors or walls will lead to signal power level drop. If we neglect the multipath, the estimated distances should correspond with following analytical curve. 
\begin{figure}[h]
\centering
\includegraphics[width=0.6\textwidth]{img/RSS_distance.pdf}
\caption{Estimated distance based on the Friis transmission formula}
\label{fig:5}
\end{figure}
\newpage
\subsection{Time of Arrival distance estimation}
Time of Arrival technique is based on knowledge of the signal travel speed (c = 299 792 458 $ms^-1$) and the signal Time of Flight (ToF) between a transmitter and a receiver.  Then, the distance can be estimated according to elementary formula: 
\begin{equation}
t_{ToF} = \frac{d}{c}
\end{equation}
\begin{figure}[!h]
\centering
\includegraphics[width=0.6\textwidth]{img/ToF_distance.pdf}
\caption{Estimated distance based on analyitcial formula}
\label{fig:8}
\end{figure}
Nevertheless, with a LoRa device, this method has several weaknesses. The first issue is synchronization. LoRa does not maintain any atomic synchronization between the node and the gateway, which would be available on an application level. By default, the analog front-end relies on built-in local oscillators, which are insufficient for time measuring techniques as their time drift is significant (and of course, both of them are drifting differently). The purpose of those oscillators is to provide pulses for LoRa modulation synchronization and typically as a clock source for processors. The manufacturers of the LoRa devices usually do not provide interfaces between the physical layer components and the application level. That will inevitably result in inaccuracy of the measured time and also of the final distance estimate as for the ToA technique the time synchronization between the node and the gateway is crucial. 
\newpage
\begin{figure}[h]
\centering
\includegraphics[width=0.4\textwidth]{img/figures_lora_time.pdf}
\caption{Time of arrival technique with the time-of-flight of the data packet}
\label{fig:3}
\end{figure}
The second considerable issue, similarly to the RSS technique, is the effect of the multipath signal propagation. In a radio environment with lots of fading, the signal ToF is increasing with each reflection, dispersion or penetration attenuation as the signal rarely propagates along a line-of-sight (LoS) as there is often no one. 
\\
***maybe FIGURE with multipath ***
\newpage
\subsection{Trilateration}
The distance estimation is the first step to the final localization technique. The next step is the usage of a geometric method exploiting a constellation of at least three signal-evaluating receivers, in our case the gateways. With the knowledge of the gateway exact position and the estimated radius distance between the node and each gateway, we can determine the position of the node by intersecting radius distance from each gateway This geometrical technique is called trilateration which is a specific case *(it uses three receivers which evaluates the signal) of multilateration.
\begin{figure}[h]
\centering
\includegraphics[width=0.6\textwidth]{img/figures_lora_tri.pdf}
\caption{Constellation of three gateways with one deployed node}
\label{fig:4}
\end{figure}
\newpage
\section{LoRa measuring parameters capabilities}
\subsection{Received Signal Strength Indicator} 
To maintain the radio connection, LoRa devices constantly measure the certain parameters. All major parameters of the analog front end and digital state machine are fully accessible via an SPI interface which gives access to LoRa chip (which is manufactured by Semtech) registers. To communicate with such interface, the knowledge of the assembler language is required or we can rely on API interfaces, which were implemented by the producer of the whole LoRa device\footnote{Microchip, Libelium, ...} – a node or a gateway. 
\\
The Received Signal Strength Indicator (RSSI) is one of those parameters. According to Semtech official datasheet (6), the RSSI provides a measure of the incoming signal power at RF input port, measured within the receiver bandwidth. The signal power is available in \textit{RssiValue}. This value is absolute in units of dBm and with a resolution of 0.5 dB. The formula below relates the register value to the absolute input signal level at the RF input port: 
\begin{equation}
RssiValue = -2 \, RF \, level + RssiOffset 
\end{equation}
where the RssiOffset is a compensation for the possible losses/gains in the front-end (LNA, SAW filter…).  For the LoRa modulation, which we are using in our project, the final RSSI value is calculated by 
\begin{equation}
RSSI = -157 +  \left(-\frac{RssiValue}{2}\right)
\end{equation}
when using High Frequency port. If we are using Low Frequency port, then:  
\begin{equation}
RSSI = -164 + \left(-\frac{RssiValue}{2}\right)  
\end{equation}
As we can see, the process of gaining the RSSI value is not very intuitive, and if we want to use the RSSI in our solution, we have to rely on manufacturers’ implementation. Possible errors in estimating the distance using the RSSI might also be caused by the fact that such use of that RSSI value was not considered during the designing the LoRa device. 
The distance estimation is the first step to the final localization technique. The next step is a usage of a geometric method exploiting a constellation of at least three signal-evaluating receivers, in our case the gateways. With the knowledge of the gateway exact position and the estimated radius distance between the node and each gateway, we can determine the position of the node by intersecting radius distance from each gateway This geometrical technique is called trilateration which is a specific case *(it uses three receivers which evaluates the signal) of multilateration.
\subsection{Signal-to-noise ratio}
Similarly to the RSSI, the SNR value is also provided via SPI interface, respectively via API interface implemented by the LoRa device manufacturer. That brings the same problems with the reliability of the final solution as we have to rely on the accuracy of the provided SNR values. Besides that, SNR value is suitable for the distance estimation only if the noise floor value is known and constant. In accordance with this assumption, the SNR value is changing only with the change of the received signal power. However, this is a significant simplification of the real-life scenario as the noise value does not have to be necessarily invariable in time. Acquiring the SNR value, we have to rely on the manufacturer implementation as in RSSI case. Studying the appropriate datasheet, the producer (Semtech (6)) was very brief regarding the proper explanation of calculation the SNR value. 
\subsection{Time-of-flight}
Unlike the RSSI and SNR, the time-of-flight*(in LoRa terminology it is called time-on-air (ToA) and it is regarded to time how long the data packet is being sent over the radio. However I will stick to the time-of-flight (ToF) as in radiolocalizing technology, the ToA expression is reserved for time-of-arrival) is not provided by the LoRa device by default. To measure the time-of-flight of the data packet, we need to write a program running on the node, which will provide the data and we need to create an application, which will evaluate these data. 
If we can measure the ToF, we will be able to estimate the radius distance of the node from the gateway. As it has been said, we can use ToF value for the future localization technique – the trilateration technique. 
\newpage
\section{Setup}
In our project, we are using one node and one gateway. As a node, the LoRaWAN Libelium Waspmote was used (8). The Waspmote is equipped with a Microchip RN2483 transceiver module, which integrates RF, a baseband controller and command Application Programming Interface (API) processor (9). The standard monopole (omnidirectional) antenna is mounted on the SMA connector of the node. The frequency was set to 868 MHz within the SRD band. The transmitting level of the node was set to the maximum value – 14 dBm, and it remained unchanged within all tests and measurements. The packets were transmitted with the spreading factor $SF = 12$, which ensures the detection with the lowest possible SNR. 
\\
The gateway was realized with the ISMT iC880A concentrator. The concentrator supports an RF interface for the 868 MHz frequency band (10). To the SMA connector of the iC880A, the standard monopole was attached. The gateway is equipped with a GPS module\footnote{gateways are usually equipped with the GPS module, this will be an advantage in future triangulation localization technique as it with the knowledge of  absolute gateway position, we can estimate the absolute node (geo)position}.
\\
Both LoRa devices are attached to Raspberry Pi small computers. The Raspberry Pi Linux-running computers are connected to the Eurecom LAN via 100BASE-TX ethernet connection. This allows us to configure the devices and modify their programs. This Eurecom LAN is connected to the internet. Therefore the gateway can access the network server. As the network server The Things Network public server was chosen (reasons described in section 2.6). The important thing is to permit all the UDP traffic as the gateway communicates with the TTN  via those ports. 
\\
In the following tables, necesary configuration addresses and access permitions are described. 
\begin{table}[h]
\centering
\includegraphics[width=\textwidth]{fig/lora_tb1.pdf}
\caption{Devices access information}
\label{table:1}
\end{table}
\begin{table}[h]
\centering
\includegraphics[width=0.6\textwidth]{fig/lora_tb2.pdf}
\caption{Application access information}
\label{table:2}
\end{table}
\subsection{Register devices to the network server}
As the LoRaWAN provides 128-bit AES (source) ciphering, unique security keys must be generated and assigned to the LoRa devices by the network server. To enable such encrypted communication\footnote{enable communication at all as with the TTN there is no unciphered option}  between our devices – the node and the gateway, and to be able to receive the data on the TTN network server, the devices need to be registered to that server.
\subsubsection{Gateway configuration}
To deploy the gateway to the TTN network, an \href{https://account.thethingsnetwork.org}{TTN account} has to be created first. Then, in the section \textit{console} we choose \textit{Gateways} and proceed to \href{https://console.thethingsnetwork.org/gateways/register}{\textit{Registering your gateway}}.
\\
As we use Semtech packet forwarder, \textit{packet forwarder} must be selected. For Gateway ID, choose a unique ID of lower case, alphanumeric characters, and nonconsecutive.In our case the ID is eui-b827ebfffeafaaa8 which is the mac address of the gateway. We continue with selecting 
the frequency plan the gateway uses - Europe 868MHz corresponds to EU863-870 MHz for EU region  This is important for following the ISM(SRD) frequency bands and terms of use for the specific region.
Then, we specify the geolocation of our gateway by clicking to drop the pin at the exact location (pan and zoom in before you drop). 
\\
After finishing the regsitration, we are taken to the Gateway’s screen where we’ll find the generated Gateway Key you need next. After registering the gateway,we select \textit{Settings} from the top right menu on the Gateway screen so we can set the gateway description, location altitude, privacy settings and other information.
\\
In this section we needed to go through the all sub-sections and fill the information. The most important information are \textit{Frequency Plan} (in our case Europe 868MHz) and \textit{Router} (ttn-router-eu). In a \textit{Collaborators} sub-section, we can also administrate all collaborators of our project – give them permission to administrate the project on the TTN server.
\\
We started with accessing the Raspberry Pi device to which the LoRa gateway is connected. This can be done from linux Terminal via ssh protocol.
\begin{minted}{bash}
local $ ssh pi@192.168.104.180
\end{minted}
Remember to connect to the RPi you need to access it from a computer in the same LAN. In our case, we need to ssh to EURCOM server first.Then, enter RPi's password and use raspi-config utility to enable SPI:
\begin{minted}{bash}
$ sudo raspi-config
\end{minted}
Reboot (it will ask on exit, but you can do it manually with sudo reboot) and configure locales and time zone:
\begin{minted}{bash}
$ sudo dpkg-reconfigure locales
$ sudo dpkg-reconfigure tzdata
\end{minted}
In out project, we decided to cooperate via GitLab\footnote{which is an web repository similar to GitHub}. To do so,  download files and folders from GitHub so make sure you have an updated installation and install git:
\begin{minted}{bash}
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install git
\end{minted}
Our RPi device was provided with already downloaded ic880a-gateway installer. If we had been  configurating a new device we would have downloaded the installer from the TTN Zurich GitHub:
\begin{minted}{bash}
$ git clone -b spi https://github.com/ttn-zh/ic880a-gateway.git ~/ic880a-gateway
$ cd ~/ic880a-gateway
$ sudo ./install.sh spi
\end{minted}
During the installation, you are asked to choose different hostname, although you don't have to. You can leave the empty. By default, remember that the installer changes the hostname of your Raspeberry Pi to ttn-gateway\footnote{pi@ttn-gateway from now, to prevent collisions with other Raspberry Pis in your network}.
You can override this in non-remote configuration mode.
In our project, we decided to use original Semtech packet forwarder (instead of the TTN's one)
Note that while using Semtech packet forwarder (or any other) it is required to set $SX1301\_RESET\_BCM\_PIN=5$ (by default it is 25) and call:
\begin{minted}{bash}
$ echo "$SX1301_RESET_BCM_PIN" > /sys/class/gpio/unexport.
\end{minted}
Now, we choose the Router instance depending on the frequency plan used in your region.
Learn more. Notice that the geographical location of a server and the supported frequency plans are two different things. As we decided to use EU863-870 MHz for EU region before (viz. Start with Registration, we have to update server address for packet forwarder in our gateway. In the $local\_conf.json$ of the packet forwarder, we updated the fields $server\_address$ as follows:
\begin{minted}{bash}
"gateway_conf": {
...
"servers": [{
"server_address": "router.eu.thethings.network # EU 433 and EU 863-870",
"serv_port_up": 1700,
"serv_port_down": 1700,
"serv_enabled": true,
...
}]
}
\end{minted}
To see what happens under the hood, and make sure our gateway is sending its packets
to the TTN-routers there were two approaches you can follow. Using \textit{ping} is not recommended as the routers are load balancers that do not respond to ping commands.
The gateway communicates with the routers via an UDP connection on port 1700. So if we listen to this port we should see packets being transferred:
\begin{minted}{bash}
 $ sudo tcpdump -AUq port 1700
\end{minted}
When the gateway is up and running this feed would (at least) give a state packet every 30-60 seconds: During the first steps, we had some issues with the connection the gateway to the netork server which were caused by closed UDP traffic from our network. A tool which provides information about successful traffic is a to a log file located at: $/var/log/syslog$, where the packet forwarder periodically writes its status. 
\begin{minted}{bash}
$ sudo tail -f /var/log/syslog
\end{minted}
Example log: 
 
 \begin{minted}{bash}
 ##### 2016-11-10 08:10:33 GMT #####
 ### [UPSTREAM] ###
 # RF packets received by concentrator: 0
 # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00%
 # RF packets forwarded: 0 (0 bytes)
 # PUSH_DATA datagrams sent: 2 (442 bytes)
 # PUSH_DATA acknowledged: 100.00%
 ### [DOWNSTREAM] ###
 # PULL_DATA sent: 6 (100.00% acknowledged)
 # PULL_RESP(onse) datagrams received: 0 (0 bytes)
 # RF packets sent to concentrator: 0 (0 bytes)
 # TX errors: 0
 ### [GPS] ###
 # Invalid gps time reference (age: 1478765433 sec)
 # Manual GPS coordinates: latitude 51.1, longitude 5.9, altitude 23 m
 ##### END #####
 \end{minted}
\subsubsection{Node configuration}
Starting with logging in our account and adding a new \href{https://console.thethingsnetwork.org/applications/add}{application}. For \textit{Application ID}, we chose an unique ID of lower case, alphanumeric characters and nonconsecutive - "eurecom\_project\_fall\_2017". For \textit{Application Description}, "Eurecom Project Fall 2017" was selected. After finishing, we were redirected to the newly added application, where we could find the generated "Application EUI" and default "Access Key" which we'll need later\footnote{If the Application ID is already taken, you will end up at the Applications overview with the following error. Simply go back and try another ID}.
\\
 
The Things Network supports the two LoRaWAN mechanisms to register devices: Over The Air Activation (OTAA) and Activation By Personalization (ABP). In this project, we will use ABP. In production, you'll want to use OTAA, which is the default. This is more reliable because the activation will be confirmed and more secure because the session keys will be negotiated with every activation. In our project we decided for ABP as it is useful for workshops because we don't have to wair for a downlink window to becom available to confrim the activation. 
\\
For "Device ID", we  chose "eurecom\_node\_1" unique ID. Again it needs to be of lower case, alphanumeric characters and nonconsecutive. For Device EUI, click could choose a random value by hitting the randomize button. Now, we were redirected to a window where a descritpion and activation method can be chosen. Also, we uncheckd Frame counter(`[5] Interf checks at the bottom of the page. This allowed us to restart our device for development purposes without the routing services keeping track of the frame counter. However, this does make the application vulnerable for replay attacks, e.g. sending messages with a frame counter equal or lower than the latest received. After that, we obtained "Device Address", "Network Session Key" and "App Session Key" that were need next in further steps.
\\
Starting with accessing the Raspberry Pi device to which the LoRa gateway is connected.
\begin{minted}{bash}
$ ssh pi@192.168.104.181
\end{minted}
Our node had Raspbian operating system already installed. If you buy a brand new Raspberry Pi,
it is provided with Raspbian OS. If you start from scratch, you have to install Raspbian distribution first. Once you install Raspbian, download and install \textit{arduPi library} in a new folder, for example: "home/pi/ardupi"
For Raspberry Pi 2:
\begin{minted}{bash}
$ wget http://www.cooking-hacks.com/media/cooking/images/documentation/
raspberry_arduino_shield/raspberrypi.zip && unzip raspberrypi.zip
$ unzip raspberrypi2.zip
$ cd cooking/arduPi
$ chmod +x install_arduPi
$ ./install_arduPi
$ rm install_arduPi
$ cd ../..
\end{minted}
Now we proceed to enable interfaces. Starting with opening the file /boot/config.txt:
\begin{minted}{bash}
$ sudo nano /boot/config.txt
\end{minted}
Add the following lines to the config.txt file:
\begin{minted}{bash}
#enable uart interface
enable_uart=1
#enable spi interface
dtparam=spi=on
#enable i2c interface
dtparam=i2c_arm=on
\end{minted}
Update the operating system with latest patches.
\begin{minted}{bash}
$ sudo apt-get update
$ sudo apt-get upgrade
\end{minted}
Then, reboot the Raspberry Pi.
\begin{minted}{bash}
$ sudo reboot
\end{minted}
At this state, the node and the gateway are assigned to the TTN netowrk server and ready to communicate. 
\newpage
\section{Solution}
\newpage
\section{Measurements}
After finishing our application, which is capable of sending the time-of-flight value of the data packet, RSSI and SNR value up to the network server, we proceeded to initial testing. The objective of the first measuerements was to verify the functionality of our application i.e. if the values provided by the application correspond with our theoretical assumptions. Besides that, we wanted to explore the limits of the LoRa modulation inside the Eruecom building. 
\\
During the first measurement, we installed the gateway in the Lab 311 in Eurecom. Spreading factor was set to 12 and node's transmitting power level remained on 14 dBm. Then, the node was moved accros the Eurecom building to several static position, where at each position 20 measurements were taken. With the help of our application, we exported the measured values to .CSV files and processed them with a simple matlab script. 
\\
The results of the first measurements revealed that multipath inside the Eurecom building is a significant issue. The building's strong fading environment caused the unexpected behaviour of the ToF values. With the increasing distance of the node from the gateway, we observed smaller ToF values, which is the opposite to the expectations. At the same time, with the small ToF values we obtained small SNR values. 
\\
the signal rarely propagates from the node to the gateway with line-of-sight transmission; there are always reflections – the measured time of the signal flight will be higher than the line of sight signal.
That indicates that due to multipath, where the signal rarely\footnote{Depends on how much energy is included in the Line-of-sight component, usually described with Rician factor K} propagates from the node to the gateway with line-of-sight transmission;  it takes more time to signal to travel that distance. Except for that, the singal looses its energy with each refflection as a part of its energy is absorbed by the reflecting surface. Other pehenomenon is the attenuation as signal is penetrating the obstacles (windows, doors, walls). Depending on material coefficients (dielectric constant/permittivity and conductivity), signal looses its energy which leads to lower receive power level and thus lower SNR. Propagating within the material, the signal is being retarded, which causes additional time dalay and thus the higher time-of-flight value. However, we suppose that  the last effect does not affect the ToF dramaticaly. 
In such indoor multipath-rich fading environment, which the Eurecom building seems to be, all those effects cause that the gateway is not able to receive the signal and decode the packet data. Therefore, the range of the LoRa node is very limited inside the building. Therefore, we decided to continue with outoodr measurements.
\\
\newpage
\subsection{Outdoor measurement}
The outdoor measurement was settled in expecation of reasonable results than within the inside measurements. 
\begin{figure}[h]
\includegraphics[width=\textwidth]{img/meas_map.png}
\caption{Map of the measured positions}
\label{fig:10}
\end{figure}
\begin{table}[h]
\caption{Measured values at several positions accross the campus}
\end{table}
\begin{figure}
\includegraphics[width=\textwidth]{img/dist_vs_snr_mean.pdf}
\caption{Estimated distance based on SNR values, fitted to the analytical expected curve}
%\label{fig:12}
\end{figure}
\begin{figure}
\includegraphics[width=\textwidth]{img/mean_val.pdf}
\caption{Mean values of the measured position}
%\label{fig:12}
\end{figure}
\begin{figure}
\includegraphics[width=\textwidth]{img/median_val.pdf}
\caption{Median values of the measured position}
%\label{fig:12}
\end{figure}