IT 18 054

Examensarbete 30 hpAugust 2018

IOT CONNECTIVITY WITH EDGE COMPUTING

Maximilian Stiefel

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

IOT CONNECTIVITY WITH EDGE COMPUTING

Maximilian Stiefel

Billions of Internet of Things (IoT) devices will be connected in the next decades.Most devices are for Massive Machine Type Communication (MMTC) applications.This requires the IoT infrastructure to be extremely efficient and scalable (like today’sInternet) to support more and more devices connected to the network over time.The cost per connection needs to be very low (like today’s Web services). Thecurrent network design with dedicated HW-based base stations (or IoT gateways)may be too costly. Furthermore, there is a vast amount of IoT radio standards, suchas Narrowband-IoT (NB-IoT), LTE-M, BLE, ZigBee, Sigfox, LoRa, to give someexamples, which all need to be implemented if they are supposed to be supported.The current approach requires to deploy parallel networks with dedicated basestations for different standards in one place. This further increases network costs.

Cloud Radio Access Network (RAN) (c-RAN) has been proposed to centralize andcloudify baseband processing in a cloud infrastructure based on GPPs, which canpotentially increase network flexibility and reduce the network Total Cost ofOwnership (TCO) significantly. It can also be beneficiary for network performance byincreased coordination possibilities. Nowadays, c-RAN still is on a concept level,because it is deemed difficult to implement due to complexity and reliability issues,e.g. for 4G/5G which requires sophisticated processing capabilities. The terminologyof C-RAN today refers more to Centralized-RAN based on Digital Signal Processing(DSP) microcontrollers and ASICs, instead of c-RAN. However, the MMTCtechnologies are usually narrowband and designed with low complexity (consideringcost of User Equipment (UE), power consumption, battery life time, etc.). Therefore,they are rather suitable for cloud implementation. Latency may be another issue forc-RAN. However, most of the MMTC applications are based on best-effort strategiesand delay-tolerance. Therefore, c-RAN offers a promising solution to deliver therequired efficiency and scalability for MMTC services.

This master thesis is part of an effort to explore the possibilities, to increase theunderstanding and to gain hands-on experiences of IoT c-RAN implementation at theedge. It focuses on the NB-IoT downlink (DL) Physical (PHY) implementation as oneexample. However, IEEE 802.15.4 (PHY layer of e.g. Zigbee) has been integrated intothe system within a collaboration between Ericsson and RISE SICS. This also shows,that c-RAN technology is able to unite multiple radio interfaces in one systemleveraging Software (SW). In this study, we built a Software Defined Radio (SDR)testbed based on GNU Radio. The USRP B210 is the Hardware (HW) tool to test theimplementation. Key components of the NB-IoT DL have been implemented.Orthogonal Frequency-Division Multiplex (OFDM) transmitter and receiver followthe NB-IoT numerology and implement algorithms for signal generation, time andfrequency synchronization, as well as equalization and demodulation. Theconvolutional code of the Voyager missions with a coding rate R = 12 is used forperformance evaluation. Different baseband modules have been tested and verified.Investigations have been carried out on the topic of latency. The measurements reveala latency, which is higher than expected. Most likely, this is due to the large buffersunderlying the GNU Radio scheduler in combination with the low speed of NB-IoT.The end-to-end system has been evaluated by field measurements (Signal-to-NoiseRatio (SNR), Bit Error Rate (BER), Packet Error Rate (PER)) conducted in an Ericssonoffice environment. With no Line-Of-Sight (LOS), the implemented system has areach of >= 65 m (from the office lab on floor 4 to the other end of the corridorwhere GFTB ER NAP NIT Fronhaul Technologies is located) with only 0.5 % PER anda SNR of 15.9 dB. In this work, system and SW design of the testbed andimplementation are presented, as well as the hands-on experiences. The testbed isready for human interaction with a fascinating Telegram bot live demo.

Tryckt av: Reprocentralen ITCIT 18 054Examinator: Mats DanielsÄmnesgranskare: Thiemo VoigtHandledare: Chenguang Lu

Acknowledgement

As a guest, living and studying in the country of Sweden, I always admired the helpfulness and kindness,I received here. I very much appreciated the working climate in the o�ce cubes and labs at Ericsson. Fur-thermore, the help of many colleagues at Ericsson and professors and researchers from Uppsala Universitywas very valuable for me. Especially, I would like to thank, Chenguang Lu, for always lending an ear tome and my problems, and for providing me with new ideas whenever I got stuck. Besides, I would like toexpress my gratitude to Thiemo Voigt, who was supporting me with his contacts at RISE SICS and UU,and who was reading and commenting on my fortnightly reports. Moreover, I would like to express mythanks to Per-Erik Ericsson, Yezi Huang, Daniel Cederholm, Eduardo Medeiros, Elmar Trojer, HenrikAlmeida, Miguel Berg, Jurgen Gobel, Niklas Wirstrom, Simon Duquennoy and Boris Dortschy. To endthis acknowledgement I would like to refer to a speech of the inventor of the radio who worded his thanks”to the Swedes” in a most marvellous way for receiving the Nobel Prize in Physics together with KarlBraun:

” You will also allow me to thank the Academy for inviting me to lecturein Stockholm, for its hospitality, and for the opportunity a↵orded me foradmiring the charm of your people and the beauty of your country.

Your Royal Highnesses, Your Excellencies. Ladies and Gentlemen, I havethe honour to ask you to drink to the health of Sweden and to the con-tinued happiness and prosperity of the Swedish nation.

- Guglielmo Marconi, Nobel Banquet in Stockholm, December 10, 1909

Table of Contents

Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I

List of Symbols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III

List of Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

List of Code Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1 Narrowband-IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Sustainable Technology for Connecting Billions of Devices . . . . . . . . . . . . . . 42.1.2 Orthogonal Frequency-Division Multiplex . . . . . . . . . . . . . . . . . . . . . . . 52.1.3 Frame Structure and Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.4 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.5 Equalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 GNU Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Docker as a Cloud Radio Access Network (RAN) Enabler . . . . . . . . . . . . . . . . . . 16

3 Design and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1 Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Data Transmission and Application Layer . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 Scrambling, Encoding and Modulation . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3 Narrowband Reference Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.4 Narrowband Primary Synchronization Signal . . . . . . . . . . . . . . . . . . . . . 213.1.5 Orthogonal Frequency-Division Multiplex . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Radio Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Baseband Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Synchronizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Orthogonal Frequency-Division Multiplex . . . . . . . . . . . . . . . . . . . . . . . 283.3.3 Equalizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.4 Demodulation, Decoding and Descrambling . . . . . . . . . . . . . . . . . . . . . . 303.3.5 Data Transmission and Application Layer . . . . . . . . . . . . . . . . . . . . . . . 30

4 System Validation and Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . 334.1 Validation of Key Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.2 Equalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3 Baseband Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Performance Analysis and Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.1 Signal-to-Noise Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.2 Bit Error Rate and Packet Error Rate . . . . . . . . . . . . . . . . . . . . . . . . . 40

I

4.2.3 Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.4 Latency Measurement and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Field Measurement Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.1 Testbed and Measurement Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.3.2 Measurement Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.4 Comparison of LimeSDR and USRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XIII

A Python Script to Parse iftop Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

B Send Dynamic IP Address with Telegram Bot . . . . . . . . . . . . . . . . . . . . . . . .XVII

C Edge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XVIII

D Radio Head . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XIX

E Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX

F Measurement Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XXI

G Lime Microsystems LMS7002M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XXII

II

List of Symbols

Symbol Unit (Abbreviation) Physical Quantitya Complex modulation symbolC Crest factorCP Length of the shorter Long-Term Evolution (LTE)

Cyclic Prefix (CP)CPEXTRA Length of the longer LTE CPCPTEMP Length of the temporary CP (3.2.2)dNPSS Narrowband Primary Synchronization Signal (PSS)

(NPSS) in frequency domainds Downsampling factorDNPSS NPSS in time domainDSF=a Byte per second (B/s) Data rate on subframe aDW Byte per second (B/s) Data rate over Universal Serial Bus (USB) wireDØMQ Byte per second (B/s) Data rate over ZeroMQ (ØMQ) interfacefs Frequency (Hz) Sampling rate�f Frequency (Hz) Frequency o↵set�f Frequency (Hz) Orthogonal Frequency-Division Multiplex (OFDM)

subcarrier spacingfFFO Frequency (Hz) Fractional Frequency O↵set (FFO)fT Frequency (Hz) Transmitter Local Oscillator (LO) frequencyGR Decibel (dB) Receiver gainGT Decibel (dB) Transmitter gainht Channel impulse responseHf Channel frequency responsek OFDM sub-carrier indexKd Derrivative Proportional-Integral-Derivative con-

troller (PID controller) coe�cientKi Integral PID controller coe�cientKp Proportional PID controller coe�cientl OFDM symbol indexNC Number of OFDM carriersN 0

C Number of used OFDM carriersNSA Number of samples used for OFDM symbols and CPN 0

SA Number of samples used for OFDM symbolsNSA,SF Number of samples used for one Narrowband-IoT

(NB-IoT) subframeNSF Number of NB-IoT subframes per frameN 0

SF Number of NB-IoT subframes per frame used fordata transmission

NSY Total number of symbolsN 0

SY Number of symbols actually occupied with data (in-stead of pilots)

NSY,SF Number of NB-IoT symbols per subframeNSY,SF,O Number of NB-IoT OFDM symbols per subframeNSY,P Number of NB-IoT pilot symbols per subframeNFFT Length of Fast Fourier Transform (FFT)Nwindow Length of a correlation window (continuous data

stream)Nreference Length of the correlation reference (fixed data

stream)M Number of bits per symbol in modulation alphabetPAPR Peak-to-Average Power Ratio (PAPR)

III

R Code ratet Seconds (s) TimetT Seconds (s) Total latencytLB Seconds (s) Lower boundary for latencyTCP Seconds (s) Rough LTE CP periodTGI Seconds (s) Guard intervalTOFDM Seconds (s) OFDM symbol lengthTSF Seconds (s) LTE subframe period! Hertz (Hz) Radial frequencyx Complex, multi-carrier signal

IV

List of Abbreviations

3GPP 3rd Generation Partnership Project.

ABI Application Binary Interface.

ADC Analog-to-Digital Converter.

AI Artificial Intelligence.

API Application Pogramming Interface.

AWGN Additive White Gausian Noise.

BER Bit Error Rate.

blob binary large object.

BPSK Binary Phase Shift Keying.

c-RAN Cloud RAN.

CAZAC Constant Amplitude Zero Auto-Correlation.

CLI Command Line Interface.

CP Cyclic Prefix.

CPU Central Processing Unit.

CRC Cyclic Redundancy Check.

DAB Digital Audio Broadcast.

DAC Digital-to-Analog Converter.

DC Direct Current.

DCI Downlink Control Information.

DDR Double Data Rate.

DFT Discrete Fourier Transform.

DL downlink.

DSP Digital Signal Processing.

EC-GSM-IoT Enhanced Coverage GSM IoT.

EFS Edge Fog Computing System.

EMC Electro-Magnetic Compatibility.

eNodeB Evolved Node B.

FEC Forward Error Correction.

FFO Fractional Frequency O↵set.

FFT Fast Fourier Transform.

FIFO First In First Out.

V

FIR Finite Impulse Response.

FM radio Frequency-Modulated radio.

FPGA Field-Programmable Gate Array.

FPU Floating-Point Unit.

GNU GNU’s Not Unix!.

GPL GNU’s Not Unix! (GNU) General Public License.

GPP Genereal Purpose Processor.

GSM Global System for Mobile communication.

HARQ Hybrid Automatic Repeat Request.

HSPA High Speed Packet Access.

HTTPS HyperText Transfer Protocol Secure.

HW Hardware.

IC Integrated Circuit.

ICI Inter Channel Interference.

ICIT Institute for Critical Infrastructure Technology.

IDFT Inverse Discrete Fourier Transform (DFT).

IEEE Institute of Electrical and Electronics Engineers.

IFFT Inverse FFT.

IFO Integer Frequency O↵set.

IoT Internet of Things.

IP Internet Protocol.

ISI Inter Symbol Interference.

ISM band Industrial, Scientific, Medical band.

JSON JavaScript Object Notation.

KISS Keep it simple, stupid.

LFSR Linear Feedback Shift Register.

LGPL GNU Lesser General Public License.

LO Local Oscillator.

LOS Line-Of-Sight.

LPWAN Low-Power Wide Area Networks.

LTE Long-Term Evolution.

LTE-M LTE Machine Type Communication.

MIMO Multiple Input Multiple Output.

MMTC Massive Machine Type Communication.

VI

Multi-RAT Multi Radio Access Technology.

NB-IoT Narrowband-IoT.

NDI New Data Indicator.

NPDCCH Narrowband Physical downlink (DL) Control Channel.

NPSS Narrowband PSS.

NRS Narrowband Reference Signal.

NSSS Narrowband Secondary Synchronization Signal (SSS).

OFDM Orthogonal Frequency-Division Multiplex.

OFDMA Orthogonal Frequency-Division Multiple Access.

OOT module Out-Of-Tree module.

PAPR Peak-to-Average Power Ratio.

PCIe Peripheral Component Interconnect Express.

PDU Protocol Data Unit.

PER Packet Error Rate.

PHY Physical.

PID controller Proportional-Integral-Derivative controller.

PIMPL PoInter to iMPLementation.

PMT Polymorphic Data Type.

PR Pull Request.

PRB Physical Resource Block.

PSK Phase-Shift Keying.

PSS Primary Synchronization Signal.

PyBOMBS Python Build Overlay Managed Bundle System.

Q/A Quality Assurance.

QPSK Quadrature Phase Shift Keying.

RAM Random Access Memory.

RAN Radio Access Network.

RAT Radio Access Technology.

RB Resource Block.

RF Radio Frequency.

RoI Return of Interest.

SC-FDMA Single-Carrier Frequency Devision Multiple Access.

SDR Software Defined Radio.

SIMD Single Instruction Multiple Data.

VII

SNR Signal-to-Noise Ratio.

SSS Secondary Synchronization Signal.

SW Software.

SWIG Simplified Wrapper and Interface Generator.

TCP Transmission Control Protocol.

TDD Time Division Duplexing.

UE User Equipment.

UI User Interface.

UL uplink.

UML Unified Modeling Language.

USB Universal Serial Bus.

VOLK Vector-Optimized Library of Kernels.

ZC sequence Zado↵-Chu sequence.

ØMQ ZeroMQ.

VIII

List of Figures

1.1 System overview block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 NB-IoT deployment options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Pulse shape of a NB-IoT signal (a) and spectrum of one subcarrier (b). . . . . . . . . . . 52.3 OFDM transmitter in terms of FFT algorithm. . . . . . . . . . . . . . . . . . . . . . . . . 62.4 OFDM receiver in terms of FFT algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5 Visualization cyclic prefixing algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6 NB-IoT signal in frequency domain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7 Frame structure and timing of NB-IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.8 Synchronization method using the CP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.9 Visualization of multi-rate signal processing for time synchronization. . . . . . . . . . . . 122.10 Visualization of the Narrowband Reference Signal (NRS) mapping scheme. . . . . . . . . 142.11 Simple channel estimation algorithm applied in this work. . . . . . . . . . . . . . . . . . . 15

3.1 Overview of the testbed as it has been designed within this work. . . . . . . . . . . . . . . 183.2 Data transmission and application layer in GNU Radio. . . . . . . . . . . . . . . . . . . . 193.3 Visualization of one packet on the application layer. . . . . . . . . . . . . . . . . . . . . . 193.4 Scrambling and encoding in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.5 NRS generation in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6 NPSS generation in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7 OFDM modulator in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.8 Class diagram Out-Of-Tree module (OOT module) for the LimeSDR. . . . . . . . . . . . 233.9 LimeSDR OOT module blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.10 NPSS time synchronizer on GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.11 Illustration of overlap-save implemented in the correlator. . . . . . . . . . . . . . . . . . . 263.12 NPSS-based frequency synchronization with PID controller in GNU Radio. . . . . . . . . 273.13 FFO estimation in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.14 OFDM demodulator in GNU Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.15 Comparison with and without equalizer after single-tap channel model. . . . . . . . . . . . 293.16 Equalization and reference symbol removal in GNU Radio. . . . . . . . . . . . . . . . . . . 303.17 Decoding and descrambling in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . 303.18 Chat application receiver side in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Low-rate cross-correlator output with clearly visible peak. . . . . . . . . . . . . . . . . . . 334.2 Distort controller with rectangular signal. . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Comparison of the result of two di↵erent equalizers. . . . . . . . . . . . . . . . . . . . . . 374.4 Estimated channel phase and magnitude. . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Fronthaul datarate comparison between compressed and uncompressed. . . . . . . . . . . 384.6 Fornthaul datarate when OFDM modulator is in the radio head. . . . . . . . . . . . . . . 394.7 Signal-to-Noise Ratio (SNR) comparison with and without compression algorithm. . . . . 404.8 Bit Error Rate (BER) and Packet Error Rate (PER) comparison between uncompressed

and compressed fronthaul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.9 Block diagram showing relation of bu↵ers, Genereal Purpose Processor (GPP) and radio

peripheral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.10 Block diagram of di↵erent Digital Signal Processing (DSP) blocks and interconnecting

bu↵ers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.11 Latency measurement results with simulation on one machine. . . . . . . . . . . . . . . . 444.12 Latency measurement results with more than one machine involved. . . . . . . . . . . . . 454.13 Map of measurement locations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

IX

4.14 Received power spectrum with the USRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.15 Time domain signals of USRP and LimeSDR compared. . . . . . . . . . . . . . . . . . . . 484.16 High-rate cross-correlator output of USRP and LimeSDR compared. . . . . . . . . . . . . 494.17 Analog Frequency-Modulated radio (FM radio) waterfall diagram w/ LimeSDR. . . . . . 49

C.1 Edge design in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XVIII

D.1 Radio head app design in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIXD.2 Radio head app design in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIX

E.1 Receiver design in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XX

F.1 Photos of measurement location for documentation purposes. . . . . . . . . . . . . . . . . XXI

G.1 Functional block diagram of the Lime microsystems LMS7002M. . . . . . . . . . . . . . .XXII

X

List of Tables

2.1 Vector to generate hierarchical sequence from length-11 Zado↵-Chu sequence (ZC sequence). 11

3.1 Specifications comparison between LimeSDR-USB and USRP B210. . . . . . . . . . . . . 223.2 Interpolation filter involved in compression algorithm. . . . . . . . . . . . . . . . . . . . . 25

4.1 Parameters of the PID controller after loop tuning. . . . . . . . . . . . . . . . . . . . . . . 364.2 Results corresponding to fig. 4.13. fT = 2.45GHz and GT = 89.8 dB. . . . . . . . . . . . . 48

XI

List of Code Examples

1 Overlap-save in code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 Simple channel estimation by averaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293 Conversion from a bit stream to a Protocol Data Unit (PDU) in the Message DEMUX. . 314 Message interpretation on PDU level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Correlator help class initialization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 Bu↵er size manipulation in GNU Radio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

XII

1 | Introduction

The Internet of Things (IoT) has emerged as a hot topic in both industry and academia in the recentyears. From critical infrastructures to consumer devices, everything is expected to be connected in theIoT era and this era has only just begun. Most companies publicly state, that the IoT becomes a keyenabler for digitalization or Industry 4.0. It is common to think connections everywhere will improve ourdaily life. It is in e↵ect a current trend, that communication and permanent connectivity is introducedin almost all parts of society, such as mobility, technologically progressive (smart?) city infrastructure,homes, industrial production and health. The enthusiasm about a full connectivity, having a phone in thepocket and Artificial Intelligence (AI) assistance connected, listening and transmitting 24/7 to Amazonservers at home, has never been greater; a new world opening up possibilities no one could ever haveimagined. Others are rather sceptical and foresee hazards for us, our families and infrastructures.

Security-by-design is an indispensable prerequisite to the establishment of vital critical infrastructure re-siliency. Each device vulnerable to adversarial compromise, inflates and bolsters the exploitable cyber-attack surface that can be leveraged against targets, and every enslaved device grants adversaries carteblanche access that can be utilized to parasitically entwine malware into organizational networks and IoTmicrocosms, and that can be leveraged to amplify the impact and harm inflicted on targeted end-users,organizations, and government entities. [1]

