Keywords

1 Introduction

With ever-changing wireless standards and protocols, there has been a conscious shift towards a programmatic approach for designing and implementing wireless radios. This has led to a tremendous interest in Software Defined Radios (SDR). SDR is a powerful concept in which filters, amplifiers, modulators and other complex signal processing blocks are realized in software, instead of on specialized hardware. As the task of signal processing is handed over to software, it is possible to use general purpose hardware, connected to an RF front end, to create powerful and highly flexible radios.

While the SDR paradigm has revolutionized the design of wireless radios, it does not provide an efficient method to control a network of SDRs. Since SDRs can be reconfigured to provide a wide variety of radio functionalities, it would be highly desirable to have a consistent interface to expose the SDR’s functional modules to the network application developer. As modules can be added, removed or changed any time, such an interface framework must be able to adapt to these changes, report events to the application, and allow control of various constituent modules while hiding their complexity from the application developer. This level of abstraction is necessary because, as the network grows and becomes more heterogeneous, it is impossible for the application developer to keep track of low-level details. Here, by the notion of heterogeneous networks, we take into consideration a network containing both wired and wireless devices. Hence, the architecture should enable network control, meet requirements of users, and abstract away the details of the implementation.

In order to provide abstractions taking into account the above considerations, we use the concept of Software Defined Networking (SDN). SDN defines abstractions that represent data plane components and the interface to control and manage these abstractions. These primitives (including asynchronous callback function event reporting) enable an application developer to obtain a logically centralized view of the network. The application developer can then dynamically adjust rules to reflect changing network conditions and requirements.

In this paper, we aim to integrate SDR and SDN to provide a principled approach for developing a consistent interface to manage underlying abstractions of SDRs. We build upon the abstract model presented in our previous paper [1], where we described a monolithic architecture for wireless radio port abstraction. In the current paper, we go beyond that and broaden the design space to provide a modular design, which is in line with the design principle of SDR. This also enables an integration of both wired and wireless networks which can be managed in a programmatic manner, thereby enabling development of key applications catering to a heterogeneous network. We call our platform CrossFlow. Some network applications that we envision can leverage CrossFlow include, but are not limited to, the following:

  1. 1.

    Physical layer adaptation including (i) frequency hopping to resist narrowband interference and prevent unauthorized interception; (ii) transmission power control to maintain a target link quality while reducing interference to other users and/or extending battery life; (iii) adaptive modulation and coding to trade-off throughput and communication reliability and adapt to channel conditions (e.g., pathloss and interference).

  2. 2.

    Quality of service (QoS) provisioning to provide QoS policies implemented through medium access control, throttling, admission control, scheduling, and error control techniques (e.g., ARQ and FEC).

  3. 3.

    Adaptive routing to allow a CrossFlow controller, with its global view of the network, to dynamically switch between different routing protocols depending on the network conditions and the application constraints.

  4. 4.

    Self-healing network to allow the CrossFlow controller to deploy fault management applications based upon self-healing mechanisms.

  5. 5.

    Cross-layer control to allow joint optimization of parameters, algorithms, and protocols at all layers of the protocol stack.

We use the generalized model of SDN introduced in [2] as a template for defining the abstractions and their features discussed above. We also build upon the concept of wireless radio ports as discussed in [3]. This abstraction is composed of a number of smaller abstractions, one for each processing block, so that fine-grained control of the processing capabilities of a radio device is provided to application developers without exposing its intricate details. This enables manipulation of critical physical, data link, and network layer properties through various well defined interfaces. Thus, using the architecture of CrossFlow, we can build applications across all layers of the network stack.

For validation purposes, we use the popular GNU Radio [4] framework, which provides a modular, open-source Digital Signal Processing (DSP) software environment for SDRs. GNU Radio modules are written in C++ and provide a mechanism to connect and manage data between them. A Python wrapper ties these blocks together to implement applications. We run GNU Radio on a host PC connected (via Ethernet) to a Universal Software Radio Peripheral (USRP) N210 device from Ettus Research, and we also run CPqd SoftSwitch software [5] as a separate module. CPqd SoftSwitch serves as a switch agent interacting between the SDN controller and GNU Radio modules. This is done through message extensions which we will discuss in subsequent sections. We also develop three proof-of-concept applications to validate our design principles: frequency hopping, adaptive modulation, and cognitive radio.

