Plug and Play Flexible Signal Classification andProcessing System

Christopher Becker, Kurt Derr, Samuel RamirezIdaho National Laboratory

Idaho Falls, ID USA{christopher.becker, kurt.derr, samuel.ramirez}@inl.gov

Aniqua Baset, Sneha KaseraSchool of Computing

University of UtahSalt Lake City, UT USA

{aniqua, kasera}@cs.utah.edu

ABSTRACT

With an expanding wireless revolution fueled by Internet ofThings (IoT), autonomous cars, and software defined radios(SDRs), the need to monitor the wireless environment inreal-time is becoming paramount in a variety of importantapplications. In this work, we present a scalable plug andplay real-time signal classification and processing architecturemotivated by these important applications. While many exist-ing works focus on specific signal classification techniques,our focus is on providing a robust and flexible architecturethat enables classification of a wide range of signals. Ourdistributed architecture allows the processing components tobe mixed and matched in a variety of configurations to bestsuit the classification and processing requirements of thedesired application. We describe how our architecture can beused in a variety of scenarios to detect unauthorized wirelessactivities including airports, power substations, and sharedwireless spectrum. We build a prototype implementation ofour architecture that successfully demonstrates its practicalityand utility. We evaluate our system in terms of both processingand networking throughput. We show that we can process upto 20 MHz of bandwidth from a HackRF One software definedradio as 32-bit IQ samples and that over 99.99% of the samplesat that sample rate can be transferred between components onthe same machine during a 15 minute period.

I. INTRODUCTION

With an expanding wireless revolution fueled by Internet ofThings (IoT), autonomous cars, and software defined radios(SDRs), the need to monitor the wireless environment inreal-time is becoming paramount in a variety of importantapplications. For instance, in rulings [1]–[3], the Federal Com-munications Commission (FCC) announced using the 3.5 GHzband with a Spectrum Access System (SAS) [4] to implementa shared spectrum model with controlled access to the band.This model consists of three tiers of access levels. The highesttier of users are Incumbent users (e.g., naval radars) who areguaranteed to have interference-free access to the band whendesired. The middle tier of users are Priority Access License(PAL) users who have prioritized access to parts of the bandnot currently being used by Incumbent users. The lowest tier ofusers are Generalized Authorized Access (GAA) users who arenot guaranteed an interference-free environment and may only

use parts of the band not currently being used by Incumbentor PAL users. In order for this model to work, the SAS mustbe able to quickly and reliably detect the presence of differentusers (i.e., Incumbent, PAL, and GAA users) to enforce therequired spectrum sharing policies.

There are several other applications that can benefit from thecapability to monitor the wireless environment in real-time. Atairports, the presence of unauthorized signals may indicate apotential danger and require action to be taken to protect lives.

In high security and control system environments includingfacilities such as power plants, military bases, and watertreatment plants, having continuous situational awareness ofthe wireless environment is important. The presence of unau-thorized signals may indicate the presence of an adversary. Theremoval of authorized signals may indicate the presence of anadversary or system issues that must be addressed quicklyto avoid serious consequences such as system failure or abreach. Devices that do not act as intended, including emittingadditional signals, can cause interference or other problems inthese environments.

In this work, we present a scalable plug and play real-time signal classification and processing architecture motivatedby these important applications. Our distributed architectureallows processing components to be mixed and matchedin a variety of configurations to best suit the classificationand processing requirements of the desired application. Thisincludes allowing the use of heterogeneous processing capa-bilities. Processing is done through the use of processing flowswhich can be modified dynamically, allowing great flexibilityat runtime. We also build a prototype implementation thatsuccessfully demonstrates the practicality and utility of oursystem. We evaluate our system in terms of both processingand networking throughput. We show that we can process up to20 MHz of bandwidth from a HackRF One software definedradio as 32-bit IQ samples and that when components areon the same machine, over 99.99% of the samples at thatsample rate can be transferred between components duringa 15 minutes period. While many existing works focus onsignal classification techniques, our focus is on providing arobust and flexible signal processing architecture useful inmany scenarios. In Section II-D we provide multiple examplescenarios where our system can be used and how our systemcan be applied to these scenarios.

Fig. 1. System Components Overview

II. SYSTEM OVERVIEW

A. Components

