1

Electrosense: Open and Big Spectrum DataSreeraj Rajendran∗‡‡, Roberto Calvo-Palomino‡‡¶§, Markus Fuchs‡, Bertold Van den Bergh∗,

Hector Cordobes¶, Domenico Giustiniano¶, Sofie Pollin∗ and Vincent Lenders�

Email: {bertold.vandenbergh, sreeraj.rajendran, sofie.pollin}@esat.kuleuven.be{domenico.giustiniano, hector.cordobes, roberto.calvo}@imdea.org

fuchs@sero-systems.de, vincent.lenders@armasuisse.ch.∗Department ESAT, KU Leuven, Belgium, ¶IMDEA Networks Institute, Madrid, Spain,

‡SeRo Systems, Germany, §Universidad Carlos III of Madrid, Spain, �armasuisse, Thun, Switzerland.

Abstract—While the radio spectrum allocation is well regu-lated, there is little knowledge about its actual utilization overtime and space. This limitation hinders taking effective actionsin various applications including cognitive radios, electrosmogmonitoring, and law enforcement. We introduce Electrosense, aninitiative that seeks a more efficient, safe and reliable monitoringof the electromagnetic space by improving the accessibility ofspectrum data for the general public. A collaborative spectrummonitoring network is designed that monitors the spectrum atlarge scale with low-cost spectrum sensing nodes. The large setof data is stored and processed in a big data architecture andprovided back to the community with an open spectrum data asa service model, that allows users to build diverse and novelapplications with different requirements. We illustrate usefulusage scenarios of the Electrosense data.

Index Terms—Spectrum Sensing, Embedded System, SignalProcessing, Distributed System, Big Data Architecture

I. INTRODUCTION

Over the past years, we have seen a tremendous increasein mobile data usage. To meet the data demands, more radiofrequency (RF) bands are being used, cells become smaller,data rates increase and more users accommodated. In addition,novel technologies are being proposed that can coexist withlegacy technology and modulation types, and short and longrange Internet-of-Things (IoT) communications increase thevariety of physical and medium access protocols connectedto the Internet. As a result, RF spectrum use is fragmented,bursty and very diverse. The monitoring of this spectrum isa complex task, as it requires a very dense sampling in time,frequency and space, resulting in a radio spectrum data deluge.Nevertheless, with the increasing spectrum usage complexity,knowledge and understanding of the spectrum usage patterns isbecoming more and more critical to ensure continued effectiveuse of this scarce resource.

Spectrum resource monitoring is important for end users,operators, spectrum regulatory bodies and also military appli-cations. Each use case has its own specific needs and chal-lenges. The grand challenge is how to design a cost-effectivesolution that meets the requirements of all potential end users.Users might be interested in electrosmog or optimizationof their indoor WiFi network. Regulatory bodies might bekeen on enforcing spectrum regulation. Operators might beconcerned about coverage maps over time for optimizing their

‡‡Equal contributors

Fig. 1: High-level overview of the Electrosense network: Low-cost sensorscollect spectrum information which are sent to the Electrosense backend.

Different algorithms are run on the collected information in the backend andthe results of these algorithms are provided to the users as a service throughan open API. Users can develop their own applications from the spectrum

information retrieved using the API.

cell networks or refarming of their frequency bands. Militaryapplications might be the most challenging, requiring thedetection and positioning of any signal hidden on purpose.Novel operators might be interested in IoT cases, such ascooperative detection of signals transmitted by low-cost low-power transceivers. This paper looks at one key aspect: is itpossible to design a spectrum sensing network that meets allthe aforementioned requirements and can be deployed quicklyby synergistic cooperation between all stakeholders?

Even though a majority of wireless researchers, industriesand spectral regulators are keen to develop a worldwidespectrum monitoring infrastructure, albeit several attempts, theresearch community has not succeeded in deploying one. Themultidisciplinary nature of the spectrum monitoring solutionis one of the main challenges that prevents the realization ofsuch a system, which in turn requires proper integration ofnew disruptive technologies. The infrastructure should flexiblyaddress the variability and cost of the used sensors, large