Our contributions can be summarized as follows.

  1. 1.

    We propose a framework that provides a uniform and consistent view of SDRs, so that a network of SDRs can be managed in an efficient manner.

  2. 2.

    We extend the SDN model with message extensions to provide support for wireless radio interfaces.

  3. 3.

    We provide sample applications using the framework for validation.

The rest of the paper is organized as follows. In Sect. 2, we review the related work done in this area. Section 3 describes the CrossFlow architecture with its SDN extensions. Section 4 describes a proof-of-concept implementation of three applications using our framework. Section 5 concludes the paper.

2 Background and Related Work

Software Defined Networking. Network reconfigurability is a major challenge in the networking industry. The explosion of mobile devices and cloud services has increased the need for on-demand installation of services and reconfiguration of flow rules according to changing traffic patterns. In addition, network elements like routers and switches have their own unique interfaces and as such management of network components is a source of concern for network application developers. As the network grows, this complexity increases exponentially and rolling out new services becomes a tedious and complicated process.

Software Defined Networking (SDN) is an architecture which tries to address these challenges by decoupling the control and forwarding functions. This enforces abstraction of underlying implementation and enables applications or network services to be developed using the abstractions. This simple and elegant design also provides applications a centralized view of the network. As a result, it has sparked tremendous research interest in providing a scalable, secure and programmatic approach towards the challenges discussed above. While SDN is a revolutionary approach, it is still mainly geared towards wired networks. Through our previous work, ÆtherFlow  [3], we tried to provide a protocol independent approach for bringing wireless into the SDN model. In this paper, we go a step further and try to provide a mechanism for dynamic radio resource management for SDRs to obtain true network visibility in a heterogeneous network.

GNU Radio framework. GNU Radio [4] is a free and open-source framework that provides signal processing functionality to implement SDRs. The main constituents of the framework are basic blocks which perform distinct signal processing functions. GNU Radio enables the composition of these blocks to synthesize new radio functionality on general purpose hardware, but it is not suitable for developing applications to control a network of SDRs. This is because each block exposes its own set of interfaces which does not scale with increasing numbers of radios in the network. In this paper, we provide uniform interfaces to control and manage these processing block abstractions, so that an application developer does not need to handle every block’s unique interface characteristics.

Aside from GNU Radio, the idea of providing a programmable wireless data plane has been implemented in [6, 7]. These papers provide modular blocks and focus on real-time guarantees for processing signals. But, like GNU Radio, they do not provide any logical interface to control a network of such programmable devices. The paper [8] deals with centralized control of devices but it focuses mainly on LTE networks. Our paper is orthogonal to these works as we provide a mechanism for centralized control while making the exposed interfaces protocol independent. The combination of SDRs and SDN has recently been used in a variety of contexts [9,10,11,12]. In [11], SDR and SDN are used to create a testbed for LTE technologies while [9, 10] focus on integration of SDR and SDN for 4G/5G technology. In [13], an SDR model for management of interference in dense heterogeneous networks is proposed while [12] developed a jamming architecture using SDN and SDR principles. These papers provide distinct solutions for various scenarios but do not provide a generic framework for handling various protocols in a principled manner.

The most closely related work to CrossFlow is the RcUBe framework [14], which provides structured abstractions for decision, control, data, and register planes of SDRs. A key difference between CrossFlow and RcUBe is that CrossFlow allows SDRs to be managed by the same SDN controller as other network devices, thereby enabling unified control of a heterogeneous network.

3 CrossFlow Architecture and Design

In this section, we motivate and describe the architecture and design of CrossFlow. In Sect. 3.1, we introduce the proposed data plane abstractions. Then, in Sect. 3.2, we describe how we extend the OpenFlow protocol to accommodate CrossFlow messages.

Fig. 1.
figure 1

Abstraction model of CrossFlow

Full size image

3.1 Data Plane Abstractions

