1

High-Level System Design of IEEE 802.11bStandard-Compliant Link Layer for

MATLAB-based SDRRamanathan Subramanian, Member, IEEE, Benjamin Drozdenko, Member, IEEE,

Eric Doyle, Member, IEEE, Rameez Ahmed, Member, IEEE,Miriam Leeser, Senior Member, IEEE, and

Kaushik R. Chowdhury, Senior Member, IEEE

Abstract—Software defined radio (SDR) allows unprece-dented levels of flexibility by transitioning the radiocommunication system from a rigid hardware platformto a more user-controlled software paradigm. However,it can still be time consuming to design and implementsuch SDRs as they typically require thorough knowledgeof the operating environment and a careful tuning of theprogram. In this work, our contribution is the design of abidirectional transceiver that runs on the commonly usedUSRP® platform and implemented in MATLAB® usingstandard tools like MATLAB Coder™ and MEX to speedup the processing steps. We outline strategies on how tocreate a state-action based design, wherein the same nodeswitches between transmitter and receiver functions. Ourdesign allows optimal selection of the parameters towardsmeeting the timing requirements set forth by variousprocessing blocks associated with a DBPSK physical layerand CSMA/CA/ACK MAC layer so that all operationsremain functionally compliant with the IEEE 802.11bstandard for the 1 Mbps specification. The code baseof the system is enabled through the CommunicationsSystem Toolbox™ and incorporates channel sensing andexponential random back-off for contention resolution.The current work provides an experimental testbed thatenables creation of new MAC protocols starting from thefundamental IEEE 802.11b standard. Our design approachguarantees consistent performance of the bi-directionallink, and the three node experimental results demonstratethe robustness of the system in mitigating packet collisionsand enforcing fairness among nodes, making it a feasibleframework in higher layer protocol design.

Index Terms—Software Defined Radio, IEEE 802.11b,CSMA/CA/ACK, Energy Detection, Exponential RandomBack-off, MEX, Reconfigurable computing.

Department of Electrical and Computer Engineering,Northeastern University, Boston, MA, 02115 USA e-mail: rsubramanian@coe.neu.edu, bdrozdenko@coe.neu.edu,doyle.e@husky.neu.edu, rarameez@gmail.com, mel@coe.neu.edu,krc@ece.neu.edu

I. INTRODUCTION

Software defined radios (SDRs) allow fine-grained control of their operation by executingthe processing steps in user-accessible programcode [1]. This technology forms the building blockfor applications needing high levels of reconfig-urability, such as access points that support mul-tiple wireless standards, or for systems like cogni-tive radios that incorporate situational intelligenceto evolve with the radio frequency (RF) environ-ment [2]. For example, in SDRs, the network de-signer can tune basic elements, such as modula-tion, spectrum spreading, scrambling, and encodingthrough software functions, instead of relying onstatic hardware, thereby allowing unprecedented ac-cess to all aspects of the radio operation. However,significant expertise is required to successfully nav-igate the hardware design, software implementation,wireless standards requirements, and computationaltiming limitations, which requires specialized train-ing and lengthens time to project completion.

A basic SDR system is composed of a computerconnected to a RF front end capable of receivingand transmitting radio signals. A RF front endrequires an antenna suited for specified RF bandsof interest, a transceiver chip that is comprised of atleast one local oscillator, analog-to-digital converter(ADC), and digital-to-analog converter (DAC), andan interface (e.g. Ethernet cable) that connects thefront end to the computer. The computer may have ageneral purpose processor to process the digital out-put and programs to realize specialized tasks such asfiltering, amplification, and modulation, which havetraditionally been implemented in hardware. The

arX

iv:1

604.

0788

1v1

[cs

.NI]

26

Apr

201

6

2

design concept of the SDR is advantageous becauseit reduces the need for special purpose hardwareand allows the developer to add new functionality tothe radio by modifying the software. The flexibilityinherent in the SDR allows for the potential tosupport many wireless standards, whereas a singlehardware transceiver can only support a few or onestandard. Hence, the SDR device can be seen as anincreasingly affordable alternative.

Any modern wireless standard relies on accuratetiming to complete the standards-specified tasks. InSDR, as the received and transmitted signals arerepresented as arrays of data samples collected bythe front-end, software processing contributes todelays. Additionally, when multiple nodes operatein a shared channel, timing issues add to the chal-lenge of ensuring synchronized behavior betweenmultiple nodes. In the absence of hardware clocks,the SDR must devise a means of calculating howmuch time has elapsed, so that transmission andreception functions are performed at the appropriateintervals. The processing functions and their internalparameters must also be open for change, should abetter algorithm be designed, or if no set thresholdsmay be possible, as is the case in highly challengingenvironments with variable noise floor. Finally, thesoftware running on the SDR must be structured ina hierarchical manner, so that its functionality canbe separated into layers that are compliant with theOpen Systems Interconnection (OSI) model. Thus,the base drivers that interface with the RF front-end platform should be abstracted from the physical(PHY) layer functionality, which in turn should beabstracted from the medium access control (MAC)layer logic. In summary, there are many designchallenges that must be overcome before a highlycustomizable SDR platform is made available forgeneral purpose use.

This paper details our approach to realize a SDRplatform using commonly available tools. We be-lieve that true and repeatable systems-level researchis only possible when a commonly used processingenvironment is used in conjunction with afford-able SDR hardware. This motivates our choices forbasing our work on MATLAB software and EttusUSRP® N210 hardware [3]. Our approach intro-duces a novel methodology for an implementationstarting at the USRP hardware driver (UHD) andbuilding progressively up the protocol stack. Tofacilitate quick deployment, it includes an initial-

ization script for the setting and tuning of the re-configurable parameters at the physical layer basedon the specific channel measurements at the chosenexperimental site. Importantly, it complies with theprocessing definitions in the IEEE 802.11b spec-ification, though hardware limitations increase thetime to completion of the entire transmission/recep-tion cycle compared to an off-the-shelf hardware-only Network Interface Card.

Our approach advances the state of the artand contributes to the research community in thefollowing ways:Standards compliant link layer: Our approachis based on the IEEE 802.11b specifications [4],faithfully modeling the DATA and ACK packetstructure, and implements both PHY-layer andMAC-layer protocols. Further, our work providesa testbed to experiment with new MAC protocolsstarting from the fundamental IEEE 802.11bcompliant standard.State-action based design: We model our systemusing a finite state machine (FSM) that transitionsonly on the clock cycles derived from theUSRP clock, allowing for slot-time synchronizedoperations. In this manner, we eliminate the needfor external clocks that would be necessary in ahardware-based design, or interrupts that may bepreferable using a real-time operating system.Design methodology using a common operatingenvironment: We use the Ettus Research UniversalSoftware Radio Peripheral (USRP) hardware,a radio front end commonly used in wirelessresearch. As the basis for our software design, weuse MATLAB R2015b and the CommunicationsSystem Toolbox Support Package for USRP-basedradio [5]. We use the MATLAB tools such asMATLAB Coder and the MEX interface to providefor acceleration and timing consistency in theexecution of system blocks.Full parameter flexibility: Using a software-onlyapproach and parameterizing the most importantvariables allows the user to reconfigure the systemas needed to adapt to changes in its environment.Publicly available: Our software is released to thepublic for research purposes under the GNU PublicLicense (GPL), and is available for downloaddirectly from GitHub [6] and MATLAB Central[7]. The modularity of our code makes it relativelyeasy to manage and will enable extensibility by thecommunity.

3

The rest of this paper is organized as follows. InSec. II, we present the system architecture. We dis-cuss related work on SDR using heterogeneous sys-tems and software platforms in Sec. III. In Sec. IV,we describe the slot-time synchronized operationsaround which the state machines for the designatedtransmitter and receiver are modeled, and we iden-tify the common system blocks. We describe thealgorithms implemented for RFFE and preamble de-tection in the PHY Layer, followed by a discussionon parameter selection and same-frequency channeloperation in Sec. V. The MAC layer design and keyalgorithms required to implement the CSMA/CAprotocol, such as energy detection and random back-off, are described in Sec. VI. The experimental setupinvolving the USRP N210 platform and MathWorksproducts is given in Section VII. In Sec. VIII, weundertake a comprehensive performance evaluationof the two node and three node system and establishthrough the experimental results that the systemexhibits fairness. Sec. IX concludes the paper.