2

spectrum data management, sensor reliability, security andprivacy concerns, which can also target a wide variety of theuse cases as mentioned before.

A few spectrum monitoring solutions are proposed in theliterature. Some examples include, Microsoft Spectrum Ob-servatory1 that allows to sense the spectrum using expensivesensors, Google spectrum2 for measurements on TV white-spaces and the IBM Horizon3 project that proposed a genericdecentralized architecture to share IoT data. While GoogleSpectrum and Blue Horizon fail to cover a large part ofthe spectrum as they are application specific deployments,Microsoft observatory on the other hand fails to enable a largescale sensor deployment mainly due to the cost of the sensingstations.

We introduce and design Electrosense4. Electrosense fol-lows the crowdsourcing paradigm to collect and analyzespectrum data using low-cost sensors as main device forsensing the spectrum. The main goal of this initiative, asshown in Figure 1, is to sense the whole spectrum in differentregions of the world and provide the processed spectrumdata to any user interested to acquire a deeper knowledgeof the spectrum usage, enabling applications as the onesmentioned above [1,2]. Worldwide deployments are plausiblewhen the crowdsourcing paradigm is combined with low costsensors. Electrosense sensors are designed using inexpensiveand easily accessible software-defined radio (SDR) front-endsand embedded platforms like Raspberry Pi, to reduce the costthat spectrum data contributors have to bear. A low-cost down-converter design5 is also provided to extend the range of thelow-end SDR platforms from 1.7 GHz to 6 GHz. Even thoughthe aim of the Electrosense project is to use low-cost hardware,high-end SDR devices can also be part of the network. Opensource software modules for low- and high-end sensors areprovided by Electrosense for easy setup6.

Crowdsourcing initiatives have been successfully appliedin other sensing contexts, for example, distributed sensornetworks collecting information about temperature, air quality,pollution or air traffic are now in widespread use today. Yet, theradio spectrum data collection poses novel challenges becauseof the sheer volume of information in the spectrum, whichis several orders of magnitude higher than the data collectedin typical sensing contexts as mentioned above. The amountof data produced by a single sensor typically varies between50 Kb/s and 50 Mb/s depending on the sensor platform andconfiguration. Storing spectrum data received from each sensorcan swiftly get any server machine out of storage space, forinstance data from 60 sensors for a single month needs astorage space of 1 terabyte in 50 Kb/s mode. In order tohandle this large volume of data in the backend and extractmeaningful information over the entire spectrum, a flexiblebig data architecture is designed. This spectrum managementarchitecture is responsible for the sensors’ control, data stor-

1http://observatory.microsoftspectrum.com/2https://www.google.com/get/spectrumdatabase/3https://bluehorizon.network/documentation/sdr-radio-spectrum-analysis4https://electrosense.org/5https://github.com/electrosense/hardware6https://github.com/electrosense

age, and algorithm deployment in the back-end for furtherprocessing.

Electrosense also includes a complete framework for iden-tifying, locating and deploying sensors securely through aconsistent registration process and remote control frameworkof the sensors. The sensed spectrum data from different sensorscan be retrieved from the electrosense backend using an openAPI7 over the Internet. Data privacy concerns are addressed byenabling public, private and restricted data access permissionswhich restrict user data access with suitable time resolutions.Readily available spectrum aggregation tools in the back-endhelp the network users, to do easy spectrum data analysis asan additional incentive. The data access permissions and otherapplications are detailed in Section II and Section IV of thispaper.

The rest of the paper is organized as follows. A briefoverview of the service model and the open API are presentedin Section II. Section III defines Electrosense system designconsiderations and the final architecture. Section IV detailsthe spectrum data analysis tools and applications. Finally,conclusions and future work are presented in Section V.

II. SPECTRUM DATA AS A SERVICE

A. Service Model