We extend the data model proposed in [2] to create an abstraction model for the CrossFlow framework, which is displayed in Fig. 1. We build upon the wireless radio port concept proposed in [3] to create a new layer of abstractions. This layer of abstractions exhibits a composition or has-a relationship with the wireless radio port abstraction (i.e., the wireless radio port has a sink, modulator, or channel coder). This means that the blocks of this layer are the objects or members that comprise the wireless radio port. These blocks are derived from the most commonly used processing blocks in GNU Radio [4]. This abstract wireless radio port model serves the following design vision:

  • It allows visibility into the signal processing blocks from an application point of view, without going into implementation details.

  • It allows for the development of an event driven framework for radio operation.

  • It could enable composition of blocks to implement new functionality. For future work, we envision that a network application could specify which blocks to connect for a specific wireless port instance, and the internal framework could handle the implementation.

In this paper, we focus on the first two bullets. Specifically, we develop an abstract interface to enable event-driven dynamic configuration of a fixed set of signal processing blocks at run-time. In order to change a signal processing block’s parameters, the application needs to send a <command, value> tuple in a message. For queries and receive event responses, it registers for events with each block and, when an event occurs, appropriate callbacks are invoked. One of the main requirements of the CrossFlow model is that each abstraction should implement four types of interfaces as proposed in both [2, 3], namely, capabilities, configuration, statistics, and events. Thus far, CrossFlow provides the interfaces for a wireless radio port abstraction with two processing blocks: Sink and Modulators. However, we plan to extend it to include the other processing blocks shown in Fig. 1. The Sink abstraction allows the SDN controller to manage the signal sinks which can be a USRP device, file, or a socket, while the Modulators abstraction allows management of modulation schemes (e.g., BPSK, QPSK, and 8PSK).

The interfaces for Sink and Modulators are categorized as follows:

  1. 1.

    Sink:

    • Capabilities: The interface allows the SDN controller to query the capabilities of sinks such as: (i) Type of sink (USRP, socket, etc.); (ii) Channels supported; (iii) Center Frequency; and (iv) IP address.

    • Configuration: The interface allows the SDN controller to configure properties of signal sinks such as: (i) Gain; (ii) Frequency, and (iii) Sample rate.

    • Statistics: The interface allows the SDN controller to gather statistics for sinks such as the received signal strength indicator (RSSI).

    • Events: The interface allows the SDN controller to take decisions based upon events such as low or high RSSI.

  2. 2.

    Modulators:

    • Capabilities: The interface allows the SDN controller to query the properties of the modulator block such as: (i) Modulations supported; (ii) Current samples/symbol; and (iii) Use of a Gray code indicator.

    • Configuration: The interface allows the SDN controller to configure properties of the modulator block such as: (i) Choice of modulation scheme (e.g. BPSK, QPSK and 8PSK); (ii) Sample/symbol; and (ii) Use of a Gray code.

    • Statistics: The interface allows the SDN controller to gather statistics for the modulator block such as: (i) Signal to Noise Ratio (SNR) and (ii) Bit Error Rate (BER).

    • Events: The interface allows the SDN controller to take decisions based upon events in the modulator block such as: (i) Low or high SNR and (ii) Low or high BER.

3.2 Message Extensions

CrossFlow uses SDN design principles to control a network of configurable SDRs. As such, to enable control plane interactions between the SDN controller and the SDR, we had two options: either we could have implemented our own control protocol to enable their interactions or extend the existing OpenFlow [15] framework. This is because OpenFlow does not natively support wireless features. In order to enable a cleaner implementation, we decided to extend OpenFlow by using experimenter messages within the OpenFlow protocol, similar to ÆtherFlow. Experimenter messages are a part of the standard OpenFlow protocol which provides a mechanism for vendors to include propriety information within the protocol. This approach has two advantages. First, we do not need to implement a new protocol for control and data plane interactions. Second, since we are using experimenter messages to carry CrossFlow messages, the SDN controller does not need to perform special handling for these messages. This enables the controller to remain target independent and hence it can handle both wired and wireless devices. In the current version of CrossFlow, we define three messages:

  • Configuration message request: Request for modification of parameters, such as gain, frequency, SNR threshold, and modulation scheme.

  • Statistics message request: Request for statistics, such as SNR and BER.

  • Event message response: Response for events, such as low SNR.

4 Proof-of-Concept Implementation

4.1 Illustrative CrossFlow Implementation