II. SYSTEM ARCHITECTURE OVERVIEW

The operational steps that architect our systemare shown in Fig. 1. In a given SDR pair, weidentify clearly the transmitting and receiving nodeby using the terms designated transmitter (DTx)and designated receiver (DRx). This terminologyhelps avoid ambiguity in describing a bi-directionaltransceiver link, where the transmitter must sendout its DATA packet and then switch to a receiverrole to get the acknowledgement (ACK). Thus, inthe discussion ahead, the DTx alternates betweenits transmit and receive functions, and the DRxalternates between receive and transmit functions.

In the initialization step, the system is preset withrecommended parameters and lets the user modifya number of parameters for the entire transceiverchain. The user then, in a simulation-only envi-ronment, initiates a parameter exploration stage,where all the nodes are virtual and are containedwithin the same computer. The DTx and DRx codesare executed with the user-supplied parameters asconstants, and the code cycles through possiblevariations in the settings of processing blocks aswell as entire algorithms, each time identifying theperformance that results from these settings.

From this data set, the user is presented with afeasible set of parameter settings. These parameter

Fig. 1: System Architecture

settings result in less than 5% packet loss at thereceiver. This represents the best case scenario, forit should be noted that further channel outages willbe introduced by the actual wireless channel. Oncethe user selects one of the possible feasible config-urations returned by the search, the code is readyfor driving the USRPs for over-the-air experiments.

We adopt the IEEE 802.11b PHY and MAC layerpacket structure specifications in our implementa-tion [4] [8]. Our approach collects all the bits inthe packet in multiples of 8 octets, which forms oneUSRP frame. This makes it easy for us to work withthe MATLAB system objects (specialized objectsrequired for streaming, henceforth referred to asobjects) and with PHY and MAC header fields in theDATA/ACK packet that happen to have sizes thatare multiples of 8 octets. Multiple USRP frames willcompose the standard-compliant 802.11b packet.

We use differential binary phase shift keying(DBPSK), as the differential component enables usto recover a binary sequence from the phase anglesof the received signal at any phase offset, withoutcompensating for phase. In addition, DBPSK re-quires only coarse frequency offset compensation,without any closed-loop techniques. If residual fre-quency offset is much less than DBPSK symbol rate,then the bit error rate (BER) approaches theoreticalvalues [9].

4

III. RELATED WORK

A. SDR Software PlatformsSpecialized software is needed to effectively work

with the SDR systems and perform the signal pro-cessing tasks needed to instantiate wireless commu-nications, such as modulation, preamble detection,encoding, and filtering. GNU Radio is one of themost widely used SDR programs, owing to thefact that it’s open source, hardware-independent,and modifiable [10]. Its GUI, GNU Radio Com-panion, allows the user to build block diagrams torepresent complex encoding and decoding schemes.Modules are built in C++, ordering of compo-nents performed in Python, and connections aremade using SWIG. Built-in modules allow theuser to perform various types of modulation (e.g.GMSK, PSK, QAM, OFDM) and error-correctingcodes (e.g. Reed Solomon, Viterbi, turbo). TheSoftware Communications Architecture (SCA) isanother open-source, HW-independent frameworkthat models SDR components using data flow di-agrams. It is also written using C++ and Python,but intra-block message-passing is accomplishedusing Common Object Request Broker Architecture(CORBA) middleware. Different software blocksare graphically represented using Unified ModelingLanguage (UML). The OSSIE software effects anSDR using the SCA framework for interaction withthe USRP board [11]. OSSIE provides a GUI toenable the designer to create new waveforms, addnew signal processing and modulation routines, andgenerate the C++/Python code for SCA-CORBAinteractions.

B. SDR on Heterogeneous SystemsThere are existing SDR projects implemented on

heterogeneous systems that make use of a combina-tion of hardware components to handle computingtasks, including digital signal processors (DSPs),application-specific integrated circuits (ASICs), andfield-programmable gate arrays (FPGAs). [12] de-scribes an SoC design for placing transceiver com-ponents, including RF receivers at 2 GHz and5 GHz, a voltage controlled oscillator (VCO), anda baseband filter. [13] proposes a hardware archi-tecture for an embedded software modulation/de-modulation (modem) platform, implementing IEEE802.11a PHY using the Altera Stratix II FPGAand S3C2410 ARM processor. [14] realizes BX501

components on an ASIC and hardware modules forMAC-layer control on FPGA in Verilog.

In addition, there are SDR projects that are im-plemented in both hardware and software on a plat-form that comprises both processor and FPGA, andthis often includes many custom-made components.WARP is scalable, extensible programmable wire-less platform produced by Rice University to proto-type advanced wireless networks [15]. It combinesa MAX2829 RF transceiver, high-performance pro-grammable hardware Xilinx Virtex-4 FPGA board,and an open-source repository of reference designsand support materials. This platform has been usedto build, among many other things, a full duplexIEEE 802.11 network with OFDM and a MACprotocol [16], and a distributed energy-conservingcooperation MAC protocol for MIMO performanceimprovements [17]. USC SDR presents a wirelessplatform to remove bottlenecks from current SDRarchitectures [18]. It combines Xilinx VC707 PCIFPGA development boards with self-sufficient ra-dio front-end daughterboards to make a MIMOtestbed, using the FPGA Mezzanine Card (FMC)connection. Real-time SW architecture allows userprograms to perform signal processing tasks, PHY-and MAC-layer algorithms. The Sora soft-radiostack combines a Radio Control Board (RCB) witha multi-core CPU. The RCB that consists of aVirtex-5 FPGA, PCIe-x8 interface, and 256 MBof DDR2 SDRAM [19]. Microsoft Research builtthe SoftWiFi Demo radio system to interoperatewith 802.11a/b/g NICs, and it uses a company-proprietary language for SDR description.

There are other SDR projects that are imple-mented using Xilinx Zynq SoC, utilizing both thePS/ARM processor and PL/FPGA fabric. Iris usesXML description to link together components toform a full radio system [20]. Components arerun within an engine, which could be either a PSprocessor core or PL logic fabric. It’s tested usingOFDM for video transmission. GReasy presents aGNU radio version for Xilinx Zynq, using Tflowto instantly program FPGA fabric [21]. [22] usesZynq SoC to implement digital pre-distortion algo-rithm (DPD), which mitigates the effects of poweramplifier (PA) nonlinearity in wireless transmitters,something required for 3G/4G base stations. Thisuses Vivado HLS to design the PL component andreceives up to 7X speedup from HW acceleration.[23] proposes a scalable cluster of Zynq ZC702

5

boards, controlled by a Zedboard that acts as atask mapper to partition data flows across the ZynqFPGAs and ARM cores. tFlow rapid reconfigurationsoftware was used to build FPGA images from alibrary of pre-built modules.

[24] describes an SDR-based testbed that imple-ments a full-duplex OFDM physical layer and aCSMA link layer using MATLAB R2013a, MAT-LAB Coder on USRP-N210 and USRP2 hard-ware. The IEEE 802.11a based PHY layer, incorpo-rates timing recovery, frequency recovery, frequencyequalization, and error checking. The CSMA linklayer involves energy detection based carrier sensingand stop-and-wait ARQ. It outlines some strategiesin establishing bidirectional communications. How-ever, this approach involves additional developmentefforts to improve speed and enable full-duplexoperation.

The above platforms make for capable choices interms of performance. However, our choice of theoperating environment was motivated by the pricepoint, which is why we chose to use the combinationof USRP N210 hardware and MATLAB softwaretowards link layer implementation. So far there hasbeen little support for MATLAB in the existingSDRs and, in this regard, our framework allowsfor quick development of new higher layer protocoldesign. In addition, our software-only infrastructureallows for full flexibility of parameter choices, anoption not available to many other SDR platforms.

IV. STATE-ACTION BASED SYSTEM DESIGN

Our approach involves first designing a numberof (i) state diagrams to reflect the logical and time-dependent operational steps of our system, and (ii)block diagrams to reflect the sequential order ofoperations. Furthermore, we structure the MATLABcode in a way that enables slot-time synchronizedoperations. For the implementation, we use MAT-LAB Coder to generate the MEX functions for theUSRP objects on an Ubuntu 64-bit platform thatserves as the host computer for the USRPs.