In order to make the most out of the data, we introducean Open Spectrum Data as a Service (OSDaaS) model inwhich the spectrum data can be used by several applications,each of them with unique requirements. This approach differsfrom a classical “Infrastructure as a Service” model used inother contexts where different applications cannot run at thesame time due to conflicting requirements. The spectrum datainherently changes over time and thus allocating the nodeto a specific application would reduce the information andthe interest of several users interested in the same spectrumdata. Therefore, the current framework prevents the users fromlaunching their own measurement campaigns as they onlyneed to access gathered data from one of the two pipelinesof the sensor: PSD (Power Spectral Density) and IQ (in-phaseand quadrature components of raw signals). In contrast, theflexibility of the OSDaaS model is an incentive to join anduse the network and an opportunity for a wide engagementand participation of citizens. In addition, the spectrum datagathered in the past can be re-processed with a new appli-cation in mind or new spectrum data can be compared witholder spectrum data. Users can join the Electrosense networkeasily by adding their own sensor through the web interface8.Specifics about the sensor such as antenna details and sensorlocation can be specified during the registration process. Thesensor status and location are readily visible in a global sensormap once it is registered.

B. Application Programming Interface (API)

Alongside with data processing, it is important to providethe community with easy access to the data. An open API

7https://electrosense.org/open-api-spec.html8https://electrosense.org/join.html

3

serves this purpose for bulk or streaming data retrieval. TheAPI also allows access to the algorithms’ output running in thebackend, for example results of the modulation classificationalgorithms or the anomaly detector. Electrosense users canretrieve magnitude data along with the sensor details usingthe API. The API allows two data retrieval modes: aggregatedand raw Fast Fourier Transform (FFT) data. Aggregated querytype allows the user to request for a bulk of data with specifiedfrequency and time resolutions, after applying a predefinedaggregation function such as averaging or max-value. Rawrequests permit to retrieve magnitude FFT data acquired bya sensor as such without any modifications. Raw FFT datafrom a sensor can be accessed only by its owner. In addition,as shown in Figure 3, there is an IQ data pipeline which isenabled on demand for data testing or for algorithms that workon IQ data in the backend. The IQ data from a sensor is onlydirectly available to its owner through the API, but conclusionsfrom algorithms related to IQ data will be made available to allusers. Furthermore, real-time spectrum monitoring is possiblethrough a streaming API in the backend. A few examples fordata retrieval can be found in the repository9.

C. Security and Privacy

Wideband spectrum monitoring on a large scale typicallyraises critical security and privacy concerns. Security concernsinclude secure data transmissions from the sensor and propersensor identification. Data privacy concerns in terms of dataaccess restrictions should also be addressed. In addition,capture and storage of IQ data, which can be decoded toreveal content, is not advisable especially in the military bands.Electrosense’s design addresses sensor identification via aproper registration process. The data from Electrosense sensorsare sent over secure TLS channels which guarantees dataprivacy and integrity and prevents the data getting modifiedby an attacker. The IQ pipeline is only accessible by theElectrosense backend and the data is deleted once the backendalgorithms are done processing it. In addition, IQ data is onlymade available to the users for their own sensors through theAPI. Furthermore, the highest time and frequency resolutionthat users can get from other sensors over the API are limitedto 60 seconds and 100 kHz respectively. Electrosense alsoallows to obfuscate sensor’s publicly displayed location withina range of a few kilometers in the sensor map, thus protectingusers’ locational privacy.

III. SYSTEM ARCHITECTURE

Electrosense was designed with a clear vision in mind thattranslates into a list of design goals as described below. Wepresent the actual architecture chosen to meet these require-ments and give a more detailed explanation of its components.

A. Design Goals and Electrosense Vision

Electrosense is a crowdsourcing approach towards spectrummonitoring where volunteers play a central role. To keep theentry barrier as low as possible, large-scale deployment can

9https://github.com/electrosense/api-examples

Fig. 2: [Left] Sensor based on a single-board computer (RPi-2) and RFfront-end (RTL-SDR) device responsible for signal acquisition. [Right] Firstprototype of custom RF converter to enable spectrum scanning in 0-6 GHz