The above quote emanates from James Scott who is part of the Institute for Critical Infrastructure Tech-nology, which sees itself as the ”leading cybersecurity think tank providing objective nonpartisan research,advisory, and education to legislative, commercial, and public-sector cybersecurity stakeholders” in theUSA. Advocators of the free software movement go as far as calling it the ”internet of stings”, not leastbecause of the fact, that lock picking has never been easier, especially when making use of non-cellular,simple, Industrial, Scientific, Medical band (ISM band) IoT standards [2].

As a matter of fact, if somebody likes it or not, more and more devices require connectivity to operate.In 2017 the number of IoT devices increased by 31% to 8.4 billion [3]. It is quite obvious, that thereis a lot of money to be made in this sector, with the number of devices connected expected to growexponentially. Currently, the IoT might be perceived as a minefield of di↵erent standards. Some of themare proprietary, others are open. Some work on ISM bands, others require the operator to own rights forlicensed spectrum utilization. There is no such thing as a workhorse for Low-Power Wide Area Networks(LPWAN) technologies for the IoT, that can answer the call for connectivity of even more low-powerdevices. These workhorses do exist in other areas e.g. Ethernet (Institute of Electrical and ElectronicsEngineers (IEEE) 802.3) to transport data over cheap twisted pair cables through buildings or beneathsurface. To give one example of an IoT comm standard, Sigfox, developed by a small French company,can transport 140 12-byte messages per day with a reach of about 30 km to 50 km in rural areas and3 km to 10 km in cities. Given the Line-Of-Sight (LOS) communication over way longer distances (>1000 km) can be established. To give another example, LoRa, engineered by Semtech and backed by anindustry alliance, promises nationwide IoT coverage (more than 10 km in rural areas). Depending on thedevices involved data rates between 0.3 kbit/s and 50 kbit/s are achievable. LPWAN technologies suchas Sigfox and LoRa have hit the market early due to not requiring the ownership of spectrum, whichis why they are so common nowadays. These two standards are somehow the pendant to 4G WiMAX(IEEE 802.16). WiMAX, although nowadays not that prevalent anymore, had a couple of advantagesover HSPA+ and LTE when it was rolled out in 2008, for instance when it comes to timing. Nevertheless,it never dominated over 3rd Generation Partnership Project (3GPP) standards, which nowadays with 4GLTE Advanced and the emerging fifth generation of mobile communication standards serve the immensedaily demands of mobile data tra�c and de facto rule the domain of broadband mobile communication.Stefan Kindt, Head of Technology Marketing at Nokia Networks, draws a comparison between WiMAXthen and Sigfox and LoRa now. He labels Sigfox and LoRA as early-birds and predicts, that the samewill happen with these two standards as what has happened with WiMAX: ”[..] in the long run, itlooks like the 3GPP evolutionary path for existing mobile networks will win the race once the 3GPPRel. 13 standardization process is completed” [4]. He is referring to the introduction of NB-IoT, LTEMachine Type Communication (LTE-M) and Enhanced Coverage GSM IoT (EC-GSM-IoT) in this re-

1

lease. Although these three wireless technologies were released in 2016, the development already begana couple of years ago in 2011 with a 3GPP feasibility study named ”Study on Provision of Low-CostMTC UEs Based on LTE”, which was the birth of LTE-M. While LTE-M adds Massive Machine TypeCommunication (MMTC) capabilities to LTE especially by trying to make LTE receivers cheaper andenabling device construction under radical power constraints (10 years + battery lifetime), EC-GSM-IoTextends the Global System for Mobile communication (GSM) with IoT functionalities. Both technologiesare backward-compatible to LTE and the GSM respectively. In contrast to EC-GSM-IoT and LTE-M,NB-IoT was conceptually never planed to be backward-compatible, which was referred to as ”clean-slate”solution within 3GPP standardization circles. NB-IoT is the wireless radio interface technology for a newgeneration of IoT devices making heavy reuse of LTE infrastructure preserving the evolutionary philoso-phy of 3GPP standards [5]. NB-IoT is the track of the future. If a new IoT device is being designed andthere are no constraints, that LTE or GSM has to be used, NB-IoT is the state of the art, that should beimplemented. Today, almost three years after the afore introduced blog post, NB-IoT is on its triumphalmarch, operators deployed the standard, products are appearing everywhere [6].

Edge

Docker

Radio Head

Docker

Fronthaul network

User Equipment (UE)

Docker

ØMQ

USBUSB

NB-IoT

Receiver 0 Software Defined Radio (SDR)

Platform

SDR

Platform

NB-IoT

Radio Head 0

NB-IoT

Transmitter 0

Figure 1.1: Overview of the system, which is the main result of this work. The three major parts are thereceiver, the radio head and the edge server.

Albeit NB-IoT or some 3GPP evolution of it will most likely be the only relevant IoT standard in thefuture, reality looks di↵erent and network providers most likely will have no other way than supportingmultiple di↵erent IoT communication specifications such as BLE, Zigbee, Sigfox, LoRa, LTE-M or EC-GSM-IoT. Hence, nowadays, one problem with IoT connectivity is the fragmentation. In order to beable to accomplish the task of fulfilling these diverse customer wishes, parallel networks have to bedeployed. These networks are not per se aware of one another and the standards do not (necessarily)include awareness of one another and thereby might or might not have a negative impact on each other’sperformance. Another problem is, that these network implementations are in bigger parts defined byspecific Hardware (HW) components. Thus, upgrades take longer and embedded developers with acertain familiarity with e.g. the processor architecture are absolutely essential. Of course, these arefactors, which push up costs for IoT connectivity, that nobody wants to pay for. The goal of having moreconnected devices and automate what can be automated, everything with a high Return of Interest, willnot be reached if the costs are too high. For this reason, in this thesis, another approach, a possiblesolution for this dilemma is surveyed. All-SW implementations running on computing devices in physicalproximity to the radio interface, the so-called radio head, are suggested as the future approach. Onthese computers computation has to be GPP-based, cheap and HW agnostic. In the edge computer thesought platform has been found. The radio interface comprises the antenna, the Radio Frequency (RF)front end and some minor signal processing capabilities in some cases. It is, in the current approach ofimplementation, connected to the base station via the fronthaul. Everything conventionally is in and onone building.

Edge computing is a rather new paradigm to get data processed in a location close to the devices wherethe data is generated and/or consumed. Edge computing is sometimes also referred to as fog computing.Some of the key benefits compared with cloud computing are: Low latency, no unnecessary data transport,

2

as well as improved security. In this project, the goal is to investigate how IoT connectivity can benefitfrom the edge computing paradigm. How Docker can help in this context to e.g. load balance or todeploy implementation faster is evaluated. As an example the NB-IoT DL has been implemented inSoftware (SW). Furthermore, a testbed for this novel way of edge-based implementation has been createdto deliver a proof of concept. Fig. 1.1 gives an overview of the system. This whole idea is rather newand known under the term of Cloud RAN (c-RAN). So far, although the term is mentioned in di↵erentpublications e.g. [7], no one has really demonstrated a working, fully cloudified system as it is presentedin this work.

The transmitter, radio head and receiver could only be implemented that quickly, because they benefit ofthe e↵orts of a community of radio hackers and companies to develop and enhance the SDR frameworkGNU Radio. Besides a in bigger parts standard compliant implementation of NB-IoT, which was writtenfrom scratch, Zigbee has been integrated into the c-RAN within a collaboration of Ericsson and RISESICS. The aim was to show, that the concept actually allows this targeted coexistence of multiple radioaccess technologies. Both radios, receiver and transmitter, were from the baseband upwards withoutany exceptions implemented in SW. Yet, these SW implementations are tied together with two USRPB210s (SDR hardware). The B210 is the interface to the analog world. In GNU Radio [8] all signalprocessing steps are executed in DSP blocks with input and output vectors. These blocks run each intheir own thread(s) coordinated by a powerful scheduler. The hardware connection of the software writtenin GNU Radio is possible, but not required. A whole design can be evaluated o↵-line in a simulation-like environment. For a vast amount of common signal processing problems GNU Radio already hasimplemented concepts up its sleeve.

Before carrying out the research presented in this work, it was unclear if this new idea could even berealised. Moreover, the challenges that come with such implementation were unknown. Challenges ofSDR edge implementation, that have only been revealed, solved and partly solved are illuminated. Ina practical way the implementation of classic SDR algorithms and how they have been migrated to theedge are described (chapter 3). The di↵erent algorithms have been validated and the overall performancehas been evaluated (chapter 4). In addition, a bit of theory below the SDR implementation is shown(chapter 2).

3

2 | Background

In order to facilitate understanding of the other chapters, this chapter aims to give insights into

Narrowband-IoT

Orthogonal Frequency-Division Multiplex

GNU Radio

NB-IoT receiver algorithms in theory (synchronization and equalization).

2.1 Narrowband-IoT

2.1.1 Sustainable Technology for Connecting Billions of DevicesLTE

PRB

24

LTE

PRB

25

NB-IoT

...

NB-IoT

LTE

PRB

0

NB-IoT

|H(f)|Guard band

LTE

PRB

49

...

f

Figure 2.1: Di↵erent deployment options for NB-IoT subsuming guard-band, in-band and stand-alone(fr. l. t. r.), ought to make a roll-out as SW upgrade possible.

As the headline borrowed from [9] already indicates, NB-IoT is seen as a promising candidate for thefuture workhorse needed in the context of the IoT to enable the emerging MMTC. The IoT is constantlygrowing and expanding into di↵erent areas. While some IoT networks are conceptually intended toonly o↵er local-area coverage (e.g. in homes) others aim to provide wide-area coverage (e.g. modernproduction plants). NB-IoT addresses the latter case and o↵ers solutions for professional, sustainableindustry environments. NB-IoT, introduced in 3GPP Release 13, targets the objectives of reduced devicecomplexity, battery longevity and enhanced coverage. NB-IoT has a 20 dB link budget improvement overLTE Rel-12 [10]. It is a new 3GPP radio access technology and, therefore, not fully backwards compatiblewith existing GSM and LTE networks. However, it is designed to enable perfect coexistence. The nameof NB-IoT resembles, that it only requires a very narrow minimal bandwidth of 180 kHz. The choiceto have such little bandwidth required for NB-IoT makes a handful of deployment options possible (fig.2.1).

In a GSM network the operator can replace one of the carriers (200 kHz) with NB-IoT.

In a LTE network the operator could allocate one or several PRBs (200 kHz) for NB-IoT.

NB-IoT could be deployed in guard bands or in stand-alone configuration.

The air interface of NB-IoT is optimized, so the parallel operation of NB-IoT with existing networkswill neither mitigate the performance of NB-IoT nor the performance of the LTE or the GSM network.According to [9], NB-IoT mimics LTE architecture and concepts. In [9] it is concluded, that NB-IoTcould even be rolled out as a SW upgrade on top of existing LTE infrastructure. Actually, NB-IoTreuses the ideas of LTE a lot, including the nomenclature, DL Orthogonal Frequency-Division MultipleAccess (OFDMA), uplink (UL) Single-Carrier Frequency Devision Multiple Access (SC-FDMA), channelcoding, rate matching, interleaving, etc. To allow cheap UE, latency requirements are stretched comparedto LTE. To give an example the acknowledgement or negative acknowledgement is expected by the UEearliest after 4ms. It is received with the next Narrowband Physical DL Control Channel (NPDCCH)UL grant, which can arrive any time later. This is another reason why NB-IoT is suitable for cloudimplementation.

4

2.1.2 Orthogonal Frequency-Division Multiplex

OFDM is a way how band and time resources can be accessed and used for data transmission. TheOFDM transmission scheme is used for 3GPP LTE, so it is not a big surprise, that it is also part ofNB-IoT [11]. Multi-carrier transmissions have been used since the 1950s. However, nowadays, with theavailability of modern signal processing the realization of the separation of di↵erent channels has becomeway less cumbersome, because steeply shouldered bandpass filters can be omitted [12]. The followingcharacteristics are outstanding about OFDM:

Typically, OFDM uses a high number of subcarriers in comparison to more straightforward multi-carrier schemes as for instance High Speed Packet Access (HSPA), which works with four subcarriers,each with a bandwidth in the order of 5MHz.

Trivial rectangular pulse shaping (fig. 2.2a (a)) is used for OFDM, which results in sin(f)f , the sinc

function, in the spectrum (fig. 2.2b (b)).

The alignment of the subcarriers in the spectrum is very tight with a spacing of �f = 1TOFDM

,where TOFDM is the symbol duration of one OFDM symbol.

-60 µ -40 µ -20 µ 0 20 µ 40 µ 60 µ

t/s

NB-IoT Pulse-Shape

(a)

-200 k -100 k 0 100 k 200 k

f/Hz

Single NB-IoT Sub-Carrier

(b)

Figure 2.2: Pulse shape of a NB-IoT signal (a) and spectrum of one subcarrier (b).

Modulation and Demodulation

An OFDM signal x(t) in baseband can be described within the interval mTOFDM t (m+ 1)TOFDM

as

x(t) =NC�1X

k=0

xk(t) =NC�1X

k=0

a(m)k (t) ej2⇡k�ft (2.1)

where xk(t) is the kth modulated subcarrier, that has the frequency fk = k · �f , a(m)k is the complex

symbol, that is modulated onto the kth subcarrier ej2⇡k�ft during the mth OFDM symbol interval. Inthe case of the NB-IoT, depending on the physical channel, which is using the OFDM resource, this canbe a Quadrature Phase Shift Keying (QPSK) or Binary Phase Shift Keying (BPSK) symbol. The numberof OFDM subcarriers usually ranges from one hundred to several thousand according to [13]. In the caseof NB-IoT one PRB consists of exactly 12 subcarries, whereas each has a �f of 15 kHz. This results ina bandwidth of 180 kHz.

5

IFFTCarrier

Allocation

...

...

...

0

0

0

0

a0

aNC�1

a0 ... aNC�1 Cyclic

Prefixing...

x0

xNFFT �1

DACFrontend

RF

Frequency Domain Time Domain

Figure 2.3: A simple transmitter can be implemented leveraging the Inverse FFT (IFFT) algorithm.

From equation 2.1 one can derive how a OFDM transmitter has to be implemented. A serial stream ofcomplex symbols (after modulation) is deserialized, i.e. mapped on a number NC of subcarriers (fig. 2.3).The frequencies of these sinusoidal signals are shifted by �f , which leads to a mathematical phenomenoncalled orthogonality (in the frequency domain). This is also where the name of OFDM comes from.Essentially, orthogonality, in the sense of OFDM, means, that in the spectrum, where one carrier has itsmaximum power density, all the others have a value of 0. Hence, the channels can be packed very tightlyin the frequency domain. This property can also be described in a mathematical way [13]:

Z (m+1)TS

mTS

xk1(t)x⇤k1(t) dt (2.2)

where xk1(t) is the time-dependent signal belonging to a data stream of one certain subcarrier and xk2(t)belongs to another parallel data stream and its associated subcarrier (xk2⇤(t) is its complex conjugate).If equation 2.2 outputs 0, orthogonality is given. Now specifics of OFDM can be inserted, leading to:

Z (m+1)TS

mTS

ak1(t)a⇤k2(t) ej2⇡k1�fte�j2⇡k2�ftdt

=

Z (m+1)TS

mTS

ak1(t)a⇤k2(t) ej2⇡�ft(k1�k2)dt = 0 for k1, k2 2 Z \ k1 6= k2

(2.3)

The orthogonality requirement in the frequency domain to avoid Inter Channel Interference (ICI) corre-sponds to the Inter Symbol Interference (ISI) condition in the time domain [12].

FFTCarrier

Deallocation

...

...

...

0

0

0

0

ea0

eaNC�1

ea0 ... eaNC�1

...

y0

yNFFT �1

ADCFrontend

RF

Frequency Domain Time Domain

Cyclic

Prefix

Removal

Figure 2.4: A simple OFDM receiver can be implemented by leveraging the FFT algorithm.

6

A demodulator for OFDM consists out of a bank of correlators (fig. 2.4). Obviously, in the ideal case thedi↵erent carriers do not interfere with one another after demodulation according to equation 2.3. Thisis due to the math behind OFDM not due to spectrum separation, since individual subcarrier spectraclearly overlap.

Implementation with FFT and IFFT

An extremely simple transmitter and receiver pair can be technologically realized by mixing modulationsymbols with a bunch of analog LOs, even so, this is not the state-of-the-art implementation for tworeasons:

OFDM can be implemented in a computationally e�cient way using FFT and IFFT algorithms.

Some extra unused carriers (left and right of the signal) are necessary to avoid extremely steepfilters flanks, because of the periodicity of the Inverse DFT (IDFT).

Thus, the signal is oversampled:

fs =1

TOFDM= �f ·N > �fNC (2.4)

The unused carriers can be filled with nulls (zero padding). Ideally, N is a power of two, or anything elsesuitable to an available FFT algorithm. Consequently, the OFDM sum signal is expressed as

xn = x(nTOFDM ) =N�1X

k=0

ak ej2⇡k�fnTOFDM (2.5)

Inserting eq. 2.4 into eq. 2.5 results in

xn =N�1X

k=0

ak ej2⇡k n

N (2.6)

where

ak =

⇢ak if 0 k < NC

0 if NC < k N(2.7)

To give an example, in 3GPP LTE NC is approximately 600 for a 10MHz band. The IFFT size could bepicked to be N = 1024. This is a sampling rate of fs = N ·�f = 15.36MHz. In [13] Dahlman, Parkvalland Skold note, that nothing forbids to change the FFT or IFFT size in a specific implementation.

Cyclic Prefix

OFDM symbol 0CP 0 OFDM symbol 1CP 1

NFFT

Copy Copy

Figure 2.5: Cyclic prefixing is understood as copying the CP last samples at the tail to the OFDMsymbol beginning.

The term cyclic prefixing refers to copying the last part of one OFDM sum signal, which is equal to apredefined guard interval TGI and pasting it at the beginning of the symbol (fig. 2.5). The utilizationof this technique introduces a couple of advantages, which are also leveraged in other communicationsschemes such as SC-FDMA [14]:

The so called Inter Symbol Interference (ISI) is wiped out as long as the maximum runtime isnot exceeded in any path the signal might take in a channel, that is characterized by multi-pathpropagation.

7

The cyclic repetition of a data block in the time domain allows to transfer the linear convolutionneeded in theory into a cyclic convolution, which can be implemented with a DFT. Moreover,this also enables channel estimation and equalization in the frequency domain, which is often lessproblematic than in time domain.

Unfavorable about the cyclic prefix solution are the decline in the signal-to-noise ratio and the degradationof the bandwidth e�ciency.There is a window in which the receiver expects to receive the particular OFDM symbol m. Due tomulti-path propagation a part of the symbol is sliding out of this window. The basic idea of the cyclicprefixing is that, while the symbol is sliding out, it is also sliding in again on the other side.

Pilots

Usually not all subcarriers are used for the payload. A limited amount of them is assigned to so-calledpilots, which makes them pilot carriers. Pilot carriers can contribute to succeed with the followingchallenges of a communication system:

Channel estimation is carried out on the basis of pilots.

Robustness against frequency o↵set errors and phase noise can be raised.

A Direct Current (DC) pilot can avoid a problem called local oscillator leakage. Local oscillatorleakage means, that the LO signal can appear in the spectrum when dealing with a badly calibratedRF frontend.

Pilots can carry information to mitigate timing synchronization errors, related to ISI, and frequencysynchronization errors, a�liated with ICI.

To enable a simple and stable demodulation of the pilot carriers, known information, in the sense of a”Keep it simple, stupid (KISS)” approach is transmitted. The task is to find a proper trade-o↵ betweenphysical resources (time slots and carriers) assigned for pilots and payload. Two variants for a distributionof pilot carriers are common. The first one is the block type, which means that pilots being sent out inone out of A time slots occupying all OFDM symbols in this particular time slot. Between two pilotsa channel estimator can utilize interpolation to find out about the change in time of the channel. Thesecond variant is the comb type, which implies, that certain subcarriers are reserved solely for usage withpilot symbols. Obviously, the comb type rather helps to smooth out channel impacts, which are timedependent, while the block type rather helps with frequency dependent distortion of the channel, i.e. ahighly frequency-selective transfer function. Therefore, the choice of the pilot deployment methodologyhas to reflect the expected channel behavior. In essence, the introduction of every pilot cuts down on theutilization of the given bandwidth, but can help to enhance the transmission quality and thus the userexperience.

Advantages and Disadvantages

The theoretical concept of OFDM was already known back in 1970 [15]. The practical implementation,however, for quite a while was not possible, since a number of specific necessities have to be given:

A proper synchronization between transmitter and receiver is crucial. The guard interval is notmeant to deal with this issue. It is rather designated to mitigate multi-path e↵ects.

It is almost not feasible to build up and integrate a vast number of analog mixers, which runsynchronously. OFDM is designated for digital signal processing, which can be outsourced to astandard GPP nowadays. The mixing and filtering is repealed in the digital domain by exploitingmodern algorithms of FFT and IFFT available on the majority of platforms.

Availability of high-quality analog components is also critical for realization of OFDM. Besides highfrequency stability of the oscillators power amplifiers play an important role. OFDM introducesa high PAPR, that demands a highly linear amplifier, to avoid non-linear distortion for above- orbelow-average signal amplitudes.

8

-200 k -100 k 0 100 k 200 k

f/Hz

12 Separate NB-IoT Sub-Carriers

(a)

-200 k -100 k 0 100 k 200 k

f/Hz

Sum-Signal with 12 NB-IoT Sub-Carriers

(b)

Figure 2.6: NB-IoT has 12 subcarriers with a distance of �f = 15 kHz (a). The sum signal uses thespectrum resources very e�ciently, since it almost has a rectangular shape (b).

In comparison with other transmission schemes OFDM can achieve an extraordinarily high bandwidthusage. This can be a�liated to the observation, that for a high number of carriers NC the spectral shapeof an OFDM sum signal becomes rectangular (fig. 2.6). Using FFT, the implementation becomes lesscomplicated.

One of the biggest drawbacks of OFDM is the rather big ratio of average power to maximum power. Thiscan be traced back to the fact, that the amplitudes of the single subcarriers are statistically independent.So the superposition of all of them varies between the sum of all subcarrier amplitudes being at a minimumand the sum of all subcarrier amplitudes being at a minimum. The higher the number of subcarriersNC , the higher the PAPR or the Crest factor, that is defined for field sizes instead. The above does notapply if only Phase-Shift Keying (PSK) (with constant amplitude) is chosen for modulation. The PAPRis defined as

PAPR = C2 =|xpeak|2

xRMS2

(2.8)

It is due to the high PAPR, that SC-FDMA is chosen over OFDMA for the NB-IoT uplink. A linearamplifier implies a reduced power e�ciency, thus, makes it less suitable for mobile UE.A comparison between advantages and disadvantages shows, that the advantages are more significantand, that for every disadvantages a solution is available to at least mitigate its impact.

2.1.3 Frame Structure and Timing

Figure 2.7 visualizes the NB-IoT frame structure and timing. Radio frames have a duration of 10ms. Theradio frames are divided into 10 subframes with 1ms duration each. Furthermore, each subframe consistsout of two slots with 0.5ms duration and in each slot seven OFDM symbols are transmitted (NormalCP). The standard defines two di↵erent CP lengths as displayed at the bottom of fig. 2.7. Every 7thOFDM symbol has a longer CP. The standard is written in terms of the sampling period

Ts =1

�f ·NFFT=

1

15 kHz · 2048 =1

30.72MHz. (2.9)

�f is the OFDM subcarrier spacing and NFFT is the FFT size. The first CP of a slot has a length of160Ts, the following six have a length of 144Ts, implying, that a FFT size of NFFT = 2048 is the basisfor the OFDM modulator. Accordingly, the length of a slot is

Tslot = (160 + 6 · 144 + 7 · 2048) · Ts = 15360 , (2.10)

the length of a subframe is Tsubframe = 2Tslot = 307200Ts and the length of a radio frame resultsin Tradio frame = 3072000Ts. There is a system frame number nf , which numbers radio frames from0..1023. Then it wraps around, resulting in a period of about 10 s. The frame number is encoded in theNarrowband SSS (NSSS) and is useful for the UE, since not every information is transmitted in every

9

radio frame. A resource element in the resource grid as shown fig. 2.10 is the smallest physical resourceunit, consisting of one carrier in one OFDM symbol. It is also important to mention, that twelve carriersand seven OFDM symbols are grouped together and called Resource Block (RB). So far there are nobig di↵erences when comparing NB-IoT with LTE. However, when NB-IoT is deployed in stand-aloneconfiguration, it makes sense to downsample by a factor d = 16. Why not even reduce the FFT size to16, since NB-IoT only has a bandwidth of 180 kHz? This sounds good, but does not work, since the CPlengths need to be integrals.

NPBCH NPSS NSSS

0 1 2 3 4 5 6 7 8 9

Subframes

Even

NPBCH NPSS

0 1 2 3 4 5 6 7 8 9

Subframes

1 ms

10 ms

0.5 ms

5.2 us

66 2/3 us

Signals

Channels

1 Hyper Frame = 1024 RF

15 kHz Subcarrier Spacing for OFDM

4.7 us

numbered

frame

Odd

numbered

frame

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

NPDCCH/

NPDSCH

Radio

Frame 0

Radio

Frame 1

CPOFDM

Symb. 0CP

OFDM

Symb. 1CP

OFDM

Symb. 6...

Radio

Frame 1023...

Figure 2.7: NB-IoT frame structure and timing. 1024 radio frames are one hyper frame. Ten subframesare one frame. Two slots are one subframe. Seven OFDM symbols are one slot. Two di↵erent CPs areattached to the symbols.

2.1.4 Synchronization

Before a DL connection can be built up, the UE has to perform a cell search. The receiver has to beset into a state of frequency and time synchronicity before the OFDM symbols can be demodulated. Inorder to do so, NB-IoT reuses the concept of PSS and SSS. NPSS unlike the LTE PSS is not influencedby the NID. Still, in NB-IoT every base station is identified with a cell ID, which takes one out of 504possible values.

NID = 3N1ID +N2

ID (2.11)

10

N1ID is the cell ID group (0 .. 167) and N2

ID is the cell ID number (0 .. 2). And still, di↵erent parts ofthe standard such as the NRS generation depend on the cell ID. In order to reduce receiver complexitythere is only one NPSS and it is a hierarchical sequence. It is transmitted in every fifth subframe beingmapped on the last eleven OFDM symbols. A length-11 ZC sequence has to be calculated and packedon the resource grid according to 10.2.7.1.1 in [11].

dNPSS(n) = S(l) · e�j ⇡un(n+1)11 , n = 0, .., 10 (2.12)

l S(l)3 14 15 16 17 -18 -19 110 111 112 -113 1

Table 2.1: Vector to generate hierarchical sequence from length-11 ZC sequence. A hierarchical sequenceis less complex and will therefore enable cheaper devices.

The last carrier k is left blank. The sequence root is u = 5. NSSS has a period of 20ms. It is onlytransmitted in every even radio frame. NSSS also is mapped on the last 11 OFDM symbols, but allcarriers are occupied by it, which makes it as long as 132 symbols. It is generated as follows

dNSSS(n) = bq(m) · e�j2⇡✓fn · e�j ⇡un0(n0+1)131 , n = 0, .., 131 (2.13)

with the parameters n0 = n%131, m = n%128, u = NID %126 + 3, q = NID126 and ✓f = 33

132 (nf/2)%4.bq(m) is defined as a set of 4 di↵erent length-128 bit sequences (cf. 10.2.7.2.1 in [11]). nf is the radioframe index. It is a well-known fact, that every ZC sequence satisfies the Constant Amplitude ZeroAuto-Correlation (CAZAC) criterion, limiting the PAPR and ideal cyclic auto-correlation [16].

Time Synchronization

There are many di↵erent ways how to synchronize in time. Two of them shall be presented. Method I,applied on NB-IoT did not yield the expected results. In simulation the peaks would only stand out by< 1 dB. For this reason Method II was chosen to be implemented in the receiver.

Method I: Symbol Synchronisation with CP

OFDM symbol 0CP 0 OFDM symbol 1CP 1

NFFT

CP

Figure 2.8: Method I for symbol synchronisation tackling the CP. This method can be realized with acorrelation with a fixed lag of NFFT .

With this method the CP is detected using correlation with a fixed lag as a first step. On average theCP repeats with

TCP =TSF

NSY,SF,O⇡ 71.43 s (2.14)

11

Automatically, this is the periodicity, with which the correlation function should have a maximum. Twowindows with the length of the shorter CP are sliding over the received data stream. These two windowshave a distance of NFFT . Since the beginning of one OFDM symbol is the CP and therefore equal toits end, the correlation function will yield a maximum when the first window is located exactly at thesymbol beginning.

(r ~ r⇤)(n) =n+CP�1X

m=n

r(m) · r⇤(m+ CP � 1) (2.15)

Apparently, this method is robust against frequency o↵set, since it equally impacts the data in bothwindows, but, has the disadvantage of being prone to multipath e↵ects, since symbols slide into oneanother if there are multiple paths. As a second step with this method, cross-correlations with the NPSShave to be performed in frequency domain to find out where the radio frame starts. Method I is beingapplied in [17].

Method II: NPSS Symbol Synchronisation in Time Domain

Downsampling d = 8

NSA,SF ·NSFd

NSA,SFd

Radio frame

Figure 2.9: Downsampling one radio frame to reduce computational complexity by d2. NPSS subframein blue. Two correlations are necessary to synchronize in time.

Instead of looking at the CP first, with this method, the received signal is directly cross-correlated withthe NPSS in time domain as already proposed years ago for LTE [18]. To do so, the NPSS, which isdefined as a frequency domain ZC sequence, has to be transformed into time domain.

(r ~D⇤NPSS)(n) =

Ncorr�1X

m=0

r(m) ·D⇤NPSS(m+ n), n = 0, .., NH � 1 (2.16)

dNPSSF�1

��! DNPSS (2.17)

NH is the number of hypotheses, which has to cover at least the length of half a radio frame

NH!=

NSA,SF ·NSF

2= 9600 (2.18)

and Ncorr is the correlation length which is Ncorr = NFFT . Of course, the value for NH above dependson the sampling frequency, which is fs = 1.92MHz. Hypotheses are the number of sample points wherethe cross-correlation has to be calculated i.e. how far one has to search to be guaranteed to stumbleover whatever ought to be found. A slightly modified version of this algorithm was targeted for theresearch project presented in this report. First, the signal would be downsampled by a factor of d = 8(visualized fig. 2.9). This allows to reduce the number of hypotheses by a factor of d. At the same timethe correlation length is reduced by a factor of d, which means a total reduction of the computationalcomplexity by d2. However, the additional processing necessary for the Finite Impulse Response (FIR)filter needs to be taken into account. Moreover, high-rate processing still in order to find the exact samplewhere the NPSS starts can not be skipped entirely. Second, the cross-correlation should cover a wholeNPSS subframe, implying, that the hypotheses also are as many as there are samples in a (downsampled)

radio frame NH = NSA,SF ·NSF

d = 2400 and, that the correlation length is Ncorr = NHNSF

= 240. For thecorrelation with the full rate, the number of hypotheses can be reduced to NSA,SF + 2Nplay. It makessense to define Nplay = X% ·NSA,SF , whereas X might be between 1% and 10% depending on the SNR.This approach guarantees time synchronization on radio frame level [19].

12

Frequency Synchronization

A frequency o↵set typically arouses because of the Doppler e↵ect.

�f =�v

cf0 (2.19)

Omitting relativity, equation 2.19 reveals, that already with a speed of 136 kmh and a carrier frequency

of 2130MHz a frequency o↵set of approx. 256.39Hz impacts the received signal. Some might say, thatIoT devices do not move. However, it is a well-known fact, that miscellaneous oscillators in receiverand transmitter HW not running at the same speed cause a bad frequency o↵set as well. An exampleare the clocks for Analog-to-Digital Converter (ADC) (receiver) and Digital-to-Analog Converter (DAC)(transmitter), which can never have the same frequency. The carrier o↵set is indicated in terms of theOFDM subcarrier’s distance �f = 15 kHz.

�f = �f · (nI + ✏F ) (2.20)

nI is the Integer Frequency O↵set (IFO) and �1 < ✏F < 1 the FFO. The FFO is especially bad, sinceit threatens the for OFDM crucial orthogonality criterion (ISI). The IFO does not lead to ISI, but stillmoves all subcarriers to some place in the spectrum where they should not be. Again, there are numerousalgorithms to estimate the FFO and two of them will be introduced in this work. Since the CP-basedmethod did not achieve expected accuracy for time synchronization, the simpler first approach fromthe beginning to utilize the CP for time and frequency synchronization, was dropped and replaced withNPSS-based synchronization algorithms. Nonetheless, the CP-based frequency o↵set estimation seemsto work with su�cing accuracy for LTE [17]. For the sake of this fact and the sake of completeness theCP-based frequency o↵set estimation is explained below, too (Method I).

Method I: Frequency Estimation with CPIn [17] the phase of eq. 2.15 has been utilized to estimate the frequency o↵set.

✏F = � 1

2⇡\"n+CP�1X

m=n

r(m) · r⇤(m+ CP � 1)

#(2.21)

Method II: NPSS Frequency in Time Domain

Acc. to [18] the FFO can be estimated with

✏F =1

⇡\"

NFFT /2�1X

m=0

r(m) ·D⇤NPSS(m)

!⇤

·

NFFT�1X

m=NFFT /2

r(m) ·D⇤NPSS(m)

!#. (2.22)

The first cross-correlation is about the first half of an OFDM symbol and the second one is about thesecond half. If the received signal and the sequence, that it is compared with were equal, the results ofboth correlations would be real, so the angle would be 0. However, if, because of a FFO, reference andactual signal are unequal, the FFO will be reflected in a phase di↵erence between the two correlations.

2.1.5 Equalization

NRS

For any equalization to be possible the NRS is required. The signal consists out of complex symbols,which are known in transmitter and receiver to make estimation of the channel impulse response Hl,k

possible. NRS is transmitted in every subframe, that has something to do with either dedicated orbroadcast DL. Before the signal can be mapped to or read from the resource grid (fig. 2.10) it needs tobe calculated (read from memory). Actually, the sequence generation (10.2.6.1 in [11]) is the same as inLTE:

rl,nS (m) =

p2

2·�1� 2c(2m)

�+ j

p2

2·�1� 2c(2m+ 1)

�m = 0, .., 2Nmx,DL

RB � 1 (2.23)

13

k"

l !

Figure 2.10: Exemplary NRS mapping for two antenna ports (p = 2000, Ericsson blue and p = 2001,light blue) and for NID = 594 with carrier index k and OFDM symbol index l. Represented are twoPRBs. The challenge lies in inter- and extrapolation of the unknown symbols.

Nmx,DLRB = 110 is a constant, nS the slot number, l the OFDM symbol within a slot and c(m) is a LTE

goldcode. Once the sequence is generated it needs to be mapped, which has to comply to the followingset of equations.

a(p)k,l = rl,nS (m

0) (2.24)

k = 6m(v + vshift)%6 (2.25)

l = NDLsymb � 2, NDL

symb � 1 = 5, 6 (2.26)

m = 0, 1 (2.27)

m0 = m+Nmx,DLRB � 1 (2.28)

vshift = NID %6 (2.29)

v =

8>>><

>>>:

0 if p = 2000 and l = NDLsymb � 2

3 if p = 2000 and l = NDLsymb � 1

3 if p = 2001 and l = NDLsymb � 2

0 if p = 2001 and l = NDLsymb � 1

(2.30)

NDLsymb is the number of symbols per slot in DL. Usually NDL

symb = 7. Eq. 2.23 works with a pseudorandom sequence generator c(m), a machine, which can be implemented as a Linear Feedback ShiftRegister (LFSR). The generator is initialized di↵erently (seed) depending on NID, NCP and nS .

cinit = 1024 ·�7(nS + 1) + l + 1

�·�2NID + 1

�+ 2NID +NCP (2.31)

NCP has something to do with the CP mode (LTE for rural areas) and is usually 1. The actual goldcodegeneration is defined in another place (7.2 in [11]).

c(n) =�x1(n+NC) + x2(n+NC)

�%2 (2.32)

x1(n+ 31) =�x1(n+ 3) + x1(n)

�%2 (2.33)

x2(n+ 31) =�x2(n+ 3) + x2(n+ 2) + x2(n+ 1) + x2(n)

�%2 (2.34)

Now the generator is settled, however, it is still not defined how to initialize each of the sub-generatorsx1 and x2. The standard dictates to fit cinit into x2, such that

cinit =30X

i=0

x2(i) · 2i. (2.35)

x1 is initialized all zero except of x1(0) = 1.

14

X(n)Y (n)

H(n)

Eric

Figure 2.11: Channel estimation neglecting noise is not optimal, but yields still good results. Equalizationin frequency domain is possible, since OFDM provides this comfort by transforming all data into frequencydomain when demodulating.

Channel Equalization at the Receiver

The receiver needs to have the same implementation of the NRS as the transmitter to create its ownversion of it. As can be seen in fig. 2.11, the received symbols Y (n) are generally speaking not equalto the transmitted symbols X(n), which constitutes a problem, because what has been sent cannot beunderstood no longer. There are numerous ways to estimate the channel impulse response H(n) andto equalize the symbols. OFDM allows to do equalization comfortably in frequency domain. Hence, aconvolution can be replaced by simple multiplication. A simple way to get a channel estimate eH(n) is toassume, that

Y (n) = X(n) ·H(n) +N(n) (2.36)

whereas N(n) is Additive White Gausian Noise (AWGN), that is added by the channel, and to estimateby neglecting the noise

H(n) =Y (n) +N(n)

X(n)⇡ Y (n)

X(n)(2.37)

eH(n) =Y (n)

X(n)⇡ H(n) (2.38)

eX(n) =Y (n)eH(n)

(2.39)

X(n) =Y (n)

H(n)=

Y (n)X(n)

Y (n) +N(n)(2.40)

Even so, when building an equalizer, it is still the question how to handle the ”empty cells” in the resourcegrid where the channel is unknown.

2.2 GNU Radio

GNU Radio is a SDR platform organized into signal processing blocks. The framework is free, as infreedom, and is licensed under the GNU General Public License (GPL) v3.0, meaning, that everybodywith the necessary abilities has the liberty to inspect, share and modify the source code. One of thereasons why GNU Radio has been chosen as the baseline for this work is, that, on the one hand, it canbe tied together with all sorts of available RF HW, and, on the other hand, it can be run o✏ine in asimulation-like environment (cf. [8]). More advantages of GNU Radio are an active community witha lot of friendly and competent hackers, as well as, the stockpile of readily available signal processingimplementations such as mathematical operators, filters, a filter design tool, Forward Error Correction(FEC) blocks or OFDM blocks. Furthermore, the toolchain around GNU Radio is very handy, as well.There is for instance PyBOMBS to help installing GNU Radio and related components by compilingfor a specific platform or gr-modtool to assist with creation and modification of new signal processingentities, so called OOT modules, to just mention the most important tools. Unlike a lot of proprietarysoftware suites, GNU Radio wants the engineer, who uses it, to understand it, interact with it and extendit. Therefore, GNU Radio applications can be written in either Python or C++. Performance criticalcode, will hereby always be implemented in C++. Actually, GNU Radio leverages SWIG [20] to wrapcompiled C++ signal processing code into Python libraries to facilitate modular application design andcode reuse with Python for each and every flowgraph. Within a GNU Radio flowgraph a bunch of serialand or or parallel signal processing operations are performed on a synchronous or asynchronous stream

15

of data (e.g. 64-bit I/Q samples). Under the hood of GNU Radio a powerful scheduler executes everysignal processing block in its own thread. To do so input and output bu↵ers are related with every block(more about the scheduler is explained in 4.2.4).

Stream Tags

Stream tags in GNU Radio are an elegant way to propagate meta information synchronously, meaning,that the meta data is associated with one specific sample in a stream. Stream tags can be integrated intoa design with the help of the gr::tag t data type and an Application Pogramming Interface (API). Thisdata type is a compound of three PMTs (key, value and srcid) and an o↵set field. Every single sampleever being read or written (within a session) is related to a certain o↵set, that can be accessed. PMTsare opaque data types engineered to be generic containers, which can safely be exchanged between blocksand thereby threads in GNU Radio. To give an example, stream tags signal where a frame begins, oncethe NB-IoT NPSS Synchronizer has found the first sample.

Messages