Since the underlying code in a MEX functionis written in C, it is generally faster than theinterpreted MATLAB. The speed-up in performancecan vary depending on the application. In our case,we preferred the MEX interface because it canenforce a consistent processing time per frame.The interpreted MATLAB, unlike the MEX, lacks

Fig. 2: System Methodology

this ability because it exhibits significant deviationfrom the desired timing. In addition, time-sensitiveoperations such as frequency offset compensation,show speed improvement using MEX.

Our system design builds upon an already-definedplatform, the USRP, produced by a well-knownplatform supplier, Ettus Research [3]. The com-munication between the USRP and host computeris established in MATLAB using the Communica-tions System Toolbox (CST) USRP Radio supportpackage, which acts as a wrapper for the EttusUSRP Hardware Driver (UHD) drivers. Identifyingthe manner in which the RF samples are transportedbetween the USRP and a calling function defines themanner in which we must build the physical (PHY)layer, as illustrated in Fig. 2.

The UHD transfer of a frame of samples toa transmit buffer is performed as soon as it isrequested while the UHD retrieval of a frame froma receive buffer has to wait until the next risingedge of a clock cycle before trying to retrieve again.The most common undesirable behaviors that canoccur are underflow and overflow. Underflow occurswhen the radio requests for a frame of data fromthe transmit buffer, but the host is not yet ready toprovide it. Overflow occurs when the receive bufferbecomes full and buffered data must be overwritten.

In this regard, we define real-time operation overthe course of an entire DATA-ACK packet exchangeusing equation (1) below:

treceive ≤ tradio (1)

where tradio is the frame time stipulated by theUSRP radio's analog-to-digital converter (ADC) and

6

treceive is the average time to recover any givenframe, which includes the time to retrieve a framefrom the receive buffer, process the retrieved frameto decode it into the corresponding bits, and othermemory and conditional operations.

Essentially, we operate in real-time if we meetthe timing deadline set forth by equation (1). Suchan operation will guarantee a stable, basic bi-directional link that shows no sign of any unde-sirable system behavior, such as buffer underflowor buffer overflow. A MAC protocol that effectivelyschedules packet transmissions reduces the potentialfor packet collisions and buffer overflow, therebydecreasing packet errors.

A. Slot-time synchronized operations

Any IEEE 802.11-based wireless transceiver im-plementation must have the ability to perform oper-ations based on some slot-based timing. Performingsuch slot-time synchronized operations will let usrealize time-sensitive functions, for example, makea node wait for a backoff (BO) duration beforesending a DATA packet.

Interpreted MATLAB or any other software thatruns on the host computer may have trouble per-forming such operations in this manner, even byactively waiting. For this reason, we rely on theUSRP for our timing. Using the value for USRPinterpolation/decimation defined in Section V-C1,we can calculate the slot time. Then, we write ourwhile loop in the main program so that it calls thetransceive function once per loop, running helperfunctions to prepare data to transmit or processreceived data based on the active state, as shownin the program code in Listing 1.

while ˜endOfTransmissionif (state==Tx)data2Tx = processData2Tx();

enddataRxd = transceive(data2Tx);if (state==Rx)processRxdData(dataRxd);

endend

Listing 1: Main program calls transceive function

At the heart of the transceiver model is thetransceive function, as shown in Listing 2. By de-sign, transceive is called at a constant time intervalthat we define as a slot time. At each slot time,

Fig. 3: Transceive Function Behavior as Definedby Operational State

transceive sends and receives a fixed number ofsamples, which we refer to as a USRP frame.

We define a slot time as the smallest unit oftime in which our SDR can make a decision. Inour design, the frame time is the minimum timeour system takes to make a decision and hence,we equate it to the slot time. In this regard, ourtransceive function performs two actions: it getsa frame from, and puts a frame into the USRPbuffers at fixed time intervals [9]. A data frameis sent or received every slot time and further, thefunctions we define for processing the received dataframe or preparing a new data frame to transmitare intended to complete in less than a slot time toensure timing accuracy. In practice, we recognizethat the processing time for certain frames mayexceed the radio time, tradio, but the recovery time,treceive, converges to the radio time.

When a node (either DTx or DRx) enters a trans-mit state (refer to Fig. 3), it transmits the samplesin the transmit buffer and ignores all samples inthe receive buffer. On the other hand, when a nodeenters a receive state, it retrieves samples from thereceive buffer for processing and puts zeroes inthe transmit buffer. This way, we make sure thatthe samples in the transmit and receive buffer arecurrent and relevant.

7

function dr = transceive(ft, d2s)persistent hrx htx;% Initialize received data variablesdr = complex(zeros(nspf,1));ns = 0;% Initialize system objects onceif isempty(hrx)hrx = ...; htx = ...;

end% Flag to release system objectsif ftrelease(hrx); release(htx);

elsestep(htx,d2s);while (ns == 0)[dr,ns] = step(hrx);

endend

Listing 2: Transceive function code

The step method of the transmitter object operatesin a blocking way as it returns only after the radioaccepts the frame to be transmitted. On the otherhand, the step method of the receiver object returnsright away, hence it is non-blocking.

The step call of receiver object will return 0 aslength of the received frame if there is not enoughdata in the radio. Once the radio collects enoughdata, the next step call returns a non-zero lengthvalue and the valid data. Since we know the samplerate of the data and the number of samples in aframe, we can calculate how long it takes to getone frame of data from the radio. The while loopblocks the transceive function until a frame of datais received. Therefore, we can use the call durationof this function as our clock source.

B. Designated Transmitter State Machine

In implementing the carrier sense multiple accesswith collision avoidance (CSMA/CA)-based proto-col in the link layer, we identify 4 main states forthe DTx, as shown in Fig. 4. Table I identifies theblocks in each substate and is described in detail inSection IV-D.

1) Detect Energy: At the start, a new USRPframe arrives, and gets stored in a receive buffer.The DTx begins to continually sense energy inthe channel and decides to transition either into abackoff state or to a transmit state depending onwhether or not the channel is busy. It first waitsfor a DCF interframe spacing (DIFS) duration andthen waits for a random amount of time that ischosen uniformly from a progressively increasing

Fig. 4: States for the Designated Transmitter (DTx)

TABLE I: Substate Operation Combinations

Block Block ComponentsSMSRC Scrambling, Modulation, Spreading, and

Raised Cosine Transmit Filter (RCTF)

RFFE Radio Frequency Front End: includes

Automatic Gain Control (AGC),

Coarse Frequency Offset Estimation (CFOE),

Frequency Offset Compensation (FOC),

and Raised Cosine Receive Filter (RCRF)

PD Preamble/SYNC Detection:

Find SYNC in Rx’d USRP frames

DDD Despreading, Demodulation, and Descrambling

time interval. Only when the channel is free doesthe DTx decrement the chosen random backofftime; otherwise, it stalls. Only when the backofftime counts down to zero does the DTx attempt totransmit.

2) Transmit DATA: Upon entering this state, theDTx prepares the DATA packet and then, by callingthe transceive function continually, places it in thetransmit buffer of the USRP which then gets trans-mitted over the air. After transmitting the DATApacket, two possibilities exist. The transmission issuccessful with the reception of an ACK, or thetransmission is not successful due to packet collisionwith another DTx.

3) Receive ACK: As soon as the DATA packetis transmitted, the DTx moves into the ReceiveACK state, searching and decoding the PhysicalLayer Convergence Procedure (PLCP) header in

8

Fig. 5: States for the Designated Receiver (DRx)

the received ACK. If that is successful, the framecontrol and the address fields are read-out fromthe subsequent MAC header and checked for ac-curacy. The DTx then progresses to transmit a newframe and repeats the above mentioned sequence ofsteps until the last frame is successfully transmitted.On the other hand, if no ACK is received, thepacket is considered lost and the DTx backs-off foran increased random backoff time and re-attemptstransmission.

4) End Of Transmission: When there are nomore DATA packets left to be transmitted, the DTxreaches the end of transmission (EOT) state.

C. Designated Receiver State MachineSimilarly, we identify 3 main states for the DRx

as shown in Fig. 5. Unlike the DTx, the DRx doesnot perform energy detection.