range.

only be achieved with low-cost sensors. The backend shouldbe flexible, to enable wide-band monitoring from sweepinglow-end sensors, to real-time scanning with more capableSDR platforms or spectrum analyzers. In addition, the backendshould be horizontally scalable, enabling to grow the networkcontinuously. Scalability introduces even more complexity intothe system, which makes it prone to failures. As such, thearchitecture must also be fault-tolerant. Finally, the backendshould be able to process a large amount of data from anysensor with low latency.

With its main goal to serve researchers as a platform forspectrum analysis, the system should have a central componentto control the sensors for specific measurement campaigns.Some applications might need to give immediate responsewhile others generate insights by inspecting the data set asa whole. Following these requirements, the system shouldsupport low-latency stream processing and large-scale batchanalyses at the same time.

In order to address these goals and requirements, the Elec-trosense architecture consists of three main components: (i) thesensors deployed by users collecting spectrum measurements,(ii) a centralized controller infrastructure to interact with thesensors and to administrate measurement campaigns and (iii)the backend which is responsible for collecting data from allthe sensors and provide insights by applying algorithms. Thefollowing subsections describe these components in detail.

B. Sensor

The sensing nodes used in the Electrosense network consistof small-sized, low-cost, software-defined embedded comput-ing devices connected to a simplistic RF front-end and ageneral purpose antenna [3] as shown in Figure 2 (left). Thesensors can measure the spectrum ranging from 20 MHzup to 6 GHz using an optional down-converter (Figure 2right). The sensors include an optional low-cost GPS deviceto synchronize the time among them which in turn helpsin enabling collaborative spectrum scanning and detectionalgorithms. For instance, in [1] the feasibility to recombinesignals collaboratively from different sensors, using GPS as areference clock, is analyzed in detail.

Two signal pre-processing pipelines are enabled on thesensor as illustrated in Figure 3. Each sensor can be configuredin order to work with both PSD or IQ pipeline. When the

4

Sampling

PSD pipeline

IQ pipelineSDR

SamplingWindowing FFT Averaging Compression Transmission

SENSOR BACKEND

PermanentStorage

TemporalStorage

Compression Transmission

GPS

CONTROLLER

Fig. 3: Sensor architecture: Sensor software contains two different pipelinesfor retrieving spectrum information.

sensor is configured in the PSD mode, the spectrum sensed bythe RF front-end is converted to the frequency domain using aFast Fourier Transform (FFT). In this mode only the averagedsquared magnitude FFTs are sent to the backend. Dependingon the averaging and compression factors, the produced datais in the order of 50-100 Kb/s. This pipeline saves bandwidthand storage over the IQ pipeline and thus contributes to thecost-efficiency of the whole network. In addition, the on-boardGPU on the Raspberry Pi is used for computing FFTs, reduc-ing the processing time. The PSD mode aids spectrum dataretrieval using a restricted network bandwidth which enablesapplications where phase information is not crucial to analyzedata in terms of signal power (Section IV-B). In addition, wide-band scanning techniques are applied that prioritize frequencybands of bursty activities over bands which are stationary [3]to overcome the hardware-limitations of low-cost radios, forinstance the limited sampling bandwidth of the low-end ADCs(e.g 2.4 MHz for RTL-SDR).

For applications which require phase and non-averagedinformation, the sensor implements an IQ pipeline. The IQmode retrieves raw measurements (IQ samples) from the RFfront-end that are then compressed and sent to the backend.This pipeline easily produces up to 50 Mb/s and hence the datais only stored temporarily in the backend. Besides spectrummeasurements in both pipelines, the sensor also providestiming information together with RF-specific values such asantenna gain. The data structure used to transport results overthe Internet is flexible and can be extended in the future.

The software that runs in the electrosense nodes is releasedas open source10. In addition to this, a GNU Radio basedsoftware module, gr-electrosense11, is provided to allow high-end SDR users to be a part of the Electrosense network.

C. Controller