Figure 1 provides an overview of our system, which caneither be used as a standalone system or integrated into a largersystem, such as a SAS. The main components of the system arethe controller (and associated plugins), a set of data interfaces,and a set of processing nodes. The controller plugins sit on topof the controller itself to provide the interface between the useror another system with our system. The system componentsmay reside on a single machine or be distributed acrossmultiple machines. We describe the individual componentsbelow.

The controller handles interactions between all of thecomponents, such as registration, configuration, and activationrequests.

Controller plugins provide a user and/or system interfacewith the rest of the system.

Data interfaces provide an interface to an underlying datasource, normally from a SDR or other streaming sources, thatcan be used by the system to classify signals or otherwiseprocess data in a variety of ways. SDR Controllers are acommon subtype of data interfaces. Other types of datainterfaces include other programs, databases, and files.

Processing nodes provide data processing capabilities to thesystem. Examples of capabilities include signal demodulation,reverse engineering, and recording. Processing nodes may alsobe chained together to provide processing flows.

B. Command and Control Interaction

As components come online, they register with the con-troller and await further commands. Part of the registrationprocess requires the components to provide information aboutthemselves. For example, for a data interface node, informationsuch as its device position (GPS coordinates), capabilitiesincluding RX and TX, and configuration options are sent. Fora processing node, examples of data sent during registrationmay include the types of capabilities it has (e.g., classificationand signal demodulation) and configuration options for thosecapabilities. Configuration options are sent in a format suchthat a wide variety of option types are available to thecomponents and new components can be added to the system

Fig. 2. Example Processing Flows

without changes being made to the core system and without thecore system having much, if any, knowledge about the plugin(e.g., which SDR hardware is being used and what type ofprocessing capabilities are desired). This allows the system toadapt over time without additional development effort to thecore system.

C. FlowsProcessing flows allow components (i.e., data interfaces,

processing nodes, and controller plugins), to be chained to-gether. Each component provides input and/or output func-tionalities in terms of ports. Each port has an associateddata type. Components may be chained together when theoutput type of the previous (source) node port matches theinput type of the current (destination) node port. Each nodequeues data to be forwarded to the next attached node(s)in the flow. Data interface nodes may contain both inputand output functionality as appropriate for the data source.Processing nodes have input functionality and may containoutput functionality as well. Controller plugins provide inputfunctionality for receiving data from the system and outputfunctionality for interacting with either the user or anothersystem. Data types are not hard-coded into the system. Rather,a string representation is used, allowing data types to be set bythe components (i.e., component plugins) and only requiringthe components to agree upon them. This allows the systemto evolve with new data types without changing the core.

Example Flows: A flow is a set of configured nodes andthe connections between the nodes that produce an acyclicgraph. Figure 2 provides example data processing flows. Thearrows show the data flow between the components. In thefigure:

• Data Interface (DI) 1, Processing Node (PN) 1, PN 2,and Controller Plugin (CP) 1 form Flow 1

• DI 1, PN 3, PN 4, PN 5, PN 6, and CP 2 form Flow 2• DI 2 and PN 7 form Flow 3For Flow 1, samples are sent from a USRP X310 SDR to a

signal demodulator. Results from the signal demodulator aresent to a protocol reverse engineering process. Results fromthe protocol reverse engineering process are sent to a controllerplugin to be presented to the user.

Fig. 3. Dynamic Flow Example: “Dynamic Flow” is added an already active“Original Flow”

For Flow 2, the same samples that are sent to the signaldemodulator from Flow 1 are also sent to two different clas-sification techniques. Results from the second classificationtechnique are further processed to determine if any additionalunknown signals have been detected. Results from the firstclassification technique and the unknown signal detectiontechnique are sent to a merger process. This merger processtakes the results from the different inputs and combines them.The combined results are sent to a controller plugin to bepresented to the user.

For Flow 3, samples from a HackRF One SDR are sent toa recording node to be saved in storage.

As can be seen, one source node can send results to multiplenodes (Flows 1 and 2) and nodes may accept input fromseveral sources (Flow 2). Flow 3 demonstrates that not allflows must involve a controller plugin.

Dynamic Flows: Flows may also be dynamically changed.Figure 3 shows an example flow where a flow was added toin order to provide additional processing. The arrows showthe data flow between the components. Originally, the flow(“Original Flow”) was designed to:

1) Take samples from a Data Interface (Source)2) Pass them to a processing node that provides classifica-

tion capabilities3) Pass the classification results to a processing node that

provides baseline comparison4) Pass the comparison results to a controller plugin (Dis-

play 1) to present them to a userAfter a rogue signal is detected, without interrupting the

existing flow, the user is able to modify the flow to add the“Dynamic Flow” part shown in Figure 3. The modificationinvolves:

1) Sending the same samples being sent to the classifica-tion node to a processing node that provides a signaldemodulation capability

2) Pass the results of the demodulation to a processing nodethat provides deep packet inspection capabilities

3) Pass the results of the deep packet inspection to acontroller plugin (Display 2) to present them to a user

D. Wireless Environment Examples

In this section, we provide the following example environ-ments and system use cases:

• Airport• Power Substations

• SAS system1) Airport: Wireless Envrionment Concerns: The pres-

ence of drones at airports has led to numerous flight dis-ruptions as illustrated by [5]–[7]. If an aircraft would crashinto a drone, not only could there be damage to the aircraft,but also could lead to a crash, injuring or killing people. Inthese cases, the drones were visually sighted. However, beingable to detect a drone by its wireless communication leavesless to chance. Similarly, in an airport environment, signalsare generated from the ground and broadcast to aircraft thatprovide necessary data for operation. For example, the Instru-ment Landing System (ILS) [8] is a landing navigation aidthat provides both vertical and horizontal guidance informationfor aircraft as they land. Jamming of this system, or worse,the overriding of this signal could be catastrophic for landingaircraft.

System Application: In these cases, SDR Controllers aredeployed in and around the airport facility. Data from theSDR Controllers is sent to processing nodes which may eithercompare current wireless environment characteristics against abaseline or specifically look for known wireless drone traffic.If anomalous signals are found by either method, further actionmay be taken such as confirming, alerting personnel and airtraffic, or shutting down the area affected to avoid seriousconsequences.

2) Power Substation: Wireless Environment Concerns:Attacks on electrical equipment such as [9]–[11] highlightattacks that continue to take place within the United States.In cases like these, having continuous knowledge of thesurrounding wireless environments may have been able toprevent the attacks or help in investigating the attacks. Forexample, if the attackers had spent time around the equipmentto scout out the locations, as well as during the attacks,their presence could have been detected if they were carryingequipment that transmitted wireless signals (e.g., cell phones)that was picked up by our system, allowing authorities to actpreemptively or more quickly. If their presence was detected,additional information about their devices (e.g., characteristicsor traffic) could have also been recorded to leave a forensictrail for investigators if needed after the attack happened.

System Application: In these cases, SDR Controllers aredeployed around the equipment to be protected. Data fromthe SDR Controllers is sent to processing nodes which maycompare current wireless environment characteristics againsta baseline. If the current wireless environment differs fromthe baseline, additional processing and/or recording of theenvironment may take place via additional Processing Nodesbeing added to the processing flows. Also, alerts may be sent todesignated personnel notifying them of an event that requiresfurther investigation by personnel.

3) SAS System: Overview: When using a SAS system,three tiers of users share a common portion of the spectrum.The highest tier of users, incumbent users, are guaranteedinterference-free access to the band when they desire it. Themiddle tier of users, PAL users, have priority access to thespectrum when and where incumbent users are not present.

Fig. 4. Component Implementation and Interaction Overview

The bottom tier of users, GAA users, have access to thespectrum when and where incumbent and PAL users are notpresent and must share the spectrum with other GAA users.If a higher-tier user starts to use the spectrum, all lower-tierusers must vacate the spectrum.

In this environment multiple capabilities are important:• Quickly and reliability detect the presence of higher-

tiered users• Detect the presence of interference sources• Determine compliance of users, particularly GAA users

The SAS relies on another system to monitor the spectrumand provide information back to the SAS.

System Application: In this environment, SDR Controllersare deployed around the area to be monitored. Our systemwould monitor the specific part of the spectrum controlledby the SAS. In this case, Processing Nodes continuously runone or more classification algorithms to look for signals. Ifsignals are detected, additional Processing Nodes are used toprovide additional information about the signals. If higher-tiered users are detected, action can be taken immediatelyto have lower-tier users clear the spectrum. If violations aredetected, the appropriate action to respond to them can betaken very quickly.

III. IMPLEMENTATION