1) Receive DATA: When the DRx successfullydetects the Preamble and the Start Frame Delimiter(SFD), it decodes the PHY and MAC header andthen progresses to extract the payload. When ex-tracting the last set of payload bits, Frame CheckSequence (FCS) is obtained and checked.

2) Wait SIFS: The DRx waits for a fixed intervalof time, referred to as Short Inter-frame Space(SIFS), before sending an ACK packet post recep-tion of the DATA packet.

3) Transmit ACK: The DRx sends out an ACKaddressed to the DTx when it successfully retrievesall the payload bits.

D. System BlocksWithin each of the substates in the FSM diagrams

(Figs. 4 and 5), there are sequential operations that

need to be performed. In order to simplify the logicof which operations must be performed in eachstate, we define a number of blocks to comprisethe most common operations, as shown in Table I.Identifying the grouping of blocks with the relatedsubstates helps better organize and restructure theimplemented code.

In each substate of DTx state 2 (Tx) and DRxstate 2 (Tx ACK), SMSRC is performed prior toeach transceive (send and receive operation). InDTx substate 3.1 and DRx substate 1.1, RFFE andPD are performed after each transceive. In DTxsubstate 3.2 and DRx substates 1.2, RFFE and DDDare performed after each transceive.

V. PHY LAYER ALGORITHMS

A. RF Front End AlgorithmsThe components in the RFFE block recover a

signal prior to preamble detection. These includethe automatic gain control (AGC), frequency off-set estimation and compensation, and raised co-sine filtering. The ordering of these componentsis an important consideration, and through exhaus-tive simulations, we found the preceding orderto be ideal. The AGC algorithm counters atten-uation by raising the envelope of the receivedsignal to the desired level. We chose to usethe MATLAB comm.AGC object [25]. To accu-rately estimate the frequency offset between thereceiver and the transmitter, we chose to use thecomm.PSKCoarseFrequencyEstimator ob-ject, which uses an FFT-based-based method, basedon equation (2), and finds the frequency that maxi-mizes the FFT of the squared signal:

foffset = argmaxfF{x2} (2)

where x is the signal, F denotes the Fast FourierTransform (FFT), and foffset is the frequency offset.

1) Speeding up the RFFE block: From our initialexperiments, we know that a frequency resolution(on the order of 1-10 Hz) is necessary in order todo preamble detection accurately. Setting such a lowfrequency resolution takes too long to execute witha sample rate of 200 kHz, or 200,000 samples persec. For this reason, we decided to decimate thesignal by a factor of 22 (the RCRF factor times thespreading rate) before CFOE, which is, in essence,an FFT. After decimation, we experimented withraising the CFOE’s frequency resolution by an order

9

of magnitude to 10-100 Hz, and determined thatit is accurate up to 100 Hz and meets the timingguidelines set by radio time.

We employ a FIR Decimator step, as shownin Listing 3, that enables us achieve an order ofmagnitude reduction in RFFE block executiontime. In essence, we are able to get enoughfrequency estimation accuracy with reduced samplerate (hence the use of decimation) and 100 Hzfrequency resolution, which requires much lessprocessing power than full frame higher resolutionestimates.

(1) dsp.FIRDecimator(’DecimationFactor’,22);(2) comm.PSKCoarseFrequencyEstimator(

’Algorithm’,’FFT-based’, ...’FrequencyResolution’,cef,...’ModulationOrder’,2,...’SampleRate’,(2e5/22));

Listing 3: RFFE Decimation Method

B. Preamble Detection Algorithms

The IEEE 802.11b preamble is a sequence ofall one bits that undergoes scrambling. Since thescrambling phase is not known, and the receivedsignal is correlated to the zero phase scrambledsequence, the maximum correlation position maynot be the synchronization position. Therefore, thestandard provides Start Frame Delimiter (SFD), tofine tune the synchronization time.

Preamble detection (PD) is performed in twostages. In the first stage, we perform a cross-correlation of the received complex data after raisedcosine filtering with the expected real preamble toget an estimate of where the preamble starts, givingthe so called synchronization delay. Finally, in thesecond stage, we look for the SFD immediatelyafter the preamble in the descrambled bit stream.If it is not in the expected place, we perform across-correlation on a window of descrambled framesamples to the left and right to further fine-tune thesynchronization delay.

1) Optimization of Preamble Detection:Detecting the Preamble fast and with high accuracyis critical to the speed at which the nodes canreliably exchange DATA/ACK packets. In oneimplementation, we exploit the property of thecross-correlation of two real signals in the frequencydomain to compute the same (i.e. the point-wise

Fig. 6: Comparison of Execution Time for 5Methods of Computing Cross-Correlation

product of the Fourier transform of the two signals),followed by an inverse Fourier transform resultingin the cross-correlation of the two signals. Sinceone of the signals is the expected preamble, itsFourier transform can be pre-computed and loadedinto the workspace during run-time.We experimented with several MathWorksutilities to compute cross-correlation faster (e.g.dsp.CrossCorrelation object, xcorrfunction).We determined the version ofdsp.Crosscorrelator(’method’,’fastest’) compiled using MEX to bethe fastest among all the candidate methods forcomputing cross-correlation with increasing signallengths, as shown in Fig. 6. It is important to notethat although we operate with signal lengths onthe order of 103, preamble detection is a frequentoperation, so savings in time add up quickly.We declare packet detection only if the secondstage finds a perfect match for the SFD. Thisapproach greatly minimizes false packet detections.

C. Parameter SelectionThe initialization step described in Section II lets

us carefully choose a number of design parameters(see table II).

1) Constant Parameters for USRP & IEEE802.11b Frame: We recognize parameters that can-not change during packet transmission/reception andhave to be fixed. The number of octets in thepayload per IEEE 802.11b packet should be maxi-mized to decrease the header overhead. In that case,a large frame size is preferred as it reduces thepercentage of overhead processing. On the other

10

TABLE II: Important Parameters

Param Block Description Range TunableRi, Rd USRP USRP Interpolation 500 No

Decimation FactorLf USRP USRP Frame 64 bits No

LengthLp Frame #Octets per 802.11b 0-2312 Yes

Packet PayloadK RFFE AGC Max 30-60 Yes

Power GainN RFFE AGC Adaptation 0.01-0.5 Yes

Step Size∆f RFFE Frequency 1-100 Hz Yes

Resolution

hand, the frame size should be minimized to makequick decisions with a small number of samples orbits, unlike a large frame size which increases theframe time, thereby reducing the resolution of timeticks for the system. We chose frame length of 1408as a well balanced compromise between these tworequirements. For this reason, the frame length isleft fixed.

The USRP N210 analog-to-digital converter(ADC) operates at a fixed rate of 100 MHz. TheUSRP interpolation-decimation rates control the rateof transmitting and receiving frames. For example,setting interpolation rate, Ri, and decimation rate,Rd, to 500 ensures that the ADC and DAC converta sample every 5 µs, as shown in equation (3).

tsample = Ri/(100Msamples/sec)

= 500/108

= 5× 10−6sec/sample

(3)

Setting frame length, Lf , to 1408 samples meansthat a frame is retrieved by the transceive functionevery 7.04 ms, as shown in equation (4).

tradio = Lf × (Ri/100Msamples/sec)

= 1408× (500/108)

= 7.04× 10−3sec/frame

(4)

Even though our system may take more than7.04 ms to process a frame every once in a while,the buffers in the USRP receiver prevents the systemfrom overrunning (or lose samples) and the system,on average, stays real-time.

2) Tunable Parameters for RFFE Block: Tunableparameters can change during transception. For ex-ample, the AGC adaptation step size controls theconvergence speed of a received signal’s envelopeto the desired level. In other words, it governs the

speed of convergence. The frequency offset esti-mation component’s frequency resolution setting isan important design consideration as it is inverselyproportional to the FFT length. A lower frequencyresolution gives more accurate offset estimates, butwith increased computational time.

D. Same-Frequency Channel Operation

In a multi-node setting, it is advantageous tooperate the transmit and receive links, at the DTxand DRx, in the same band of frequencies. Thus, weset both DTx and DRx to operate at the same centerfrequency. Unlike different-frequency channel oper-ation, this eliminates the need for repeated switchingof transmit and receive center frequencies whentransitioning among the energy detection, transmit,and receive states. In addition, it makes for an easierimplementation of medium access and contentionresolution.