In this section, we describe our implementation of adaptive modulation, frequency hopping and cognitive radio applications using the CrossFlow framework. For illustration, we implement our model on a USRP N210 SDR from Ettus Research. We use the CPqD Softswitch [5] (ofsoftswitch) software as the switch agent in the SDN model. Its main functionality is to enable communication between GNU Radio and the python based Ryu SDN controller. As described in previous sections, the applications will send messages to the processing blocks, e.g., to configure them. The ofsoftswitch then forwards this request to a centralized CrossFlow Hub inside the GNU Radio domain.

Fig. 2.
figure 2

Transmitter implementation diagram of CrossFlow with two processing blocks: Sink and Modulators

Full size image

There are four main components (blocks) in the illustrative CrossFlow module that we implement in GNU Radio, namely, the CrossFlow Hub, the Modulation Controller (Mod Controller for brevity), the SNR Monitor and the USRP Controller (see Fig. 2).

  • The CrossFlow Hub is the interface between the Modulation (Mod for brevity) and USRP controllers in GNU Radio and the Ryu SDN controller. The CrossFlow Hub and the Ryu SDN controller communicate via packet data unit (PDU) socket. The CrossFlow Hub is responsible for receiving commands from ofsoftswitch (or any other compliant interface), interpreting the commands, and forwarding the commands to the appropriate controller block (i.e., the USRP or Mod controller in our implementation). It is also responsible for receiving information from different controller blocks and sending information to the Ryu SDN controller. The CrossFlow Hub has in/out ports to send commands and receive information to/from the GNU Radio controller blocks. It also has in/out PDU ports for interfacing with Socket PDU.

  • The Mod Controller is responsible for receiving commands from the CrossFlow Hub, and selecting the appropriate modulation scheme from the modulation bank. For illustration, we include three modulation schemes (BPSK, QPSK, and 8PSK); however, thanks to the modular design, we can easily add more schemes. The Mod Controller can also feedback information to the Ryu SDN controller about the modulation scheme that is currently in use and the number of modulation schemes available in the modulation bank.

  • The SNR Monitor is responsible for monitoring the SNR level and generating an event in case the SNR level falls below a certain threshold, which can be configured by the application. Currently the framework uses the existing SNR probe of GNU Radio, which supports four SNR estimators for M-PSK modulated signals. This monitoring block is also responsible for relaying the SNR statistics back to CrossFlow Hub in response to a SNR statistics query generated by the application.

  • The USRP Controller is responsible for controlling different RF parameters of the USRP Transmitter/Receiver based on commands from the CrossFlow Hub. In our proof-of-concept implementation, we control the carrier frequency and the power of the signal. It can also feedback information to the CrossFlow Hub about the current RSSI, SNR, carrier frequency, power, etc.

Although our illustrative implementation only has three controllers (facilitating abstraction of the USRP Sink/RF implementation, SNR estimation, and the adaptive modulation implementation), additional controllers can be easily added to support new functionalities and abstractions.

Table 1. Variation of the SU’s SNR and PER as a function of the PU’s normalized transmission power. The SU transmits at a fixed rate of 1 Mbps.
Full size table

4.2 Example Applications

Frequency Hopping Application: Frequency hopping is a technique of transmitting radio signals by spreading the signal over a sequence of changing frequencies. It can be used against jamming and for protecting against unauthorized eavesdropping. In our implementation, the Ryu SDN controller simply issues a GNU-CONFIG-FREQ command with the desired frequency and pushes this configuration to the device. As shown in Fig. 2, the ofsoftswitch receives this command and forwards it to the GNU Radio domain. The centralized CrossFlow Hub inside the GNU Radio domain processes this request and issues appropriate commands to the USRP Controller, which ultimately signals the USRP block to tune to the requested frequency.

Adaptive Modulation Application: Adaptive Modulation is a technique where the modulation is changed according to the conditions of the channel. There are various estimators which are used for obtaining channel quality. These can be based on SNR, BER, or other environment specific parameters. Similar to the frequency hopping application, the Ryu SDN controller issues the GNU-CONFIG-MOD command with the appropriate modulation scheme (e.g., BPSK, QPSK, or 8PSK) and forwards the request to the device. The request ultimately reaches the Mod Controller, which is a multiplexer block that selects the requested modulation scheme as shown in Fig. 2.