Figure 4 provides an overview of our prototype implemen-tation. For simplicity, we show only one instance of eachcomponent. The arrows with solid lines show the data (sample)flow through the architecture while the arrows with dottedlines show the configuration and command data flow. The“Data/Signal Source” component is not strictly within thescope of our system, but present in the figure as a reference.

We implement a prototype of our system in C++ using theQt Framework [12], version 5.9 as three separate applications:data interface, processing node, and controller as well asmultiple plugins for each component.Communication betweendifferent components occurs over HTTPS. Commands andconfiguration information uses the JSON format. Sample datauses a custom format. Graphviz [13] is used for flow visual-ization. Plugins are developed using Qt’s Plugin Framework.

As can be seen in Figure 4, the main components (DataInterface, Processing Node, and Controller Backend) handleall inter-component communication, allowing plugins to focuson data manipulation and processing. This allows pluginsand our core system to be developed in relative isolation,

Fig. 5. Controller GUI with Classification Result Viewer Plugin

Fig. 6. Controller GUI with ADSB Mapper Plugin

allowing changes to be made to the overall system (e.g.,performance upgrades) to be made without affecting plugindevelopment and changes made to plugins to occur withoutaffecting the overall system. Data communication is doneusing a “push”-style architecture. Nodes receive samples fromtheir sources as the samples are ready. Information about thespecific components and aspects of the system is provided inthe following subsections.

A. Controller and Plugins

We use a SQLite [14] database using Qt’s SQLite driverto manage node information. The controller is broken intobackend and frontend components.

The backend implementation can be used by multiple ver-sions of the frontend. The backend handles interacting withthe nodes and providing updates on node information, suchas registration, status, etc., to the frontend. Controller pluginsare loaded based on information specified in the configurationfile. The backend is also responsible for activating flows givena flow representation from the frontend. More informationon the representation and activation process can be found inSection III-G.

The frontend implementation provides a graphical userinterface (GUI) to the user. Figures 5 and 6 shows the maincontroller GUI with different plugins active. Figure 5 has aclassification result viewer plugin active, while Figure 6 hasan ADSB Mapper plugin active. The interface allows the userto view all registered data interfaces, processing nodes, andcontroller plugins and their status (left hand side of the GUIin Figures 5 and 6). It also allows the users to generate flowsusing currently registered components, as shown in Figure 7,and view the current status of those flows. Part of the GUIis also assigned to display the output from controller plugins(right hand side of the GUI in Figures 5 and 6).

Fig. 7. Flow Creation GUI

Each controller plugin provides the following information:a string representing the type of the plugin, information aboutplugin-wide configuration options, and information about theinput channels. The plugin also implements functionality to:load settings from a configuration file, activate the plugin givena configuration from user input, deactivate the plugin, inputsamples, and signals to request samples and indicate the pluginhas been deactivated. In addition, plugins designed for a GUIcan provide an interface (QWidget) that is incorporated intothe controller frontend GUI interface.

We currently have implemented plugins to provide a view ofclassification results, signal clusters, IQ samples, and ADSBdata mapper. For the ADSB data mapper plugin, we use theMarble mapping library [15] to provide mapping capabilities.

B. Data Interface and Plugins

Device interfaces are loaded as specified in the configurationfile. A data interface may load and use multiple data interfaceplugins. Each plugin exposes one or more channels. The datainterface is responsible for interacting with the controller andtaking data from the data interface plugins and providing themto the other nodes as needed to complete the flow while leavingthe data generation to the plugins themselves.

Each plugin provides the following information: a stringrepresenting the source type and information about the avail-able channels. The plugin also implements functionality to:load settings from a configuration file, activate and deactivate achannel in the plugin given a configuration from the controller,a signal to indicate the plugin deactivation, and generate data.

We currently have implemented plugins to provide constantdata, read in IQ values from a file, interact with USRP [16]SDR devices, interact with HackRF One [17] devices, providesignal classification data from various sources, provide signalclustering data from various sources, and ADSB Decoder.For the USRP and HackRF One device plugins, we useGNU Radio [18] to retrieve samples and a custom sampleexport block to export the samples to the output channel.For the ADSB decoder, we use a RTL-SDR [19] device withdump1090 [20] to decode the signals.

C. Processing Node and Plugins