Apart from continuous wide-band monitoring, it is inter-esting to have a more detailed look at particular parts ofthe frequency spectrum. This is accomplished with the helpof a command-and-control layer as depicted in Figure 4. Inorder to start and control such in-depth measurements, thecontroller communicates with sensors directly and influencestheir scanning strategy, some examples include, the frequencyrange the sensor should scan, the sensor frequency hoppingstrategy or the sensor sampling rate.

The core of the controller infrastructure is a Message QueueTelemetry Transport (MQTT) broker system which consists

10https://github.com/electrosense/es-sensor11https://github.com/electrosense/gr-electrosensexamplese

of a set of several independent machines forming a cluster.This ensures scalability and fault-tolerance in case of a hard-ware failure. MQTT is a publish-subscribe-based messagingprotocol and has a wide adoption in IoT applications [4].The brokers have a permanent connection to the sensors oversecure TLS channels as well as to a machine called mastercontroller. The master offers an interface where administratorscan start and stop measurement campaigns. It is responsiblefor executing these commands on different sensors using theMQTT connection. Spectrum measurements collected by thesensors are passed to the backend over secure TLS channelsas shown in Figure 4. The control layer is a part of theElectrosense backend and works in a closed loop with thedata processing path for easy response validation.

D. Backend

All data collected by the sensors is sent to the backend. Inorder to fulfill the design goals, in particular scalability, thesystem is built upon a Lambda architecture [5] with exclu-sively horizontally scalable system components. The Lambdaarchitecture is a three-layered architecture consisting of batch,speed and serving layer. An overview of the whole backendarchitecture can be found in Figure 4. The batch layer isresponsible for executing bulk analysis tasks on large data sets.These tasks, mostly involve complex long-running algorithms,whose results might take several minutes to hours to complete.To overcome this gap and, furthermore, provide the capabilityfor real-time monitoring with sub-second delay, there is theneed for a speed layer. It is possible to run different or identicalapplications on each of these layers simultaneously.

In addition, the Electrosense backend has an ingestionlayer to support high availability. It consists of a distributedmessage queue that stores multiple replicas of each incomingmeasurement. Implementation and functionality of each layeris detailed in the subsequent sections.

1) Ingestion Layer: Sensor measurements eventually reachthe collector as shown in Figure 4. The collector insertsreceived data as messages into a distributed queuing system.Using a distributed queuing system, we decouple data inges-tion from processing in the batch and speed layer, allowingan asynchronous mode of operation. Furthermore, the inges-tion layer serves as a intermediate buffer for incoming data,allowing maintenance of batch and speed layers without dataloss. Apache Kafka [6], a distributed messaging system whichfeatures replication, partitioning and data retention is used asthe queuing system. Following the ingestion layer, spectrumdata is processed on two different paths: in batch and speedlayer simultaneously.

2) Batch Layer: The batch layer is responsible for storingall incoming raw data as an immutable master dataset andexecuting long-running workloads. The batch layer facilitatesprocessing of huge amounts of historical data, ensuring noloss of information in case of algorithmic errors. The masterdataset is stored in a binary format on a distributed file system.The Hadoop Distributed File System (HDFS) [7] is employedallowing data to be stored in files which are distributed andreplicated over a cluster of servers. Apache Spark [8], which

5

Backend

MQTT

Speed Layer

Batch LayerIngestion Layer

Serving Layer

TLSSensing Data

SSH server

Database

Collector 1Collector 1Collector 1Kafka BrokerKafka BrokerKafka Broker Spark

SparkStreaming

CLI (Admin)

Browser (User)

HDFS

Cassandra

Impala RES

T A

PI

SensorsSensors

Control Flow

Data Flow

Campaign/SensorStatus

Aggregated & Raw data

MasterController

MQTT

SSHRemote Management

MQTT

CommandMQTT Broker

(Cluster)

Command & Control Layer

SSH

Fig. 4: Sensors are managed by the control layer which sets the scanning parameters for a specific campaign. The configured sensors send the spectruminformation to the backend, where the data is processed and distributed over the API to the users.

