IN
DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,
SECOND CYCLE, 30 CREDITS ,
STOCKHOLM SWEDEN 2019
Virtualizing LoRa baseband
functionalities to the Edge
PRATIK VIJAYENDRA WALVEKAR
KTH ROYAL INSTITUTE OF TECHNOLOGY
Virtualizing LoRa baseband
functionalities to the Edge
PRATIK VIJAYENDRA WALVEKAR
Master in ICT Innovation
(EIT - Internet Technology and Architecture) Date: September 25, 2019
Supervisor: Dr. Peng Wang, KTH Royal Institute of Technology, Stockholm and Dr. Chenguang Lu, Ericsson Research, Stockholm Examiner: Prof. Marina Petrova, KTH Royal Institute of Technology School of Electrical Engineering and Computer Science
iii
Abstract
Traditional network architecture design of Low Power Wide Area Networks (LPWAN) suffer from their inability to dynamically scale resources based on the incoming traffic and involve manual procedures for capacity upgrades. There is a need to develop a cloud-native architecture where the gateway hard-ware performs signal detection while baseband processing is virtualized in the Edge, provisioning for dynamic scaling of resources. Cloud Radio Access Net-work (CRAN) as a concept can be leveraged to realize such a functional split architecture.
iv
Sammanfattning
Traditionell nätverksarkitekturdesign av LOWWAN (Low Power Wide Area Networks) lider av deras oförmåga att dynamiskt skala resurser baserat på den inkommande trafiken och involverar manuella procedurer för kapacitetsupp-graderingar. Det finns ett behov av att utveckla en moln-ursprunglig arkitektur där gateway-hårdvaran utför signaldetektering medan basbandsbehandling är virtualiserad i Edge, vilket möjliggör dynamisk skalning av resurser. Cloud Radio Access Network (CRAN) som ett koncept kan utnyttjas för att förverk-liga en sådan funktionell split-arkitektur.
v
Acknowledgement
This thesis work would not have been possible without the constant support and encouragement from the kind people around me. Firstly, I would like to thank my KTH examiner Associate Prof. Marina Petrova for patiently partic-ipating in each of my presentations and for providing a thorough feedback on my thesis work. My special thanks to my KTH supervisor, Dr. Peng Wang, for providing patient and valuable assistance throughout the duration of the work. I would like to specially acknowledge the outstanding support extended by my Ericsson supervisor Dr. Chenguang Lu, who provided a conducive work at-mosphere for the successful completion of this work. I am also grateful to my colleagues Saptarshi, Daniel and Gyanesh for their expert inputs which were very useful during the implementation phase of the thesis work. Additionally, I would like to extend my heartfelt gratitude to my Manager at Ericsson, Elmar Trojer who provided me with the opportunity of carrying out this work at his Ericsson Research unit.
The master thesis journey could not have been complete without the con-stant support of my friends from the EIT study program who not only made it an enjoyable experience but also helped me survive through the long Swedish winters.
Contents
1 Introduction 1 1.1 Problem Statement . . . 2 1.2 Objectives . . . 3 1.3 Proposed Solution . . . 3 1.4 Research methodology . . . 5 1.5 Report overview . . . 5 2 Background 6 2.1 LPWAN . . . 6 2.2 LoRa . . . 6 2.2.1 Radio Access . . . 9 2.2.2 MAC . . . 10 2.2.3 Frame Structure . . . 11 2.2.4 Network Topology . . . 11 2.3 Centralized RAN . . . 12 2.3.1 Split architecture . . . 12 3 Related Work 17 3.1 Reverse-engineering LoRa . . . 17 3.2 Split architecture . . . 183.3 LoRa physical layer . . . 18
CONTENTS vii
5 Implementation 30
5.1 Fipy IoT Board . . . 30
5.2 Software Defined Radio . . . 31
5.3 Host Machines . . . 31
5.4 GNURadio . . . 32
5.5 Makefile and Docker . . . 32
6 Performance Evaluation 35 6.1 Measurement setup . . . 35
6.2 Measurement results . . . 36
6.2.1 Fronthaul utilization . . . 36
6.2.2 Split vs Non-split . . . 37
6.2.3 Preamble detection accuracy . . . 38
6.2.4 Correlation method comparison . . . 40
6.2.5 Python vs C++ implementation . . . 41
6.2.6 Virtualized multi-RAT setup . . . 41
List of Figures
2.1 Chirp signal of different SF characteristic. Note that the
sym-bol duration doubles with every increase in SF. . . 8
2.2 LoRaWAN stack adapted from [1]. . . 11
2.3 LoRa Frame structure. The numbers below represent the length in bits. The maximum length of PHY Payload is 234 bytes. . 12
2.4 Traditional LoRa network architecture (above) vs proposed LoRa split-architecture (below). . . 13
2.5 The different split architecture options for RH-Edge split adapted from [15]. . . 14
4.1 Functional block diagram of LoRa split-architecture as pro-posed in this work. . . 19
4.2 Channelization process. . . 20
4.3 Low pass filter response for the channelizer block. . . 21
4.4 Over-the-air capture of SF7 preamble sequence represented by 6 upchirps and 2.25 downchirp symbols. . . 23
4.5 LoRa Semtech calculator tool. . . 24
4.6 Virtual machine vs Docker adapted from [24]. . . 28
5.1 GNURadio software blocks running on the RH host. . . 32
5.2 GNURadio software blocks running on the Edge host. . . 33
5.3 Flowchart indicating the steps for virtualizing the Edge appli-cation implemented in GNURadio. . . 34
6.1 End-to-End measurement setup. . . 35
6.2 FH link utilization for scenario with preamble detection cap-turing varying number of LoRa packets (blue) and without preamble detection capturing noise samples (orange) extrap-olated from 1 day capture. . . 36
LIST OF FIGURES ix
6.3 The variation of packet error rate (PER) with SNR for base
architecture and split architecture. . . 37
6.4 Accuracy of detecting the different SFs for SNR 0. . . 39
6.5 Correlation method comparison [17] vs our method. . . 40
6.6 CPU utilization - Python vs C++. . . 42
6.7 LoRa CPU utilization for Multi-RAT scenario. . . 43
6.8 Network usage for Multi-RAT scenario. . . 43
A.1 Calibration mapping of GNU Rx Power vs Ideal Rx Power with varying gain. . . 51
B.1 Polynomial function of degree 3 to map GNU Rx Power with ideal power. . . 52
List of Tables
2.1 Comparison of different LPWAN technologies. . . 7 2.2 EU863-870 TX data rate. . . 10 6.1 Comparison of work function execution time for Python vs
C++ implementation. . . 38 6.2 Symbols correlated for different SFs in our method vs [17]
method.
Our method: GNURadio max block buffer size = 4096
[17] method: GNURadio max block buffer size = 32768 . . . 39
Chapter 1
Introduction
The fifth Generation (5G) mobile network is set to provide a range of connec-tivity services. We may broadly classify them in terms of high speed mobile broadband, low-latency applications and massive connectivity at scale. The massive connectivity at scale is driven by the Internet-of-Things (IoT), a tech-nology that has been around for a while, but is gaining relevance today be-cause of the development of the Low-Power Wide Area (LPWA) technology ecosystem, as well as the short-range IoT technologies. Open standards such as LoRaWAN [1], Narrow-Band IoT (NB-IoT) [2], IEEE 802.15.4 [3], etc. have accelerated the adoption of the IoT technologies to cater to the multitude of use cases of businesses. However, the employment choice of the technologies depend on the use cases. Since businesses usually have multiple use cases, it is needed to deploy multiple IoT technologies which come with their own Radio Access Technology (RAT), gateway hardware, compute, network and storage stack. This would incur high Capital Expenditure (CAPEX) and Operational Expenditure (OPEX) on the business organizations. A traditional network ar-chitecture consists of radio masts with proprietary hardware which carry out the physical baseband processing and forward the higher layer data to the core network. A deployment scenario as this is inefficient and inflexible, in terms of the large investments that need to be made on each baseband processing hardware, in terms of resource utilization with every RAT that is introduced as well as the challenges that come with maintaining the interoperability be-tween the different standalone IoT stacks [4]. Traditional architectures also do not scale dynamically with increase in traffic and require manual capacity up-grades, which is difficult and complex to carry out in the large-scale LPWAN deployment scenario.
2 CHAPTER 1. INTRODUCTION
A solution to this problem is to develop a scalable and flexible multi-RAT IoT system which is able to serve devices operating on different IoT RATs dy-namically based on incoming traffic. Enabling such a solution would require redesigning the traditional network architecture to a more cloud or edge native design, where the baseband processing is shifted from the radio masts to the edge servers, following the Cloud RAN concept [4] and [5].
This thesis work was carried out in cooperation with Ericsson Research, Stockholm. A part of this work is connected to the EU project 5G-CORAL [6]. The aim of this thesis work is to virtualize the baseband processing to the edge for LoRa, a LPWA standard operating in unlicensed band (e.g. EU868 band) and integrate it into the multi-RAT IoT testbed being developed.
1.1
Problem Statement
The Cloud RAN (CRAN) implementation of LoRa introduces some new chal-lenges that need to be tackled. There needs to be a clear understanding of the LoRa standard - what purpose does it serve, what is the design philosophy, what are the performance constraints, etc. The feasibility study of LoRa with regards to a cloud native implementation is first carried out, after which the following problems are tackled.
CHAPTER 1. INTRODUCTION 3
method which reduces the FH link utilization with higher multiplexing gains.
• Multichannel problem - The LoRa standard requires the implementa-tion of atleast 3 mandatory channels for LoRa-based communicaimplementa-tion systems operating in the European band [8]. This feature needs to be implemented as part of our system as single channel gateways are not considered as standard-compliant.
• Multi-RAT integration - One of the main goals of the thesis is to inte-grate multiple IoT RATs namely NB-IoT, IEEE 802.15.4 and LoRa into a single system and enable their interoperability. Each of these stacks are implemented in different host environment with different host ma-chine, OS, software version, etc along with different library dependen-cies. Hence, there is a need to virtualize the LoRa IoT implementation in a way that the integration is seamless and independent of the host environment that it was implemented on. The solution should also en-sure that the implementation can be run on any host irrespective of the underlying host system configurations.
1.2
Objectives
The purpose of this thesis work is to implement the LoRa IoT stack in the RH-Edge split architecture setup and integrate it as part of the multi-RAT IoT system. The first objective is to study and understand the LoRa standard and specification. The CRAN split methods as proposed in the literature are re-searched and the split method most suitable to LoRa needs to be chosen. The split architecture is to be implemented by means of a method to successfully detect and forward only the LoRa packets to the edge processing. The ob-jective is to have a performance which is as good as the non-split traditional architecture or better and present the feasibility of the LoRa baseband split ar-chitecture. Additionally, the thesis work should take into consideration all the problems discussed in Section 1.1 and implementation needs to be carried out accordingly.
1.3
Proposed Solution
archi-4 CHAPTER 1. INTRODUCTION
tecture setup by means of using a LoRa-based transmitter for transmitting the LoRa packets, a receiver, and 2 host machines emulating the RH and Edge pro-cessor. In the second step, we develop a preamble detection scheme employing the physical layer features of LoRa and implement it in the RH. The pream-ble detection method enapream-bles the identification of LoRa baseband I/Q samples which are sent to the edge for processing. In the final steps, the multichannel support is added and the setup is virtualized for multi-RAT IoT integration. The following open source tools are well suited for implementing the various aspects of the work.
• LoRa IoT Board - A LoRa transmitting device is required in order trans-mit the LoRa packets. For this purpose, we use Pycom’s Micro-Python enabled Fipy microcontroller board which is capable of transmitting LoRa packets using Semtech’s SX1272 chipset. It supports the oper-ation in LoRa as well as LoRaWAN mode including support Class A, Class B and Class C devices. The Fipy board can be programmed to function as a sensor node or as a gateway with support of upto 100 nodes [9].
• USRP B210 hardware - The USRP B210 provides a fully integrated, single-board, Universal Software Radio Peripheral (USRPTM) platform with continuous frequency coverage from 70 MHz – 6 GHz. Designed for low-cost experimentation, it allows quick prototyping with GNU Ra-dio while providing higher performance. Experiment with the USRP B210 covers a wide range of applications including: FM and TV broad-cast, cellular, GPS, WiFi, ISM, and more [10].
• GNURadio - GNURadio is a free software development toolkit that pro-vides signal processing blocks to implement Software-Defined Radios (SDR) and signal-processing systems. It can be used with external RF hardware like National Instrument’s USRP to create software-defined radios, or without hardware in a simulation-like environment [11]. • Docker - Docker is a set of coupled software-as-a-service and
CHAPTER 1. INTRODUCTION 5
1.4
Research methodology
The research methodology employed in this work is mainly experimental with a quantitative approach. The feasibility of the split architecture setup can be verified by benchmarking it with non-split architecture. For this purpose, met-rics such as link utilization, signal-to-noise ratio vs packet error rate are em-ployed. In order to verify that feasibility of the multi-RAT scenario, an addi-tional metric of CPU utilization is used. This indicates that the assumptions of this thesis would rely on realism where factual validation of the implemen-tation would be provided. Since, the development of a split architecture for LoRa is novel, existing theories are used to develop a hypothesis, for instance deciding on the choice of split architecture, and the hypothesis is tested by means of executing a research strategy based on the chosen hypothesis. The data collected from the experimentation is analysed by using mathematical tools which provide statistics on that data. Finally, the quality of the over-all system is measured by its ability to accurately detect and decode the LoRa data symbols under varying radio conditions, in standalone as well as in multi-RAT environment. These would indicate the consistency and reliability of the overall system.
1.5
Report overview
The report is organized as below.
Chapter 2 gives the background on LoRa physical layer features and
Chapter 2
Background
This Chapter gives an overview of the different LPWAN technologies, fo-cussing in detail on the LoRa technology. We discuss the various physical layer features of LoRa, the radio access and network topology. The different physical layer split options for CRAN architecture are also presented in detail.
2.1
LPWAN
The low power consumption requirements of battery powered IoT devices makes the adoption of higher resource-consuming cellular based radio tech-nologies a difficult choice for these devices. Moreover, the end-devices are not required to transmit huge quantities of data (for e.g.: >256 KBps). These constraints have led to the adoption of energy efficient low power radio tech-nologies like LoRa, SigFox, Narrow-Band IoT (NB-IoT), IEEE 802.15.4, etc which provide long range connectivity (>5 Km) at low data rate transmissions in the range of tens to hundreds of Kbps. Table 2.1 compares the three popular LPWAN technologies namely LoRa, SigFox and NB-IoT.
2.2
LoRa
LoRaWAN (Long Range Wide Area Network) is a LPWAN technology pro-posed by the LoRa Alliance , a non-profit organization that is compro-posed of over 400 member companies. LoRaWAN offers among other things high de-vice dependent battery time by using an adaptive data rate scheme and quality of service (QoS) due to service classes [1]. LoRaWAN uses LoRa, a propri-etary radio modulation technique based on Chirp Spread Spectrum (CSS), as a physical layer. LoRaWAN itself is an open standard and contains the link
CHAPTER 2. BACKGROUND 7
LPWAN TECHNOLOGIES Comparison
Metrics
LoRa NB-IoT SigFox
Battery life ∼ 10 years ∼ 10 years ∼ 10 years Frequency
Bands
sub-GHz ISM Unli-censed bands Licensed LTE bands, 2G re-farmed bands, LTE guard bands sub-GHz Unli-censed bands Bandwidth 125KHz \ 250KHz \ 500KHz 200 KHz signal bandwidth of 100 Hz
Data Rate upto 50 Kbps upto 250 Kbps ∼ 1 Kbps Range ∼ 15 Km (rural) and
∼ 5Km (urban)
∼ 15Km ∼ 30 Km (rural)
∼ 10 Km (urban) Latency high (seconds) low (50-100
milliseconds
high (tens of sec-onds)
Modulation Chirp Spread Spec-trum (CSS) OFDM (Down-link) and SC-FDMA (Uplink) Binary Phase Shift Keying (BPSK)
MAC 3 different MAC pro-tocols 1. Class A- for battery powered end devices
2. Class B- for bat-tery powered actua-tors
3. Class C- for main powered actuators Packet Datalink Control Plane (PDCP) ALOHA Network topology
Star Cellular Star
8 CHAPTER 2. BACKGROUND
layer protocols of LoRa [8]. The following are some of the important physical layer features of LoRa.
• Chirp Modulation - LoRa uses a modulation scheme based on chirp spread spectrum. The data is encoded in the form of sequential chirps which linearly increase with frequency over time. This modulation scheme makes it robust against frequency offsets due to Doppler shifts, multi-path and fading, making it suitable for deployment in outdoor environ-ments. Resistance to these effects also means longer communication range owing to higher link budget.
• Spreading factor (SF) - The spread spectrum schema encodes the data symbol across multiple chip (or bit) values. LoRa provides for a SF range from 6 to 12. Higher the SF, longer is the symbol duration and hence higher time on air. The higher SF leads to lesser data rate because of longer air times but are more resistant to interference. Figure 2.1 depicts the variation of the chirp signal characteristic with increase in SF for SFs 6, 7 and 8. It may be noted that the symbol duration doubles with increase in SF.
Figure 2.1: Chirp signal of different SF characteristic. Note that the symbol duration doubles with every increase in SF.
CHAPTER 2. BACKGROUND 9
This makes LoRa a versatile radio technology well suited for use in large IoT deployments.
• Duty-cycling - A typical IoT gateway serves 2000-4000 IoT nodes in an urban scenario. If all the nodes communicate together, it leads to chaos with high interference (inspite of the orthogonality) and higher packet error rate. Moreover, such frequent transmissions may lead to congestion in the FH and backhaul links which may affect the transmis-sions from other technologies. In order to overcome these issues and regulate the transmissions from the LoRa end-nodes, duty cycling is in-troduced in the LoRa standard. Duty cycling ensures that an end-node occupies the channel only 1% of the time while being inactive the rest 99% of time. For example, a transmitting node can be active only for 36 seconds in an hour. Duty cycling ensures that there are no rogue trans-missions adversely affecting the network performance as LoRa doesn’t really employ any scheduling mechanisms for uplink.
• Adaptive data rates - LoRa provides a wide range of data rates upto 50 Kbps depending on the SF used. The LoRa network can instruct a device to shift to particular data rate (or SF), channel, etc depending on the radio conditions in order to optimize the battery life and network capacity. For instance transmitting on higher SFs reduces battery consumption due to low data-rate transmissions.
2.2.1
Radio Access
10 CHAPTER 2. BACKGROUND
scheme and SF significantly affect the data rate and range of a connection. The data rate varies between 0.25 bps for LoRa with a SF of 12 and 5470 bps for LoRa with a SF of 7. LoRa also allows to double the bandwidth of a channel to gain 11 Kbps for LoRa with a SF of 7 or to change the modulation scheme to frequency key shifting (FSK), to gain a data rate of 50 Kbps [1]. Table 2.2 lists the data rates for different spreading factors. LoRaWAN implements an Adaptive Data Rate (ADR) scheme to maximize the battery life of the IoT-devices and to improve the network capacity. Each IoT-device can choose its data rate and transmission power freely, as long as it follows the restrictions of the unlicensed bands, to achieve an optimal communication. By manipu-lating the spreading factor, the bandwidth or the modulation scheme, data rate and low energy consumption can be traded for an increased connection range and signal robustness. The devices can also choose to let the connection be optimized by LoRa. If LoRa is allowed to optimize the connection, it will adapt the modulation scheme by lowering the spreading factor as long as the connection is stable. A smaller spreading factor means a shorter connection range but higher data rates, less energy consumption and less time to transmit messages.
Data Rate
Configuration Physical bit rate (bit/s) 0 LoRa: SF12 / 125 KHz 250 1 LoRa: SF11 / 125 KHz 440 2 LoRa: SF10 / 125 KHz 980 3 LoRa: SF9 / 125 KHz 1760 4 LoRa: SF8 / 125 KHz 3125 5 LoRa: SF7 / 125 KHz 5470 6 LoRa: SF6 / 125 KHz 11000 7 FSK 50000
Table 2.2: EU863-870 TX data rate.
2.2.2
MAC
CHAPTER 2. BACKGROUND 11
every IoT-device have to implement if it wants to communicate via LoRaWAN. In this class the downlink traffic can only occur directly after an uplink mes-sage has successfully be transmitted. Class B, meaning “Beacon”, expands the protocol by a mechanism, where the IoT-devices can request scheduled trans-mission frames for their downlink messages. Class C, refers to “Continuously Listening” devices where one of the uplink message windows between the up-loads is constantly open. The IoT-device can use this open window to listen for incoming downlink messages. If the IoT-devices support these classes, they can switch between them arbitrarily. Using class B or even C improves not only the downlink data rates but also the latency. The downside is an increased energy consumption [1]. Figure 2.2 presents the LoRaWAN communication stack.
Figure 2.2: LoRaWAN stack adapted from [1].
2.2.3
Frame Structure
Figure 2.3 presents the frame structure of LoRa. It consists of a programmable preamble varying from 2 symbols (+ 4.25 fixed preamble symbols) to 65535 symbols (+ 4.25 fixed preamble symbols) followed by physical header and physical header CRC. This is followed by the physical payload of maximum 234 bytes. The physical payload contains the MAC header, MAC payload only in the case of LoRaWAN mode operation. Finally the last frame is the CRC which is present only in case of uplink but absent in downlink.
2.2.4
Network Topology
12 CHAPTER 2. BACKGROUND
Figure 2.3: LoRa Frame structure. The numbers below represent the length in bits. The maximum length of PHY Payload is 234 bytes.
gateway ID, network quality information etc before forwarding it to the net-work server. The Netnet-work Server are the central elements of the star topology and the terminal element of the LoRaWAN MAC layer. Besides being respon-sible for various tasks like filtering duplicate messages, data rate adaption, ad-dress checks and acknowledgments and processing all MAC layer requests, they also create the connection between the IoT-devices and their associated Application Servers. The Network Server that contains the device, service and routing profile of the IoT-device is the home Network Server. There are two types of the network server: The forwarding Network Server, that just forwards messages and the serving Network Server, that controls the MAC layer for the IoT device. The Network Server chooses exactly one base station for downlink messages based on the metadata from gateway [13]. The whole communica-tion between the back-end server is realized over IP networks and secured by symmetric key encryption. The root keys for the encryption are stored in the third and last type of back end servers, the Join server. This Server derives session keys and communicates them between the concerned other elements of the network, namely the IoT-device, the Network Servers and the Applica-tion Server. Figure 2.4 presents the tradiApplica-tional LoRa network architecture and the proposed split network architecture.
2.3
Centralized RAN
2.3.1
Split architecture
architec-CHAPTER 2. BACKGROUND 13
Figure 2.4: Traditional LoRa network architecture (above) vs proposed LoRa split-architecture (below).
tures. The first one is the decentralized architecture where the baseband pro-cessing is carried out in the distributed RHs while the second one uses a cen-tralized approach where multiple baseband units are pooled into a central pro-cessing system and thus referred to as Cloud RAN or CRAN [4]. In both the architectures, the RHs are connected to the central cloud or Edge via a link called the Fronthaul (FH). The FH link is one of the important cost drivers of large scale deployments and the choice of the architecture has a direct impact on the FH link usage [14]. In case of IoT, where there would be large scale de-ployments of transmitting nodes or sensors and a sufficiently large deployment of RHs to serve these sensors, the architectural choice becomes crucial. More-over, if the deployment scenario is multi-RAT then the data that flows through the FH increases multiple folds compared to single deployments. All these factors need to be taken into account while deciding on the type of split ar-chitecture. In this section, the different split architecture options as described in [15] are presented and their advantages/disadvantages are discussed. Since the focus is on the physical (PHY) layer implementations of LoRa , the split options are restricted upto the PHY layer without looking into the MAC layer split. Figure 2.5 depicts the different split architecture options and the impact of the choices on the centralization gain and the FH rate.
14 CHAPTER 2. BACKGROUND
Figure 2.5: The different split architecture options for RH-Edge split adapted from [15].
signals are downconverted to baseband and digital I/Q samples are ob-tained. These I/Q samples are sent via the FH link to the cloud/edge for the baseband processing. This approach provides the highest central-ization gain among on the all the option. The FH utilcentral-ization is also the highest as all the data needs to be sent to the cloud/edge everytime for processing. This would require static provisioning of the FH bandwidth which can be seen as a drawback. Since the synchronization in time and frequency is carried out in the edge, the latency requirements for the FH becomes crucial. The RHs are less resource consuming due to the shift of the processing to cloud making their implementation less complex. • Split B - In this split option the synchronization is also carried out in
CHAPTER 2. BACKGROUND 15
• Split C - In this option, the demodulation is carried out at the RH while decoding is pushed to the edge. In this implementation, the central-ization decreases with the decoding alone being implemented in edge. Joint detection is not possible whereas joint decoding is possible. So any duplicate LoRa packet sent to multiple RHs cannot detected but can be decoded as single packet at the edge. This additional demodulation processing of duplicate packets in multiple RHs adds to resource con-sumption on the RH. Moreover, the demodulated packets should have sufficient Signal-to-Noise Ratio (SNR) in order to be decoded, requir-ing the FH link to be less corruptive.
• Split D - This is the last split option where the entire PHY layer process-ing is localized on the RH and all the higher layer processprocess-ing is central-ized. This provides the least centralization and is the adopted method of real world deployments. The FH rate scales with the user throughput so the FH rate increases in case of high device activity. This option is not suitable in case of multiple RAT deployments as it would lead to in-creased computational overhead at the RH causing performance degra-dations.
16 CHAPTER 2. BACKGROUND
Chapter 3
Related Work
This chapter presents the literature review of the research works employed in this thesis work. We broadly classify the related works in the following sections: i) Research works related to reverse-engineering LoRa, ii) Research works related to CRAN split architectures and iii) Research works related to LoRa physical layer.
3.1
Reverse-engineering LoRa
The first efforts in reverse-engineering the patented LoRa physical layer was carried out by Knight et. al [16]. The authors used the GNURadio platform to realize a LoRa decoder system using SDR. The system is not fully performant in that it is found to decode only short frames without header. The authors in [17] overcame the performance hurdles witnessed in [16] by adopting certain changes to the reverse engineering process - performing deinterleaving before dewhitening, employing a diagonal deinterleaving mechanism, etc. They em-ployed a new synchronization algorithm using normalized cross-correlation of the the instantaneous frequencies, which was better able to detect the start of the preamble symbol. The implementation has drawbacks in that it fails to decode 2 or more SFs being transmitted on same channel which in theory should be a possibility because of LoRa’s SF orthogonality. The authors fur-ther presented an SNR range of 0 to 20 dB which is atleast 8 dB lower than the theoretical SNR range for LoRa. Since the SNR measurement methodology is not clearly described in the paper, that might be the cause for such varied re-sults. Despite the drawbacks, this implementation is observed to be the closest to the LoRa chipset physical implementation.
18 CHAPTER 3. RELATED WORK
3.2
Split architecture
The authors in [18] present a framework for the integration of edge/fog com-puting and networking resources, with a view to gain better efficiency due to resource pooling. The authors broadly present 2 platforms - Edge Fog System (EFS) and Orchestration Control System (OCS) which can be leveraged for the functioning of multi-RAT systems. The paper discusses certain challenges as-sociated with utilizing EFS for different IoT technologies’ connectivity. The work does not cover any implementation results but is rather intended lay a roadmap for future efforts in Edge/Fog computing. The research work pre-sented in [15] discusses the challenging requirements of the FH and backhaul networks and how these requirements can be relaxed by employing a CRAN architecture. The authors present 4 split options in the physical layer of LTE and map each split option with the required FH rate. The authors in [7] present an extensive survey of functional split architectures covering industrial and academic research. The advantages/disadvantages of four split options in the physical layer and six split options in the data link layer are discussed. The authors highlighted that most of the functional split investigations have been carried out in the physical layer with split options at the IFFT block, MAC layer and PDCP layer being widely adopted in industry.
3.3
LoRa physical layer
Chapter 4
Methods
The split architecture CRAN design techniques were discussed in Section 2.3.1 among which the split A option was chosen due to its simplicity and the advan-tages discussed before. Figure 4.1 presents the functional block diagram for the split architecture employed in this work. The split A option requires that the RF processing and the A/D-D/A conversion take place in the RH with the raw I/Q samples being forwarded to the Edge server through the FH link. The Edge processor carries out the baseband processing of the I/Q samples and decodes the LoRa payload. In this section, the methods employed to realize these functionalities are discussed. Emphasis is laid on the theoretical aspect of the methods and their contribution to developing the split architecture.
Figure 4.1: Functional block diagram of LoRa split-architecture as proposed in this work.
20 CHAPTER 4. METHODS
4.1
Multi-Channelization
LoRa EU standard requires at least 3 mandatory channels namely 868.1 MHz, 868.3 MHz and 868.5 MHz of 125 KHz bandwidth to be implemented on any standard compliant receiver gateway. The data captured by the antenna is fed to the SDR hardware whose function is to downsample the RF signals to the frequency and signal bandwidth of interest. The channelization of this wide range RF sample capture is carried out by the channelizer, the first block im-plemented in software. The function of this block is to perform the frequency translation of the signal in order to select the channel of interested from the wide RF capture. Figure 4.2 depicts the process of channelizing as performed by this block.
Figure 4.2: Channelization process.
The operations performed in the channelization process are as follows. • Frequency translation - This operation shifts the frequency of the desired
narrow band signal to the baseband frequency. It must be noted that the sampling frequency fs must follow the Nquist criteria and should be
large compared to the bandwidth of the channel. This is to prevent anti-aliaising which may corrupt the signal of interest due to overlapping interferers.
CHAPTER 4. METHODS 21
filtered out. For this purpose, a low pass filter with real taps is chosen which channelizes only the amount equivalent to the signal bandwidth. Figure 4.3 represents the low pass filter response for the channelizer block. GNURadio’s filter design tool was employed to design the mag-nitude response of the filter based on parameters like the sampling rate, stop of pass band, start of stop band, transition bandwidth, windowing method, etc
• Decimating - Many a times it is required to have the outgoing samples from the filter block to be sent at a lower sampling rate in order to match the input sample criteria for the next blocks. It is for this reason that the decimation function is used where it reduces the sampling rate by a factor as mentioned.
GNURadio library provides a native block called XLATing filter, which carries out the above functions. Multiple such blocks were configured to im-plement the 3-channel feature in the RH. The channels chosen as design were the 3 EU-mandatory LoRa channels namely 868.1 MHz, 868.3 MHz and 868.5 MHz.
22 CHAPTER 4. METHODS
4.2
Preamble detection
The first and foremost question that comes up while designing any commu-nication receiver system is how to detect a signal? The widely established signal detection theory is a means to measure the ability to differentiate the information-carrying signal pattern from the noise. Preamble detection is a method which is widely adopted in many modern packetized communication standards like LTE, 3G, NB-IoT, etc. Since RH is the system which con-verts the RF signal to baseband I/Q samples, it becomes natural to implement preamble detection technique in the RH at the beginning of the receive chain. Before getting into the details of how LoRa preamble detection is performed, it is important to point out the advantages that it brings to the split-architecture system.
• The LoRa standard provides a long range of programmable preamble se-quence ranging from 2 symbols to 65535 symbols which makes it conve-nient to use preamble detection as means of detecting LoRa based pack-ets. Figure 4.4 shows over-the-air captured LoRa preamble sequence for SF7 at 1 MSamples/s.
• The preamble detection detects only LoRa based packets and filters out all noisy or non-LoRa I/Q samples. Since the split A option is used, a method like this becomes quite beneficial in reducing the FH link uti-lization when LoRa signals are not being transmitted.
• The preamble detection is a lightweight implementation on the RH com-pared to all the heavy processing that is carried out on existing LoRa-based IoT gateways.
The first step in detecting the preamble is to understand the characteristics of the LoRa signal. As mentioned in Section 2, LoRa uses a Chirp Spread Spectrum (CSS) modulation technique. Let x(t) be the time domain linear chirp signal, whose frequency varies linearly with time as f(t),
x(t) = ej2πR0Tf (t)dt (4.1)
f (t) = kt + f0 (4.2)
where f0 is the initial frequency at time t = 0, k is a constant associated
with the chirpyness of the signal given by k = f1− f0
CHAPTER 4. METHODS 23
Figure 4.4: Over-the-air capture of SF7 preamble sequence represented by 6 upchirps and 2.25 downchirp symbols.
f1is the final frequency of the chirp and T is the time taken to sweep from
f0 to f1, also known as the symbol duration. From (4.2),
Z t 0 f (t)dt = Z t 0 (kt + f0)dt = kt2 2 + f0t (4.4)
Replacing (4.4) in (4.1), we get the time domain linear chirp signal,
x(t) = ej2πt(kt2+f0) (4.5)
LoRa employs the chirp modulation scheme of (4.5) where k in (4.3) de-pends on bandwidth (bw) and symbol duration. The LoRa symbol duration in turn depends on bandwidth and spreading factor (SF), terms previously de-fined in Section 2. We hence obtain the LoRa chirp signal as below,
x(t) = ej2πt(2.2sfbw2t+f0) (4.6)
24 CHAPTER 4. METHODS
LoRa preamble consists of a series of consecutive upchirps followed by 2.25 downchirps. Semtech provides a tool [20] to input different LoRa modulation parameters and get an estimate of the system’s performance. This tool was used to decide the length of the preamble sequence as shown in the
Figure 4.5. The LoRa preamble sequence has a range from 2 bytes to 65535 bytes. Having a long preamble sequence of 65535 bytes results in preamble duration of around 536 seconds while a preamble length of 2 bytes results in preamble duration of about 51 ms. Hence, the preamble sequence is set to around 8.25 symbols in order to have a shorter preamble duration and lower time on air so that more devices can be connected over a day whilst following the duty cycle regulations, while also being long enough to provide sufficient signal-to-noise (SNR) ratio gains due to multiple symbol correlations, as will be explained in the following sections.
Figure 4.5: LoRa Semtech calculator tool.
4.2.1
Cross correlation
CHAPTER 4. METHODS 25
in order to match certain signal characteristics or patterns. Let us consider 2 complex-valued signals f(t) and g(t), the cross correlation, w(t), between them is mathematically defined as,
w(t) = f (t) ⊗ g(t) = Z +∞
−∞
f∗(τ − t)g(τ )dτ (4.7)
where ∗ denotes the complex conjugate. While Equation 4.7 represents the time domain cross correlation, it may also be performed in frequency domain. Consider the following derivations presented in [21]
w(t) = Z +∞ −∞ f∗(τ )g(t + τ )dτ = Z +∞ −∞ [ Z +∞ −∞ F∗(v)e2πivτdτ Z +∞ −∞ G∗(v0)e−2πiv0(t+τ )dv0]dτ = Z +∞ −∞ Z +∞ −∞ Z +∞ −∞ F∗(v)G∗(v0)e−2πiτ (v0−v)e−2πiτ v0tdτ dvdv0 = Z +∞ −∞ Z +∞ −∞
F∗(v)G∗(v0)e−2πiv0[int+∞−∞e−2πiτ (v0−v)dτ ]dvdv0 = Z +∞ −∞ Z +∞ −∞ F∗(v)G∗(v0)e−2πiv0tδ(v0− v)dv0dv = Z +∞ −∞ F∗(v)G(v)e−2πivtdv = Fv[F∗(v)G(v)] (4.8)
where Fvindicates the Inverse Fourier transform , ∗ denotes the complex
con-jugate and f (t) = Fv[F (v)](t) = Z +∞ −∞ F (v)e−2πivτdv g(t) = Fv[G(v)](t) = Z +∞ −∞ G(v)e−2πivτdv (4.9)
26 CHAPTER 4. METHODS
higher time complexity than the frequency domain implementation for which a proof is presented [22] for 2D images. This can be explained as follows: Let Np represent the length of the preamble samples, Nb represent the length of the incoming buffer samples. In case of the time domain cross correlation, the Np samples are multiplied with Np out of Nb samples on every loop of range
Nb, so the time complexity is O(Nb * Np * Np) multiplications and O(Nb * Np * Np) additions. In the frequency based cross correlation, the time com-plexity is given by O(Nb * Np * log(Np)) multiplications and O(Nb * Np *
log(Np)). So, for large values of Nb and Np, the FFT based frequency domain
cross correlation is much more efficient. Hence, this method is employed in the implementation of the preamble detection.
The authors in [17] employ a method of autocorrelation to detect the LoRa preamble sequence. The method exploits the repeating pattern of the incom-ing chirp symbols in the preamble , where 2 consecutive chirps are correlated. Since they have the same signal characteristics, this should lead to a high cor-relation value. But this method of corcor-relation is not ideal. Both incoming chirps captured from the over-the-air transmissions are affected by the noise characteristic of the channel, which affects the correlation. Secondly, the au-tocorrelation method would require extremely large internal buffers for higher SFs which would impact the output rate of the incoming packets. Hence, we propose a cross-correlation method analogous to template matching, where the incoming chirp symbols are correlated with a locally generated chirp sym-bol of the same feature. It may be noted from (4.10) that this method provides a 3 dB gain in SNR for every symbol correlation, in comparison to method of autocorrelation. Let s(k) denote the preamble chirp symbol, σndenote the
standard deviation of the noise. Then SN Rautocorr = Σs2(k) 2σ2 n SN Rcrosscorr = Σs2(k) σ2 n (4.10)
CHAPTER 4. METHODS 27
4.3
Edge processing
The preamble detection discussed in Section 4.2 helps in identifying the LoRa packets and forwards the I/Q samples to the the Edge server for baseband pro-cessing. The baseband processing follows the highlighted steps as presented in the Figure 4.1. The open source implementation provided in [17] is used to implement the edge processing. The description of each of the blocks used in this implementation is provided below.
• Synchronisation - The first step after preamble detection is to achieve time synchronisation with the start of the LoRa symbol. The symbol starting point is estimated by a sliding window cross-correlation of the instantaneous frequency of the received LoRa signal and the locally syn-thesized chirp and taking the argument max of this value. This argmax value is compared with a threshold and the LoRa signal is rejected in case of the correlation coefficient falls below the threshold. This method has an advantange that it mitigates Channel Frequency Offset (CFO), in-troduced by channel and SDR, by correlating on the instantaneous fre-quency instead of just the complex value.
• Demodulation- The second step is the demodulation of the LoRa chirp modulated signals. The demodulation mechanism as mentioned in [23] and reverse-engineered in [16], uses a FFT-based approach. The LoRa upchirp signals are de-chirped by multiplying with a downchirp signal in order to obtain a constant frequency symbol. By taking the FFT of this symbol, the frequency bin with the highest energy containing the transmitted data is obtained. The implementation in [17] differs from the FFT-based demodulation in that it uses the second order derivative of the instantaneous frequency of the signal to estimate the time shift of the symbol. This method removes the need to carry out the frequency corrections that need to be carried out for the FFT-based approach. • Deinterleaving - The demodulated chip values are deinterleaved in the
28 CHAPTER 4. METHODS
• Dewhitening - The LoRa patent[23] specifies the whitening as the XOR-ing the data with 9-bit Left Shift Register (LSR) in order to keep the transmitted data free of DC noise. The dewhitening process is carried out as presented in [17] after the payload is decoded.
• Decoding - The payload is decoded by performing Hamming decod-ing. The Hamming codeword consists of parity bits and data bits. The data bits are posititoned at specified positions in the codeword. Stan-dard Hamming decoding has data bits positioned at indices 1, 2, 3 and 5 for codeword (8, 4) but as per the experimentation outcomes of au-thors in [17], the mapping sequence employed in LoRa is 0, 1, 2 and 3. This is the final step where all the payload data sent by the transmitter is decoded.
4.4
Virtualization
The function implemented in the edge need to be virtualized in order to remove any dependencies associated with libraries, GNURadio Out-Of-Tree (OOT) software modules, GNURadio software environment, etc. Container environ-ment like docker is well suited for deploying applications in a self-contained manner.
Figure 4.6: Virtual machine vs Docker adapted from [24].
CHAPTER 4. METHODS 29
Chapter 5
Implementation
In this Chapter, a detailed description of the hardware and software implemen-tation is presented. The core idea is to generate the LoRa modulated packets from an off-the-shelf transmitter device and decode these packets by imple-menting a custom receive chain in the Edge. In the following sections, the individual components that form the complete system are explained.
5.1
Fipy IoT Board
A transmitter device is required to modulate and send the raw data bytes as LoRa packets, which would then be decoded by the receiver. For this purpose, Pycom’s IoT board called Fipy is used as the transmitter. FiPy is an easily programmable microcontroller which employs a MicroPython REPL environ-ment. It uses a Semtech’s SX1272 LoRa chipset for the LoRa modulation. The Fipy is mounted on an Expansion Board to which an antenna operating in the EU ISM band is connected. The hardware setup is completed once this device is connected to host computer via an USB cable [9]. The board is programmed in Python in a text editor like Atom, making using of the LoRa network library. The various programmable parameters significant to generate the LoRa packets of a particular format as described below.
• Mode - used to set the operating mode either LoRa (physical layer) or LoRaWAN (Physical + MAC)
• Region - used to set the operating region of the device. For Europe, it is EU868.
• Frequency - used to set the transmission frequency in EU868 band.
CHAPTER 5. IMPLEMENTATION 31
• Bandwidth - used to set the signal bandwidth as 125KHz/250KHz/500KHz. • SF - used to set the spreading factor for transmission. Range is from 6
to 12.
• Preamble - used to set length of the programmable preamble sequence. Length varies from 2 to 65535.
• Coding Rate - used to set the coding rate. Supports values 1, 2, 3, 4. • Power_Mode - used to set the LoRa power modes. Can be LoRa.
AL-WAYS_ON, LoRa. TX_ONLY or LoRa. SLEEP. • Tx_I/Q and Rx_I/Q - enables or disables I/Q inversion. • Public - selects between public or private sync word.
5.2
Software Defined Radio
The first point of contact in the receiver chain is the SDR board from National Instruments(NI) namely USRP B210. The B210 provides RF frontend capa-bilities and converts analog RF samples to digital I/Q samples. The hardware has 4 ports -2 Receive(RX) and 2 Transmit/Receive (TX/RX) to which an an-tennae operating in the EU868 band is connected. The major advantage with using this hardware is that it provides easy programmability through the signal processing block in the GNURadio environment. The SDR is connected to the RH via USB 3 where the preamble detection mechanisms are implemented in the open source software GNURadio.
5.3
Host Machines
32 CHAPTER 5. IMPLEMENTATION
5.4
GNURadio
The GNURadio is an open-source project providing tools for developing com-munication systems consisting of signal processing blocks. It provides the flexibility to use pre-available signal processing libraries or to implement cus-tom blocks, called out-of-the-tree (OOT) modules in either C++ or Python programming languages. The blocks are connected to each other by means of a dataflow graph, which means that the block processes the samples in chunks as and when a data arrives. It uses a powerful scheduler to schedule the ar-rival of the samples based on the data consumption capacity of a block. In this work GNURadio 3.7.9 is used as the software environment for implementing the capabilities in RH and the Edge. Figure 5.1 and 5.2 present the different software blocks, as depicted in Chapter 4 Figure 4.1, which are implemented on the RH and Edge hosts respectively.
Figure 5.1: GNURadio software blocks running on the RH host.
5.5
Makefile and Docker
CHAPTER 5. IMPLEMENTATION 33
Figure 5.2: GNURadio software blocks running on the Edge host.
34 CHAPTER 5. IMPLEMENTATION
after building the required dependencies in the dockerfile.
Chapter 6
Performance Evaluation
In this Chapter, we present the details regarding the measurement setup, the measurement methodology and measurement results of this thesis work.
6.1
Measurement setup
Figure 6.1: End-to-End measurement setup.
Figure 6.1 presents the end-to-end measurement setup. The transmitter side consists of Pycom board containing the Semtech SX1272 LoRa chipset which is programmed to transmit the LoRa packets. 2 Intel NUCs containing i7 6th generation processors with 16 GB RAM are used to emulate the RH and the Edge, which are connected via an Ethernet link. The USRP B210 SDR is connected to RH to receive the transmitted LoRa packets. Both the RH and
36 CHAPTER 6. PERFORMANCE EVALUATION
edge hosts run the GNURadio 3.7.3 environment which contain the software blocks mentioned in previous sections.
6.2
Measurement results
6.2.1
Fronthaul utilization
Figure 6.2: FH link utilization for scenario with preamble detection captur-ing varycaptur-ing number of LoRa packets (blue) and without preamble detection capturing noise samples (orange) extrapolated from 1 day capture.
CHAPTER 6. PERFORMANCE EVALUATION 37
data that was transmitted via the Ethernet FH link was inferred. In case of non-preamble based link utilization, the preamble detection block was dis-abled and the measurements were repeated. The non-preamble case is seen to consume around 9 MB of data per second which means that in 1 day it consumes 9MB*3600*24=777600 MB of data. We may thus see that the uti-lization is reduced by 227 times for 10000 packet transmissions in a day due to the preamble detection mechanism. The implementation ensures that with scalability of RH gateways, the link utilization due to noise samples is mini-mized.
6.2.2
Split vs Non-split
PER vs SNR
Figure 6.3: The variation of packet error rate (PER) with SNR for base archi-tecture and split archiarchi-tecture.
38 CHAPTER 6. PERFORMANCE EVALUATION
= Sp + N where Sp is the signal power arriving at the RX port of USRP and
N is the noise introduced by the channel + USRP hardware. Given S’p, a tar-get SNR value is chosen so that corresponding noise value to be added to the signal is calculated from the formula SNR= S’p - Ncalc. For example, if SNR
of 10 dB is to be achieved, then the signal power is first calculated from the arriving samples and the noise to be added to the signal to achieve the SNR of 10 dB is calculated. In this way measurements were carried for the differ-ent values of SNR. It may be observed that non-split base architecture detects 100% of the packets for a SNR above 5 dB while it reaches the 0% success for SNRs<-3. The split is found to have a better performance for sub-zero SNR while the it closely follows the base for SNRs > 0dB. This indicates that the performance of split architecture is as good as the base architecture indi-cating the split architecture setup is completely feasible. The negative SNR performance improvement of split may be attributed to marginally better de-tection because of the multiple preamble symbols giving better correlation. If we compare with performance of hardware LoRa decoders we may observe that, the SNR performance is around 10 dB worse. This may be attributed to the limited capabilities of the gradient based decoding algorithm used by [17]. Additionally, C++ implementation outperforms the python implementa-tion due to slower execuimplementa-tion of the preamble block causing packet losses. The execution time of the work function of preamble blocks over 10 LoRa packets is presented in table 6.1 where we clearly see that C++ performs a lot faster.
Implementation language Work function execution time (ms)
Python 4.05
C++ 3.746
Table 6.1: Comparison of work function execution time for Python vs C++ implementation.
6.2.3
Preamble detection accuracy
CHAPTER 6. PERFORMANCE EVALUATION 39
Figure 6.4: Accuracy of detecting the different SFs for SNR 0.
SF Samples per symbol No. of symbols cor-related: Our method No. of symbols cor-related: [17] method 6 256 16 2 7 512 8 2 8 1024 4 2 9 2048 2 2 10 4096 1 2 11 8192 0.5 2 12 16384 0.25 2
Table 6.2: Symbols correlated for different SFs in our method vs [17] method. Our method: GNURadio max block buffer size = 4096
[17] method: GNURadio max block buffer size = 32768
40 CHAPTER 6. PERFORMANCE EVALUATION
each gnuradio buffer of 4096 samples would contain 16, 8, 4, 2, 1, 0.5 and 0.25 symbols of SF6 to SF12 respectively. This further implies that the cor-relation coefficients is sufficiently high upto SF10 because of 1 or more LoRa symbol matches where SF11 and SF12 are partially matched. SNR 0 being not sufficiently high SF11 and SF12 detection accuracy suffer. It is also note-worthy that SF11 and SF12 sequences are very long with a longer time-on-air. Such modulation would be employed in few applications where the devices are buried deep into an area and for majority of use cases modulation upto SF10 is more than sufficient to provide wide range of connectivity options.
6.2.4
Correlation method comparison
CHAPTER 6. PERFORMANCE EVALUATION 41
from Table 6.2. For SF 11 and 12, the correlation values are much higher for the method in [17] owing to larger buffer sizes where complete chirp symbols are correlated as opposed to our method where only 0.5 and 0.25 symbols, respectively, are correlated. The drawback of having large buffer sizes is that it introduces higher processing delays which affects the performance of the subsequent blocks in the system. This would further indicate that there is a trade-off between buffer size and processing delay in order to achieve higher correlation.
6.2.5
Python vs C++ implementation
The initial code implementation was carried out in python owing to fast proto-typing, lesser build cycles and simplicity in coding. Although python provides a host of libraries suitable for this thesis work like numpy-fft, cross-correlation, etc., in the GUNRadio environment it is primarily used as a scripting lan-guage for connecting the blocks in the flowgraph but not for runtime process-ing of each blocks. Hence, in order to make the best use of the GNURadio environment to achieve performance gains as well as maintain coherence with the previous IoT RAT implementations (like NB-IoT and IEEE 802.15.4) re-lated to this work, the python software block was re-implemented in C++. Figure 6.6 shows the comparison of the CPU utilization for python vs C++ implementation. It may be observed that the CPU utilization of C++ is bet-ter distributed among the threads by the scheduler with maximum utilization in a single thread being <50% whereas in python the maximum utilization shoots over 100% in a single thread with the other CPU cores being ineffi-ciently utilized. Furthermore from Appendix C we observe that the core CPU temperature in case of python implementation consistently shoots over a dan-gerous 90oC value while the c++ implementation results in a max temperature of around 60oC. An operating temperature range of over 85oC is deemed as unsafe even under high loading conditions. Furthermore, as seen from Table 6.1 the work function execution time for C++ is 8% better than python mak-ing C++ the better choice for implementation of the software blocks in the GNURadio environment.
6.2.6
Virtualized multi-RAT setup
42 CHAPTER 6. PERFORMANCE EVALUATION
(a) Idle CPU utilization
(b) Python implementation
(c) C++ implementation
Figure 6.6: CPU utilization - Python vs C++.
CHAPTER 6. PERFORMANCE EVALUATION 43
be noted that the traffic was generated only for LoRa and IEEE 802.15.4 while NB-IoT was used just as a background process.
Figure 6.7: LoRa CPU utilization for Multi-RAT scenario.
Figure 6.8: Network usage for Multi-RAT scenario.
44 CHAPTER 6. PERFORMANCE EVALUATION
Chapter 7
Conclusions
In this thesis work, the baseband split-architecture was introduced as a con-cept for IoT RAT namely LoRa. The drawbacks of the traditional architecture namely non-scalability and inefficient resource consumption were highlighted and physical layer baseband split-architecture were explored. The proposed virtualized architecture enables the softwarization of the hardware baseband processing providing better control over handling Fronthaul (FH) network ca-pacity as well as efficient use of computing resources. For this purpose, a preamble detection method was proposed, which accurately identified the SF characteristic of the chirp signal being transmitted, the implementation of which was carried out in the gateway node called Radiohead (RH). Open-source implementations were used to implement the Edge processing func-tions.
In comparison to the non-split architecture, several benefits were achieved. The FH link utilization was reduced by many folds by employing the split-architecture. The reduction in the network usage is mainly attributed to the detection and selective transmissions of the LoRa based packets which resulted in efficient use of the FH link. For 10000 packet transmission, the performance was observed to be better by over 200 folds. The preamble detection method introduced in this thesis work was shown to accurately (>98%) detect Spread-ing Factors (SF) 6, 7, 8, 9 and 10 while the accuracy was over 60% for SFs 11 and 12, the cause of which was identified as small buffer sizes indicating a tradeoff between SF detection accuracy and the input buffer size of GNURadio blocks. The split-architecture was shown to perform as good as the non-split architecture for the SNR range -3 dB to 10 dB for the over-the-air measurement methodology. The proposed preamble detection method performed better than the method presented in [17], for all SFs upto 10. The feasibility of the
46 CHAPTER 7. CONCLUSIONS
tualizing the LoRa physical baseband processing to the edge was proven by successfully integrating with other RAT technologies like IEEE 802.15.4 and NB-IoT. Initial results of the multi-RAT system showed a LoRa CPU utiliza-tion of around 13% for 2-RAT setup, positively reinforcing the realizautiliza-tion of multi-RAT system. Furthermore, C++ was recommended to be a better im-plementation choice for the GNURadio environment over Python due to faster execution times, lower CPU utilization and for functioning in optimal core temperature range. The thesis was able to achieve its goal of implementing a flexible, scalable and resource-saving capable IoT system architecture. It addi-tionally enabled multi-RAT interoperability by simultaneously executing with IEEE 802.15.4 and NB-IoT without witnessing much performance degrada-tion.
7.1
Limitations
In this section, the limitations of the thesis work are listed.
• The implementation was shown to work consistently in a lab environ-ment on a prototype test bed. The NUC processors were used as emu-lators for RH and edge, In real world deployments the processing capa-bilities of RH will be much lower and that of the edge would be much higher.
• Two LoRa nodes transmitting on the same channel but with different SFs could not be decoded in the software decoder implementation in the Edge, while in theory as well as in hardware gateways this is possi-ble. This is one of the major limitations as it fails the SF orthogonality condition of LoRa standard.
• There were problems associated with accurately detecting higher SFs 11 and 12 due to the requirement of larger buffer size to hold samples equalling atleast 1 symbol length of the 2 SFs.
CHAPTER 7. CONCLUSIONS 47
• A maximum of 2 IoT nodes with 2 different channels and SFs were con-nected to the split setup while the deployment in real world run into 1000s of nodes, a more realistic scalability scenario.
7.2
Future work
Bibliography
[1] N. Sornin (Semtech), M. Luis (Semtech), T. Eirich (IBM), T. Kramp (IBM), and O.Hersent (Actility). “https://LoRa-alliance.org/resource-hub/LoRawanr-specification-v10”. In: LoRa Alliance (2015).
[2] Y-P Eric Wang, Xingqin Lin, Ansuman Adhikary, Asbjörn Grövlen, Yutao Sui, Yufei Blankenship, Johan Bergman, and Hazhir S Razaghi. “A primer on 3GPP narrowband Internet of Things (NB-IoT)”. In: arXiv
preprint arXiv:1606.04171 (2016).
[3] http://www.ieee802.org/15/pub/TG4.html.
[4] China Mobile. “C-RAN: the road towards green RAN”. In: White paper,
ver 2 (2011), pp. 1–10.
[5] ZhenBo Zhu, Parul Gupta, Qing Wang, Shivkumar Kalyanaraman, Yonghua Lin, Hubertus Franke, and Smruti Sarangi. “Virtual Base Station Pool: Towards a Wireless Network Cloud for Radio Access Networks”. In:
Proceedings of the 8th ACM International Conference on Computing Frontiers. CF ’11. Ischia, Italy: ACM, 2011, 34:1–34:10. isbn:
978-1-4503-0698-0. doi: 10 . 1145 / 2016604 . 2016646. url: http : //doi.acm.org/10.1145/2016604.2016646.
[6] 5G CORAL project webpage, “http://5g-coral.eu/”.
[7] Line MP Larsen, Aleksandra Checko, and Henrik L Christiansen. “A survey of the functional splits proposed for 5G mobile crosshaul net-works”. In: IEEE Communications Surveys & Tutorials 21.1 (2018), pp. 146–172.
[8] “LoRaWAN 1.1. Regional Parameters Specification, https://www.LoRa-alliance.org/”. In: LoRa Alliance (2017).
[9] Pycom Fipy webpage, “https://docs.pycom.io/datasheets/development/fipy/”. [10] USRP B210 webpage, “http://www.ettus.com/all-products/ub210-kit/”. [11] GNURadio webpage, “https://www.gnuradio.org/”.
BIBLIOGRAPHY 49
[12] Docker webpage, “https://www.docker.com/”.
[13] M. Centenaro, L. Vangelista, A. Zanella, and M. Zorzi. “Long-range communications in unlicensed bands: the rising stars in the IoT and smart city scenarios”. In: IEEE Wireless Communications 23.5 (Oct. 2016), pp. 60–67. issn: 1536-1284. doi: 10 . 1109 / MWC . 2016 . 7721743.
[14] Vinay Suryaprakash, Peter Rost, and Gerhard Fettweis. “Are hetero-geneous cloud-based radio access networks cost effective?” In: IEEE
Journal on Selected Areas in Communications 33.10 (2015), pp. 2239–
2251.
[15] J. Bartelt, P. Rost, D. Wubben, J. Lessmann, B. Melis, and G. Fet-tweis. “Fronthaul and backhaul requirements of flexibly centralized ra-dio access networks”. In: IEEE Wireless Communications 22.5 (Oct. 2015), pp. 105–111. issn: 1536-1284. doi: 10.1109/MWC.2015. 7306544.
[16] Matthew Knight and Balint Seeber. “Decoding LoRa: Realizing a mod-ern LPWAN with SDR”. In: Proceedings of the GNU Radio
Confer-ence. Vol. 1. 1. 2016.
[17] Pieter Robyns, Peter Quax, Wim Lamotte, and William Thenaers. “A multi-channel software decoder for the LoRa modulation scheme”. In: 2018.
[18] Ping-Heng Kuo, Alain Mourad, Chenguang Lu, Miguel Berg, Simon Duquennoy, Ying-Yu Chen, Yi-Huai Hsu, Aitor Zabala, Riccardo Fer-rari, Sergio Gonzalez, et al. “An integrated edge and Fog system for future communication networks”. In: 2018 IEEE Wireless
Communica-tions and Networking Conference Workshops (WCNCW). IEEE. 2018,
pp. 338–343.
[19] Guillaume Ferré and Audrey Giremus. “LoRa Physical Layer Principle and Performance Analysis”. In: 2018 25th IEEE International
Confer-ence on Electronics, Circuits and Systems (ICECS). IEEE. 2018, pp. 65–
68.
[20] Pycom Fipy webpage, “https://www.semtech.com/products/wireless-rf/
LoRa-transceivers/sx1272”.
[21] Weisstein, Eric W. "Cross-Correlation Theorem." From MathWorld–A
50 BIBLIOGRAPHY
[22] A. Goshtasby, S. H. Gage, and J. F. Bartholic. “A Two-Stage Cross Correlation Approach to Template Matching”. In: IEEE Transactions
on Pattern Analysis and Machine Intelligence PAMI-6.3 (May 1984),
pp. 374–378. issn: 0162-8828. doi: 10.1109/TPAMI.1984.4767532. [23] Olivier BA SELLER and Nicolas Sornin. Low power long range
trans-mitter. US Patent 9,252,834. Feb. 2016.
[24] Whitepaper: Definitive Guide to Enterprise Container Platforms,
“https://www.docker.com/”.
Appendix A
Calibration
Figure A.1: Calibration mapping of GNU Rx Power vs Ideal Rx Power with varying gain.
Appendix B
Curve fitting
Figure B.1: Polynomial function of degree 3 to map GNU Rx Power with ideal power.
Appendix C
Temperature - python vs c++
(a) Python implementation temperature variation
(b) C++ implementation temperature variation
Figure C.1: CPU core temperature variation.
TRITA-EECS-EX-2019:688