Processing nodes are loaded as specified in the configurationfile. A processing node can load multiple plugins, but only oneplugin may be active at any given time. The processing nodeis responsible for interacting with the controller as well as

retrieving data from the previous node(s) in the flow to provideto the plugin and taking data from the plugin and providingit to the next node(s) in the flow. The processing of the dataitself is handled by the activated plugin.

Each processing node plugin provides the following infor-mation: a string representing the type of capability, informationabout capability-wide configuration options, and informationabout the input and output channels. The capability alsoimplements functionality to: load settings from a configurationfile, activate the capability given a configuration from thecontroller, deactivate the capability, input data, signals torequest data and indicate the plugin deactivation, and generateoutput data if needed.

We currently have implemented plugins to pass data to thenext node, WiFi signal demodulation, and wireless signal clas-sification. The pass-through plugin is useful for debugging andperformance testing. The WiFi demodulation plugin attemptsto demodulate IQ samples into WiFi packets and save themto a PCAP file using GNU Radio and the gr-ieee802.11 [21]and gr-foo [22] modules and a custom sample import blockto input samples from the input channels. The classificationplugin acts similar to the signal classification data interfaceexcept it completely decouples the source from itself.

D. Node Configuration Options

When registering, plugins may provide information aboutadditional parameters they support to the Controller that can beconfigured by the user. Currently, the supported configurationoption types are: arrays, booleans, doubles, integers, JSONstrings, ranges, selections, and strings. Arrays and ranges havea subtype of either integer or double. JSON values act asa “raw” input type. Selection types involve lists of values auser can choose from. These options are presented to the userwhile configuring a chain and sent to the nodes during chainactivation.

E. Input/Output Channels

Each channel includes channel-specific configuration op-tions as well as the data type allowed represented as a stringand the expected size of the data type. A data type may befixed-sized or dynamic in nature. For example, a data type maybe “complex float 32,” representing a sample being a complexvalue made up of two 32-bit floating point values. In that case,the data type would be an 8-byte fixed-size data type. Anotherexample of a data type would be “classification results,”representing a sample being a result from processing samples.In this case, the data type may be dynamic in nature as it maycontain a list of values.

Each component’s output channel maintains a separatecircular sample buffer for each connection. This allows perfor-mance information to be tracked and the latest samples to besent every time sample sets centrally to save on processing, butare maintained independently for each connection, meaningthat if two nodes receive samples from the same source node,the ability of one node to consume samples does not affectthe ability of the other node to consume samples.

F. Sample Format and Communication

Each sample is represented by a byte array which holds thedata and a dictionary of tags for that sample. The byte arraysonly have meaning to the plugins that directly interact withthem and are treated as just bytes by the architecture as awhole. This allows new sample data types to be added to thesystem without any changes to the core system. Sample datatypes are represented by strings. The sample tag dictionaryis implemented using a QVariantMap which allows multipletypes of data to be sent in the same data structure. Whenmoving samples between nodes, the exact packet format(particularly the data section) depends on whether or not thedata type for the samples is fixed-sized or dynamic in nature.Each set of samples includes the following information:

• format version• the number of missed samples since the last request for

samples• the sample type string• the size of the samples (or that they are dynamic in size)• the number of samples sent• the sample data• a dictionary of the sample tags

If the samples are fixed-sized, the sample data is treated as asimple data buffer and the raw sample data is read and writtencontiguously into that space using memory copies and canbe done in parallel. On the other hand, if the samples aredynamically-sized, each sample is prepended by the size (inbytes) of the sample data and must be done serially.

G. Flow Representation and Activation

Flows are represented using a JSON format which consistsof a list of nodes with their configuration and a list of connec-tion pairs. Flows are not allowed to contain cycles, allowing usto compute an activation order based on dependencies basedon Kahn’s Algorithm [23]. A node is dependent on any node itreceives input from. Generally, this means that data interfaceshave no dependencies and all processing nodes and controllerplugins will have at least one dependency. Once the activationorder is determined, nodes are activated in that order waitingfor all dependencies of that node to successfully activate beforecontinuing. As part of the activation, output channels willsend back the port that will serve samples to the next node.That information is then sent along with the configurationinformation when activating a node with dependencies.

IV. EVALUATION