From our initial experiments, we learned that thereceive-only port, RF2, of the USRP leaks about7 dBm into the transmit & receive port, RF1. Theeffect of this leakage causes the DTx to detect thepreamble in its own DATA packet while it is waitingfor an ACK. We added logic to ensure that the DTxrejects its own DATA packet as soon as it reads theMAC header and does not find the expected ACKframe control sequence.

VI. MAC LAYER DESIGN

We first implement the CSMA/CA protocol thatallows the nodes to sense the channel and attemptto transmit packets only when the channel is idle toavoid packet collisions. Then, we modify this baseimplementation with the standards-specific func-tions, as described below.

A. MAC Overview

Our MAC layer employs the Distributed Coor-dination Function (DCF) strategy incorporating theCSMA/CA mechanism as it is described in theIEEE 802.11 specification [8]. Our implementationincorporates the key features of CSMA/CA, namely,1) carrier sensing via energy detection, 2) DCFinterframe spacing (DIFS) duration, and 3) exponen-tial random backoff. An illustration of the overallsteps of the operation is shown in Fig. 7 and Fig.8.

11

Fig. 7: CSMA/CA/ACK Timeline Chart - EnergyDetection

Fig. 8: CSMA/CA/ACK Timeline Chart -Exponential Random backoff and Retransmission

1) Energy Detection: Channel occupancy can beidentified by detecting RF energy in the channel.Energy in the channel is computed using equation(5).

Energy =n=N∑n=1

|x(n)|2 (5)

In our implementation, x(n) represents the samplesin the USRP frame retrieved from the receive bufferof the USRP.

2) DIFS Period: The standard specifies thatwhen a packet is prepared by the DTx and readyto be sent to the intended DRx, the DTx mustactively listen to the channel for a fixed specifiedamount of time known as the DIFS period. If duringthis period, the DTx senses RF signal energy fromother transmitting devices (i.e. when the channel isfound busy), it defers the transmission and enters aChannel Occupied state. In this state, the DTx staysidle as long as the ambient RF energy is above aspecified threshold. When the energy drops belowthe threshold (i.e. the medium is sensed to be free),the DTx resets the DIFS duration and starts countingdown again.

3) Binary Exponential Random Backoff: Thismethod of random backoff is used to scheduleretransmissions after collisions. Essentially the re-transmissions are delayed by an amount of timedetermined by a minimum contention window, cmin,

and the number of attempts to retransmit the DATApacket. With this increased number of retransmitattempts, the delay can increase exponentially.

When the DIFS duration runs out, the DTxtransitions to the exponential random backoff statewherein it generates a random backoff delay uni-formly chosen in the range [0, W-1] where W iscalled the contention window (CW).

In correspondence with the IEEE 802.11 stan-dard, time is slotted using a basic time unit whichis the time needed to detect the transmission of apacket from any other station. In our implementa-tion, tradio represents the basic time unit for thesystem, within which we can detect another DTxtransmitting.

As an example, after k collisions, a randomnumber of slot-times is chosen at random from[0, 2k-1] as described in equation (6).

Random Back-off Delay = randi[0, 2k-1]× tradio (6)

The MATLAB randi function picks an integeruniformly at random from the specified interval. Inour implementation, we have the option to truncatethe exponentiation with a fixed number of retrans-mits so as to have a ceiling for the Random backoffDelay.

VII. EXPERIMENTAL SETUP

We use the USRP N210 platform [3], as it allowsus to define the parameters listed in Section V-C1,connect to a PC host using a gigabit Ethernet cable,and to program it using MATLAB [5]. We use theUbuntu OS, with send and receive buffer sizes forqueues set to ensure that there is enough kernelmemory set aside for the network Rx/Tx buffers.We also set the maximum real-time priority forthe usrp group to give high thread schedulingpriority. This change is made by adding a lineto the file \etc\security\limits.conf thatsets the rtprio property for the @usrp group to50. The overall setup is shown in Fig. 9.

A. Communications System Toolbox USRP SupportPackage

We use the Communications System Tool-box objects for our design [26]. We used thecomm.AGC object and the PSK coarse frequencyoffset estimator that allows us to work withFFT-based options. These objects facilitate easy

12

Fig. 9: Transceiver Hardware Setup

generation of C code using MATLAB Coder.Here, the comm.SDRuTransmitter object putsa frame on the USRP transmit buffer, andcomm.SDRuReceiver gets a frame from theUSRP receive buffer. However, this approach hassome disadvantages, such as a requirement for fixedframe length and single-threaded step methods.

B. MATLAB CoderA number of steps must be taken to make the

MATLAB code ready for C code generation usingMATLAB Coder. All variables that do not changeover the course of the program execution are given astatic size and type (including real or complex). Allobjects are declared as persistent variables as theycannot be passed into MEX functions. The first callto each function tests whether the persistent variableis empty, and initializes each object if true. Thetransceive and RFFE function code are designed inthis manner.

VIII. EXPERIMENTS AND RESULTS

We choose to evaluate our system using a numberof experiments. First, we time the reception ofDATA packets at the DRx. Next, we time the RFFEblock using both interpreted MATLAB and MEX.We then perform a two node experiment, measuringbi-directional link latency and packet error rate.We then profile execution time in the transmittingstates. Finally, we perform a three node experiment,measuring previous metrics and goodput.

In the three node experiment, we address the fair-ness in our system. Considering two bi-directionallinks emerging from two DTxs but incident on aDRx helped us to design (within hardware con-straints) and demonstrate a stable bi-directional link

Fig. 10: Process Time per USRP frame at DRx

and allowed us to test the fairness enabled by theMAC protocol in the most simplified way, therebyeliminating the need for further multi-node sce-narios. Performing more scenarios would requiresetting up and performing experiments involvingmultiple nodes and host machines, and would takea large amount of effort. Such an effort would nothave helped us in attaining our goal of fairnessassessment. In addition, we can presume that anincrease in the number of DTx nodes would exhibitless fairness because it increases the likelihoodof collisions. In this situation, nodes that wouldcollide would also choose to wait for increasedbackoff periods, which would give other nodes anincreased opportunity for transmissions. Additionaltests would not be necessary to confirm this hypoth-esis.

A. Timing DATA Packet Reception at DRxAt the DRx, after preamble detection, the elapsed

time to process each retrieved USRP frame corre-sponding to an entire DATA packet is shown in Fig.10. The dotted line represents the average of allthe frame processing times towards a DATA packetreception. The DTx sends out a DATA packet that ismade up of 258 USRP frames. After recovering theheader bits, the DRx retrieves the payload, whichis 250.5 USRP frames (2004 octets). Since thePreamble is 128 bits long, it corresponds to 2 USRPframes. Hence, we account for the reception of (258- 2) = 256 USRP frames in the DATA packet.

The time to process any given frame usually fallsbelow the desired frame time, tradio, and is fairlyconstant at 2.87 ms. The first set of frames have ahigher processing time because they consist of theMAC header information that must be resolved (e.g.frame control, MAC address).

13

Fig. 11: RFFE block timing using interpretedMATLAB and MEX

B. RFFE Block Timing

The timing of the RFFE block for various valuesof the frequency resolution parameter in interpretedMATLAB and C code compiled into MEX is shownin Fig. 11. The addition of a FIR decimationstep in the RFFE block reduces the sampling rateof the input for the subsequent coarse frequencyoffset estimation (CFOE). This reduction helps inincreasing the frequency resolution, currently set at100 Hz, which is the key parameter in controllingthe execution time of CFOE. Further, we benefitfrom the improved accuracy of CFOE in that itcorrects the signal so well that the later preambledetection block produces the correct synchroniza-tion delay to detect the start of DATA/ACK packet.The results clearly establish that average executiontime for the RFFE block decreases with increasein frequency resolution. The reason for this is thatCFOE uses progressively smaller FFT lengths. Asbefore, the average execution time using MEX isgenerally smaller than using interpreted MATLAB.Also, the standard deviation for MEX results isalways significantly less. Hence, MEX is a betteroption for the purpose of enforcing consistent RFFEexecution times, which is required for slot-timesynchronized operations.

C. Two Node Performance (1 DTx and 1 DRx)