Cognitive Radio Application: We build upon the frequency hopping application mentioned above to construct a cognitive radio application. Cognitive radio is a type of radio in which the device is aware of its environment and can dynamically change its operating parameters like transmission power, frequency, gain, etc., in response to the environmental conditions. In CrossFlow, we implement an application that can configure a radio device to switch channels based upon a low SNR event measured by the device. The experimental setup is shown in Fig. 3, where we have three USRP N210 devices that act as sender, receiver and noise source. In our setup, the sender and receiver are secondary users (SUs) and the noise source is the primary user (PU). We assume that the SUs are frequency agile and can operate at either 910 MHz or 915 MHz. All transmissions use a 2 MHz bandwidth. Meanwhile, we assume that the PU only operates at 910 MHz. The SUs are set 5 m apart.

Using this setup, we conduct two tests: one to measure the effect of the PU’s transmission power on the SU’s packet error rate (PER) and SNR at the 910 MHz carrier frequency (measured over 1,000,000 packets transmitted by the SU at 1 Mbps while the PU operates at normalized transmission powers of 0.0, 0.09, 0.14, where 0.0 indicates that the PU is silent), and another to measure how quickly the cognitive radio can trigger and respond to a low SNR event (with normalized PU transmission powers 0.09, 0.17 and 0.22, and SU data rates of 256 Kbps, 512 Kbps and 1 Mbps).

Table 1 shows the PER and SNR values obtained in the first experiment where the PU and SU transmit on the 910 MHz carrier frequency at the same time. As expected, the SU’s PER increases and SNR decreases as the PU’s transmission power increases on the same channel.

In the second experiment, which demonstrates a simple cognitive radio application, we assume that the PU is initially silent and that the SU is initially transmitting in the spectrum “hole” at 910 MHz. Once the PU starts to transmit, the SU experiences a decrease in its SNR. When the SNR falls below a specified threshold (4 dB in our experiment), a low SNR event is triggered by the SU’s SNR Monitor block and the event summary is sent to ofsoftswitch through the CrossFlow Hub. This request is then forwarded to the Ryu SDN controller using the event response message. The application, upon receiving this message, sends a GNU-CONFIG-FREQ command so that the SU changes its carrier frequency to 915 MHz to avoid the interference from the PU. The sequence of actions involved in changing the channel is similar to the sequence in the frequency hopping application described earlier.

Fig. 3.
figure 3

Setup for cognitive radio application in CrossFlow

Full size image
Fig. 4.
figure 4

Packet losses incurred while the SU transitions to the unoccupied channel, and the associated transition delay, for di erent SU rates (kbps) and normalized PU transmission powers.

Full size image

In Fig. 4(a), we show the number of packets that are lost over the course of time required for the SNR to be sensed below the 4 dB threshold, for the receiver to generate the low SNR event, and for the Ryu SDN controller to respond by issuing the GNU-CONFIG-FREQ command, and finally for the transmitter to switch frequencies. We repeat this experiment three times for each combination of SU data rate (256, 512, and 1024 kbps) and normalized PU transmission power (0.09, 0.17, and 0.22), and report the average of each group of three measurements in Fig. 4(a). In Fig. 4(b), we report the time that elapses over the aforementioned sequence of events. We note that this switching time is independent of the SU’s data rate and the PU’s transmission power.

5 Conclusion and Future Work

In this paper, we presented a framework for programming a network of software defined radios using software defined networking (SDN) principles. The framework we propose allows adaptive, flexible, and real-time (re)configuration of software defined radio interfaces from a network controller application. It streamlines the development of network applications by hiding the low level internal details of the signal processing pipeline. In order to validate our approach, we also provide three proof-of-concept applications: frequency hopping, adaptive modulation and cognitive radio. This shows that our design is viable and can be extended to introduce new capabilities.

One of the challenges that we need to consider is in-band control of the radio devices. Currently we implemented our design using an out-of-band wired control channel. The CrossFlow framework can easily be extended to enable in-band control of devices and it will be our next design goal. Another area of focus is the latency between controller and SDR framework. The issue can be mitigated by the introduction of distributed control module in SDR. The distributed control module will allow devices to take local decisions while the centralized controller is responsible for introducing policies and global management, thereby ensuring reduced latency.