allows parallel computation by evenly distributing workloadover several computing nodes, is employed for data processing.For accessing data stored on HDFS, a fast and scalable queryengine Cloudera Impala [9] which understands a subset of theSQL language is deployed. The latency of the batch layer asa whole is in the order of minutes or even hours.

3) Speed Layer: The Electrosense speed layer is based onSpark Streaming. It is an extension of Spark which computesits’ results continuously on a parallel cluster over a smallwindow of recent data, with the current default windowlength set to 5 seconds. Spark Streaming meets the designrequirements as the spectrum data is high in volume andalgorithms do not demand sub-second latency. As Impala isnot suitable for near real-time storage requirements, the speedlayer persists its results in another database. We use ApacheCassandra [10], a hybrid between a key-value and column-oriented distributed storage system for this real-time databaseas it represents well the data structure of spectrum data.

4) Serving Layer: As seen before, the batch and speedlayers store their results differently. The serving layer takescare of data fusion to provide query results to the user whilehiding the complexity of the multi-layer architecture. It offersthe open API which serves as the endpoint for any user orapplication to retrieve data. The serving layer handles querieson different views and combines results from batch and speedlayer if necessary. In case results are available in both layers,batch layer results are preferred as they provide more accuratedata. In Electrosense, the serving layer is a custom componentwhich offers a RESTful web service over HTTP.

IV. SPECTRUM DATA PROCESSING AND ANALYSIS

To substantiate the value of the data generated by theElectrosense framework, a few applications are presented inthis section. We envision some of these applications to beintegrated in Electrosense’s batch and speed layer in thebackend, but the goal of Electrosense is that users can startimplementing their own applications by using the open API.

A. Live and Historical Spectrum Visualization

We have developed a web front-end to enable easy visual-ization of the spectrum data12. The spectrum visualizer allows

12https://electrosense.org/app.html

Madrid (Spain)

400 500 600 700 800

Frequency (MHz)

0

1

2

3Tim

e(h

ours

)-60

-50

-40

-30

-20

Pow

er

(dB

m/b

in)

Trieste (Italy)

400 500 600 700 800

Frequency (MHz)

0

1

2

3Tim

e(h

ours

)

Pow

er

(dB

m/b

in)

-60

-50

-40

-30

-20

Fig. 5: TV band occupancy in Madrid and Trieste.

interactive sensor selection and varying frequency resolutionfor detailed spectrum viewing. The visualization tool allows tolook at historical spectrum data from the sensors, since the sen-sor registration. For this purpose, the batch layer pre-computesspectrum data at various temporal and frequency aggregationlevels and stores this information in queryable tables for low-latency access over the web. For live spectrum updates with 5second delays, a streaming display is incorporated to the webinterface directly from the speed layer.

B. Dynamic Spectrum Access

Dynamic Spectrum Access (DSA) enables a technologymodel to manage spectrum availability and needs in termsof frequency, time, geography, quality and cost of the service.Cooperative and distributed spectrum sensing approaches forcognitive radios can solve hidden primary user problemsand reduce the non-detection probability and false alarmsremarkably [11]. Advanced collaborative sensing strategiesalong with detailed sensor density analysis is required toaddress the complete cognitive cycle. A white space detectionstudy is done to validate the feasibility of the framework inthis direction.

The term white spaces usually refers to the unused broad-casting frequencies in the TV band (400-800 MHz). The

6

availability of white spaces is highly region dependent, forinstance the white spaces in Europe in the 470-790 MHzband is found to be less than in the USA [12]. Using theElectrosense infrastructure and the sensors configured in thePSD pipeline, it is feasible to detect the white spaces in acertain region. Figure 5 shows the spectrum occupancy in thebroadcasting TV band (400-800 MHz) of two different cities inEurope with a frequency resolution of 1 MHz and 60 secondstime resolution. Similar analysis can be easily performed byretrieving the aggregated data from the Electrosense backendthrough the API.

C. Spectrum Cop