In this section, we evaluate our system based on theprocessing throughput as well as the networking throughput.The processing throughput is how well we can handle inputfrom multiple SDRs at different sample rates. The network-ing throughput is how well we can handle data transferredbetween nodes. For all plugins, we use a data type of“complex float 32,” representing a complex value with eachcomponent being a 32-bit float value, making it a fixed-sizeddata type of size 8 bytes. All tests are performed on Dell 7530laptops running Ubuntu 18.04.2 LTS.

Fig. 8. Network Throughput Evaluation Flow

A. Processing Throughput

For this evaluation, we use a HackRF One, USRP B210, andUSRP X310 at different sample rates to determine how muchsignal bandwidth we will be able to handle processing. Forthese devices, we use the Data Interface plugins we built forUSRP and HackRF One devices as mentioned in Section III-B.For the flow, we simply start up a Data Interface node with theappropriate plugin loaded. We have no other node connectedto it. To determine whether or not we are able to handlethe processing load, we run the modules for an hour. If an“overflow” notification was seen, processing at some pointalong the communication path is not keeping up with samplesbeing sent from the device and we consider the sample rate tobe too high. This may take place for a variety of reasons,including the use of certain USB bus controllers, lack ofdedicated CPU, or a slow connection between the device andthe computer. For this test, the node is run on an Intel XeonE-2186 (2.9 GHz) processor. The HackRF One and USRPB210 are both connected via USB (USB 3.0 ports) on thecomputer. The USRP X310 is connected directly to a 1 GbpsEthernet port on the computer. Sample rates are tested in 1MHz increments. The results are listed in Table I.

TABLE IPROCESSING THROUGHPUT RESULTS

DeviceHackRF One USRP B210 USRP X310

Max Sample Rate(MHz) 20 18 20

B. Networking Throughput

For this evaluation, we use a HackRF One at differentsample rates to determine how much throughput can beachieved when sending data between nodes. The flow isillustrated in Figure 8. For the flow, we have a Data InterfaceNode with the HackRF One plugin loaded connected to apassthrough Processing Node as mentioned in Section III-C.The passthrough node does no processing on the data, butsimply forwards it. We instrument this node to record howmany samples from the HackRF are received as well as howmany are lost at the source and destination nodes. We run thisevaluation with two node setups. For the first setup, both nodesare on the same physical machine, running on an Intel XeonE-2186 (2.9 GHz) processor. For the second setup, each nodeis on a separate machine with a gigabit Ethernet switch inbetween. The HackRF One component is running on an IntelXeon E-2186 (2.9 GHz) processor, while the passthrough nodeis running on an Intel Xeon E-2176 (2.7 GHz) processor. Eachtest was run for 15 minutes.

TABLE IINETWORKING THROUGHPUT RESULTS

SetupSample

Rate(MHz)

(% of Total)Total

SamplesReceived

andProcessed

RemoteLost

LocalLost

SingleNode

10 99.994 0.000 0.006 890436682615 99.993 0.000 0.007 1329455048520 99.997 0.000 0.003 18088607575

MultipleNodes

10 99.097 0.884 0.019 889698260915 95.943 4.043 0.014 1319172468320 72.162 27.832 0.006 18254974947

The results are shown in Table II. As can be seen, when thenodes are on the same machine, no samples are lost due tothe network. The small percentage of packets lost locally aredue to the local receive buffer filling up before samples arebeing processed during startup. After starting up, processingkeeps up with the incoming samples. This also explains thedecreased percentage of samples lost locally as the sample rateincreases. When multiple nodes are used, we see sample lossoccurring due to network delay. The percentage of samples lostincreases as the sample rate we use increases. We also see asmall percentage of samples are lost locally as well. Similarto local sample loss when nodes are running on the samemachine, the local samples lost when on separate machinesoccurs only at the very beginning. The higher percentage oflocal samples lost when running on multiple machines can beaccounted for by the fact that the processing node was runningon the slower machine when the nodes are split.

The network loss can mainly be attributed to two factors.First, both the HackRF One and USRP devices use smallerdata types (line-format) than we are transferring. For instance,a HackRF One’s resolution is 8-bits per I or Q sample, makingthe actual sample size 16-bits. However, the GNU Radiorepresentation we receive is 32-bits of resolution per I or Qsample, making the actual size 64-bits. This means our pluginis attempting to move four times as much data. Second, neitherHackRF One nor the Ettus devices use encrypted packets whentransferring data to the host. This means traffic between ournodes incurs additional overhead from the security used.

