Content uploaded by Yalin E. Sagduyu
Author content
All content in this area was uploaded by Yalin E. Sagduyu on Nov 24, 2018
Content may be subject to copyright.
Distributed Cognitive Radio Network Architecture,
SDR Implementation and Emulation Testbed
Sohraab Soltani∗, Yalin Sagduyu∗, Yi Shi∗, Jason Li∗, Jared Feldman‡and John Matyjas‡
∗Intelligent Automation, Inc., Rockville, MD, USA
‡U.S. Air Force Research Laboratory, RITF, Rome, NY, USA
Email: {ssoltani, ysagduyu, yshi, jli}@i-a-i.com, {jared.feldman, john.matyjas}@us.af.mil
Abstract—This paper presents a distributed cognitive radio
network architecture for joint routing and spectrum access,
its implementation with software-defined radios (SDRs), and
its evaluation in a high-fidelity emulation testbed. CREATE-
NEST, a comprehensive cognitive radio system, is built as an
experimental prototype that provides a Cognitive Radio nEtwork-
ing ArchiTecturE (CREATE) for distributed support of cross-
layer optimization in cognitive radio networks, and the Network
Emulator Simulator Testbed (NEST) capability for plug-and-
play cognitive network implementation with USRP N210 radios.
CREATE deploys a full protocol stack with distributed coor-
dination (no common control channel) and local network state
information, and integrates neighborhood discovery, spectrum
sensing and channel estimation with joint routing and chan-
nel access implemented with backpressure algorithm. The high
fidelity, controllable and repeatable wireless testbed platform,
NEST, supports USRP N210 radios communicating with each
other through RFnest, a high fidelity wireless network emulation
tool. RFnest provides realistic physical channel environments
under various path loss, fading, delay, and mobility scenarios
for cognitive networks and provides protocol design verification
and evaluation over realistic RF channels with digitally controlled
channel impulse responses. The CREATE-NEST implementation
is distributed with plug-and-play devices running identical codes
and scales up seamlessly. Extensive emulation testbed results are
provided to verify the CREATE-NEST implementation.
Keywords—Cognitive radio network; software-defined radio;
cross-layer design; network optimization; distributed coordination;
implementation; emulation; testbed; USRP; GNU Radio.
I. INTRO DUC TI O N
Spectrum resources are scarce but they are not effi-
ciently utilized with static spectrum allocation. Cognitive radio
paradigm answers this need by opportunistically discovering
and using spectrum opportunities across time, space, and
frequency. In a multi-hop communication setting, spectrum
occupancy is time and location-dependent and therefore joint
design of routing and spectrum access is needed with dis-
tributed implementation instead of using a common control
channel (both a bottleneck and a single point of failure).
The current state-of-the art focuses on either a device-level
stand-alone SDR solution or an isolated protocol-level solu-
tion. Instead, we follow an end-to-end cognitive networking
approach with full protocol stack implementation that provides
DISTRIBUTION A. Approved for public release; distribution unlimited.
(AFRL/RITF; 88ABW-2015-1510). Supported by USAF/AFRL under contract
FA8750-12-C-0228. Any opinions, findings and conclusions or recommenda-
tions expressed in this material are those of the authors and do not necessarily
reflect the views of the Air Force.
distributed control, network adaptation to spectrum dynamics,
network-centric dynamic spectrum access and cross-layer op-
timization. We built a complete end-to-end Cognitive Radio
nEtworking ArchiTecturE (CREATE) that deploys neighbor-
hood discovery, spectrum sensing, channel estimation, channel
rendezvous for distributed coordination, spectrum allocation
(frequency allocation, power control, and channel access), and
joint scheduling and routing.
CREATE captures the temporal and spatial spectrum op-
portunities on channels and allows for distributed spectrum re-
source allocation by optimizing performance objectives across
different network layers by running a backpressure algorithm.
The backpressure algorithm [1] is an ideal candidate for
dynamic routing in spectrally diverse cognitive radio networks
[2], [3] without maintaining end-to-end paths. CREATE de-
ploys a backpressure algorithm that is locally executed at each
cognitive node to make the individually optimal routing and
channel access decisions over different frequency channels.
The backpressure algorithm has been implemented on WiFi
radios [3] and with a static wireless indoor testbed [4]. We
implemented CREATE on GNU Radio [5] and Python mod-
ules, and run it on USRP N210 radios [6]. We built a high-
fidelity programmable network emulation simulation testbed
(NEST) to test and evaluate CREATE. Using Radio Frequency
Network Emulator Simulator Tool, RFnestTM [7], real signals
are sent over emulated channels among cognitive nodes with
dynamically controlled topology, mobility and channel impulse
response properties.
Wireless network evaluation is mainly done either through
software simulation or hardware testbeds. These approaches
lack the fidelity needed for accurate and realistic evaluation
of a network. Software simulations, such as ns-2/3, OPNET
and QualNet, typically use simplistic physical layer model-
ing that ignores various effects, e.g., nonlinearity, filtering
and inter modulation by hardware. There have been several
developments of cognitive radio or SDR testbeds [8], e.g.,
ORBIT in WINLAB [9] and CORNET in Virginia Tech
[10]. These testbeds can only represent static scenarios that
cannot be reliably controlled or repeated and cannot emulate
a representative geometry of a specific (e.g., mobile) scenario.
NEST provides a repeatable and controllable testbed for cog-
nitive radios communicating with each other in a dynamic RF
propagation and mobility environment that we can control and
replay in RFnest.
We started developing CREATE-NEST in [3], where we
used four programmable radios (RouterStation Pros) controlled
by a common software code. This code allowed distributed
network architecture but this capability was not implemented
on SDRs running individual codes. In this paper, we provide
the fully-operational SDR implementation with a full protocol
stack by addressing practical design, radio implementation
and testbed evaluation issues. The summary of our novel
contributions in this work is given as follows:
1) Fully distributed network architecture is implemented
on individual cognitive nodes running their own ver-
sions of identical software.
2) Software-defined radios (USRPs) are introduced as
cognitive nodes and the clean slate network architec-
ture is implemented in Python wrapping GNU Radio
implementation of physical (PHY) layer.
3) The testbed is implemented with plug-and-play radios
and the testbed size is increased with seamless inte-
gration capability of adding new nodes without any
need to change software and hardware requirements.
4) Additional capabilities to collect and exchange con-
trol information are implemented with improved dis-
tributed coordination fulfilling objectives of through-
put maximization, traffic prioritization and energy.
The main components of CREATE and their integration
with NEST are shown in Fig.1.
Fig. 1. CREATE system diagram and integration with NEST.
The rest of the paper is organized as follows. Section II
introduces the distributed coordination phases. The waveform
and PHY layer aspects are described in Section III. Section IV
presents the programmable network emulation testbed. Section
V provides experimentation results of cognitive radio network
capabilities. Section VI concludes the paper.
II. DIS TR IBU TE D CO OR DINATIO N
CREATE design addresses three main challenges: 1) no
use of common control channel and centralized controller;
2) spectrum utility maximization over multiple channels; and
3) distributed implementation of backpressure algorithm. The
existing cognitive radio architectures are typically based on
a dedicated common control channel [11], where nodes can
collect and share local information, and collectively compute
their strategies across the protocol stack. However, common
control channel may limit the rate of information exchange
and it may pose a single point of failure. Instead, CREATE
establishes distributed negotiation and coordination channels
(shared with data communications) asynchronously and adapts
to network dynamics by discovering the local neighbor rela-
tions and updating the channel and queue information.
At each layer of the cognitive radio protocol stack, different
protocols and functions are implemented by letting each cog-
nitive radio operate with the identical protocol stack. Besides
the application and transport layers for generating application
traffic flows at each node, the capabilities implemented at the
other layers are as follows:
1) Network layer: Backpressure routing algorithm, for-
warding decision, priority transmission, and multicast
routing.
2) MAC layer: Node synchronization, neighborhood dis-
covery, transmission negotiation, spectrum allocation
and distributed coordination functions.
3) Physical layer: Spectrum sensing, channel mea-
surement, link estimation, power control, rate con-
trol, channel hopping, modulation, and Orthogonal
Frequency-Division Multiplexing (OFDM) transmis-
sion.
We implemented distributed coordination functions, illus-
trated in Fig. 2, operating in four phases:
1) Neighborhood discovery and channel estimation.
2) Exchange of flow information updates and execution
of backpressure algorithm.
3) Transmission decision negotiation.
4) Data transmission.
Fig. 2. Distributed coordination function phases for the CREATE node.
A. Phase 1: Neighborhood Discovery and Channel Estimation
A CREATE node enters this phase when joining the
network for the first time and then later periodically. In this
phase it broadcasts discovery (DIS) messages to announce
its presence to its potential neighbors. Each node performs
channel hopping where it visits a specific channel for a given
period of time and then switches to another channel. The DIS
packet format is depicted in Fig. 3.
Fig. 3. Discovery packet format transmitted during neighborhood discovery.
If a node receives DIS packet of another neighbor, it
includes 1) the neighbor ID iand 2) the estimation of the
channel quality for the link which is specified by channel
frequency Fiin the next DIS packet. The channel estimation
is performed by calculating the root mean square (RMS) value
of the received signal that carries the neighbor i’s DIS packet.
When a node switches to a new channel, it broadcasts
a new DIS packet, which includes the information of those
neighbors that this node has already discovered and listens
over the channel to receive DIS packets of new neighbors. Each
node remains in the neighborhood discovery phase for a period
of TTR (time-to-rendezvous). We set TTR =F×Cseconds,
where each node visits Fchannels, each for Cseconds. When
the TTR expires, a node switches to flow update and schedules
transmission phase. At the end of the neighborhood discovery
phase, a node has built a local topology including the list of
the neighbors that it has discovered along with the quality and
frequency information of the links to those neighbors.
B. Phase 2: Exchange flow information updates and perform
backpressure algorithm
In this phase, a CREATE node performs channel hopping
such that the node visits a specific channel for a given period
of time and then switches to another frequency channel. It then
broadcasts SYN message on each channel visited to inform its
neighbors about the status of its backlog. This includes 1) the
number of traffic flow queues and 2) the number of packets in
each queue. Each queue represents one traffic flow identified
by source and destination IDs.
Fig. 4. SYN packet format transmitted during flow update.
Fig. 4 illustrates the packet format for a SYN message.
As the node receives SYN messages from other nodes, it
iteratively builds a complete database, which includes 1) the
queue information of the neighbors and 2) the link quality of
those frequency channels, where the neighbors are available.
In this phase, if a neighbor receives a SYN message from a
node that is not in its topology database (constructed during
the neighborhood discovery phase), it estimates the channel
quality and updates its topology database, as well.
In this phase, once a node has enough information about
its neighbors, it notifies the network layer (cross-layer feed-
back from MAC to network layer) to run the backpressure
algorithm. If the backpressure algorithm finds the optimal
transmission schedule, then the node switches to transmission
decision exchange phase. Otherwise, it remains in flow infor-
mation update phase until necessary information is collected
from neighbors for the backpressure algorithm. Backpressure
routing algorithm is implemented at the CREATE network
layer that provides the following optimization solution: 1)
spectrum and power allocation decision are made jointly; 2)
the next hop is selected for routing; 3) transmissions are
coordinated for distributed channel access. Each node ikeeps
a separate queue for each flow iwith backlog Qs
i(t)at time t.
For all links, nodes choose the flow to transmit as the one with
the maximum difference of queue backlogs at the receiving and
transmitting ends, i.e., for each link (i, j )a node ichooses the
flow
s∗
i,j = argmax
s[Qs
i(t)−Qs
j(t)]+,
where [·]+= max (·,0). Then, we define the spectrum utility
Uij (t) = cij (t)hQs∗
i,j
i(t)−Qs∗
i,j
j(t)i+
and node itransmits to neighbor j∗(t)that yields the maximum
spectrum utility, i.e.,
j∗(t) = argmax
j∈Ni
Uij (t),
where Niis the set of the next hop candidates for node ito
select. The value of cij (t)is an empirical goodput over link
(i, j)calculated from bit error rate, BER, which is calculated
using the empirical signal-to-noise-ratio SNR value obtained
from the received signal power and the rate of the OFDM
waveform based on the bandwidth and FFT symbol length.
We have also incorporated priority and energy objectives
into the backpressure decision. We assign to each link (i, j)
and channel frequency fa priority level Sij (f)that represents
the vulnerability of this link to jamming and eavesdropping at
the given frequency. Each session sarrives with a minimum
priority requirement Ss. Then, the spectrum allocation and
routing decisions optimize the spectrum utilities subject to the
new priority constraint Ss≥ Sij (f).
For energy efficiency, we introduce a virtual queue that
tracks the energy consumption [12]. In particular, the trans-
mission power selected by any CREATE node corresponds to
the arrival at the virtual queue and the service rate is set as the
average power. Then, the goal is to stabilize the energy virtual
queues (along with packet queues) such that the average energy
constraint is satisfied for each node. We define Xi(t)as the
backlog of node i’s energy queue at time t,Pi(t)as the virtual
queue arrival (power consumption) and ¯
Pias the service rate
(average power constraint). Then, the energy queue evolves
over time as
Xi(t+ 1) = Xi(t)−¯
Pi++Pi(t).
We reflected this trade-off into the backpressure algorithm
by augmenting the spectrum utility with energy measures such
that the modified spectrum utility is given by
Uij (t) = cij (t)hQs∗
i,j
i(t)−Qs∗
i,j
j(t)i+
−Xi(t)Pi(t).
The utility function is a trade-off between the backlog and
the energy consumption. For a small average power constraint,
the system tends to avoid data transmissions and this leads
to a high backlog. For a large average power constraint,
the system prioritizes the backlog over energy consumption
leading to low backlog with high energy consumption. At the
end, the backpressure algorithm implemented at network layer
schedules node i’s next transmission by specifying 1) neighbor
ID, 2) channel frequency (link), and 3) traffic flow.
C. Phase 3: Transmission decision negotiation
Based on backpressure decision, each node transmits RTS
back to its neighbor over the assigned link/channel. Fig. 5
illustrates the format of the RTS transmitted during this phase.
Fig. 5. RTS packet format transmitted during transmission decision exchange
phase.
In this phase, every node that has scheduled a transmission
sends RTS packets to the neighbor that is a potential receiver.
It also listens over that channel for any possible RTS packets
from its neighbors. After a node has sent its schedule transmis-
sion decisions and received the decisions of its neighbors, it
is possible that these decisions conflict with each other. There
are three possible conditions for packet conflicts:
1) Two nodes have decided to send packets to each
other at the same frequency channel (this is a conflict
because a node cannot simultaneously transmit and
receive packets).
2) Two nodes have decided to send packets to the same
destination at the same frequency channel.
3) There exists a possible hidden node interference
problem.
If one of these conditions occurs, a node should give up its
decision and let the other node proceed with the transmission.
This conflict is solved by considering the utility of each node’s
decision. Simply, a node with higher backpressure utility value
is selected as the winner of the conflict. Since each node
has complete information of its decisions and its neighbors’
decisions, the resolution of such conflicts does not require
central control. After analyzing the received RTS packets, a
node decides to receive data packets or insists on its own
scheduled transmission. In the former case, it transmits CTS
packet to the neighbor that has the highest RTS. Otherwise, it
simply ignores the neighbor RTS and does not send CTS. Fig.
6 shows the packet format for CTS message.
Fig. 6. CTS packet format transmitted during transmission decision exchange
phase.
A node stays in this phase for a period of Transmission
Decision Time (TDT). If it receives a CTS packet during this
period, it will switch to data transmission phase. Otherwise it
will switch to flow information update phase. It is important
to note that a node may receive CTS packet after it switches
to flow update phase. In this case, the node will switch back to
the data transmission phase and will initiate data transmission.
D. Data Transmission
A node enters the data transmission phase to transmit
or receive data packets. For transmission, a node gets data
packets from the selected queue at the transport layer and
generates a DATA packet. Packets are transmitted either as raw
packets or as coded. For CREATE UDP packet transmission
is implemented at the transport layer. The format of the DATA
packet is illustrated in Fig. 7.
Fig. 7. DATA packet format transmitted during data transmission phase.
III. WAVE FOR M AND PHY L AYE R ASPE CTS
The CREATE testbed uses USRP N210 radio frontends
equipped with SBX transceivers. These radios can send or
receive signal over a single frequency channel. For the PHY
layer for the CREATE-NEST, we implemented transmit and
receive paths to construct a full-duplex radio to transmit
waveform and decoded packets from received waveform using
GNU radio with different OFDM options. An example of
such options includes modulation (BPSK, QPSK, etc.), OFDM
symbol length (e.g., 512), OFDM occupied carrier length (e.g.,
200), transmitter power (e.g., ranging from 0 to 31.5 dB),
transmitter amplitude (e.g., scales from 0 to 1.0 relative to
the maximum value), frequency carrier (e.g., we are using
SBX transceivers that can operate from 4.4MHz to 4.4 GHz),
and receiver gain (e.g., ranging from 0 to 31.5 dB). Note that
some of these parameters such as transmitter amplitude and
frequency carrier will dynamically change during the course
of node lifetime based on the CREATE decisions.
Transmit Path: Specific modulation parameters are ex-
tracted and the modulator class is initialized to modulate the
data and deliver it to the USRP module for transmission. The
USRP module is initiated using key parameters: 1) Symbol
rate based on the transmitter bit rate (set by the optimization
module) and the modulation scheme. 2) Sample per symbol,
the number of bits per symbol. 3) Transmitter frequency, the
carrier frequency (channel) where the USRP will transmit the
signal over. An instance of the transmit path that generates
the RF signal is connected to the USRP.
Receiver Path: The first step is to build the demodulator
based on the user modulation choice and the modulation
parameters. The next step is to design a filter to get the actual
channel that we want to operate on. To that end, we design a
low-pass filter and specify the filter coefficients such as gain,
sampling rate, center of the transmission band and the width of
the transmission band as well as the filter type. Then, we define
a packet receiver that performs demodulation on the received
Fig. 8. Testbed snapshot.
signal. Note that the receive path module uses carrier sensing
block to detect an incoming signal. Then, the channel filter is
connected to the carrier sense block and the packet receiver
module. After demodulation, the receive path module delivers
the payload to higher layers.
Real-Time Spectrum Sensing: The CREATE protocol uses
spectrum sensing to enforce nodes to back off. Each node
intends to transmit while the channel is idle or to switch
to another channel. This capability reduces the likelihood
of signal interference and packet distortion significantly. To
implement real-time spectrum sensing, we use multithreading
to sense the spectrum in real time (when the radio is not
transmitting) and return the energy of the signal calculated
using the average magnitude square of the sensed signal.
Power Control: Another capability added to CREATE node
is power control. Suppose node iinitially transmits its packets
with power Pi(t)to meet the target SNR of SN RT. When a
node receives the SYN packets from other neighbors, it extracts
the estimation of its transmission power ˆ
Pi(t). Then, it adjusts
its transmission power with the following formula:
Pi(t+ 1) = hˆ
Pi(t)i−1
×SN RT×Pi(t)×ϑ, (1)
where ϑis the noise level. The CREATE node ithen adjusts
the transmission waveform power using the Pi(t+ 1) value to
transmit the next packet at time t+ 1.
IV. COG NIT IV E RA DI O NE TW ORK EM UL ATI ON TES TBE D
Fig. 8 illustrates the network setup and different compo-
nents of the CREATE-NEST. The testbed consists of several
USRP N210s [6] sharing the spectrum in a fully distributed
implementation with adjustable power, rate and channel allo-
cation. The current setup deploys eight USRP N210s, however
it can scale up seamlessly with more radios.
Each USRP device represents a front-end of a cognitive
wireless node. The PHY layer is implemented by the open
source GNU Radio software [5] at each controller laptop,
where other protocol layers (MAC, network, transport and
application layers) are implemented by Python programming
language and integrated within the GNU Radio software. The
plug-and-play system allows integration of other radios, e.g.,
RouterStation Pros as primary users or as RF interferers.
Arbitrary topologies are supported in this testbed by
wireless mesh connection capability of RFnest, a Field Pro-
grammable Gate Array (FPGA) based Radio Frequency Net-
work Emulation Simulation Tool that allows all of the channels
of a full network of radio nodes to be emulated in real time,
with all communication nodes experiencing a realistic channel
impulse response [7]. Instead of over-the-air transmission, we
remove antennas of USRPs and connect them over RF cables
to RFnest. Then, RF signals travel through RFnest and the
radio experiments are repeated with identical channel scenarios
thereby increasing the fidelity of performance evaluation.
V. EM ULATIO N TES T BE D RE SU LTS
Network topology is generated through RFnest and shown
in Fig. 9. Emulation test parameters are given in Table I.
Fig. 9. Emulation test topology.
TABLE I. EM UL ATI ON T ES T PARA ME TE RS.
Parameter Value
Duration to visit a single channel 2 seconds
Duration in discovery phase 60 seconds
Duration in decision negotiation phase 60 seconds
Duration to exchange data packets 30 seconds
Duration to broadcast queue updates 20 seconds
Channels to visit 2.41, 2.43, 2.46GHz
Packet size 500 bytes
OFDM FFT length 512
OFDM cyclic prefix length 128
OFDM occupied length 200
OFDM modulation BPSK
USRP power transmission range (-15,-5) dBm
Emulation runtime 30 minutes
The performance results are shown in Fig. 10. From the
average overhead, we can see that all nodes have relatively
similar overhead. The reason is that the majority of the
overhead stems from discovery and synchronization to other
nodes in order to preserve the network topology. However, the
energy consumption for relay nodes 3 and 4 is higher than
other relays since most data packets are relayed through these
nodes. The backlog dynamics are presented by measuring the
queue size of each node over time. The backlog dynamics
are influenced by the backpressure decisions over time. In
this scenario, we observe that the backpressure algorithms are
routing most traffic through node 4 to the destination. Finally,
the throughput growth for node 6 illustrates the accumulated
packets received by the destination over time.
2 3 4 5 6
Node ID
2 3 4 5 6
Node ID
Fig. 10. Performance for emulation scenario with 6 nodes.
VI. CO NCL USI ON
In this paper, we presented distributed cognitive radio
network architecture, its SDR implementation using USRP
N210 and GNU Radio, and its high fidelity evaluation in a
wireless network emulation testbed. Each cognitive radio runs
the identical code for a full protocol stack with distributed
coordination (no common control channel) and local network
state information and performs neighborhood discovery, spec-
trum sensing, channel estimation and backpressure algorithm
for joint routing and channel access. Four phases are executed
for distributed coordination to detect and utilize spectrum op-
portunities: 1) neighborhood discovery and channel estimation;
2) exchange of flow information updates and execution of
backpressure algorithm; 3) transmission decision negotiation;
4) data transmission. We implemented these cognitive radio
capabilities on GNU Radio using USRP N210 as RF front
ends. For high fidelity test and evaluation, we built a pro-
grammable emulation testbed, where real signals are sent over
emulated channels (generated by network channel emulator,
RFnest) among cognitive nodes running distributed cross-
layer optimization algorithms. Using this plug-and-play testbed
capability, we demonstrated situational awareness, spectrum
sharing and routing capabilities subject to realistic network
topology and physical channel effects.
REF ERE NC E S
[1] L. Tassiulas and A. Ephremides, “Stability properties of constrained
queueing systems and scheduling policies for maximum throughput in
multihop radio networks,” IEEE Transactions on Automatic Control,
vol. 37, no. 12, pp. 1936-1948, 1992.
[2] L. Ding, T. Melodia, S. N. Batalama, J. D. Matyjas, and M. J. Medley,
“Cross-layer routing and dynamic spectrum allocation in cognitive radio
ad hoc networks,” IEEE Transactions on Vehicular Technology, vol. 59,
no. 4, pp. 1969-1979, 2010.
[3] L. Ding, Y. E. Sagduyu, T. Melodia, J. H. Li, J. Feldman, and J. Matyjas,
“CREATE-NEST: A distributed cognitive radio network platform with
physical channel awareness,” in Proc. IEEE MILCOM, 2013.
[4] R. Laufer, T. Salonidis, H. Lundgren, and P. Le Guyadec, “Xpress: a
cross-layer backpressure architecture for wireless multi-hop networks,”
in Proc. ACM MOBICOM, 2011.
[5] E. Blossom, “GNU Radio: tools for exploring the radio frequency
spectrum,” Linux Journal, vol. 2004, no. 122, pp. 4, 2004.
[6] M. Ettus, “Universal software radio peripheral (USRP),” Ettus Research
LLC, http://www.ettus.com, 2008.
[7] J. Yackoski, B. Azimi-Sadjadi, A. Namazi, J. H. Li, Y. E. Sagduyu, and
R. Levi, “RFnest: Radio frequency network emulator simulator tool,”
in Proc. IEEE MILCOM, 2011.
[8] S. M. Nishra, D. Cabric, C. Chang, D. Willkomm, B. Schewick, A.
Wolisz, and R. W. Brodersen, “A real time cognitive radio testbed for
physical and link layer experiments,” in Proc. IEEE DySPAN, 2005.
[9] D. Raychaudhuri, I. Seskar, M. Ott, S. Ganu, K. Ramachandran, H.
Kremo, R. Siracusa, H. Liu, and M. Singh, “Overview of the ORBIT
radio grid testbed for evaluation of next-generation wireless network
protocols,” in Proc. IEEE WCNC, 2005.
[10] “Virginia Tech cognitive radio network testbed (CORNET),”
http://cornet.wireless.vt.edu/trac/.
[11] B. F. Lo, “A survey of common control channel design in cognitive radio
networks,” Physical Communication, vol. 4, no. 1, pp. 2639, 2011.
[12] M. J. Neely, “Energy optimal control for time-varying wireless net-
works,” IEEE Transactions on Information Theory, vol. 52, no. 7,pp.
2915-2934, 2006.