Spectrum enforcement is challenging mainly due to theeffort involved in analyzing, detecting and locating anomaliesoccurring in the spectrum. Even with a large scale deploymentof spectrum scanners, the anomaly detection process is de-manding. Automated systems to detect pirate FM stations, fakeGSM towers, unauthorized transmissions hindering normalfunctioning of meteorological radars and even transmissionsat higher power levels than the permitted levels of operationis fundamental for effective enforcement. A good anomalydetector should first detect whether a particular transmissiontype is allowed in the frequency of interest. Moreover, itshould fingerprint normal spectrum transmissions by analyzingthe temporal and spatial features of the transmitters in termsof power levels and spectral occupancy. The former can beachieved to some extent using a modulation classifier and thelater by learning spectral occupancy distributions over time. Adrastic variation of any of the aforementioned features can beclassified as an anomaly.

To validate modulation classification using Electrosense,a time domain deep learning modulation classifier is usedin the backend which works effectively with gr-electrosenseusing the IQ pipeline [13,14]. The deep learning model takesIQ samples as input giving out the probability of the databelonging to a particular modulation class. The model istrained to learn from the modulation schemes’ time domainamplitude and phase information, without requiring expert fea-tures, such as higher order cyclic moments. Analyses show thatthe proposed model yields an average classification accuracyof over 90% at varying SNR conditions ranging from 0 dBto 20 dB, independent of channel characteristics. In future acomputationally efficient binarized version of the model willbe deployed on low-cost sensors reducing the data overheadof sending IQ samples to the backend [14].

D. Localization

Transmitter localization is a promising application used forgenerating both automated transmitter maps and transmitterfingerprinting. Research on received signal strength indica-tor (RSSI)-based indoor and outdoor localization has gainedinterest in recent years [15]. However, the accuracy of theRSSI information drawn from the Electrosense sensors mustbe verified to validate localization. Such a sensor is calibratedand then the system gain, consisting of the antenna gain,cable losses and front-end gain, is measured for absolute

� �� �� �� �� �� �� �� �� ��

��������������

���

���

���

��

��

��

��

����������

�������������

�������������������

Fig. 6: RSSI measured using a LoRa and Electrosense sensor.

power measurements. RSSI measurements are made in the435 MHz ISM band using standard LoRa sensors. A splitteris employed to ensure an equal antenna signal reaches both aLoRa receiver and a low-cost Electrosense sensor. A mobileLoRa transmitter is configured to send packets every threesecond over a period of 80 minutes. Their GPS logged andtime-stamped locations are sent to the receiver. The collectedRSS measurements from both the LoRa and Electrosensesensors are depicted in Figure 6. This plot shows that accurateRSSI information can be obtained from properly calibratedElectrosense sensors. The RSSI dips in the sensor data areattributed to the lengthy frequency scan of the sensor, whichis over 40 seconds, causing it to miss some packets. Existingalgorithms presented in the literature [15] can be deployedusing the sensed spectrum data retrieved through the open APIor implemented directly in the backend.

V. CONCLUSION AND FUTURE WORK

We have introduced Electrosense, a global initiative thatseeks a more efficient, safe and reliable use of the electro-magnetic space by improving the accessibility of spectrumdata for the general public. Electrosense as a crowdsourcednetwork provides solutions to the problems associated withlarge scale spectrum monitoring and the resulting data deluge.The network users receive incentives in terms of free datastorage, readily available applications and an open API.

As the first version of the Electrosense network is fullyfunctional, the next step will be in the direction of enablingusable applications in the backend. The feasibility of variousapplications were already presented in the section IV of thispaper. Research will be continued on the application space, todevelop new algorithms for spectrum prediction and anomalydetection. We also plan to implement temporal and spatialinterpolation in the backend to produce spectrum geomaps.In addition, in future the PSD pipeline in the sensor will beenhanced with advanced spectrum estimation techniques suchas Welch’s method. Furthermore, algorithms to extract usefulanalytics from the spectrum data to overcome data storageconstraints will also be explored in future. Detecting fakeor forged data from malicious users, by enabling temporalspectrum comparisons among co-located sensors and user