Link layer contention resolution and other MAClayer functions depends on the ability to reliablygenerate alternating DATA-ACK packets betweenthe sender and receiver. In this regard, determiningthe performance of this basic link is important.

Packet error rate (PER) and bi-directional linklatency are key performance indicators of the two

Fig. 12: Two Node Performance: Packet Error Rate

node system. Of particular interest is the perfor-mance of the system when the transmit power levelof the DTx is decreased below standard levels. TheDTx was set up to send IEEE 802.11b compliantpackets each with a large payload of random binarybits (2012 octets). The DRx receives the packet,checks for the correctness of the header informationand acknowledges the receipt of the DATA packetby transmitting an ACK. The experiment was de-signed to be statistically significant, and hence, 100packets were transmitted for each of the 5 differenttransmit gain settings. The results were averagedover 5 runs.

The experimental setup involved two host com-puters, both running MATLAB R2015b on a UbuntuOS environment, each interfaced via the Ethernetcable to a USRP N210. The devices are configuredto be DTx and DRx respectively and are kept abouta meter apart.

1) Packet Error Rate: A packet is in error if theACK for the same is not received in time by theDTx. This could mean that either the packet couldnot be decoded properly by the DRx or that the ACKwas corrupted or lost while in transit to the DTx.An ideal system must recover quickly from sucherrors and, best trade-off PER and bi-directional linklatency. PER is measured on average in percentagereflecting how many packets might be received inerror for every 100 packets sent.

2) Bi-directional Link Latency: Bi-directionallink latency is the average time taken by the DTxbetween sending a DATA packet and receiving thecorresponding ACK packet. The bi-directional linklatency includes any delay resulting from retrans-missions accounting either for loss of DATA packetor ACK packet. Note that since the MAC layer coderuns during the course of the experiment, the bi-

14

Fig. 13: Two Node Performance: Bi-directionalLink Latency

directional link latency includes the DIFS durationand the random backoff period both set at 20 ms.The MAC layer functionality however is largelydormant in the 2 node case due to the lack ofcontention. Bi-directional link latency is averagedfor a packet in seconds.

In the two node system, increasing DIFS andbackoff time practically has no effect on the packeterror rate due to lack of contention. However, in-creasing DIFS and backoff time also increases linklatency by the same amounts. It should be noted thatin the specifications, DIFS and contention windowslot time are both fixed constants.

D. Profile of Time Elapsed in DTx States

At the DTx, we measured the time elapsed ineach state for a DATA-ACK packet exchange. Thestacked plots shown in Fig. 14 and Fig. 15 showthe breakdown of the time spent in each substate.The plot at the top shows the small contributorsto the overall processing time, and the one at thebottom shows the large contributors. Both the plotsare part of the same DATA-ACK packet exchangeand are separated for clarity. Note that (1) the timespent in the MAC portion of the code includesthe time elapsed to detect energy in the channelcontinually together with the DIFS and randombackoff duration, and (2) the time taken to send theIEEE 802.11b DATA packet includes the time toprepare the packet.

From Fig. 12 and Fig. 13, we can infer that the 2node experiments show that the system guarantees aconsistent≤ 5% packet error rate and approximately7 seconds of bi-directional link latency (DATA-ACKpacket exchange inclusive of the MAC functions)

Fig. 14: Timeline Breakup of DATA-ACK PacketExchange at DTx

Fig. 15: Timeline Breakup of DATA-ACK PacketExchange at DTx

over a wide range of transmit gains (15-30 dB).Importantly, varying the distance between the 2nodes does not significantly affect performance.Even moving the 2 nodes farther apart while stillin line-of-sight (e.g. by 15 meters), the PER and bi-directional link latency stayed consistent. However,the presence of many metallic surfaces, such as inour lab setting, give rise to multi-path reflectionsthat can be strong and result in packet errors. Thefact that the performance was significantly betterwhen the nodes were connected by RF cables con-firms the case.

Keeping the packet sizes identical (DATA andACK are 2072 octets and 40 octets long respec-tively), the standard off-the-shelf devices, oper-ating at standard specified timings, the link la-tency Lstd−link (neglecting media contention, back-off times, and retransmissions) can be computed us-ing Equation 7. TxDATA and TxACK represent theelapsed time (in microseconds) to transmit a DATA

15

packet and an ACK packet (at 1Mbps) respectively.

Lstd−link = DIFS + TxDATA+ SIFS + TxACK

= 50µs+ (2072× 8)µs+ 10µs+ (40× 8)µs

= 16956µs = 16.956ms(7)

Comparing this to tradio in equation (4), we seethat the link latency is in the same order as ourslot time. Owing to hardware constraints, packetexchanges in standard devices are in the order ofmilliseconds while exchanges in this system are inthe order of seconds. However, we argue that this isacceptable because our system adds the feature ofsoftware definition, which requires additional timefor execution.

E. Three Node Experimental Setup (2 DTxs and 1DRx)

Given that without the MAC layer, theDATA/ACK packet collisions and the linklatencies will be unacceptably high, we performedexperiments to assess the MAC performance with aset of 3 USRPs (three nodes: 2 DTxs and 1 DRx).To that end, we implemented MAC functionsto distinguish the two links and fine-tuned theMAC/PHY parameters of the system. We expect tosee increased bi-directional link latency and PERas the DTxs contend to gain access to the channelleading to packets collisions and subsequentretransmits.

In our 2 node experiments, we confirmed thatfor a wide range of transmit gains, the performanceremains consistent. We now have two independentlinks incident on one shared DRx, and hence, wedo not expect to see much difference in the perfor-mance of the two links when varying the transmitgains here in the 3 node case. Instead, we measuredbi-directional Link Latency and Packet Error Ratefor DATA-ACK packet exchange in the two linksas shown in Fig. 16 by varying the payload size inthe DATA packet. Essentially, the experiments letus compare the individual performances of the twolinks and further establish the MAC layer’s role inenforcing fairness among the DTxs in accessing thechannel.

1) Implemented MAC functions: The MACheader format for DATA and ACK shown in Fig.17 and Fig. 18 respectively will aid in discussion ofthe MAC layer functions [8].

Fig. 16: Three Node System with 2 DTxs and 1DRx

Fig. 17: MAC Header - DATA packet [8]

Fig. 18: MAC Header - ACK packet [8]

The DRx determines the DTx address from theMAC header of the received DATA packet and sendsout an ACK addressed to that DTx. Furthermore, theDRx can reject DATA packets not addressed to it.Note that steps right from preamble detection, SFDdetection, all the way up to reading into the IP ad-dress of the DTx from the MAC header, are carriedout at the DRx, preceding the rejection of that DATApacket. On the other hand, the DTxs can determinethe DRx from the MAC header of the receivedACK and can go on to either accept or reject theACK based on the IP Address. Previously, we hadthe DTx re-transmitting DATA packet only towardslost ACKs. Clearly, these are the MAC functionsnecessary for scaling up the system, enabled byreading into the MAC header of the DATA/ACK

16

packet.2) MAC parameters: We learned from our initial

set of experiments that the DATA/ACK packet pro-cessing in the host machine takes significantly moretime compared to time taken in transmitting a DATApacket. This is expected as most SDRs use a hostcomputer for processing. Also, the SIFS duration,set in the order of microseconds in commercialproducts, imposes a time constraint in most SDRsthat is difficult to achieve. The reason is that thelatency for the signal to move back and forth fromthe radio to the host exceeds the SIFS durationrequirements. The standard specifies the constantsas follows: Slot-time = 20 µs, SIFS = 10 µs, DIFS= SIFS + 2 x Slot-time = 50 µs.

The experiments helped us fine-tune the DIFSduration (which the standard specifies be greaterthan SIFS), random backoff duration, and ACKtimeout duration towards fewer packet collisions. Asa result, we performed our experiments with DIFSduration, minimum contention window, and ACKtimeout duration set at 0.75, 0.5, and 5.0 seconds,respectively.

3) Picking the Energy Threshold: Three nodeperformance relies heavily on the energy detectionstep at both the DTxs. Accuracy of energy detectionis critical and it requires the energy threshold becarefully picked at both the DTxs, enabling eachDTx to back off as soon as they sense anotherDTx transmit, and subsequently transmit at theright instants of time, thereby keeping the packeterrors and bi-directional link latency to a desiredminimum. Additionally, it enforces fairness towardschannel access among the DTxs.