V. RELATED WORK

GNU Radio [18] allows real-time processing and providessome plug and play capabilities by use of out of tree moduledevelopment and flowgraphs. However, generally this ap-proach is designed to not be distributed and has multipleperformance problems which we discuss in greater detailin [24]. GNU Radio is solely focused on signal processingand designed to work with only a limited number of inputand output types. While we use GNU Radio to implementparts of our prototype, our architecture does not rely on it andcan incorporate other capabilities, provide better performancefeedback, handle a wider variety of input and output types,and is designed to be distributed.

VI. CONCLUSION

We presented a distributed architecture that allows process-ing components to be mixed and matched in a variety ofconfigurations to best suit the classification and processingrequirements of the desired application. We built a prototypeimplementation of the system and evaluated our prototypeto show the practicality and utility of our system. We showthat the system is easily expandable and flexible in terms ofprocessing flows, changing components, and heterogeneousprocessing capabilities. We also evaluated the prototype interms of both processing and networking throughput.

ACKNOWLEDGMENT

This research made use of the resources of the HighPerformance Computing Center at Idaho National Laboratory,which is supported by the Office of Nuclear Energy of the U.S.Department of Energy and the Nuclear Science User Facilitiesunder Contract No. DE-AC07-05ID14517.

REFERENCES

[1] Federal Communication Commission, “In the matter of unlicensedoperation in the tv broadcast bands: Third memorandum opinion andorder,” FCC Document 12-36, April 2012.

[2] ——, “Presidents council of advisors on science and technology, realiz-ing the full potential of govt-held spectrum to spur economic growth,”July 2012.

[3] ——, “Amendment of the commissions rules with regard to commercialopeations in the 3550-3650 mhz band, report and order and secondfurther notice of proposed rulemaking,” FCC Document, April 21, 2015.

[4] C. W. Kim, J. Ryoo, and M. M. Buddhikot, “Design and implementationof an end-to-end architecture for 3.5 ghz shared spectrum,” in IEEEDySPAN, 2015, pp. 23–34.

[5] BBC News, “Gatwick Airport: Drones ground flights,” BBC.[6] ——, “Heathrow airport: Drone sighting halts departures,” BBC.[7] L. Aratani, “Drone activity halts air traffic at Newark Liberty Interna-

tional Airport,” The Washington Post.[8] “Ground-Based Navigation - Instrument Landing System (ILS),”

https://www.faa.gov/about/office org/headquarters offices/ato/serviceunits/techops/navservices/gbng/ils/, 2016.

[9] J. Pagliery, “Sniper attack on California power grid may have been ‘aninsider,’ DHS says,” CNN.

[10] T. Fedschun, “Power equipment near start of Camp Fire in Californiahad damage, utility reveals,” Fox News.

[11] P. Behr, “Substation attack is new evidence of grid vulnerability,” E&ENews.

[12] “Qt,” https://www.qt.io/, 2018.[13] “Graphviz,” https://www.graphviz.org/, 2019.[14] “SQLite,” https://www.sqlite.org/, 2017.[15] “Marble,” https://marble.kde.org/, 2019.[16] Ettus Research, “The Universal Software Radio Peripheral,” https://

www.ettus.com/product, 2017.[17] Great Scott Gadgets, “HackRF One,” https://greatscottgadgets.com/

hackrf/, 2018.[18] “GNU Radio,” http://gnuradio.org/, 2018.[19] RTL-SDR, “RTL-SDR,” https://www.rtl-sdr.com/, 2019.[20] “Dump1090,” https://github.com/MalcolmRobb/dump1090, 2019.[21] “IEEE 802.11 a/g/p Transceiver,” https://github.com/bastibl/

gr-ieee802-11, 2018.[22] “Some GNU Radio blocks that I use.” https://github.com/bastibl/gr-foo,

2018.[23] A. B. Kahn, “Topological sorting of large networks,” Commun.

ACM, vol. 5, no. 11, pp. 558–562, Nov. 1962. [Online]. Available:http://doi.acm.org/10.1145/368996.369025

[24] C. Becker, A. Baset, S. Kasera, K. Derr, and S. Ramirez, “Experienceswith using gnu radio for real-time wireless signal classification,” in GNURadio Conference, 2018.