Back in the days, GNU Radio only knew streams to exchange data between di↵erent blocks. Later, theneed to pass meta data between blocks became visible and stream tags were the answer. They allowedto pass polymorphic data isosynchronously to a predecessor block. Still, if packetized data ought to betransmitted, GNU Radio lacked a solution. For this reason, the asynchronous message passing interface,heavily relying on PMTs, was introduced. Messages are publishes on a certain port and can have a lotof subscribers. Each block has a message input queue. An element can for example be pasted directlyinto the queue by utilizing the gr::basic block:: post API function. Every time a block published amessage on a port, GNU Radio iterates through the list of blocks, that subscribed to this message portand copies the PMT to the input First In First Out (FIFO) of each subscriber block. A simple examplewithin the design described in this section is the Chat Transmitter. Chat messages are usually despatchedasynchronously. Thus, the best way to notify the Message MUX is with a message.

Volk

Strictly speaking, the Vector-Optimized Library of Kernels (VOLK) is not a part of GNU Radio althoughit was historically first introduced together with it. It is embedded as a git submodule in the GNU Radiorepository. The idea of VOLK is to be able to produce portable Single Instruction Multiple Data (SIMD)code. Even nowadays, there is still no compiler to handle vectorization of a signal processing algorithmproperly [21]. Therefore, VOLK takes another path to solve the issue: For each (currently supported)architecture and mathematical operation a hand-written vectorized implementation, a so called proto-kernel, exists. After running a profiler (and considering a few other aspects), VOLK is able to choose theoptimal i.e. fastest implementation itself during runtime or executes a generic implementation (i.e. forloop based) if no vectorized platform-specific C code exists. A programmer who includes and links againstVOLK can just call functions like volk 32fc x2 multiply 32fc(...) to multiply all the correspondingcomplex elements in two vectors without the need to worry about how the Floating-Point Unit (FPU) ofthe processor works (as long as a proto-kernel is being provided). VOLK functions should be used in thecode whenever it is possible.

ZeroMQ

ØMQ is not a part of GNU Radio either. However, there is an OOT module making smart patterns ofØMQ such as publisher-subscriber or push-pull available in GNU Radio. ØMQ is interestingly licensedunder the GNU Lesser General Public License (LGPL) v3.0. It is a powerful, asynchronous messaginglibrary. In the context of this work message transport is realized with a Transmission Control Protocol(TCP) socket.

2.3 Docker as a Cloud RAN Enabler

Docker [22] provides virtualisation or ”dockerization”, a widespread term in this context, on the level ofthe operating system. As a typical application Wikipedia mentions a web server and a web applicationrunning in one container and a data base being accessed by the web app running in another container.

16

Di↵erent containers are apart from one another and can communicate with di↵erent means (such assockets). Indeed, Docker containers currently outperform virtual machines, since all containers are runby one operating system kernel independent of what actually runs in the container. Containers are quiteoften created from templates to save time scripting the Dockerfile, a Docker image description. TheDockerfile is what is being searched for by the command docker build [dir]. It is a well known fact, thatvirtualisation is going to play an important role in the future of mobile communication [23]. Dockeris de facto the industry leader in virtualisation technology. Generally speaking, working with Dockercontainers increases productivity and reduces deployment e↵ort. With Docker developers are not longerforced to set up a development environment, but can directly start writing code. Moreover, Docker allowsflexibility and an adaptive network in which for instance a second NB-IoT transceiver can be spawn in asecond container running on the same edge server.

17

3 | Design and Implementation

Figure 3.1 displays an overview of the whole system as it has been implemented. The signal flow is fromthe edge to the receiver, because only DL has been implemented that far. Three parts assembled makethe testbed. These are the edge (server), the radio head and the receiver.

Edge

Docker

Radio Head

Docker

Fronthaul network

UE (Receiver)

Docker

ØMQ

USBUSB

NB-IoT

Receiver 0 SDR SDR

Platform

NB-IoT

Radio Head 0

NB-IoT

Transmitter 0

Baseband signal generation & compression

Hardware adaption & decompression

Synchronization, FFT, equalization,

Platform

demodulation, decoding, message processing

Figure 3.1: Overview of the testbed as it has been designed within this work.

3.1 Edge

When using the term edge, it usually refers to a hierarchical block (cf. C) in GNU Radio, but it can alsomean the edge part of the whole system, that subsumes this block. The following paragraph describesthe GNU Radio block. In the edge the NB-IoT baseband signal is created and from there transportedover the network to the radio head with the help of ØMQ. In order to compile one radio frame andhave for instance the NPSS in the right place, a multiplexer with ten inputs (one for each subframe) isused. A subframe has exactly the length of 168 samples (12 carriers ⇥ 14 OFDM symbols). Having thisinformation makes it easy to multiplex accordingly.

3.1.1 Data Transmission and Application Layer

The application layer right now consists of a chat application, which can be hooked up to a Telegrambot, and a partly realized idea enabling to transmit and interpret all kind of messages. This approachallows flexibility: It allows e.g. to implement a gateway from IEEE 802.15.4 to NB-IoT and vice-versa.The Chat Transmitter implements the bot back end. The idea is, that a user can interact with the demo.Also, it is simply more convenient to be able to test the system by just grabbing the smartphone andtexting a bot. The bot is running in its own thread, which converts and dispatches received messagesfrom Telegram users. Internally, messages, that come out of the Chat Transmitter, are GNU RadioPDUs, a special type of PMT (cf. 2.2). PDUs are always a pair, having meta data, a std::string to bemore specific, and a payload, that always has to be a std::vector. In the case of the Chat Transmitterit is a vector of std::uint8 t. The meta data identifies the message type, which is corresponding to ahand-crafted set of classes grouped in the namespace gr::nbiot::msg. For message creation a messageclass should be taken. All message classes have a common interface ancestor mmsg, which can providecontent and type. When for instance a chat message should be transmitted the class mchatmsg is

18

Figure 3.2: DSP blocks related with the data transmission and application layer. Sporadically arrivingmessages are combined with a stream of 0s to avoid bu↵er underruns. Cyclic Redundancy Check (CRC)bytes, preamble, type field and tail are added.

adequate. The Async CRC32 (a GNU Radio block) expects a PDU and calculates the CRC over thepayload. Four bytes are attached at the end of the payload. Moreover, there is a message class, thatallows system evaluation on-the-fly, msystemmsg. This message class and other classes are derived frommjmsg implying, that JavaScript Object Notation (JSON) strings are transmitted over the air. In the

beginning, raw strings were transmitted and fields were added in combination with a char, that could beused together with boost::split, which reduces overhead, but also convenience. The Chat Transmitterhas a whole lot of functionalities as for instance sending messages in bulk, which is needed for systemevaluation.

JSON String ( std::vector<uint8 t>)SOM #0 .. SOM #7 TYPE EOM #7EOM #0 ..

Overhead

Payload

Start Of Message

End Of Message1 Byte

Max. Msg. Size Bytes

Figure 3.3: Structure of a packet. The preamble byte is repeated multiple times. Likewise, the tail byteis repeated. A type field indicates the message type e.g. mchatmsg. The payload is a JSON stringrepresented in bytes. This messaging interface and the packet format are not part of any standard.

UE should always be able to sync on the NB-IoT signal, which is why, a base station always needs totransmit. For this reason, the Message MUX multiplexes received PDUs with an arbitrary data stream.0s have the advantage, that the preamble detection on the receiver side is not always triggered (cf. 3.3.5).The Message MUX also knows the messaging conventions and derives an inserted type field from the metadata. The consecutive bytes after the 8-bit type field are the message bytes, the payload. To summarize,it can be said, that the Message MUX produces a byte stream, that looks as visualized in fig. 3.3 whena message of a known type arrives.

3.1.2 Scrambling, Encoding and Modulation

Figure 3.4: Inside the NB-IoT Scrambler and Encoder: Non-standard compliant scrambling and encod-ing with the NASA Voyager code. GNU Radio has to be changed to enable FEC with a three-armsconvolutional code.

Next in the signal processing chain scrambling is applied to the data stream. Scrambling and codingschemes are not standard compliant yet, since GNU Radio will have to be modified, in order to get the

19

Viterbi decoding working for a code with three polynomials. Instead, besides a simple 8-bit scramblingscheme (0x8A mask, 0x7F seed) the following encoder with two arms and a constraint length of K = 7has been utilized for coding. Each equation represents the transfer function of one arm.

H0(z) = 1 + z�2 + z�3 + z�5 + z�6 (3.1)

H1(z) = 1 + z�1 + z�2 + z�3 + z�6 (3.2)

The section about the gr::fec::code::cc decoder in the GNU Radio manual [24] says, that this convolu-tional code is the same as implemented in the telemetry unit of the NASA Voyager probes. The LTEtail-biting code is reused in NB-IoT and it has three arms (cf. 5.1.3.1 in [11]). The modulation is a simpleand standard compliant QPSK modulation.

3.1.3 Narrowband Reference Signal

Figure 3.5: Inside the hierarchical NB-IoT Reference Signal MUX : The actual NB-IoT Reference SignalMUX depends on the LTE Reference Signal Generator, which itself needs the LTE Goldcode Generator.This approach makes the implementation modular and easily reusable.

The NRS signal is fully standard compliant. To be honest, the implementation might not be the moste�cient one, since in the beginning an interface class gr::nbiot::ref symbols::interface triggers a lotof initial processing, which is carried out in a brute-force fashion. However, once this is done, theresults are in the memory and can be fetched from there. This interface class is integrated into theNB-IoT Reference Signal MUX, as well as, the NB-IoT Reference Signal DEMUX, a part of the equalizer(see 3.3.3). The decision to do all of those calculations on-the-fly has the advantage, that the code ishighly reusable and modular. The LTE Goldcode, as an example, plays its role in di↵erent parts of thestandard. The communication, which is ongoing in-between the di↵erent threads and interfaces of themis rather complicated, which is why this section will only scratch the surface of the architecture. TheNB-IoT Reference Signal MUX only has a few parameters such as the antenna port or the subframe.These parameters are fed into a shared data structure of the type gr::nbiot::ref symbols::shared t. Theinterface object, which forms a composition together with the rs mux impl object, has access to theshared data. While not initialized it asks the LTE Reference Signal Generator for the two necessarycomplex sequences. These have a length of 2Nmax,DL

RB = 220. However, only two symbols out of thatsequence will be actually mapped to physical resources, which is di↵erent in LTE. These symbols arestored in the shared object. gr::nbiot::ref symbols::interface, also calculates the carrier indices bearingreference symbols and communicates this information via the shared data structure. The referencesequences are calculated in the LTE Reference Signal Generator. This block iterates through all possibleinitial values for the LTE Goldcode pseudo random generator and asks the corresponding generator forthe goldcodes, that must not be shorter than 2 · 2 · Nmax,DL

RB = 440 out of mathematical reasons (cf.2.1.5). In contrast to the LTE Reference Signal Generator, the LTE Goldcode Generator produces anew sequence when it is asked to. It is possible to derive the initial value for the generator from theOFDM symbol and the subframe and then calculate only one goldcode and one reference sequence fromit. This might be a small performance optimization, which can be easily implemented and tried out in thefuture. In general the design optimization paradigm should be not to communicate too much in-betweenthe threads as this is always linked with communication overhead. One simplification has been donein the current design iteration: To be a 100 percent standard-compliant equalizing and reference signalmultiplexing has to be done for each slot individually. Nonetheless, all the maths is according to the

20

standard and once, the initialization is done and data flows through the hierarchical block, it is copyingmemory from the input to the output and multiplexing samples stored in memory into the data stream.In that state the multiplexer can operate blazingly fast.

3.1.4 Narrowband Primary Synchronization Signal

Figure 3.6: Inside the hierarchical NB-IoT NPSS Generator: ZC sequence is generated and multipliedwith a vector to create the NPSS subframe.

The NPSS generation fully complies to the standard, too. Except for the ZC sequence generator theflowgraph is an assembly from native GNU Radio components. The ZC sequence block performs a coupleof sanity checks and calculates the actual ZC sequence, which is then stored in the memory. The work()function only tries to copy as big chunks of memory as possible to the output.

3.1.5 Orthogonal Frequency-Division Multiplex

Figure 3.7: Inside the hierarchical NB-IoT OFDM Modulator: Serial/parallel conversion, IFFT and CPattachment (not visible here). Cyclic prefixing had to be changed in GNU Radio and will (hopefully)become part of the next release (3.8).

A lot of enthusiasts, who worked with GNU Radio before, have done a great job introducing a well-working infrastructure for Orthogonal Frequency-Division Multiplex (OFDM). Hence, there was not toomuch to do here, except for understanding, what the programmers who developed OFDM systems withGNU Radio before, thought when implementing the code. How to build a simple OFDM transmittercan be seen in fig. 3.7. One thing, that had to be modified was the OFDM Cyclic Prefixer. It didnot support to add CPs with di↵erent lengths. Unfortunately, this broke the GNU Radio API; and theblock is deployed in a lot of places e.g. Digital Audio Broadcast (DAB), Bluetooth or IEEE 802.11,since nowadays OFDM is the preferred way to e�ciently make use of given bandwidth. For this reason,the modification is still o�cially not a part of GNU Radio today. Most likely, it will be merged whenversion 3.8 rolls out. A couple of other small changes, however, became part of GNU Radio already. Togive an example, a bug in the OFDM Carrier Allocator was fixed. In general, it feels like the OFDMinfrastructure has been primarily developed for packet-based OFDM transmissions.

3.2 Radio Head

ØMQ takes care of transporting the baseband signal from the edge to the radio head, where it is eitherfurther processed (see D.2) or directly forwarded to the HW (see D.1). The radio head is not represented asan hierarchical block, but only as an app (an executable python script). This app takes useful CommandLine Interface (CLI) parameters to e.g. set the gain.

21

3.2.1 Hardware

In order to successfully build a SDR transmitter, one component is crucial. It is the hardware, thatreceives the digital baseband signal (via e.g. USB) and converts it into the real world with an I/Qmodulator. Moreover, RF circuitry for upconversion and consecutive power amplification is needed.Exemplarily, a block diagram of the Lime Microsystems LMS7002M FPRF, the RFIC of the LimeSDRboard is displayed in fig. G.1.

In the beginning investigations have been carried out in order to find out whether the LimeSDR is asuitable tool for research in the context of c-RAN or not. LimeSDR is a rather new project of Myriad-RF, which is a part of the company Lime microsystems, that has the goal to ”[remove] the barriers towireless innovation” [25]. All Myriad-RF HW and SW is completely open-source, which does not applyfor the inside of their mixed-signal ICs, such as the LMS7002M. There are multiple reasons to go for theLimeSDR:

1. A LimeSDR Mini can already be purchased for 159 .

2. The specs are charming (3.1).

3. Everything is open-source, so one can look inside the driver or the HW, which can be helpful forcomprehension.

4. Customized HW can be prototyped quicker, since a detailed open-source reference design is avail-able.

LimeSDR-USB USRP B210RFIC Lime Microsystems LMS7002M FRPRF Analog Devices AD9361MIMO 2 x 2 2 x 2FPGA Altera Cyclone IV EP4CE40F23 Xilinx Spartan6 XC6SLX150Connectivity USB 3.0 USB 3.0Bandwidth 61.44MHz 61.44MHzFrequency Coverage 100 kHz - 3.8GHz 70MHz - 6GHzSoftware Support C driver with API and examples Everything works out of the boxPrice USD 299 USD 1,100

Table 3.1: Specifications comparison between LimeSDR-USB and USRP B210. Essentially, the specsindicate, that the two devices have the same capabilities, but a di↵erent price tag. The LimeSDR,however, made way more problems.

When this project was started in January 2018 the LimeSDR was the only SDR HW available in the labat that time. When it comes to software, a driver for the LimeSDR with integration into SoapySDR wasavailable. SoapySDR is a vendor neutral SDR support library trying to provide a hardware abstractionlayer for di↵erent SDR platforms [26]. Furthermore, there is gr-osmosdr [27], a GNU Radio OOT module,with support for SoapySDR. The first tests have been done with this configuration, going around a fewcorners. It did not really work that well. A native solution for GNU Radio was not available back then.Therefore, the work on a custom, hand-written OOT module, which runs directly on top of the driverAPI, was launched. It was easier said than done to integrate the driver into GNU Radio for two reasons:

1. Parallel and concurrent behaviour of di↵erent GNU Radio blocks i.e. receiver (source) and trans-mitter (sink).

2. The driver was still changing a lot and every time a new driver binary large object (blob) has beencompiled, installed and linked against, the behaviour seemed to have changed a bit, which is ofcourse, quite natural, as everything, HW and driver, was brand new.

The design goal of the OOT module was to create easily extendable software to enable Time DivisionDuplexing (TDD), meaning, that source and transmit block could be accessed concurrently. This is notan easy task, as there is only one USB, one driver, which can only perform one read or write operationon the HW at once. After a couple of Scrum iterations and approx. a month of work, a design witha singleton in the center slowly annealed (fig. 3.8). The architecture is many-faceted, which is whythis section only tries to give an overview. The singleton hw mid layer construction is due to to the

22

usage of C++11 thread-safe. Every interaction with the hardware is done via this middleware. Criticalcode sections are protected with a std::mutex ( hw state). The hw mid layer itself is a compositionwith one object for HW initialization, one for deinitialization and another one for serving HW requestsat runtime. All classes, which touch the hardware are derived from an interface class hw base, thathas access to shared pointers, which know the HW settings for the receiver and the transmitter and thecurrent HW state (e.g. current existence of I/Q data streams). gr::sync block and gr::block are partof GNU Radio.

hw mid layer

hw initializer hw deinitializer hw runtime handler

hw state

hw streamer

hw base

settings t

stream t

limesdr base

limesdr sink impl limesdr source impl

limesdr sink limesdr source

parser gr::sync block

gr::block

Figure 3.8: Class diagram OOT module for the LimeSDR only showing the most important relations. Inthe center hw mid layer, a singleton with thread-safe methods, brings together parallel DSP in GNURadio and the hardware driver, which relies on libusb.

In GNU Radio a block always has an interface ancestor class, which is also displayed in the Unified Mod-eling Language (UML) diagram. This is because the GNU Radio developers decided to go for a softwareengineering technique, that is called PoInter to iMPLementation (PIMPL). This means, that the actualimplementation is hidden away in a separate class and accessed via an opaque pointer. That approachbreaks compilation dependencies, which would be there when using private members for implementationinstead. The library interface with this technique will have a stable Application Binary Interface (ABI),which can function together with di↵erent implementation versions, too [28]. A special feature of the

23

blocks of the gr-limesdr OOT module (fig. 3.9) is, that there is only one parameter as an input from theUser Interface (UI). Python was leveraged to convert variables to strings and concatenate them to onelong string, which is being processed: The advantage is, that the interface does not have to be changed inso many di↵erent places, but only once, in the parser, which converts the one big string back to individualvariables. The interface class limesdr base handles the parsing and subsequent settings. An interestingfact about this interface is, that it is obtained with multiple inheritance, which is virtual to avoid the di-amond problem. A configurable logger has been used for the whole OOT module [29]. The configurationhas been exposed to the UI, too. In the end, the OOT module now supports TDD and 2 x 2 MultipleInput Multiple Output (MIMO). Moreover, time tags are (optionally) set for relating samples to theinternal HW counter (e.g. for positioning applications). Callbacks are used to change frequency and gainon-the-fly. In general, every single HW feature (even on register level) can be accessed and configuredaccordingly with these GNU Radio blocks, since they operate on driver level, as aforementioned.

Figure 3.9: Blocks related with the LimeSDR OOT module: Logger, source, sink (from left to right).The module is a byproduct of this work and enables convenient graphical usage of the LimeSDR HW.

3.2.2 Baseband Compression

The baseband signal is oversampled by a factor of

NFFT

N 0C

=128

12= 10

2

3(3.3)

when a FFT size of NFFT = 128 is being used for OFDM. Unfortunately, it is not possible to have aFFT size lower than 128, because of two reasons. First, to have the complexity advantage of nlog(n)of the algorithm, the FFT size has to be a power of two, which 12 is not. Secondly, the standarddemands a sampling frequency of fs = 30.72MHz with a corresponding FFT size of 2048 [11]. In thisconfiguration the first CP has a length of 160 samples and all other CPs have a length of 144. Now, itis quite obvious, that this FFT size does not make sense at all when only loading 12 carriers. The bestsolution would be a FFT size of 16, corresponding to an undersampling factor of 128 and a samplingfrequency of fs = 240 kHz. Why this does not work out becomes visible when dividing the CP lengthsby the undersampling factor. CPs can only be copied to the symbol beginning sample-wise. Hence, thelowest possible sampling rate is fs = 1.92MHz, maintaining the necessary integral CP lengths of 10 and 9respectively. However, the oversampling factor of 10 2