7

sensor ranking, is another active area for future research.Extensive studies will be also done to understand how complexalgorithms can be disintegrated for large scale deploymenton these cheap sensors. Electrosense can be the first step todemocratize the access to the spectrum data to everyone. Theage of spectrum data democratization has arrived and it couldhelp to increase the transparency and the knowledge aboutspectrum usage.

REFERENCES

[1] R. Calvo-Palomino, D. Giustiniano, V. Lenders, and A. Fakhreddine,“Crowdsourcing spectrum data decoding,” IEEE International Confer-ence on Computer Communications (INFOCOM), pp. 1–4, May 2017.

[2] A. Nika, Z. Li, Y. Zhu, Y. Zhu, B. Y. Zhao, X. Zhou, and H. Zheng,“Empirical validation of commodity spectrum monitoring.” in SenSys,2016, pp. 96–108.

[3] D. Pfammatter, D. Giustiniano, and V. Lenders, “A software-definedsensor architecture for large-scale wideband spectrum monitoring,”in Proceedings of the 14th International Conference on InformationProcessing in Sensor Networks, ser. IPSN ’15, 2015, pp. 71–82.

[4] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, andM. Ayyash, “Internet of things: A survey on enabling technologies,protocols, and applications,” IEEE Communications Surveys & Tutorials,vol. 17, no. 4, pp. 2347–2376, 2015.

[5] N. Marz and J. Warren, Big Data: Principles and Best Practices ofScalable Realtime Data Systems. Manning Publications Co., April2015.

[6] J. Kreps, N. Narkhede, J. Rao et al., “Kafka: A distributed messagingsystem for log processing,” in Proceedings of the NetDB, 2011, pp. 1–7.

[7] K. Shvachko, H. Kuang, S. Radia, and R. Chansler, “The hadoopdistributed file system,” in Mass Storage Systems and Technologies(MSST), 2010 IEEE 26th Symposium on. IEEE, 2010, pp. 1–10.

[8] M. Zaharia, M. Chowdhury, T. Das, A. Dave, J. Ma, M. McCauley,M. J. Franklin, S. Shenker, and I. Stoica, “Resilient distributed datasets:A fault-tolerant abstraction for in-memory cluster computing,” in Pro-ceedings of the 9th USENIX conference on Networked Systems Designand Implementation. USENIX Association, 2012, pp. 2–2.

[9] M. Kornacker, A. Behm, V. Bittorf, and et al., “Impala: A Modern, Open-Source SQL Engine for Hadoop,” in Proceedings of the 7th BiennialConference on Innovative Data Systems Research, 2015.

[10] A. Lakshman and P. Malik, “Cassandra: a decentralized structuredstorage system,” ACM SIGOPS Operating Systems Review, vol. 44, no. 2,pp. 35–40, 2010.

[11] T. Yucek and H. Arslan, “A survey of spectrum sensing algorithms forcognitive radio applications,” IEEE communications surveys & tutorials,vol. 11, no. 1, pp. 116–130, 2009.

[12] J. van de Beek, J. Riihijarvi, A. Achtzehn, and P. Mahonen, “Tv whitespace in europe,” IEEE Transactions on Mobile Computing, vol. 11,no. 2, pp. 178–188, Feb 2012.

[13] N. E. West and T. O’Shea, “Deep architectures for modulation recog-nition,” in 2017 IEEE International Symposium on Dynamic SpectrumAccess Networks (DySPAN), March 2017, pp. 1–6.

[14] S. Rajendran, W. Meert, D. Giustiniano, V. Lenders, and S. Pollin,“Distributed deep learning models for wireless signal classification withlow-cost spectrum sensors,” arXiv preprint arXiv:1707.08908, 2017.

[15] A. Zanella, “Best practice in rss measurements and ranging,” IEEECommunications Surveys Tutorials, vol. 18, no. 4, pp. 2662–2686,Fourthquarter 2016.