The receive gain set at the DTx and the inter-node distances (1 meter in our experiments) affectthe magnitude of the energy threshold. A valueclose to and slightly above the noise floor set asthe energy threshold will not work as intended, asa power-cycle of the USRP changes it. Also, anenergy threshold set at a large value might notallow the DTxs to sense each other transmittingdue to rapidly fluctuating RF power output despitethe AGC. Therefore, each DTx may not backoffat the right instants, leading to collisions at theDRx. However, by picking a small enough energythreshold, which is enough to detect signal energyover channel noise, we could make each DTx sen-sitive enough to sense the other DTx transmittingand backoff fairly well, thereby reducing packet

Fig. 19: Three Node Performance - Packet ErrorRate of the Links

Fig. 20: Three Node Performance - Bi-directionalLink Latencies

retransmissions.

F. Three Node Performance: Experimental Results

Packet error rate and bi-directional link latencyfor DATA-ACK packet exchanges in the two linksvarying the payload size in the DATA packet areshown in Fig. 19 and Fig. 20, respectively. Fourdifferent payload sizes, 500, 1000, 1500, and 2000octets, were used for the experiment to measure 3node performance.

Smaller payload sizes correspond to smaller pack-ets and decreased time that the DTx is occupyingthe channel whereas larger payload sizes increasesthe likelihood of packet collisions. The link latencyand the packet error rate in the latter is bound toincrease as larger packets incur higher processingdelay at the DRx and more collisions necessitatingincreased packet retransmits.

1) Goodput: Goodput, a performance measureused in computer networks, is the rate at which

17

Fig. 21: MAC Layer Fairness - Averaged LinkLatencies

useful information bits traverse a link. Goodput canbe measured using equation (8),

Goodput =Total payload bits correctly decoded

Average Bi-directional Link Latency(8)

The average Goodput of the two bi-directional linkscomputed using (8) are shown in Table III. Noticethat the goodput increases with the payload size.The reason for this is that the combined PHY andMAC header occupies a decreased fraction of theentire DATA packet as the payload size increases.

TABLE III: Average Goodput for Varying PayloadSizes

Payload Size Link 1 Goodput Link 2 Goodput(#Octets) (Kbps) (Kbps)

500 0.41 0.401004 0.66 0.701500 0.89 0.892004 1.05 1.02

In the three node system, when there is a sym-metric increase in DIFS and backoff time at thetwo DTxs, then the system will remain fair withreduced contention, resulting in fewer packet errors.However, the goodput decreases as link latencyincreases. Also note that the standard specifies theDIFS and the contention window slot time be fixedconstants.

2) Fairness: The line shown in Fig. 21 is repre-sentative of an ideal system, in which the two DTxsaccess the channel equally often, such that their bi-directional link latencies are identical. Fairness is

an important feature for the system to possess, andis brought about by the MAC protocol.

Notice that the latencies of the two links deviateby only a small amount from the ideal line forvarying payload sizes. This result establishes therole and efficacy of the MAC layer in enablingand enforcing fairness among the two DTxs whenaccessing the common channel.

IX. CONCLUSIONS

Building our system around the concept of state-action based design and slot-time synchronizedoperations helped combine and realize the PHYand MAC layer that is IEEE 802.11b standardcompliant. In addition, the system allows the userreconfigure the parameter values as needed. Usingthe MATLAB Coder to automatically generate MEXfunctions is beneficial in improving the speed con-sistency of our system blocks, most notably RFFE,which can vary its frequency resolution parameter.This work provides a testbed to experiment withnew MAC protocols beyond that specified in theIEEE 802.11b standard. The state machine designenables modularity of code base and should allowfor extensibility by the community. The three nodesystem remains fair to the two bi-directional linksfor varying payload sizes in the DATA packet.Through our experiments we have established therole and efficacy of the implemented MAC layertowards mitigating packet collisions and enforcingfairness among DTxs in accessing a common chan-nel.

There were a number of difficulties during theimplementation that we had to overcome. Fore-most, we had trouble realizing slot-synchronizedoperations, one of the most crucial issues in real-time testbeds. Second, it was difficult to pick theright energy threshold to deal with a variable noisefloor due to environmental noise effects. Finally,our system required a thorough calibration stepprior to running experiments. The minimum receivegain settings at the devices are always different.While performing the experiments, we took care toisolate the experimental setup from highly reflectivemetallic surfaces and external transmissions, as istypical in a lab environment.

These experimental results have provided us withperformance benchmarks that will focus future workon further optimization and sophistication of the

18

MATLAB-based MAC layer. Also, as part of ourfuture work, we plan use this framework to performevaluation studies on the co-existence of LTE and802.11 Wi-Fi networks.

ACKNOWLEDGMENTS

This work is supported by MathWorks under theDevelopment-Collaboration Research Grant A#: 1-945815398. We would like to thank Mike McLernonand Ethem Sozer for their continued support on thisproject. We would also like to thank Taylor Skillingfor his support with the experiments.

REFERENCES

[1] I. F. Akyildiz, W.-Y. Lee, M. C. Vuran, and S. Mohanty, “Nextgeneration/dynamic spectrum access/cognitive radio wirelessnetworks: a survey,” Computer Networks, vol. 50, no. 13, pp.2127–2159, 2006.

[2] K. R. Chowdhury and T. Melodia, “Platforms and testbedsfor experimental evaluation of cognitive ad hoc networks,”IEEE Communications Magazine, vol. 48, no. 9, pp. 96–104,2010. [Online]. Available: http://dx.doi.org/10.1109/MCOM.2010.5560593

[3] Ettus Research, Inc. (2015) USRP N200/N210 NetworkedSeries. [Online]. Available: http://www.ettus.com

[4] Part 11: Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications: Higher-Speed PhysicalLayer Extension in the 2.4 GHz Band, IEEE Std. 802.11b-1999,1999.

[5] MathWorks, Inc. (2016) USRP Support from CommunicationsSystem Toolbox. [Online]. Available: http://www.mathworks.com/hardware-support/usrp.html

[6] R. Subramanian. (2016) IEEE 802.11b standard compliantlink layer code for MATLAB-based SDR. [Online]. Available:https://github.com/80211bSDR/LinkLayer-MATLAB

[7] ——. (2016) IEEE 802.11b link layerfor MATLAB-based SDR. [Online]. Avail-able: http://www.mathworks.com/matlabcentral/fileexchange/55784-ieee-802-11b-link-layer-for-matlab-based-sdr

[8] Part 11: Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications, IEEE Std. 802.11, 1999.

[9] B. Drozdenko, R. Subramanian, K. Chowdhury, andM. Leeser, “Implementing a MATLAB-based Self-configurableSoftware Defined Radio Transceiver,” in Cognitive RadioOriented Wireless Networks - 10th International Conference,CROWNCOM 2015, Doha, Qatar, April 21-23, 2015, RevisedSelected Papers, ser. Lecture Notes of the Institute for ComputerSciences, Social Informatics and TelecommunicationsEngineering, M. Weichold, M. Hamdi, M. Z. Shakir,M. M. Abdallah, G. K. Karagiannidis, and M. Ismail, Eds.,vol. 156. Springer, 2015, pp. 164–175. [Online]. Available:http://dx.doi.org/10.1007/978-3-319-24540-9

[10] GNU Radio Project. (2015) GNURadio: The free andopen source radio ecosystem. [Online]. Available: http://www.gnuradio.org

[11] C. R. A. Gonzalez, C. B. Dietrich, S. Sayed, H. Volos, J. D.Gaeddert, P. M. Robert, J. H. Reed, F. E. Kragh et al., “Open-source SCA-based core framework and rapid developmenttools enable software-defined radio education and research,”Communications Magazine, IEEE, vol. 47, no. 10, pp. 48–55,2009.

[12] M. Simon, P. Laaser, V. Filimon, H. Geltinger, D. Friedrich,Y. Raman, and R. Weigel, “An 802.11 a/b/g RF Transceiverin an SoC,” in 2007 IEEE International Solid-State CircuitsConference. Digest of Technical Papers, 2007.