3 is actually an overhead in baseband data transport,very costly, very much unwanted. Everything, which is not placed on the loaded carriers has to be zero,and therefore redundant infromation, anyways. There is certainly more than one solution for this issue.In this work, two possible answers to the baseband compression question are showcased:

Performing all OFDM operations in the radio head.

Calculating the IFFT with a size of 16, protecting with an extra CP, that is in the current imple-mentation removed again afterwards, and interpolating the signal in the radio head.

For interpolating the signal generated with a FFT of length 16, it has to be made sure, that images aresuppressed with enough attenuation. When interpolating a complex signal images will occur repetitivelywith a distance of fs, which is 240 kHz in this case. The baseband signal also has a bandwidth of 180 kHz(centered at 0Hz, repeated at 240 kHz, 480 kHz etc.). For this reason, the stop band has to start at240 kHz� 90 kHz = 150 kHz and the pass band must not end before 90 kHz.The design constraints have been fed into the GNU Radio filter tool, which spit out the filter with theproperties displayed in tab. 3.2. The filter length, the number of taps has an impact on the ISI caused

24

Type EquirippleRipple 0.1 dBPass band end 100 kHzStop band start 150 kHzWindow NoneStop band attenuation 40 dBGain 0 dBfs 1.92MHzTaps 84

Table 3.2: Interpolation filter to upsample the baseband signal to a standard-compliant frequency offs = 1.92MHz.

by the interpolation (filter). It is a well-known fact, that a tapped channel model is used to simulatemultipath e↵ects when evaluating communication systems. The e↵ect on the signal is the same here,since there will be energy left from the prior OFDM symbol, i↵ the CP is not long enough. To put itin a nutshell, there is a trade-o↵ between filter quality (steep flanks, high attenuation, ergo many taps)and the CP length to protect against ISI. For the given filter any CP length longer than 11 will avoidISI completely. This is not necessarily required, because typically some taps especially in the end andthe beginning contribute very little to the output signal. The old interpolated CP (with a length of 80samples) is today removed in the radio head and LTE compliant CPs are added.

3.3 Receiver

The receiver is implemented in a hierarchical block (see E) and can be integrated in di↵erent ways e.g. intoits own app and executed on a laptop to do field measurements (as described in 4.3). A demultiplexingblock has been developed, since it did not exist in GNU Radio to be able to pick a received radio frameto its pieces.

3.3.1 Synchronizers

NPSS Synchronizer

Figure 3.10: Inside the NB-IoT NPSS Synchronizer: Two signal paths for low-rate (top) and high-rate(bottom) correlation. This two-stage synchronization reduces computational e↵ort for the receiver infinding the frame beginning. The NB-IoT NPSS Synchronization Gate is the central intelligence routingaround streams and triggering tracking corrections.

Acquiring the signal timing is the first and most important step for the receiver when searching a cell andcamping on it. A synchronization based on the CP did not yield acceptable results, the peaks where not

25

significant enough, a cross-correlation algorithm was implemented instead as for instance described in[30]. However, the time synchronization was divided into two steps leveraging multi-rate signal processingas shown e.g. in [19]. Instead of correlating over radio frames with a size of 19200 samples, the correlationwindow size is 19200/ds = 2400. The reference, which is searched in the received signal has consequentlya length of 240 samples. In general, it is easier with NB-IoT to synchronize on the NPSS when comparingto the PSS synchronization with LTE, since NB-IoT only defines one length-11 ZC sequence instead ofthree length-63 ZC sequences. As mentioned earlier, the correlations are performed in time domain,implying, that the references have to be converted from frequency to time domain. Well, in case of thedownsampled signal the problem with the integral CP lengths strikes again. The CPs of the receivedsymbols can obviously not be removed before the signal is not in sync. However, simulations have shown,that simply adding a uniform CP of length one to the reference produces a nice steep peak where itis expected. A versatile correlator block did not exist so far in GNU Radio, which is why it has beendeveloped from scratch. The block is in its functionalities orientated on what numpy.correlate provides.There are various di↵erent types of correlation. Just to give a few examples:

Correlation with memory (overlap) and without.

Correlation where only one input stream is continuous and correlation where both are continuous.

Correlation with a valid output length, same output length or full output length (Matlab correla-tion).

etc.

Nreference

Nwindow

Nreference � 1 +Nwindow

Nreference � 1

Figure 3.11: Depiction of how overlap-save works. Without applying such an algorithm a valid outputfor the correlator (time synchronization) cannot be achieved. Moreover, without overlap-save the resultlength would be wrong. Thus, the block would decimate.

For the time synchronization the conclusion was, that a valid correlation with memory is necessary. Itis for instance also undesired in this particular case, that all the processing for the reference streamscontinues. This is why the related reference samples are only requested once and copied into the memory.To achieve, that a correlation algorithm has a memory either overlap-add or overlap-save needs to beimplemented [31]. In practice, a valid convolution (and correlation is nothing but a convolution) will runinto length issues due to windowing, that one has to take care of. Continuing with the example of thelow-rate correlator, the valid correlation has a length of

Ncorrelation = Nwindow �Nreference + 1 (3.4)

This is because of the nature of convolution (cf. 6 in [32]) and the demand to not have e↵ects onthe frontiers (valid convolution/correlation mode). The reference sequence is only shifted within thereceived signal window, meaning that the reference and the received signal always overlap. Doing so, itis inevitable, that Ncorrelation < Nwindow, which would mean ending up with a decimator. However, acorrelator should not be a decimator. A sync block is what is needed, which is why the overlap has to

be handled in a way, that Ncorrelation!= Nwindow. The decision was in favor of overlap-save illustrated

in fig. 3.11. Inserting the new window length of Nwindow +Nreference � 1 into eq. 3.4 gives a correlationlength Ncorrelation, that is equal to the window length Nwindow. Yet, the first result will be shorter.

26

1 std::memcpy(d_vec_w_mem, d_vlong->vec + (d_vlong->len - d_vshort->len + 1),sizeof(gr_complex)*(d_vshort->len - 1) );,!

Code Example 1: Overlap-save as it is performed by the correlator help class partly on shared objects.

Code example 1 shows what has been done in the code. A bu↵er vector d vec w mem has old samplesstored. Another thing, which can be explained with the aid of this example is, that all the vectors areshared pointers, which allows skipping to copy arround a lot of memory. Instead, the correlator class isbeing directed to the places where to find input data and where to store output data. The Correlator isa composition and the actual work is done by a correlator help class leveraging VOLK. An interestingproblem, that occured during the development is, that the correlator help class is configured by itsuser (another class) and then after pointing to where the input data is and where to put the outputdata, only one correlate() function exists, which can be called by the user, although the correlate()implementation depends on the type of correlation desired. The boost::bind technique has been usedfor the correlator to pick the right correlation implementation itself and bind it to the public functioncorrelate.

It is also necessary to mention, that the Correlator has a bunch of more features. An important one isto detect maxima and report them as a PDU. As a consequence an adaptive threshold is required, too.The adaptive threshold utilizes a kind of Monte Carlo method to estimate the maximum to correlationoutput noise ratio. A desired SNR e.g. 6 dB can be configured. The maximum reporting is needed tocommunicate with the NB-IoT NPSS Synchronization Gate. By judging the feedback, the gate gets fromthe di↵erent correlators, it can coordinate things e.g. low-rate correlation was successful, trigger high-ratecorrelation and find the exact sample where the frame starts.

NPSS Frequency Synchronizer

Figure 3.12: Inside the NB-IoT NPSS Frequency Synchronizer: Control loop aiming to keep the frequencyo↵set at 0Hz. Surprisingly for the most, the frequency o↵set of ej!fFFOt can easily be compensatedmultiplying the signal with a sinusoid with negative frequency e�j!fFFOt.

To track the frequency o↵set a PID controller has been implemented. The frequency o↵set is the processvariable, the correction frequency the control variable and the estimated FFO is the input to the PIDcontroller, the error variable. To correct the o↵set the incoming data stream is simply multiplied witha complex sinusoid e�j!fFFOt, that ideally has exactly the same absolute frequency as the o↵set. Thus,figuratively speaking, the pointer has the same speed, but it rotates in the opposite direction. Fig. 3.14shows how the actual FFO estimation was implemented in accordance to [18]. It is very convenient, thatafter the NB-IoT NPSS Synchronizer, given that everything worked out, the data stream is frame alignedwith a precision of one sample. For this reason, first the NPSS subframe is copied out of the signal, thenthe first three OFDM symbols, which are 0 anyways, and the CP of the fourth symbol are removed.

3NFFT + CPEXTRA + 3CP = 421 (3.5)

The yellow block, which is currently bypassed, allows to not trigger the frequency synchronization for

27

Figure 3.13: Inside the NB-IoT NPSS FFO Estimator: Two correlator blocks performing the two neces-sary cross-correlations to be able to detect the frequency o↵set. The underlying concept is introduced in2.1.4.

every radio fame, but instead for instance every tenth frame. The kind of correlation, which is calculatedby the same very versatile Correlator block, is less complicated, since memory is not needed. Thecorrelation result only has a length of 1. Maxima do not need to be detected and the reference can stillbe produced once and stored.

3.3.2 Orthogonal Frequency-Division Multiplex

Figure 3.14: Inside the NB-IoT OFDM Demodulator: CP removal, FFT and extraction of the carriers,which are non-zero. The CP removing block is also organically hand-written.

First the CPs have to be removed, which is done with a self-written block. In general, this is not toocomplicated to realize, since the stream is aligned at that point. FFT is a block, that GNU Radioprovides and the carrier deallocator, designed within this work, extracts the symbols from used carriersand ignores the ones, which are out-of-band.

3.3.3 Equalizers

From fig. 3.15 one can see, that the equalizer does what it is supposed to in simulation. This outcome canbe achieved with both estimators, that have been conceptualized within this work. The code excerpt 2 isa part of the work() function of the simple estimator. First, it becomes clear, that the aforementionedinterface class gr::nbiot::ref symbols::interface is quite useful to build estimators. Secondly, one can see,that the estimation is in that case as simple as calculating the average of every channel estimate andfilling it in for every sample in half a subframe (slot).Not only the NB-IoT Reference Signal DEMUX, but also the NB-IoT Channel Estimator, are connectedto the LTE Reference Signal Generator. The demultiplexer utilizes the ref symbols::interface class,

28

-150 -100 -50 0 50 100 150In-Phase

-150

-100

-50

0

50

100

150

Quadratu

re

Symbols Not Equalized

-0.6 -0.4 -0.2 0.0 0.2 0.4 0.6In-Phase

-0.6

-0.4

-0.2

0.0

0.2

0.4

0.6

Quadratu

re

Symbols Equalized

Figure 3.15: Before (left) and after (right) equalizer with single-tap simulation model. No noise. Withoutthe equalizer the signal has the wrong phase and amplitude, which both need to be ”normalized” for thedemodulator to be able to map the symbols to two bytes each.

1 for (const int& ofdm_symb : symbols_w_pilots) {2 // Maneuver to right OFDM symbol

3 auto y = y_in + ofdm_symb*d_ncarriers;4 for (int ref_i=0; ref_i<2; ref_i++) {5 // Get the index of the ref. symbol

6 auto k = d_interface->get_next_k();7 // This is how the ref. symbol should look like.

8 auto ref = d_interface->get_next_ref();9 // Estimation

10 estimate += y[k]/ref;11 }12 }13 // Just average

14 estimate /= gr_complex(symbols_w_pilots.size()*2, 0);15 std::fill(&*h_out, &*(h_out + d_nrb), estimate);

Code Example 2: Simple estimator just averages the channel estimates and fills in the average for eachand every symbol. For each resource element in the resource grid a channel estimate is necessary. Wherethe estimates are not available because the pilots are missing they have to be ”made up” somehow.

29

as well. This proves the versatility of the software engineering concepts behind the reference signalgeneration.

Figure 3.16: Inside the NB-IoT Subframe Equalizer: Reference symbol generation, channel estimation,equalization and removal of the reference symbols. The information where the reference symbols are andwhat magnitude/phase they have respectively, can be obtained with the GNU Radio messaging interfacefrom the LTE Reference Signal Generator.

The simpler estimator was developed because the spline estimator did not work in practice, althoughit did in simulation (see 4.1.2). A whole subframe was assumed to be within the coherence time ofthe channel for that algorithm. This estimator calculates cubic splines [33] to interpolate in frequencyand time dimension. To avoid having to apply linear extrapolation the 13th OFDM symbol from thepreceding subframe was stored and reused for spline interpolation for the next time.

3.3.4 Demodulation, Decoding and Descrambling

Figure 3.17: Inside the NB-IoT Decoder and Descrambler: Decoding with Viterbi algorithm and de-scrambling. The FEC feature of the comm system is based on the Voyager code.

In fig. 3.17 the counterpart to what has been presented in 3.1.2 is shown. The demodulation is based onsoft decision.

3.3.5 Data Transmission and Application Layer

In code example 4 it can be seen, that the Message DEMUX also knows about the message interface, justlike the transmitter. Before dispatching a PDU, that will be processed by the Async CRC32, the type fieldis evaluated. If the data type field makes sense, it is encapsulated into a PDU. boost::dynamic bitsetis leveraged to implement e�cient preamble and tail detection.If the CRC checking is passed. The Chat Receiver gets the PDU and looks at the type, which isnumbered according to the definition in the interface. The interface and consequently the numbering isused throughout the system. So far, the Chat Receiver breaks somewhat the messaging hierarchy, because

30

Figure 3.18: Detecting and extracting messages with the Message DEMUX. Interpretation of chat mes-sages with the Chat Receiver. The receiver also makes use of the messaging interface. Due to the CRC,messages in the majority of all cases are only received when they are free of bit errors.

1 bool data_corrupt = false;2 try {3 type = d_msg_interface.type2str(_type);4 } catch(std::exception& e) {5 std::cout << e.what();6 data_corrupt = true;7 }8 if (!data_corrupt) {9 // Create PDU paylodad and meta data

10 // When creating a new vector make it shorter by one, leave out the type byte

11 pmt::pmt_t out_payload = pmt::init_u8vector(std::distance(msg_vec.begin(), msg_vec_it)-1,msg_vec.data()+1);,!

12 // Label the message send out accordingly

13 pmt::pmt_t out_meta = pmt::string_to_symbol(type);14 // Meta data is the byte vector we just created

15 pmt::pmt_t msg_pmt = pmt::cons(out_meta, out_payload);16 // Publish message on message port

17 message_port_pub(d_port_id, msg_pmt);18 }

Code Example 3: The Message DEMUX has access to the messaging interface and uses it to either labelPDUs or discard the data if the type is unknown.

it does not only accept messages of the type msg::mchatmsg. The intentions concerning applicationdesign of the messaging interface are di↵erent. Optimally, there are multiple di↵erent blocks responsiblefor receiving di↵erent message types and ignoring others.All the evaluation (latency and PER) is done within the msg::msystemmsg class itself.

31

1 if (std::find(std::begin(msg::TYPES_STRS), std::end(msg::TYPES_STRS), pmt::symbol_to_string(in_meta)) !=std::end(msg::TYPES_STRS)){,!

2 // This is still kind of suboptimal as one block should only handle messages of one type.

3 // Convert back to vector and print.

4 size_t len = 0;5 const uint8_t* msg_char = pmt::u8vector_elements(in_payload, len);6 if (len > d_max_msg_size) {7 std::cout << this->alias() << ": Invalid message length. Discarding." << std::endl;8 } else if (msg_char != nullptr) {9 std::string msg_str(msg_char, msg_char + len);

10 if (pmt::symbol_to_string(in_meta) == d_msg_interface.type2str(msg::CHAT_MSG)) {11 msg::mchatmsg chat_msg(msg_str);12 // Do something with the chat message.

13 } else if (pmt::symbol_to_string(in_meta) == d_msg_interface.type2str(msg::SYSTEM_MSG)) {14 msg::msystemmsg system_msg(msg_str);15 std::cout << "Received system message: " << system_msg.get_content() << "\n";16 } else {17 std::cout << ": Unsupported message type.\n";18 }19 // Save last message for debugging purposes.

20 d_last_msg = msg_str;21 }22 }

Code Example 4: The Chat Receiver checks the message type, which corresponds to the PDU headerand accordingly the received data is further processed. It could be a chat message or a system message.Either way a JSON string is interpreted. This demonstrates the capabilities of the messaging interface.

32

4 | System Validation and Perfor-mance Evaluation

To see how the system performs testing in three di↵erent categories has been carried out. First, di↵erentanalysis have been done to make sure, that key algorithms work as intended. Automated Quality As-surance (Q/A) tests were a useful tool for algorithm validation. Secondly, it was investigated how SNR,BER and PER change when the system is exposed to noise (simulation). Moreover, the data rate wasvalidated and the impact of di↵erent system components on latency was checked (simulation and tests inreality). Third, with field test it was attempted to find the limits of the system e.g. over what distanceand in which environment can data be transmitted.

4.1 Validation of Key Algorithms

4.1.1 Synchronization

Time Synchronization

0 2 4 6 8Time/ms

-15

-10

-5

0

5

10

15

(r~

D⇤ N

PSS)(t)

Low Rate Correlator Output

RealImag

(a) Low rate correlation over one radio frame looking forthe signal shown in 4.1b. Data length = 2161. fs/8 =240 kHz.

0.0 0.2 0.4 0.6 0.8 1.0Time/ms

-1.00

-0.75

-0.50

-0.25

0.00

0.25

0.50

0.75

1.00

dN

PSS

NPSS Subframe

RealImag

(b) NPSS signal, that is generated in the receiver asreference in frequency domain.

Figure 4.1: Cross-correlating NPSS (fig. 4.1b) with down-sampled received signal (fig. 4.1a) as a firststep. max|(r ~D⇤

NPSS)(t)| is the rough NPSS subframe start. This peak is clearly visible in the figureon the left.

The time synchronization is highly e�cient per se from concerning computational e↵orts, since multi-ratesignal processing is applied (cf. 3.3.1). It can be shown, that this claim also holds for reality, for thisparticular implementation. In fig. 4.1a the output of the Correlator in the low-rate signal path of theNB-IoT NPSS Synchronizer can be seen, while field tests are being performed. The correlation has anoutput length of 2161. As so often in engineering, this value is not a coincidence. It has to be exactly thatnumber of samples for the whole chain proving to function as intended. It should not be a sample more orless, because a valid convolution is calculated by the algorithm.( The documentation of numpy.correlatethe numpy manual [34] explains this quite well.) The window size of this correlator is configured to beNSA,SF ·NSF /ds = 2400. When correlating over one radio frame it is impossible to miss the NPSS. Thus,this window length has been chosen. Consequently, the reference length is NSA,SF /ds = 240, which ispretty short, leading to extremely low computational intensity during synchronisation. The signal thealgorithm ought to find is the NPSS, shown in fig. 4.1b. This is only half the truth, since what is

33

displayed still needs to be squeezed through the OFDM machinery (FFT and cyclic prefixing). The codesetting the correlation output length is located in the correlator help class.

1 // State machine of correlator.

2 if (d_corr_state == NOT_INITIALIZED) {3 d_res->len = d_vlong->len - d_vshort->len + 1;4 // Conjungate of f is needed every time the correlate_valid routine is executed.

5 d_vec_short_conj = static_cast<gr_complex*>( volk_malloc(sizeof(gr_complex)*d_vshort->len,d_alignment) );,!

6 volk_32fc_conjugate_32fc(d_vec_short_conj, d_vshort->vec, d_vshort->len);7 d_corr_state = INITIALIZED;8 }

Code Example 5: Correlator help class initialization. First result will be shorter. The output lengthequals the input length thereafter.

The initialization state of the correlator class is shown in the code example 5. It is a part of the memoryof this algorithm, needed when applying valid correlations with a constant reference window wise on acontinuous stream of samples. Memory in that sense stands for the algorithms ability to ”remember”data from earlier iterations. d res is a std::shared ptr pointing to an object in which the result vectoris wrapped into. The shared object is manipulated by the correlator class to only produce valid outputsamples avoiding windowing e↵ects at the beginning and at the end.

When putting the NB-IoT NPSS Synchronizer into verbose mode, information becomes visible, which ishelpful for verifying the correct and intended, computationally inexpensive behaviour of it.

npss_sync_gate0: Timeout has been set to 100 ms.correlator_cccc0: Alignment on this machine is 32 bytes.correlator_cccc0: Correlator settings flags are 00011010correlator_cccc0: Constraining multiple to 3840.correlator_cccc1: Alignment on this machine is 32 bytes.correlator_cccc1: Correlator settings flags are 00011010correlator_cccc1: Constraining multiple to 2400.

In the initialization phase VOLK (2.2) determines the byte alignment. Moreover, the number of outputitems, the scheduler asks for, is constrained to a multiple of the longer input vector to the convolution.The initialization is done by each correlator block individually. It is always fine to return less items thanwhat the scheduler asks for. Actually, in order to maintain the validity property of the convolution inthe beginning a number of items smaller than asked for by the scheduler has to be returned.

npss_sync_gate0: State: LOW_RATEnpss_sync_gate0: noutput_items 19200 produced_tagged 0 produced_high_rate 0 produced_low_rate 19200

consumed 19200,!

correlator_cccc1: Work is being called.correlator_cccc1: Current threshold is 18. Update failed: 0.correlator_cccc1: Maximum message dispatched. Maximum is: 859.correlator_cccc1: produced_corr 2161npss_sync_gate0: Received message.

First, low-rate correlations are triggered over and over again until an answer in the form of a message (2.2)is received from the low-rate correlator. In the beginning this part had a bug, due to the asynchronousnature of the GNU Radio message passing interface: Even if the low-rate correlator directly found amaximum, it would still be condemned to process another frame by the NB-IoT NPSS SynchronizationGate, since the message receiving function hook would be called too late. This would kind of wreck theachievements in terms of computational e�ciency, which were hard-earned before. Now, as the outputshows, this issue has been solved by jumping into a wait state with a (configurable) timeout.

npss_sync_gate0: State: LOW_RATE_REALIGNnpss_sync_gate0: Throwing away 5912 samples.npss_sync_gate0: noutput_items 19200 produced_tagged 0 produced_high_rate 0 produced_low_rate 0 consumed

5912,!

npss_sync_gate0: State: HIGH_RATEnpss_sync_gate0: noutput_items 19200 produced_tagged 0 produced_high_rate 3840

34

produced_low_rate 0 consumed 19200correlator_cccc0: Work is being called.correlator_cccc0: Current threshold is 198. Update failed: 0.correlator_cccc0: Maximum message dispatched. Maximum is: 881.npss_sync_gate0: Received message.correlator_cccc0: produced_corr 0npss_sync_gate0: State: HIGH_RATE_REALIGNnpss_sync_gate0: Throwing away 10481 samples.npss_sync_gate0: noutput_items 19200 produced_tagged 0 produced_high_rate 0 produced_low_rate 0 consumed

10481,!

npss_sync_gate0: State: TRACKINGnpss_sync_gate0: noutput_items 19200 produced_tagged 19200 produced_high_rate 0 produced_low_rate 0

consumed 19200,!

Secondly, the input data is realigned according to the information available so far. Then, another corre-lation is triggered in the high-rate domain with a window length of 3840 samples (an exemplary outputcan be seen in fig. 4.16, which is not related to the output shown above). Where is this number comingfrom? The reference has a length of NSA,SF . However, what has been determined to be the first sampleof the NPSS could be a bit o↵. Therefore, the window length has been extended by a play of 5%, whichequals NSA,SF ·NSF · 5% = 960 samples. The first guess could end up before or after the actual start ofthe NPSS subframe, this is why the correlation window starts 5% before and ends 5% after the symbolwhere the frame start is expected, which is what finally explains the 3840 samples. The output has againa length of 3840 � 1920 + 1 = 1921 for the first time. After that it is going to be longer. To be moreprecise, what goes in also comes out, since a convolution should neither be decimating nor interpolating.The play parameter is certainly a setscrew for performance optimizations. Alignment is always doneunder the assumption, that the fifth subframe is allocated for NPSS, as demanded by the standard (cf.2.1) and the result of the alignment is supposed to be the beginning of the radio frame.

npss_sync_gate0: State: TRACKINGnpss_sync_gate0: Triggering a tracking correlation.npss_sync_gate0: noutput_items 19200 produced_tagged 19200 produced_high_rate 3840 produced_low_rate 0

consumed 19200,!

correlator_cccc0: Work is being called.npss_sync_gate0: State: TRACKINGnpss_sync_gate0: Waiting for 10 ms.correlator_cccc0: Current threshold is 126. Update failed: 0.correlator_cccc0: Maximum message dispatched. Maximum is: 54719.correlator_cccc0: produced_corr 0npss_sync_gate0: noutput_items 19200 produced_tagged 0 produced_high_rate 0 produced_low_rate 0 consumed 0npss_sync_gate0: Received message.Estimated drift offset: -1 nitems_written(1) 57600.npss_sync_gate0: State: TRACKING_REALIGNnpss_sync_gate0: Interpolating 1 sample(s).npss_sync_gate0: noutput_items 19200 produced_tagged 19200 produced_high_rate 0 produced_low_rate 0

consumed 19199,!

As soon as the stream is aligned according to the correlation results, the machinery is switched intothe tracking mode. Naive approaches of the synchronization problem in the beginning did not consider,that the tracking is necessary. However, in reality, because the clocking of DAC (transmitter) and ADC(receiver) are not in sync, samples are missing or superfluous. Within approx. 4 s the signal would driftaway without tracking as tests with the USRP have shown. The output above indicates, that one sampleis missing in the receiver, so it has to be made up and the stream has to be realigned. One thing, thatcan be derived from the output, as well, is that the built-in adaptive threshold of the correlators doeswhat it is supposed to.

Coming to a conclusion, it would hardly be an exaggeration to state, that the time synchronisation is acorner stone for a working receiver system. The time synchronization algorithm presented, implementedand evaluated in this work takes drifting into account by either discarding or zero padding of samples,as well as, trying to keep the processing e↵ort slim by leveraging multi-rate signal processing.

Frequency Synchronization

Fig. 4.2a shows the output of two NB-IoT NPSS FFO Estimators one placed before and one placed afterthe NB-IoT NPSS Frequency Synchronizer. As explained in detail in 3.3.1 under the hood of this blocka PID controller achieves the best possible frequency o↵set mitigation. In this case the control loop isexecuted with a frequency of 100Hz, which is the highest frequency possible for this application, because

35

0.0 0.5 1.0 1.5 2.0 2.5 3.0Time/s

-0.15

-0.10

-0.05

0.00

0.05

0.10

0.15

Estim

ated

Frequen

cyO↵set

Frequency Sync. Impulse Response

�fafter

�fbefore

(a) Controller distortion with 2205Hz amplitude rect-angular signal.

-3 -2 -1 0 1 2 3In-Phase

-2

-1

0

1

2

3

Quadra

ture

Symbols after OFDM Demodulator w/o Frequency Sync

(b) Constellation plot w/o freq. sync and equalizer,1680 samples.

Figure 4.2: Simulated controller distortions of 2205Hz can be corrected with 5% error left in 160ms (fig.4.2a). Frequency synchronization is inevitable as tests have shown (fig. 4.2b).

one NPSS subframe is needed to run the estimation calculations and it only occurs once every 10ms(cf. 2.1). The channel model is a simple multiplication of the baseband signal with another signal so(t),defined as

so(t) = ej·2⇡·fFFO·t·rect(t), (4.1)

whereas fFFO is the maximum FFO and rect(t) is the boxcar function periodically continued with aperiod of 1 s. Thus, the frequency o↵set of this trivial channel model jumps between 0Hz and fFFO =2205Hz. After simulating and carefully tuning in an iterative fashion according to [35] the PID controllerparameters shown in table 4.1 have proven to work quite well.

Kp 0.1Ki 0.2Kd 0.1

Table 4.1: Parameters of the PID controller after loop tuning.

One of the problems with this method is, that the FFO estimation equation from the paper [18] doesnot really keep what it promises: A FFO of �fC = 15 kHz is not corresponding to an estimation outputof exactly 1, but 0.92257 instead in this case. Reasons for this deviation might be numerical instabilitywith floating point arithmetics as for instance discussed in [36] or the non-compatibility of the algorithmto NB-IoT.( It has been developed for LTE.) Another problem is, that noise impacts the estimationsignal directly, which makes it hard for the controller to keep up speed-wise.( The constellation diagramsometimes rotates a bit back and forth and without an equalizer the system would not work at all.)

Nevertheless, the frequency estimator is functional and needed. Removing it leads to the observation of a”noisy circle” in the constellation diagram, which is the classical indicator for frequency o↵set. Originaldata depicting this phenomenon is plotted in 4.2b. Furthermore, the controller is quite quick: The 5%deviation line is hit after just 160ms (16 controller iterations) in the experiment discussed in this section(fig. 4.2a), although the frequency distortion is unrealistically high.

4.1.2 Equalization

Fig. 4.3a shows the receiver symbols after the equalizer, which leverages splines to interpolate the samplesfor which the channel characteristics Hl,k is unknown, since pilots can of course not be everywhere (see2.1.5). l is the OFDM symbol and k is the carrier. Further investigations have to be carried out onthis way of estimating H, because it is not entirely evident why this did not work out as intended. Onesuspicion was, that the coherence time of the channel is too short, so the trick with storing one OFDMsymbol from the last subframe (cf. 3.3.3) is not a good idea. Assuming a coherence time of a bit more than1ms the problem might be, that memory is added to the algorithm. Old information about the channel

36

-2.0 -1.5 -1.0 -0.5 0.0 0.5 1.0 1.5 2.0

In-Phase

-2.0

-1.5

-1.0

-0.5

0.0

0.5

1.0

1.5

2.0

Quadratu

re

Spline Estimator

(a) Spline interpolating channel estimator, 7560 sam-ples. BER = 30%. PER = 99.87% (10 000 packets).SNR = �7.2 dB.

-2.0 -1.5 -1.0 -0.5 0.0 0.5 1.0 1.5 2.0

In-Phase

-2.0

-1.5

-1.0

-0.5

0.0

0.5

1.0

1.5

2.0

Quadratu

re

Simple Estimator

(b) Simple channel estimator, 7560 samples. BER =0.004%. PER = 0.01% (10 000 packets). SNR =16.2 dB.

Figure 4.3: The first trial with a spline interpolation and linear extrapolation obviously failed. However,the second trial was successful although the approach was trivial.

state is thereby applied over and over again to estimate the current channel characteristics. However,since the channel changes very quickly over time, as can be observed looking at the estimated H witha working equalizer (fig. 4.4), this memory has been removed, which did not help to get better results.Another speculation at this point in time is, that the spline interpolation leads to noise enhancement.

It is rather obvious, that the simple estimator (results in fig. 4.3b), engineered in a second attemptworked much better. The measured SNR of 16.2 dB still is avowedly not optimal, but this can also berelated to other components, which need to be further optimized. In fig. 4.4 the way the simple equalizeroperates can clearly be seen: It outputs the same value for one subframe (84 samples), which equals sevenOFDM symbols. For this reason, channel phase and gain have an ”edgy”, digital look. The channel gaindoes only vary by about 1.5 dB, but the phase looks like a sawtooth signal. As �f = d arg{H}/dt, thisresult implies, that the frequency o↵set is constant for a certain amount of time and then jumps. It hasto be investigated if this is a systematic error. The equalizer is responsible to get rid of the last bit offrequency o↵set, so a certain phase change is acceptable.

0.0 0.2 0.4 0.6 0.8 1.0t/s

-3

-2

-1

0

1

2

3

arg� H

/rad

Channel Phase

(a) Channel phase in radians.

0.0 0.2 0.4 0.6 0.8 1.0

t/s

-1.0

-0.5

0.0

0.5

1.0

1.5

2.0

2.5

3.0

� � H� � /dB

Channel Gain

(b) Normalized channel gain in Decibel.

Figure 4.4: The channel seems to have a certain periodicity. This could be a periodic, distorting signal,which is due to bad Electro-Magnetic Compatibility (EMC) design modulated onto the received signal.The signal gets a ”digital look” from the averaging over a time of 0.5ms.

In a nutshell, the equalizer is an important component for performance tweaks. Yet, the simple equalizeris achieving decent results, removes the residual FFO, that the NB-IoT NPSS Frequency Synchronizer

37

failed to erase, and, most importantly, reliably prepares the symbols for the QPSK soft decoding.

4.1.3 Baseband Compression

0 10 20 30 40 50 60Time (s)

0

2

4

6

8

10

12

14

16

Data

Rate

MiB

/s

Data Rates of USB and Socket w/o Compression

USB: Radiohead to USRP

ØMQ: Edge to Radiohead

0 10 20 30 40 50Time (s)

2

3

4

5

6

7

Data

Rate

MiB

/s

Data Rates USB and Socket w. Compression II

USB: Radiohead to USRP

ØMQ: Edge to Radiohead Compressed

Figure 4.5: The proposed fronthaul compression algorithm based on undersampling the baseband signalwith a factor of d = 8 corresponding to a FFT size of NFFT = 16 results in a compression ratio of 5.3:1.The fronthaul data rate is 2.777MiB/s using compression, which is even more than 2.5 times less thanover the USB cable.

With baseband compression a c-RAN can be tailored to specific deployment requirements. Furthermore,generally speaking, in the telecommunication industry, it is not desired to occupy bandwidth, which isactually not required.

The data rate over the USB wire DW (without overhead) is expected to be

DW � fs · 4B ⇡ 7.324 MiBs (4.2)

since the in the settings specified USRP wire format is a 16 bit integer (for each of the two DACs). fs is1.92MHz equal to one sixteenth of what is defined in 4.1 in [11] as sampling frequency. The lower samplingrate is possible because of undersampling by a factor of 16 due to the lower bandwidth requirement ofNB-IoT (cf. 3). Without any kind of compression the expected data rate over the network link DØMQ is

DØMQ � fs · 8B ⇡ 14.648 MiBs (4.3)

since GNU Radio passes a stream of complex 32 bit floats in-between the ØMQ endpoints. The � signinstead of the = sign is used, because a certain amount of overhead must be assumed. In order to findout how much bandwidth is actually occupied by ØMQ stdout of the tool iftop has been redirected to afile, which was later on post-mortem parsed with a python script (see A).

iftop -n -B -f "port 5555" -t > iftop.out

Tra�c over the USB wire has been sni↵ed with the help of the usbmon kernel module and self-writtensoftware to filter out the interesting packets, as well as, to process them (cf. 3.2.2).

As can be seen in fig. 4.5 the measured USB data rate and the socket data rate do have approximatelythe afore calculated values. The first measurement without compressed fronthaul (fig. 4.5, left) shows atransient. Both measurement tools have been set up before the actual edge and radio head designs havebeen booted. Although, iftop and the USB data rate sni�ng tool were started when the edge-radio headsystem was already running, some windowing e↵ect is visible for the second measurement with fronthaulcompression, which is due to iftop.

How much signal processing is outsourced into the radio head on the one hand and how much bandwidthis occupied on the fronthaul link on the other hand is a technological trade-o↵. A system should beoptimized for a specific case or platform e.g. when the data link is pricey more processing should be done

38

0 10 20 30 40 50 60Time (s)

0

2

4

6

8

Data

Rate

MiB s

Data Rates USB and Socket w. Compression I

USB: Radiohead to USRP

ØMQ: Edge to Radiohead Compressed

ØMQ: Edge to Radiohead Mean

Figure 4.6: When all OFDM operations are outsourced to the radio head, the lowest datarate on thefronthaul can be obtained. The data transmission however is not constant, which is an implementationproblem.

in the radio head. This is being discussed in more detail in 3.2.2. When fully outsourcing all OFDMoperations to the radio head, the achievements concerning bandwidth savings seem to be satisfying lookingat the results shown in 4.6. However, the average data rate over the socket, which ØMQ is hooked up to,is twice as high as necessary. After compression, the data rate needed for transmissions over the networkis

DØMQ = NSY · 1

TSF· 8B ⇡ 1.282 MiB

s (4.4)

where NSY · 1TSF

= 168 kS/s. Supposedly, the data is almost always retransmitted or something else is

going wrong in the interface between ØMQ and GNU Radio. This has not been further debugged.

When applying the interpolation method proposed earlier to compress the fronthaul link, the data ratecan be calculated as follows.

DØMQ � (NFFT + CPTEMP ) ·NSY,SF,O ·NSF · 1

TSF· 8B = 2.777 MiB

s (4.5)

The results show, that the simple interpolation method already yields a compression ratio of about 5.3:1.Admittedly, the current implementation is not optimal. In simulation it was not possible to get a SNRhigher than 18.1 dB, which is still more than enough to demodulate the signal, however, not satisfying,since the SNR in that case should solely depend on the cyclic prefix length and the interpolation filterlength, which it did not as experimentally found out. These results allow the conclusion, that thealgorithm has not reached a level of su�cient maturity yet and needs further improvement. Moreover,the results show, that it is possible, by finding the right trade-o↵ between fronthaul bandwidth and radiohead complexity, to perfectly adapt a NB-IoT edge system to the given deployment circumstances.

4.2 Performance Analysis and Simulation Results

The overall performance of the demo application was su�cient for it to be used to give booth visitors thepossibility to interact with the technology at the EuCNC 2018 in Slovenia.

4.2.1 Signal-to-Noise Ratio

One important aspect, that has been surveyed is the system’s response to noise. To do so, as a firststep, the transmission was redirected through a simple channel model with one tap 1 + 1j and AWGN.In order to avoid clipping at the receiver side when working with HW, first the antenna output signalwas normalized by hand, in order to get the peak value of the signal not to be greater than 1. This isnecessary to avoid clipping, as well. The SNR has been measured after the equalizer with the MPSKSNR Estimator Probe provided by GNU Radio. In fig. 4.7 the results of what happens to the SNRin both cases when adding noise are displayed. Again it is visible, that the fronthaul compression is not

39

-35 -30 -25 -20 -15 -10 -5 0Added Noise Power/dB

5

10

15

20

25

30

35SNR/d

B

SNR in AWGN Channel

SNR

SNR w/ Compression

Figure 4.7: Comparison of compressed and uncompressed fronthaul. The SNR is measured after equal-ization. The SNR with compressed fronthaul signal has a certain negative o↵set from the uncompressedsignal. The compression algorithm limits the SNR to 18.1 dB due to immaturity. However, this is stillenough to demodulate a QPSK.

perfect yet, since it degrades system performance (see 4.1.3).

In summary, without baseband compression and a SNR of only 4 dB one can still get 10% of all packetsthrough the system. An explanation for this impressive robustness is the coding (50% of the informationis sent twice) and the modulation alphabet, which only knows four symbols.

4.2.2 Bit Error Rate and Packet Error Rate

The BER was estimated on the data link layer, by counting 1s. The estimation is based on the assumption,that i↵ nothing goes wrong and there is no tra�c, not a single 1 will be transmitted. This also implies,that messages should not be dispatched during BER measurements. As described in 3.1.1 zeros aremultiplexed with the actual data, in case data is available. When no data is available, the stream ofzeroes is scrambled and encoded (cf. 3.1.2). If no bit error occurs only 0s should come out at the receiverside accordingly after decoding and descrambling. A new block the BER Estimator has been introducedto count 1s and calculate the BER on-the-fly. The PER is calculated by attaching a linearly increasingnumber to each packet. During object creation of a msystemmsg on the receiver side an algorithm isexecuted keeping track of how many packets have possibly been dropped when a new packet comes in.Basically there are four possible cases in which the receiver would drop a packet:

Preamble is faulty.

Tail is faulty.

Data type field is faulty.

Data is faulty.

If the preamble is wrong the state machine in the Message DEMUX never reaches the receiving state.The max msg size, a constructor parameter of this block, is used to detect if the tail is faulty. If thedata type field can not be interpreted the packet is discarded as well. All theses steps are taking placebefore the four CRC bytes are even touched. If a CRC error occurs afterwards the packet is sorted out,

40

-35 -30 -25 -20 -15 -10 -5 0Added Noise Power/dB

0.0

0.2

0.4

0.6

0.8

1.0PER and BER w/o Compression

BERPER

-35 -30 -25 -20 -15 -10 -5 0Added Noise Power/dB

0.0

0.2

0.4

0.6

0.8

1.0PER and BER w/ Compression

BER w/ CompressionPER w/ Compression

Figure 4.8: BER and PER comparison between uncompressed (left) and compressed (right) fronthaul.Measurement carried out leveraging internal mechanisms implemented for the sole purpose of evaluation.Compression details: NFFT = 16, CPEXTRA = 10 and resulting compression ratio is approx. 5.3:1.

too.

Fig. 4.8 shows the results when comparing BER and PER of a transmission system with fronthaulcompression and without fronthaul compression (details on compression in 3.2.2). It is rather obviousfrom reviewing these results, that the fronthaul compression in its current state of implementation lowersthe system performance (more information in 4.1.3).