[13] S. G. Kim and S. H. Cho, “Implementation of an embeddedsoftware modem platform,” in Advanced Technologies for Com-munications, 2008. ATC 2008. International Conference on.IEEE, 2008, pp. 356–359.

[14] Y. Jiao, X. Wang, G. Xiao, and H. Chen, “Design, implementa-tion and testing of an IEEE 802.11 b/g baseband chip,” in ASIC,2007. ASICON’07. 7th International Conference on. IEEE,2007, pp. 934–937.

[15] R. U. O. WARP Project. (2015) Wireless open-access researchplatform. [Online]. Available: http://warp.rice.edu/index.php

[16] M. Duarte, A. Sabharwal, V. Aggarwal, R. Jana, K. Ra-makrishnan, C. W. Rice, and N. Shankaranarayanan, “Designand characterization of a full-duplex multiantenna system forWiFi networks,” Vehicular Technology, IEEE Transactions on,vol. 63, no. 3, pp. 1160–1177, 2014.

[17] C. Hunter, L. Zhong, and A. Sabharwal, “Leveraging physical-layer cooperation for energy conservation,” IEEE T. VehicularTechnology, vol. 63, no. 1, pp. 131–145, 2014. [Online].Available: http://dx.doi.org/10.1109/TVT.2013.2271121

[18] H. V. Balan, M. Segura, S. Deora, A. Michaloliakos, R. Rogalin,K. Psounis, and G. Caire, “USC SDR, an easy-to-program, highdata rate, real time software radio platform,” in Proceedings ofthe second workshop on Software radio implementation forum.ACM, 2013, pp. 25–30.

[19] K. Tan, J. Zhang, J. Fang, H. Liu, Y. Ye, S. Wang,Y. Zhang, H. Wu, W. Wang, and G. M. Voelker, “Sora: Highperformance software radio using general purpose multi-coreprocessors,” in Proceedings of the 6th USENIX Symposiumon Networked Systems Design and Implementation, NSDI2009, April 22-24, 2009, Boston, MA, USA, J. Rexford andE. G. Sirer, Eds. USENIX Association, 2009, pp. 75–90.[Online]. Available: http://www.usenix.org/events/nsdi09/tech/full papers/tan/tan.pdf

[20] J. van de Belt, P. D. Sutton, and L. Doyle, “Acceleratingsoftware radio: Iris on the Zynq SoC,” in 21st IEEE/IFIPInternational Conference on VLSI and System-on-Chip, VLSI-SoC 2013, Istanbul, Turkey, October 7-9, 2013, M. Margala,R. A. da Luz Reis, A. Orailoglu, L. Carro, L. M. Silveira,and H. F. Ugurdag, Eds. IEEE, 2013, pp. 294–295. [Online].Available: http://dx.doi.org/10.1109/VLSI-SoC.2013.6673295

[21] R. Marlow, C. Dobson, and P. Athanas, “An enhanced andembedded GNU radio flow,” in Field Programmable Logic andApplications (FPL), 2014 24th International Conference on.IEEE, 2014, pp. 1–4.

[22] B. Ozgul, J. Langer, J. Noguera, and K. A. Vissers, “Software-programmable digital pre-distortion on the Zynq SoC,” in 21stIEEE/IFIP International Conference on VLSI and System-on-Chip, VLSI-SoC 2013, October 7-9, 2013, M. Margala, R. A.da Luz Reis, A. Orailoglu, L. Carro, L. M. Silveira, and H. F.Ugurdag, Eds. IEEE, 2013, pp. 288–289. [Online]. Available:http://dx.doi.org/10.1109/VLSI-SoC.2013.6673292

[23] C. Dobson, K. Rooks, and P. M. Athanas, “A power-efficientFPGA-based self-adaptive software defined radio,” in 24thInternational Workshop on Power and Timing Modeling,Optimization and Simulation, (PATMOS), Palma de Mallorca,Spain, September 29 - Oct. 1, 2014. IEEE, 2014, pp. 1–8.[Online]. Available: http://dx.doi.org/10.1109/PATMOS.2014.6951901

[24] T. Collins and A. Wyglinski, “Skynet: SDR-Based PhysicalSimulation Testbed,” in Vehicular Technology Conference (VTCFall), 2015 IEEE 82nd, Sept 2015, pp. 1–2.

19

[25] MathWorks, Inc. (2016) comm.AGC System Object.[Online]. Available: http://www.mathworks.com/help/comm/ref/comm.agc-class.html

[26] ——. (2016) Communications System Toolbox. [Online].Available: http://www.mathworks.com/help/comm/index.html

[27] M. Margala, R. A. da Luz Reis, A. Orailoglu, L. Carro, L. M.Silveira, and H. F. Ugurdag, Eds., 21st IEEE/IFIP, VLSI-SoC2013, October 7-9, 2013. IEEE, 2013.

Ramanathan Subramanian Ram is a Ph.D.candidate in the Department of Electrical andComputer Engineering at Northeastern Univer-sity, Boston advised by Prof. Kaushik Chowd-hury. He completed his Masters in ComputerScience and Automation at Indian Institute ofScience, Bangalore, India. His current effortsare focused on implementing the MAC layerfunctionality for MATLAB-based SDR on the

USRP hardware. He then will progress to research MAC mechanismsthat allow LTE to co-exist with Wi-Fi in the unlicensed spectrum.

Benjamin Drozdenko Ben is a Ph.D. candi-date at Northeastern University, the university-wide MathWorks TA, and a graduate researchassistant in implementation of a MATLAB-based Cognitive Radio framework, co-advisedby Prof. Chowdhury and Prof. Leeser. From2008 to 2014, Ben worked for MathWorks,Inc., producers of MATLAB and Simulink,where he wrote technical documentation and

examples for several Signal Processing and Communications areaproducts and traveled to customers’ sites to deliver training courses.From 2004 to 2008, Ben worked as a Systems Engineer at RaytheonIntegrated Defense Systems, focusing on ground-based radar forballistic missile defense.

Eric Doyle Eric is an undergraduate studentat Northeastern University studying Electricaland Computer Engineering and has been a re-search assistant in Prof. Kaushik Chowdhury’sGENESYS Laboratory since August 2015. Hisresearch interests are in communication sys-tems and acoustics. He has been vice presidentof the Acoustical Society of America chapterat Northeastern since 2014 and has held coop

positions at Bose Corporation and Insulet Corporation. In his freetime he enjoys practicing violin.

Rameez Ahmed Rameez is a Ph.D. candidatein the Department of Electrical and Com-puter Engineering at Northeastern University,Boston. He works under the guidance of Prof.Milica Stojanovic in the field of underwateracoustic communication. His research interestsare in digital communication, wireless com-munication and network protocols. In his freetime he enjoys cooking and traveling and has

an ardent love for cars and electronic gadgets.

Miriam Leeser Miriam Leeser is a Professorin Electrical and Computer Engineering atNortheastern where she is head of the Re-configurable and GPU Computing Laboratory.She received her BS degree in electrical engi-neering from Cornell University, and Diplomaand PhD degrees in computer science fromCambridge University in England. She was onthe faculty at Cornell University’s Department

of Electrical Engineering before coming to Northeastern, where she isa member of the Computer Engineering research group. Her researchincludes using heterogeneous architectures for signal and imageprocessing applications including wireless communications as well asimplementing computer arithmetic and verifying critical applications.She is a senior member of the IEEE and of the ACM.

Kaushik Chowdhury Kaushik Roy Chowd-hury is Associate Professor in the Electri-cal and Computer Engineering Department atNortheastern University. He was earlier As-sistant Professor in the same university from2009-2015. He received his Ph.D. from theGeorgia Institute of Technology in August2009, under Prof. Ian F. Akyildiz and M.S.from the University of Cincinnati in 2006,

advised by Prof. Dharma Agrawal. Prof. Chowdhury is the winnerof the NSF CAREER award in 2015. He received the best paperaward at the IEEE International Conference on Communications(ICC) in 2013, 2012 and 2009, as well as the best paper awardat the International Conference on Computing, Networking andCommunications (ICNC) in 2013. He is the current Chair of theIEEE Technical Committee on Simulation and is Sr. Member of theIEEE. He serves as the area editor for the following journals: ElsevierAd Hoc Networks, Elsevier Computer Communications, and EAITransactions on Wireless Spectrum.