4.2.3 Data Rate

******* MESSAGE DEBUG PRINT ********(((rate_now . 1980.35) (rate_avg . 2001.97)))******************************************* MESSAGE DEBUG PRINT ********(((rate_now . 2011.79) (rate_avg . 2002.96)))******************************************* MESSAGE DEBUG PRINT ********(((rate_now . 2011.79) (rate_avg . 2003.84)))************************************

Above the output is shown, that is obtained when probing the data rate in GNU Radio with availableinfrastructure on the data link layer after the Message MUX (update rate ms=500, alpha=0.1). In thiscase only one subframe has been used for the data transmission. This beautifully even value of 2 kB

s is nota coincidence, but corresponds to the following equation and is another proof, that the system functionsas intended:

DSF=0 = fS · N0C

NC· N

0SA

NSA· N

0SY

NSY· N

0SF

NSF·M ·R (4.6)

where

D is the data rate and DSF=0 is the data rate of the 0th subframe.

fS is the sampling rate as defined by the standard (cf. [11]).

N 0C

NCis the FFT oversampling ratio (cf. 2.1.2).

N 0SA

NSAis the ratio between samples used for OFDM symbols and samples for the cyclic prefix.

N 0SF

NSFis the ratio between the number of occupied subframes and available subframes, in other words,

the amount of time actually used to transmit the application data.

N 0SY

NSYis the ratio between pilot symbols and data symbols.

M is the number of bits per symbol with this modulation alphabet.

41

R is the code rate.

N 0SA

NSAcan be further expanded to

N 0SA

NSA=

NFFT · 7NFFT · 7 + CP · 6 + CPEXTRA

(4.7)

where NFFT = 128 is the FFT length and CP = 9 and CPEXTRA = 10 are two cyclic prefix lengths.

Also, N 0SY

NSYcan be further expanded to

N 0SY

NSY=

NSY,SF �NSY,P

NSY,SF=

NSY,SF,O ·N 0C �NSY,P

NSY,SF(4.8)

where NSY,SF = 168 is the number of symbols in one subframe (1ms), NSY,P = 8 is the number of pilotsper subframe (per antenna port), NSY,SF,O = 14 is the number of OFDM symbols per subframe andN 0

C = 12 is still the number of carriers used per OFDM symbol (128 samples, which is equal to 66 23 s).

As pointed out in 2.1.3, NB-IoT requires two CPs. Inserting the values given for this project and eq. 4.7and eq. 4.8 into eq. 4.6 gives

DSF=0 = 1.92MHz · 12

128· 128 · 7128 · 7 + 6 · 9 + 10

· 168� 8

168· 1

10· 2 · 1

2= 16 kbit

s = 2 kBs . (4.9)

4.2.4 Latency Measurement and Analysis

When the whole system was tested for the first time, including the application layer, the latency betweentapping the send button in Telegram and seeing the message popping up on the receiver side, was striking.This is why a closer look has been taken on what causes the latency and how to reduce it to a minimum.It is a well-known fact, that working with SDRs simultaneously means struggling with the topic oflatency and data delay (cf. 5.2.3 in [37]). On the one hand clear advantages of SDRs are the flexibility,reusability across di↵erent platforms due to HW abstraction and the fact, that the implementation is easilymaintainable. On the other hand the GPP approach is payed with delays in-between the di↵erent signalprocessing blocks. FPGAs, in contrast, are known for enabling Physical (PHY) layer implementationswith minimal latency.

SDR

FPGAGPP

FIFO

ADC

DAC

FIFO

TX RF

RX RF

Low LatencyHigh Latency

Link

Figure 4.9: Bu↵ers in the HW cause latency as well as the data link from GPP to the radio peripheraldoes. Radio implementations in FPGAs are well-known for very little latency.

First, additional latency is introduced by the data link between the radio, DACs and/or ADCs, and theGPP (fig. 4.9). Data is bu↵ered and transferred making use of for instance USB, Ethernet, or PeripheralComponent Interconnect Express (PCIe), to just name a few common standards. The FPGA and theDAC/ADC are usually integrated in a SDR and the SDR ships supporting most likely one or two di↵erentstandards for the data link to the GPP, which is why the possibilities to influence this part are ratherlimited. Even so, this is not a problem, since this part of the system has already been designed to beoptimized on low latency/high throughput or can be configured in the driver to be optimized for eitherof those. Throughout this work USB 3.0 was used for the data link together with libusb to link GPPand SDR.Secondly, latency is added by SW. GNU Radio and any other SW-based PHY implementation exchangedata between di↵erent DSP blocks with the help of bu↵ers. A successor block reads data from a shared

42

DSP Block 1DSP Block 0 FIFO

Extra Latency

readwrite

Figure 4.10: Bu↵ers interconnecting di↵erent DSP blocks introduce latency.

bu↵er to retrieve its input data and a predecessor block writes the output data to the aforementionedbu↵er. From the point of view of the scheduler, which underlies GNU Radio, a bigger bu↵er is better,since read and write operations take up Central Processing Unit (CPU) cycles. Moreover, the frequencyof memory accesses is as commonly known limited. A bigger bu↵er size enables the processing of moredata every time the scheduler executes the work() [38] function of a DSP block and therefore raises theoverall data throughput. Bu↵er size and latency have a proportional relation: latency / buffer size (cf.eq. 4.10).

In GNU Radio vectors of samples are passed from one block to another. The size of this vector isadjusted automatically depending on how long a block needs to process the data. Hence, GNU Radioships with a dynamic scheduler. GNU Radio’s scheduler is designed to prioritize throughput, in plainEnglish, the amount of samples in a certain period of time, over latency. Thus, the bu↵ers are maximizedup to the maximum amount of data one block can handle at a time. This behaviour is highly e�cientin terms of processing speed, since the scheduler overhead is kept low and the CPU performs actualDSP as desired instead of shovelling memory from one place to another. The downside of this strictthroughput optimization is high latency. However, in later revisions GNU Radio added a couple offeatures to mitigate latency and to fine tune the overall design if strict latency requirements are given. Inparticular, the GNU Radio API provides a couple of functions to manipulate input and output bu↵ers.E.g. void gr::block::set max output bu↵er(int port, long max output bu↵er) constrains the maximumoutput bu↵er size of a specific port of a block, whereas void gr::block::set max noutput items(int m)sets the maximum input bu↵er size. (The term noutput is in GNU Radio nomenclature equivalent tothe word input size.) Therefore, the programmer has the possibility to directly set an upper boundaryto the latency, at least theoretically.

As it turned out the scheduler is not always able to manage the given presets, which it spits out duringruntime. An example follows: The edge design uses the Message MUX to multiplex e.g. chat messageswith a stream of zeroes, which is always in place (cf. 3.1).

1 /* We will try to minimize the output buffer size

2 to maximize throughput and see what we will get.*/

3 if (d_verbose) {4 std::cout << this->alias() << ": Trying to constrain output buffer to " << d_max_msg_size +

d_signaling_len*2 << "\n";,!

5 }6 set_max_output_buffer(d_max_msg_size + d_signaling_len*2);7 if (d_verbose) {8 std::cout << this->alias() << ": Output buffer size: " << max_output_buffer(0) << "\n";9 }

Code Example 6: Di↵erent parameters about bu↵ers can be manipulated in GNU Radio. The codedosplayed above constrains the output bu↵er size of the Message MUX. However, the scheduler notnecessarily is able to manage the constrains.

The above code tries to enforce an upper bu↵er size boundary equal to the maximum message size pluspreamble and tail, then reads it back during object construction. In the terminal the following output isproduced:

43

message_mux0: Trying to constrain output buffer to 116message_mux0: Output buffer size: 116gr::log :WARN: flat_flowgraph - Block (message_mux0) max output buffer set to 4096 instead of requested 116

Similar output occurs as well in the context of the NB-IoT Scrambler and Encoder when the GNURadio Companion is used to set the maximum output bu↵er size.

To gather data about the latency and to find out which parameters have an impact on it, bulk transfers ofmessages outgoing from the Chat Transmitter are initiated. Every message gets a normal Unix timestamp.When received, after going through the whole chain, the Chat Receiver compares the timestamp to thecurrent epoch and calculates the latency in seconds. 1000 messages are transferred and the latency isaveraged over all received messages. The number of occupied subframes is the free variable (cf. 2.1.3),which applies for all measurements. The Telegram bot is deactivated when bulk messages are transferred,since HyperText Transfer Protocol Secure (HTTPS) communication with the bot API slows down themeasurement and leads to additional delay. With this approach the accuracy is limited, since Unixtimestamps result in an accuracy of seconds. Nonetheless, as found out, if averaging is applied thismethodology is still accurate enough to see the di↵erences in latency when changing certain parameters.

2 4 6 8 10

Number of subframes

0.0

2.5

5.0

7.5

10.0

12.5

15.0

17.5

Laten

cy/s

Latency Experiment I

One machine

One machine fitted

One machine w/o OFDM

One machine w/o OFDM fitted

One machine w/o OFDM w/o coding

One machine w/o OFDM w/o coding fitted

Figure 4.11: Measurements carried out on one machine, no network layer: The latency is displayed as afunction of the number of occupied subframes in di↵erent scenarios. FEC can be identified as one of theworst contributors to latency.

In figure 4.11 the results of the first latency experiment are displayed. It was carried out involvingonly one machine (Debian 9, Intel(R) Core(TM) i5-3320M CPU @ 2.6GHz and 8GB DDR3 RAM @1600MHz). Three distinct settings have been predefined for this experiment:

1. One machine: The whole chain from base station to receiver on one machine without a SDR or anetwork connection involved.

2. One machine w/o OFDM: Same as 1, but the transmission is only based on QPSK modulation.The correct datarate is preserved by having the OFDM operations running in parallel, but the datastream is terminated with a Null Sink instead of being processed in the transceiver.

3. One machine w/o OFDM w/o coding: Same as 2, but coding and scrambling is skipped throughbypassing the NB-IoT Scrambler and Encoder and the NB-IoT Decoder and Descrambler.

For the second experiment, the results are shown in fig. 4.12, another set of three cases has beenilluminated:

44

2 4 6 8 10Number of subframes

2.5

5.0

7.5

10.0

12.5

15.0

17.5Latency/s

Latency Experiment II

Radiohead

Radiohead fitted

Receiver

Receiver fitted

One machine

One machine fitted

Radiohead w/o coding

Radiohead w/o coding fitted

Figure 4.12: Measurements with radio head and receiver: The latency is visualised as a function of thenumber of occupied subframes in di↵erent scenarios. It is possible to conclude, that the ØMQ interfaceor the network adds further latency of about half a second for di↵erent data rates.

1. Radio head: The signal is received and processed on the radio head. The base station is runningon the edge computer.

2. Receiver: latency of the overall system involving HW and an actual transmission over the air.

3. Radio head w/o coding: Same settings as in 1, but coding and scrambling blocks, which weresuspected to contribute significantly to the latency, were removed.

Up to three computers have been involved in the above mentioned experiment:

Two computers, radio head and edge, equipped with Debian 9, an Intel(R) Core(TM) i7-6770HQCPU @ 2.6GHz and 16GB DDR4 RAM @ 2133MHz.

The aforementioned computer, receiver.

Equation 4.10 shows the mathematical model, which aims to explain the results.

tT =SBU

DSF=0 ·N 0SF

+ tLB (4.10)

Actually, the fitting is based on this model, inducing, that it is not too far from the truth. The variablesare:

SBU - size of the biggest bu↵er.

DSF=0 - data rate on data link layer occupying one subframe.

N 0SF - number of occupied subframes.

tLB - lower boundary consisting of a delay which is due to the nature of the implementation.

Applying brute force to the system by not throttling it with a desired sampling rate leaves the term tLB

as the only contributor to the latency.

limD!1

tT =SBU

D+ tLB = tLB (4.11)

45

Presumably, the parameter tLB is a sum, reflecting di↵erent aspects leading to a lower boundary inlatency, which can not be overcome by brute force i.e. by boosting the data rate and has not been fullyunderstood yet.

tLB = tPROC + tNET + tCPY + tALG + tDL + ... (4.12)

Contributors to this boundary can be

tPROC - sum of all the time needed by the CPU to do the signal processing/ execute algorithms.

tNET - delay introduced by the Ethernet connection (subsuming ØMQ, TCP/Internet Protocol(IP) in that case).

tCPY - overhead from read/write operations.

tALG - nature of one or multiple algorithms introduces latency (e.g. data is not forwarded to thenext DSP block while calculations are ongoing although this would be feasible).

tDL - data link between HW and GPP as mentioned above.

Other sources of latency, which have not been determined yet.

For instance the whole system running on one machine (experiment I, setting 1) leads to the followingmodel parameters when the fitting is performed with scipy.optimize.curve fit(): S = 34.947 kB, D =2 kB

s , tLB = 576.446ms.

In fig. 4.12 the results of the latency with only one machine are plotted as well, which allows to identify,the network stack tNET as a major source of latency. The communication stack between edge and radiohead has not yet been tailor-made. It is provided instead by ØMQ (cf. 2.2). Another observation is, thatthe coding and scrambling, in general the data link layer, is the worst contributor to the latency. In thiscase as well, infrastructure available in GNU Radio has been put in place, instead of implementing it byhand (cf. 3.1.2). Moreover, the latency contribution of the HW part, including e.g. the data link tDL isvery low, which becomes evident, comparing ”Radio head” and ”Receiver” measurement. Summarizing,one can say, that the latency has to be further optimized by refactoring DSP blocks and implementingtailored solutions for absolutely every part of the system.

4.3 Field Measurement Results

4.3.1 Testbed and Measurement Setup

To see how well the system, designed and built within this work, performs, it has been tested in a randomo�ce cube at the Ericsson headquater. A floorplan, also indicating where the receiver has been placedto carry out measurements, is shown in fig. 4.13. In order to gather the results presented in the nextsubsection, the RAN, including radio head, SDR and edge server, were located on a table in a fixed place(blue filled circle); whereas, the receiver sat on a movable table and was relocated for each measurement.Radio head and edge, two seperate desktop personal computers, connected by an Ethernet switch, wereequipped with Debian 9, an Intel(R) Core(TM) i7-6770HQ CPU @ 2.6GHz and 16GB DDR4 RAM @2133MHz, while the receiver was a standard laptop with Debian 9, Intel(R) Core(TM) i5-3320M CPU @2.6GHz and 8GB DDR3 RAM @ 1600MHz. Both radio head and receiver were connected to the USRPB210. The gains, GT and GR are mentioned in tab 4.2. The center frequency of the NB-IoT signal wastuned to fT = 2.45GHz and an analog bandwidth of bT = bR = 200 kHz has been set in both receiver andtransmitter hardware. Photos of the di↵erent locations, where the receiver has been set up, to capturethe signal, can be found under F.

4.3.2 Measurement Results

Fig. 4.13 together with tab. 4.13 present the overall performance results of the Edge Fog ComputingSystem (EFS) including the receiver built to have a complete test platform. It was possible to receiveand decode the signal in a side corridor in the o�ce cube shown in the floor plan in a distance of 50mwithout line of sight and having walls as well as a metal-framed glass door in-between. Fig. 4.14 showsthe power spectrum of the received NB-IoT signal stand-alone deployment (cf. 2.1). To be able to useSSH to connect to the headless edge and radio head computers a practical script, that sends IP addressesvia a bot has been written (B). In this way the computers just have to be in a network where they canlogin to obtain terminal access.

46

Figure 4.13: Random o�ce cube at the Ericsson headquarter, which served as test area. Circle centrespoint to the locations where data has been measured (tab. 4.2). The filled circle centre is the location ofthe transmitter. In a distance of roughly 65m w/o LOS a PER of 0.5% with a SNR of 15.9 dB could beachieved.

-2.0 -1.5 -1.0 -0.5 0.0 0.5 1.0 1.5 2.0Frequency/MHz

-50

-40

-30

-20

-10

0

|H(f)|/

dB

Normalized Received Power Spectrum USRP B210

|H(f)|180 kHz bandwidth

Figure 4.14: Received power spectrum with USRP. GT = 89.8 dB, GR = 30dB. Distance: approx. 3m.The bandwidth of 180 kHz is achieved, the filter could be a bit more steeper and the attenuation of only5 dB on the left hand side to the first side lobe is too low. However, this is versatile and non-optimizedHW, which would not be used in a product.

47

Distance Description GR BER PER SNR1 61m End of the corridor. Metal-framed glass door

in-between. Transmitter additionally hiddenaround a corner.

60 dB 1.89% 57.12% 8.4 dB

2 20m Metal-framed glass door, metal handrail and in-between.

30 dB 0.02% 0.3% 16.2 dB

3 50m Transmitter behind metal-framed glass door.UE in side corridor.

76 dB 6.43% 66.37% 5.8 dB

4 65m End of the corridor. Metal-framed glass doorin-between. Tight hallway.

30 dB 0.03% 0.5% 15.9 dB

Table 4.2: Results corresponding to fig. 4.13. fT = 2.45GHz and GT = 89.8 dB.

4.4 Comparison of LimeSDR and USRP

0 2 4 6 8 10t/ms

-1.00

-0.75

-0.50

-0.25

0.00

0.25

0.50

0.75

1.00

R� s(

t)

Radio Frame LimeSDR

0 2 4 6 8 10t/ms

-1.00

-0.75

-0.50

-0.25

0.00

0.25

0.50

0.75

1.00R� s(

t)

Radio Frame USRP

Figure 4.15: Comparison of one radio frame in time domain (not in sync) LimeSDR (left) and USRP(right). Both signals have similar shapes and the NPSS is clearly visible after the middle of the frame,since the first three symbols are 0s only. Nevertheless, synchronization failed with the LimeSDR, becausethe noise was too high.

Quite a substantial amount of work and time has been put into creating a hardware abstraction model, aso-called OOT module, in GNU Radio for the LimeSDR (see 3.2.1), as it has not been available whenthis project was kick-started in January 2018. It turned out, that the price ratio (of approx. 400%)between LimeSDR and USRP is justified, since in combination with GNU Radio the USRP B210, incontrast to the LimeSDR works just fine out of the box in a plug ’n play fashion. Fig. 4.15 shows oneNB-IoT radio frame received at a random point in time with each board. The zeroes in both plots are thefirst three OFDM symbols of the NPSS signal containing a length-11 ZC sequence in the fifth subframeof each radio frame (cf. 2.1.3). Hence, this particular pattern has to emerge once in 10ms, which isthe scope plotted here. In time domain both signals look quite similar. Still, the signal captured withthe LimeSDR could not be demodulated or even properly synced on. Digging deeper, looking at thehigh-rate correlator exposes the problem: The NB-IoT ZC sequence correlation does not bring forth theexpected peak, standing out where the first sample of the fifth subframe in the radio frame is locatedas displayed in fig. 4.16. Due to that, it is impossible to keep the receiver in time sync long enough toproperly synchronize in frequency and demodulate.

When the OOT module gr-limesdr has been developed hardware and software have been tested in variousscenarios. One of them was the simultaneous transmission and reception of analog FM radio with a centerfrequency of 434MHz in an ISM band (waterfall plot from gqrx displayed in fig. 4.17). With some moree↵ort in fine-tuning it should be possible to get the NB-IoT implementation to work on the LimeSDRplatform, as well.

48

0.0 0.5 1.0 1.5 2.0

t/ms

-5

0

5

10

15

20

(r~

D⇤ N

PSS)(t)

High-Rate Correlator Output LimeSDR

Real

Imag

0.0 0.5 1.0 1.5 2.0

t/ms

-5

0

5

10

15

20

(r~

D⇤ N

PSS)(t)

High-Rate Correlator Output USRP

Real

Imag

Figure 4.16: Comparison of high-rate correlator output between LimeSDR (left) and USRP (right). Itis not possible with the current implementation to synchronize on the NB-IoT signal with the LimeSDRinvolved as receiver and/or transmitter. The reason can be seen in this figure: Too high noise and noevident peak indicating the frame start.

Figure 4.17: Analog FM radio with fC = 434MHz testing simultaneous transmission and reception.Audio makes it easier to detect if something went wrong. The LimeSDR scored very well with simplerapplications, so with a bit more e↵ort it is believed NB-IoT will be able to run on it especially asMyriadRF demonstrated a LTE base station with it.

49

5 | Related Work

[17] presents a LTE receiver framework, which has heavily influenced this work, especially on the receiverside (cf. 3.3). As underlying SDR framework for their research GNU Radio has been chosen, too.Since LTE and NB-IoT are by design intentionally very similar (which is for instance pointed out in [39])and the source code of this project is publicly available (cf. [40]), this OOT module has been a veryhelpful reference. The framework comprises specific LTE baseband functionality wrapped into blocksto be easily reconfigurable. The authors claim, that the code can be used to decode arbitrary channelsof the LTE downlink. In their work the profiling tool Valgrind facilitates looking for bottlenecks inthe implementation. The results of [17] mainly focus on performance analysis and optimization. Foroptimization code was refactored making heavy use of VOLK. Among other things, their work describes,that having a longer FFT size decreases the number of CPU cycles needed for the same algorithm. Thepaper leaves this result uncommented. According to what the research, described in this document hasfound out, this observation can be explained with a higher scheduler overhead (cf. 4). Moreover, digginga bit deeper into one of the theses related with [17], available in [40], it leaps to the eye, that the SNRworking with an actual LTE signal in their lab has about (12 dB), which is similar to the results of thiswork (cf. 4). In [41] it is also stated, that the complete processing of 10 s LTE signal takes about 35 s.Moreover, it says, that the experimental measurements where carried out using an USRP B210.

[42] describes an approach to implement parts of NB-IoT, which, too, utilizes the parallels between NB-IoT and LTE. They present their implementation based on srsLTE [43], carry out a performance study andreport their experiences with one of the first worldwide commercial NB-IoT deployments. The authorswrite about their e↵orts to implement all DL and UL channels and signals of the NB-IoT standard, whichare relevant for their tests (PHY layer only). Their code is integrated into the srsLTE library, whichis under GNU A↵ero General Public License. A NB-IoT example application for the Evolved Node B(eNodeB) and for the UE have become part of the library. srsLTE is dependent on VOLK, however, noton GNU Radio (cf. [44]). Software Radio Systems Ltd., the company behind the srsLTE project andthe NB-IoT extension of it, even claims, that the library has been tested together with low-cost hardwaresuch as the LimeSDR. As depicted in 4.4, the tests carried out within this work indicate, that there areissues with the LimeSDR at least when combining it with the NB-IoT implementation described in thiswork. In [42] the main results are, that the theoretical DL speed of 226 kbit/s is not achievable in practice,instead 32.38 kbit/s with acknowledgements is the outcome of their measurements. Similarly, the authorssee 68 kbit/s as a realistic upper boundary for UL. Latency is not evaluated. srsLTE is implemented inC for GPPs. Nevertheless, in [42] the topics of c-RAN or Multi Radio Access Technology (Multi-RAT)are not covered.

[7] is definitely one of the earliest publications talking about c-RAN realization of NB-IoT. It is pointedout in the article, that a limited set of NB-IoT features is implemented and the implementation focuseson the lower layers of the protocol. In the LTE UL the synchronous Hybrid Automatic Repeat Request(HARQ) architecture requires, that the eNodeB answers exactly after 4ms in the fourth subframe. Theauthors of [7] acknowledge, that a deployment of a software-based implementation in a cloud for LTE isnowadays impossible to realize due to the delay introduced by the fronthaul. In contrast, the NB-IoTHARQ is meant to be asynchronous. At any time later than 4ms the UE awaits an acknowledgement.eNodeB signals the acknowledgement or negative acknowledgement with the New Data Indicator (NDI)in the Downlink Control Information (DCI) within the next uplink grant. Their NB-IoT protocol stackis implemented in C++. Presumably, GNU Radio is the framework leveraged in their work, too. Theauthors state, that their C++ implementation is suitable to be executed on a cloud server, but, they donot go deeper into how to actually solve problems occurring with a c-RAN implementation. For instance,they mention, that a 20MHz carrier, 4x4 antenna configuration, and 32-bit I/Q sample precision requires7.9Gbit/s. It is economically not reasonable to transport such data streams over a commercial RAN.Unlike [7], this work, tries to detect and address a couple of unsolved problems related with c-RANe.g. baseband compression. Although, a setup with actual hardware is mentioned, the results seem tobe derived from simulations with very simple channel models. The c-RAN, presented in their researchconsists out of a standard personal computer, a USRP-X310 and the USRP UBX-160 as RF daughterboard. The fronthaul is with this approach not customizable. The main result presented in [7] is, that

50

the coverage is limited by the coherence time of a fast fading channel, they are making use of. Theyconclude, that the SNR gain from repetitions is decreased by 10 dB due to the fast fading channel.However, the authors summarize, that with an ideal static channel an UL coverage improvement of 20 dBcan be achieved with 128 repetitions.

51

6 | Conclusion

In summary, a proof of concept testbed has been built up. It supports NB-IoT, but the implementationis not yet fully standard compliant. The testbed subsumes

A GNU Radio OOT module with all software and Q/A testing.

A software to measure USB data rates with the help of the Linux kernel.

A Dockerfile to build an image, which allows to execute the SDR apps.

A GNU Radio OOT module for HW linkage with the LimeSDR.

The NB-IoT receiver comprises algorithms for time and frequency synchronization (4.1.1), OFDM demod-ulation, equalization, decoding and higher layer testing functionalities. Correspondingly, the basebandsignal includes NPSS (2.1.4) and NRS (2.1.5). Moreover, all OFDM operations are functional and higherlayer functionalities have been written to test as well as to demonstrate the system. A couple of con-tributions to GNU Radio have been made. A Pull Request (PR) to the master branch exists only fora few of those. The File Filter Taps block with the underlying File Taps Loader has been introducedto ease the e↵ort of importing taps into GNU Radio. Also, a versatile Correlator and a block to dodemultiplexing have been implemented. Furthermore, the OFDM Cyclic Prefixer has been changed tomake di↵erent CP lengths possible. On the one hand, contributions to GNU Radio are proficient, sincethe own implementation or fork do not diverge when everything finally ends up in the master branch.On the other hand, not all changes are accepted or they need to be refactored a lot. GNU Radio code ishighly portable and far behind concerning C++ and Python standard revision. So it can take a longtime until the changes are patched into the software package, that ships with ones favorite Linux flavor.Hence, to work with fresh mods, required by this project, GNU Radio needs to be compiled from a fork,that uses one branch for each change. This is another reason why a Docker image is very handy.

Also, a baseband compression algorithm for fronthauling has been introduced in this work. Althoughit is not yet methodologically sound, the principle definitely works. A compression ratio of 5.3:1 canbe achieved by undersampling in the edge transmitter and interpolating, a very trivial task to be donein the radio head. Through measurements it could be proven, that the data rate over the network wasreduced significantly while the data rate over the USB cable stayed the same as expected. The currentimplementation of the algorithm most likely infringes the orthogonality criteria, which leads to mitigationof the systems overall performance. However, in simulation, a SNR of 18.1 dB could be achieved withoutnoise, which is more than enough to demodulate QPSK (more under 4.1.3).

A lot of e↵ort has been put into getting cheaper HW, in particular the LimeSDR, to run. Sadly enough,with the LimeSDR a stable time synchronization failed. Even so, other tests with the board yieldedpromising outcomes and with more expensive HW, namely the USRP B210, satisfying results could beaccomplished (4.4). Without LOS within an o�ce area, in a distance of roughly 65m, a PER of 0.5%and a SNR of 15.9 dB could be achieved (4.3).

52

7 | Outlook

This master thesis started from scratch concerning the NB-IoT implementation, SDR HW, a compressionalgorithm suitable for this NB-IoT implementation and Docker experiences. It will be way easier to buildup further research on top of this thesis. There is HW, that has proven to work, literature has been soughtand evaluated. A testbed, ready to interact with and extend, exists. A Docker image takes away thehassle of setting up a development environment and allows to dive directly into the gorgeous pleasure ofwriting code. The question is not anymore ”What is possible?”, but ”What has to be done?”. What hasto be done is actually further developing the NB-IoT implementation. Most of the DL is implemented,so this needs to be extended and optimized. Also, the UL has not been touched in this work. Therefore,it is definitely part of the next step to implement the UL. The implementation needs to be optimized onlatency. Some investigations should be carried out on how to tweak GNU Radio to reduce delays. Thefronthaul compression algorithm has to be brought up to the level of maturity to be patented and shippedto customers. When it comes to Docker one needs to think of a concept which allows to dynamicallyallocate resources in this context. How is this for instance possible sharing one USRP B210?

53

Bibliography

[1] J. Scott and D. Spaniel, Rise of the machines: The dyn attack was just a practice run. CreateSpaceIndependent Publishing Platform, 2016, isbn: 1540894576.

[2] Lockpicking in the iot, 2016. [Online]. Available: https://www.youtube.com/watch?v=ix_Fw75kKb8.

[3] R. Kohn, Konzerne verbunden sich gegen hacker, 2018. [Online]. Available: http://www.faz.net/aktuell/wirtschaft/diginomics/grosse-internationale-allianz-gegen-cyber-attacken-

15451953-p2.html?printPagedArticle=true#pageIndex_1.

[4] Nokia, Is sigfox/lora the new wimax? 2015. [Online]. Available: https://www.nokia.com/en_int/blog/is-sigfoxlora-the-new-wimax.

[5] O. Liberg, M. Sundberg, E. Wang, J. Bergman, and J. Sachs, Cellular internet of things: Technolo-gies, standards, and performance. Academic Press, 2017, isbn: 012812458X.

[6] MediaTek, Dual mode nb-iot, gsm/gprs platform for smart trackers, wearables, iot security andindustrial applications, 2018. [Online]. Available: https://www.mediatek.com/products/nbIot/mt2621.

[7] Yihenew Dagne Beyene et al., “Nb-iot technology overview and experience from cloud-ran imple-mentation,” Jun. 2017.

[8] Free Software Foundation (FSF), Gnu radio, 2018. [Online]. Available: https://www.gnuradio.org/.

[9] S. Landstrom, J. Bergstrom, E. Westerberg, and D. Hammarwall, Nb-iot: A sustainable technologyfor connecting billions of devices, 2016. [Online]. Available: https://www.ericsson.com/en/ericsson- technology- review/archive/2016/nb- iot- a- sustainable- technology- for-

connecting-billions-of-devices.

[10] P. Eric Wang et al., “A primer on 3gpp narrowband internet of things (nb-iot),” vol. 55, Jun. 2016.

[11] 3gpp ts 36.211 physical channels and modulation, English, 650 Route des Lucioles - Sophia Antipo-lis Valbonne - FRANC: 3rd Generation Partnership Project, 2017. [Online]. Available: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=

2425.

[12] J. Goebel, “Multiplexverfahren,” Duale Hochschule Baden-Wurttemberg Ravensburg, Campus Friedrichshafen,Vorlesungsarbeitsblatter Ubertragungstechnik, 2016.

[13] E. Dahlman, S. Parkvall, and J. Skold, 4g: Lte/lte-advanced for mobile broadband, second. AcademicPress is an imprint of Elsevier, 2014.

[14] H. G. Myung, “Introduction to single carrier fdma,” in 15th European Signal Processing Conference(EUSIPCO 2007), 2007.

[15] S. B. Weinstein, “History of communications, introduction to the history of ofdm,” IEEE Commu-nications Magazine, M. Schwartz, Ed., 2009.

[16] Zado↵-chu sequence, 2018. [Online]. Available: https://en.wikipedia.org/wiki/Zadoff%E2%80%93Chu_sequence.

[17] J. Demel, S. Koslowski, and F. K. Jondral, “A lte receiver framework using gnu radio,” vol. 78,Jan. 2015.

[18] Y. Yu and Q. Zhu, “A novel time synchronization for 3gpp lte cell search,” pp. 1–4, Sep. 2012.

[19] A. Ali and W. Hamouda, “On the cell search and initial synchronization for nb-iot lte systems,”pp. 1–4, 2017.

[20] Swig, 2018. [Online]. Available: http://swig.org/.

[21] Volk, 2018. [Online]. Available: http://libvolk.org/.

[22] Docker, 2018. [Online]. Available: https://docker.com.

XIII

[23] A. Gopalasingham, D. G. Herculea, C. S. Chen, and L. Roullet, “Virtualization of radio accessnetwork by virtual machine and docker: Practice and performance analysis,” in 2017 IFIP/IEEESymposium on Integrated Network and Service Management (IM), 2017, pp. 680–685.

[24] Gnu radio 3.7.10.1 manual, 2018. [Online]. Available: https://www.gnuradio.org/doc/doxygen/.

[25] Myriad-rf, 2018. [Online]. Available: https://myriadrf.org/.

[26] Soapysdr, 2018. [Online]. Available: https://github.com/pothosware/SoapySDR/wiki.

[27] Osmocom gnu radio blocks, 2018. [Online]. Available: https://osmocom.org/projects/gr-osmosdr/wiki/GrOsmoSDR.

[28] Pimpl, 2018. [Online]. Available: https://en.cppreference.com/w/cpp/language/pimpl.

[29] Stack Overflow, Small logger class, 2018. [Online]. Available: https : / / stackoverflow . com /questions/5028302/small-logger-class#5028917.

[30] S. Huang, Y. Su, Y. He, and S. Tang, “Joint time and frequency o↵set estimation in lte downlink,”pp. 1–5, 2012.

[31] M. Borgerding, “Turning overlap-save into a multiband mixing, downsampling filter bank,” pp. 1–7,Mar. 2006.

[32] S. W. Smith, The scientist & engineer’s guide to digital signal processing. California Technical Pub,1997, isbn: 0966017633.

[33] ttk592, C++ cubic spline library, 2016. [Online]. Available: https://github.com/ttk592/spline.

[34] SciPy community, Numpy.correlate, 2018. [Online]. Available: https://docs.scipy.org/doc/numpy/reference/generated/numpy.correlate.html.

[35] C. Hardy, The basics of tuning pid loops, 2014. [Online]. Available: https://www.crossco.com/blog/basics-tuning-pid-loops.

[36] M. Brain, C. Tinelli, P. Rummer, and T. Wahl, “An automatable formal semantics for ieee-754floating-point arithmetic,” pp. 160–167, Jun. 2015.

[37] T. F. Collins, R. Getz, D. Pu, and A. M. Wyglinski, Software-defined radio for engineers. AnalogDevices, 2018.

[38] Free Software Foundation (FSF), Gnu radio manual and c++ api reference documentation, 2018.[Online]. Available: https://www.gnuradio.org/doc/doxygen.

[39] Rohde & Schwarz, Narrowband internet of things - whitepaper, 2016. [Online]. Available: https://www.rohde-schwarz.com/de/applikationen/schmalbandiges-internet-der-dinge-white-

paper_230854-314242.html.

[40] Communication Engineering Lab (CEL) at the Karlsruhe Institute of Technology (KIT), Germany,Gnu radio lte receiver, 2018. [Online]. Available: https://github.com/kit-cel/gr-lte.

[41] K. Maier, “Synchronisation eines lte-empfangers mit mehreren empfangsantennen,” Karlsruhe In-stitute of Technology, Communications Engineering Lab, Tech. Rep., Oct. 2014, bachelor’s thesis.

[42] A. Puschmann, P. Sutton, and I. Gomez, “Implementing nb-iot in software - experiences using thesrslte library,” May 2017.

[43] S. R. S. Ltd., Srslte, 2018. [Online]. Available: https://github.com/srsLTE/srsLTE.

[44] I. Gomez-Miguelez, A. Garcia-Saavedra, P. D. Sutton, P. Serrano, C. Cano, and D. J. Leith, “Srslte:An open-source platform for lte evolution and experimentation,” Feb. 2016.

A | Python Script to Parse iftop

Output

1 #!/usr/bin/python

2

3 import sys, getopt, csv4

5 class iftop_parser:6

7 def __init__(self, fname, edge_ip, radiohead_ip):8 self.fname = fname9 self.edge_ip = edge_ip

10 self.radiohead_ip = radiohead_ip11 self.lines = self.read_file(fname)12

13 def read_file(self, fname):14 return [line.rstrip('\n') for line in open(self.fname)]15

16 def get_data(self, ip):17 clean = []18 for line in self.lines:19 clean_row = []20 if ip in line:21 splt=line.split(" ")22 splt_len=len(splt)23 for i in range(splt_len-1):24 if splt[i] != '' and 'B' in splt[i]:25 suff=splt[i].find("GB")26 mult=1e927 while suff == -1:28 mult /= 1e329 if mult == 1e6:30 suff=splt[i].find("MB")31 elif mult == 1e3:32 suff=splt[i].find("KB")33 elif mult == 1:34 suff=splt[i].find("B")35 rate_str=splt[i][:suff].replace(',','.')36 rate_float=float(rate_str)*mult37 clean_row.append(rate_float)38 clean.append(clean_row)39 return clean40

41 def dump_to_csv(self, clean, index, fname):42 with open(fname, 'wb') as f:43 wr = csv.writer(f)44 cnt = 045 for c in clean:46 row = []47 row.append(c[index])48 cnt += 249 row.append(cnt)50 wr.writerow(row)51

52 def main(argv):53 edge_ip = ""54 radiohead_ip = ""55 fname = ""56 help_msg = argv[0] + " -e <edge_ip> -r <radiohead_ip> -f <file>"57 try:58 opts, args = getopt.getopt(argv[1:],"he:r:f:",["edge=","radiohead=","file="])59 except getopt.GetoptError:60 print help_msg61 sys.exit(2)62 for opt, arg in opts:63 if opt == '-h':

XV

64 print help_msg65 sys.exit(0)66 elif opt in ("-e", "--edge"):67 edge_ip = arg68 elif opt in ("-r", "--radiohead"):69 radiohead_ip = arg70 elif opt in ("-f", "--file"):71 fname = arg72 p = iftop_parser(fname, edge_ip, radiohead_ip)73 edge_clean = p.get_data(edge_ip)74 print edge_clean75 p.dump_to_csv(edge_clean, 0, "iftop_edge_datarate.csv")76 radiohead_clean = p.get_data(radiohead_ip)77 print radiohead_clean78 p.dump_to_csv(radiohead_clean, 0, "iftop_radiohead_datarate.csv")79

80 if __name__ == "__main__":81 main(sys.argv[0:])

B | Send Dynamic IP Address withTelegram Bot

1 #!/bin/sh

2 #################################################################

3 # Script to send the IP address of a host to you using a

4 # Telegram bot. This script also adds a cron job, so that the

5 # bot nofifies you with every boot.

6 #

7 # Author: Maximilian Stiefel

8 # Last modified: 26. April 2018

9 # CLI usage: ./send_telegram_dynamic_ip bot chat

10 # Required PKGs: curl

11 #################################################################

12

13 #################################################################

14 # Vars

15 #################################################################

16 HOST=$(hostname)17 FILE=`realpath $0`18 NU_PARAMS=219

20 #################################################################

21 # Action

22 #################################################################

23 # Check if the expected number of parameters is given.

24 if [ $# != $NU_PARAMS ]25 then26 echo "Error: Illegal number of parameters."27 exit 1;28 fi29 # Get bot token and chat id.

30 BOT=$131 CHAT_ID=$232 URL="https://api.telegram.org/bot$BOT/sendMessage"33 ENTRY="@reboot $FILE $BOT $CHAT_ID"34 # Wait until we are online.

35 while ! wget -q --spider http://google.com ; do true; done36 # Get private IP.

37 CURRENT_IP=$(ip addr | grep 'state UP' -A2 | tail -n1 | awk '{print $2}' | cut -f1 -d'/')38 MESSAGE="Hej! Ha en trevlig dag. IP adressen av $HOST ar $CURRENT_IP."39 # Instruct bot.

40 curl -s -X POST $URL -d chat_id=$CHAT_ID -d text="$MESSAGE" > /dev/null41 echo "Message sent."42 # Grep returns zero if entry is found.

43 if ! crontab -l | grep -q "$ENTRY" ; then44 crontab -l > cron45 echo "$ENTRY" >> cron46 crontab cron47 rm cron48 echo "Added $ENTRY"49 echo "to crontab."50 else51 echo "Crontab entry $ENTRY"52 echo "already exists."53 fi54 exit 0;

XVII

C | Edge

Figure C.1: Inside the hierarchical edge block.

XVIII

D | Radio Head

Figure D.1: Radio head app.

Figure D.2: Radio head app with interpolation algorithm, which was suggested in this work.

XIX

E | Receiver

Figure E.1: Inside the hierarchical receiver block.

XX

F | Measurement Locations

Figure F.1: Photos of the locations where the measurements in the random Ericsson o�ce cube havebeen carrierd out.

XXI

G | Lime Microsystems LMS7002M

Figure G.1: Functional block diagram of the Lime microsystems LMS7002M.

XXII