Radio Hardware Virtualization for Software-Defined Wireless Networks

Software-Defined Network (SDN) is a promising architecture for next generation Internet. SDN can achieve Network Function Virtualization much more efficiently than conventional architectures by splitting the data and control planes. Though SDN emerged first in wired network, its wireless counterpart Software-Defined Wireless Network (SDWN) also attracted an increasing amount of interest in the recent years. Wireless networks have some distinct characteristics compared to the wired networks due to the wireless channel dynamics. Therefore, network controllers present some extra degrees of freedom, such as taking measurements against interference and noise, or adapting channels according to the radio spectrum occupation. These specific characteristics bring about more challenges to wireless SDNs. Currently, SDWN implementations are mainly using customized firmware, such as OpenWRT, running on an embedded application processor in commercial WiFi chips, and restricted to layers above lower Media Access Control. This limitation comes from the fact that radio hardware usually require specific drivers, which have a proprietary implementation by various chipset vendors. Hence, it is difficult, if not impossible, to achieve virtualization on the radio hardware. However, this status has been changing as Software-Defined Radio (SDR) systems open up the entire radio communication stack to radio hobbyists and researchers. The bridge between SDR and SDN will make it possible to bring the softwarization and virtualization of wireless networks down to the physical layer, which will unlock the full potential of SDWN. This paper investigates the necessity and feasibility of extending the virtualization of wireless networks towards the radio hardware. A SDR architecture is presented for radio hardware virtualization in order to facilitate SDWN design and experimentation. We do believe that by adopting the virtualization-oriented hardware accelerator design presented here, an all-layer end-to-end high performance SDWN can be achieved.


Introduction
SDN is a promising concept at networking level, it decouples the network control and data forwarding functions, allows directly programmable network control, and provides diverse network services to a variety of applications.Before the introduction of the SDN concept, there were an increasing amount of labels/headers appended to packets, to support various kinds of protocols for different services on the Internet, which greatly increased the processing burden on the edge routers and switches.SDN solves the issue by using a disruptive design that separates data and control planes: routers and switches become dumb devices, which are only responsible for forwarding data according to the controller's instructions.The controller applies slow-varying configurations on the data forwarding devices, in order to slice/allocate the network resources to different types of services during runtime.Such an approach allows virtualizing a single physical network into multiple and heterogeneous logical network domains, each domain serving a certain category of traffic flow in the most appropriate way.The SDN approach is very encouraging, but has been basically designed for wired networks and mainly involves the higher layers of the protocol stack, e.g.layer 4 to 7 of the Open Systems Interconnection (OSI) model.It is primarily providing transport capacity and service differentiation up to the edge router of wired networks.
Wireless networks benefiting from the flexibility offered by virtualization in SDN are known as SDWN, however, it must be emphasized that the wireless medium, i.e., 'radio spectrum', has very different properties than the ones exhibited by wired networks.In wired networks, a port of a switch or router is always connected to fiber or UTP cables.Multiple ports are equivalent to multiple isolated non-interfering communication links with constant data rate.As a result, Ethernet is ubiquitous in the wired network.On the other hand, the wireless medium is not isolated but shared.In wireless networks, there is interference when multiple links are simultaneously running in the same or adjacent radio spectrum bands.In addition, the data rate of a wireless link is dynamic, due to the variations in distance (mobility), channel conditions (e.g., heavily shaded or LOS), unpredicted interference from other co-located wireless technologies or radiating devices (e.g.microwave ovens).Hence, unlike wired networks that are dominated by Ethernet or optical links that have a deterministic capacity, wireless networks are non-deterministic and established upon many heterogeneous PHY and MAC layer standards, with each standard serving a different type of traffic flow.For example, LoRa [1] and SigFox [2] are used for long range low rate sensor data collection, while Zigbee is designed for short-mid range low-mid rate sensor networks [3]; Bluetooth is known for short range accessory communications [4]; WiFi is devised for short range high throughput applications [5]; 2G/3G/4G mobile networks serve mid-high throughput terminals over a mid-long range [6,7]; etc.
From an end-to-end communication point of view, the different traffic flows are characterized by different QoS requirements, such as for example, latency and throughput, which will be addressed later in this paper.The main idea here is that, in wireless communications networks, one technology can hardly meet all requirements and can not give firm guarantees to QoS requirements.The lack of coordination and interaction among all the wireless networks standards, can jeopardize the overall performance of a network.The versatility in wireless network's PHY and link layers is somewhat comparable to the era before SDN's appearance in the wired network, where various headers are appended into packets to support different services.Therefore, the logical next step in wireless networks is the achievement of runtime configuration across the diverse wireless standards by applying the SDN concept.This implies two requirements: (i) the lower layer radio stack needs to be more flexible in order to support runtime configuration and virtualization; (ii) the conventional SDN paradigm needs to be extended to counteract the uncertainties in wireless networks, by taking measurements in order to optimize the radio resource allocations (e.g., spectrum, time, space).
In the remainder of this paper, we first present a comprehensive view on the status of various efforts towards SDWN in Section 2; next an end-to-end view of the SDN-enabled wireless network from the ORCA project [8] is given in Section 3; then Section 4 presents a novel architecture for radio hardware virtualization to support the ORCA vision, followed by initial experimental validations; finally we conclude this work in Section 5.

State of the art analysis
This section begins with the recent progress in the field of flexible and generic physical layer radio implementations, and the trend towards more dynamic spectrum allocation schemes; then we move on to two representative ways of real-life SDWN practices.

Evolution towards flexible PHY
At the radio level, we have observed the emergence of SDR.An SDR is a radio communication system where transceiver components that are typically implemented on Application-Specific Integrated Circuit (ASIC), e.g., digital mixers, filters, equalizers, modulators/demodulators, multiple antenna techniques etc., are instead implemented on software on a host computer or on an embedded system equipped with programmable hardware like Application-Specific Instruction set Processor (ASIP) or Field-Programmable Gate Array (FPGA).The concept behind SDR is very encouraging for the development of state-of-the-art physical layer (PHY) functionalities, because software programming allows faster development cycles.Therefore, many advanced and flexible physical layer techniques are available on SDR platforms, including Massive MIMO, full duplex, mmWave, and various novel waveforms.
The main problem with software implementation is the slower sequential execution of algorithms, even when multi-core or many-core Central Programming Unit (CPU) platforms or Graphics Processing Units (GPUs) are used, in contrast to a very fast execution and a very high degree of parallelization achieved with implementations on ASIC, ASIP or FPGA.For this reason, SDR development has so far mostly been limited to non real-time physical layer development, as software implementations do not always offer the fast execution times that are required for true networking experimentations, e.g., experiments requiring acknowledgment of MAC frames within a few microseconds.Recently, we have been observing limited yet increasing efforts to code more and more transceiver functionality on hardware, e.g., FPGA, trading off software flexibility for faster execution times, at the cost of higher design time.In both cases, SDR implementations are much more open, which gives potential to support functionalities such as network virtualization on the lower communication stack.

Evolution towards generic PHY
Current wireless networks are composed of many different standards below the transport layer, which are necessary due to the versatility in the wireless medium and the traffic demands.In recent years, we have been noticing that individual physical layer standards are evolving towards each other to become more generic/homogeneous.For instance, Narrow Band Internet of Things (NB-IoT) has been developed as a subset of LTE to support low power and long range IoT applications, which has similar capabilities as LoRA [9].In addition, LTE also supports smaller Transmission Time Intervals (TTI), which are complementary to the standard 1 ms TTI for serving low-latency applications [10].Conventional WiFi standards dont support flexible sub-carrier allocation, meaning that the spectrum resource cannot be sliced besides the selection of channels.The latest WiFi standard 802.11ax is supposed to support the sub-carrier allocation feature, which is comparable to the resource blocks in LTE [11].According to the standardization of 5G New Radio (NR), "scalable OFDM numerology" is proposed to support sub-carrier spacing ranging from 15 kHz (same as LTE) to 240 kHz (close to WiFi 802.11a, 312.5 kHz), to enable the operation in a much wider radio spectrum and coverage areas [11,12].Without doubt, the evolution towards a more generic/homogeneous physical layer in wireless network will make the support of SDWN more convenient.

Evolution towards dynamic spectrum allocation
As stated previously, the radio communication link is not isolated by nature, but it could be achieved by enforcing the usage of a chunk of the spectrum only for a specific application, this is referred to as the licensed spectrum usage.This is the simplest approach, however, it is not efficient, since the static allocation causes waste of spectrum when there is no traffic demand from a given application.Some efforts are already being pushed to increase the utilization rate of the licensed spectrum, by allowing secondary usage of the spectrum without sacrificing the communication quality of the the incumbents, e.g., TV white space [13] or spectrum sharing in radar bands [14].The alternative to the simplest approach is the unlicensed spectrum access, where technologies share the medium with equal privileges.This approach is best represented by the current situation in ISM bands, where several technologies compete for spectrum access.However, the chances of over-the-air collisions increase when there is no coordination among devices/technologies, which is likely to trigger extended back off periods, leading to poor spectrum efficiency and lower QoS observed in the end-to-end communication links.The control and management functionalities in SDN could be borrowed to improve coordination between wireless network entities for spectrum usage.In addition to improving the efficiency of allocated radio spectrum, huge bandwidth can be harvested by extending wireless signal spectrum to mmWave band [15], such as 5G [11,12] and 802.11ad [16].
Generally speaking, there is a trend going on for dynamic spectrum allocation, and many of the pioneer works in this area are based on SDR, focusing on its ability to rapidly adapt the operational parameters in order to achieve the optimal performance [17].

SDWN experiments on commercial WiFi chipset
Some SDN experiments have already been carried out in the wireless network domain.An off-the-shelf WiFi Access Point (AP) device can be split into multiple virtual APs on demand by flashing customized firmware, e.g., OpenWRT, [18].In this way, the bandwidth supported by the physical AP is sliced and can be allocated to different users or services.Seamless mobility among physical APs can be achieved by managing the virtual APs across multiple physical APs [19].These functionalities are implemented in layers above upper-MAC.It means that multiple virtual entities share a single physical layer and lower-MAC layer by Time Division Multiplexing (TDM).
Although these efforts are important progresses towards SDWN, there are a number of significant limitations caused by the lack of SDN oriented physical and lower-MAC layers.As the virtual APs are created in a pure software manner, the additional overhead caused by running multiple link services, e.g., authentication status maintenance, context switching, etc., upon a weak processor causes a severe performance degradation in throughput [20,21].Furthermore, extra latency and jitter are introduced for a specific service/user, due to different virtual entities accessing the single physical link through time division multiplexing, meaning that when one entity is accessing the physical link, the rest of the users/services are waiting for their turn.

SDWN experiments on SDR and cloud computing
Essentially, SDR aims to implement radio transceiver functionalities, which are traditionally realized in hardware, on software domain.It is a promising candidate for physical layer implementation of SDWN, as demonstrated in use cases such as Cloud based Radio Access Network or Centralized Radio Access Network (C-RAN) [22].In C-RAN systems, a Remote Radio Head (RRH) only performs conversion between the digitized baseband signal and the analog RF signal.The Baseband Unit (BBU) is implemented in the servers on the cloud, which in turn performs all the necessary processing tasks of the physical layer.Empowered by the rather mature virtualization technologies in computer science domain, the software BBU can be created, allocated, migrated and deleted on the fly.The BBU in the cloud might achieve comparable throughput as their hardware counterparts, however, the performance in terms of latency is generally much worse.Fortunately, existing mobile network standards can tolerate a relatively large latency.For instance, LTE has a 1 ms TTI and 4 ms Hybrid Automatic Repeat Request (HARQ) feedback delay [7].
Although centralized BBU functions work well for some applications, it is difficult to serve applications with tight latency requirements.For example, self-driving functions relaying on vehicle-to-vehicle communications require the base station to be located as close as possible to the vehicle in order to minimize the reaction time of the vehicle.For this type of use case, Mobile Edge Cloud (MEC) is a more suitable architecture than C-RAN.However, even MEC cannot softwarize the wireless standards with extremely low latency requirement, such as WiFi.WiFi's low MAC requires a node to acknowledge a successfully received packet within the duration of Short Inter Frame Space (SIFS) [5].SIFS ranges from 16 µs down to 3 µs, depending on the specific variant of WiFi standards (IEEE802.11a/b/g/n/ad,etc).It is evident that this requirement cannot be met with the BBU entirely implemented in software.The lower-MAC and hardware coded physical layer need therefore to be tightly integrated in order to fulfill the necessary level of latency requirement.

ORCA's vision
The overall vision of the H2020 ORCA project is to drive end-to-end wireless network innovation by bridging real-time SDR and SDN.The project aims at exploiting the maximum flexibility at radio, medium access and network levels, in order to meet a very diverse application requirements [23].
This vision is illustrated in Fig. 1 and is further explained step-by-step using factory-of-the-future as the driving scenario.The manufacturing industry is one of the most demanding verticals with respect to ultra-low latencies, ultra-high reliability, ultra-high data rates, ultra-high availability, reliable indoor coverage in harsh environments (with a lot of metal structures) as well as energy-efficient and ultra-low communication costs for produced and connected goods.At the top of Fig. 1  observed corresponding to different application requirements.For the manufacturing scenario, a non-exhaustive list of traffic classes (TCs), can be identified.These TCs were inspired by [24,25].TC1: time-critical sensor/actuator control loop: bidirectional communication, low data rate (in the order of kbps), stringent timing requirements (below 1 ms cycle time, order 100 µs response time, below 1 µs jitter), ultrahigh reliability (99.9999999 %), indoor, very short range (in the order of 10 m).Examples: motion control in printing machines, textile weaving machines, paper mills.
TC3: low-latency continuous medium throughput: point-to-point and pointto-multipoint, moderate data rate (in the order of 10-100 kbps), low latency and jitter (both below 10 ms), ubiquitous coverage and high availability (indoor + on-site outdoor), mobility support, large autonomy.Example: voice communications between workers with headsets in the manufacturing hall.
TC4: correlated data capturing: moderate data rates (in the order of kbps up to 100 Mbps), moderate latency (10-100 ms), ultra-high time synchronization accuracy (below 100 ns), and moderate reliability (99.999 %), ubiquitous indoor coverage.Example: capturing of time-correlated sensor data on the shop floor to facilitate virtualized design processes that integrate simulator data with real-life data sensed during production.
TC5: non time-critical in-factory communication: moderate data rates (in the order of kbps up to 100 Mbps), latency in the order of 100 ms (limited by human response times), moderate reliability (99.999 %) ubiquitous coverage and high availability (indoor + on-site outdoor), mobility support.Examples: interactions between humans and machines or robots, localization of assets and goods.
TC6: bursty traffic: non-time critical (very large latencies allowed), large data volumes (in the order of MB up to 100 GB).Examples: sporadic software/firmware updates of machines, temporary reconfiguration of machines.
TC7: best effort: low priority, no firm guarantees on data rates or latency, minimal shared capacity, ubiquitous coverage (indoor-outdoor).Example: typical Internet application (email, web surfing).
The current radio technologies lack capabilities with respect to wireless performance, management of heterogeneous devices, technology interoperability and application (traffic) demands.Flexible and seamless connectivity across different Radio Access Technologies (RATs) will be required in order to instantaneously adapt the capacity and mobility needs to changing environments and application demands.A first approach to deal with such very diverse traffic demands would be the application of SDN techniques.Instead of employing one physical network infrastructure to deal with all the different traffic classes, applying complex traffic algorithms or QoS scheduling mechanisms, the network infrastructure can be virtualized into separate and independent network infrastructures, applying the most appropriate protocols and resource sharing mechanisms to deal with a specific traffic class.This approach is called network slicing or vertical slicing.This is illustrated by the vertical, colored pipes in Fig. 1.Each pipe in the figure represents a single network slice, architected and optimized for the specific requirements of the applications supported by its traffic class.For the manufacturing scenario described above, this results in 7 different pipes.The main focus of SDN today is on wired networks (Ethernet, optical transport networks) and on layer 3. ORCA offers a wireless SDN, by extending the current SDN vertical slicing capabilities with lower layer wireless capabilities.
To that end, the vertical pipes (corresponding to different traffic classes) need to be mapped onto the radio resource grid (bottom of Fig. 1), hereby maximally exploiting the radio degrees of freedom like time, frequency and space.It is important to note that the space dimension allows the reuse of spectrum and time resources through space division multiple access (not shown in Fig. 1).The radio resource grid corresponds to the overall capacity of the radio infrastructure.Each block in the radio resource grid represents a chunk of radio resources consuming a certain part of the airtime, spectrum and space (con-trolled by the power setting for omni-directional antennas or by directional beam in 3D MIMO case) with a certain PHY configuration (modulation and coding scheme) providing a certain dynamic capacity (in terms of data payload it can carry).This capacity is dynamic, as it changes over time due to changes in the wireless environment (requiring adaptations to the PHY).The mechanism of mapping vertical pipes to radio resource blocks is called radio slicing.It is responsible for the dynamic allocation of available resource blocks in the radio resource grid over the different traffic classes.
The focus of the ORCA project is on wireless functionalities that are needed to extend the current SDN concepts.ORCA has no intention to develop new network-level SDN paradigms, but will align with other SDN-oriented initiatives (based on heterogeneous and cooperative networks integrated through SDN/NFV techniques) as to ensure that ORCA developments are compliant with common SDN mechanisms.The focus of this paper is to enhance data plane functionalities of wireless networks once this is necessary to support more advanced SDN control functionalities in the future of SDWN.

Radio Hardware Virtualization
To support the SDN functionalities and ORCA architecture, a requirement analysis is carried out targeting runtime reconfigurable SDR physical and lower-MAC layers.More specifically, the ORCA SDR architecture aims to meet the following requirements: 1. Requirement Analysis (a) RF Resource Slicing: Radio Frequency (RF) resource slicing is used to slice wireless resources, such as spectrum, time and beams, i.e., space beams pointing to specific directions.As a generalized module, it should not stick to any specific standard.A practical choice is to use it as the last stage of the digital processing chain, just before the Analog to Digital Converter (ADC) and Digital to Analog Converter (DAC).The module multiplexes/demultiplexes IQ sample streams from/to physical layer transceivers.The transceivers could be physical entities or logical/virtual entities.
To perform multiplexing/demultiplexing in real time under control parameters, this module needs high processing throughput and precise timing control (in the case of time slicing).For instance, a 4 antenna WiFi RF front-end generates 2.56 Gbps, i.e., a data rate of 20 Msps (IQ samples) x 32-bit per sample (16-bit I, 16-bit Q) x 4 antennas.In order to multiplex several WiFi transceivers in the frequency domain, a link with a high data rate is required.(b) Multi-channel Transceiver: Multiple concurrent transceiver instances are necessary in order to utilize radio resources for multiple concurrent beams or frequency channels, in this way, multiple simultaneous services are supported by separate radio slices.A multi-channel transceiver can be achieved by implementing multiple physical instances, or creating multiple logical instances from single or fewer physical instances.In terms of hardware/computing resources occupancy, the latter is better.When the same set of physical resources are shared by multiple logical instances, the hardware context switching speed is essential to support multiple instances.
The core part of the physical layer is the transceiver chain.In general, a receiver should include synchronization, channel estimation, equalization, decoding, deframing, etc.; on the other hand, a transmitter should include framing, coding, modulation, etc.For low latency standards or time critical services, the transceiver should have low processing delay and should therefore be implemented in ASIC or FPGA.For relaxed latency standards or services, it could be either software or hardware implementation.(c) Context Switching Support: In the computer science domain, when multiple programs/virtual-machines share the same CPU, they actually sleep and wake up frequently and quickly, triggered by user input, network packet arrival or other CPU generated interruption.Before sleep, the CPU's state needs to be saved for the instance.This can be done by saving the CPU's internal registers into the memory.Before waking up, a restoring operation is performed to make sure that the execution is resumed correctly.Compared with CPU, the radio transceiver functionality is more complicated.There are lots of internal stages, FIFOs, buffers, state machines inside the radio transceiver, therefore, context saving and restoring are challenging operations when one radio transceiver is supposed to be shared or switched quickly among multiple users/services.Therefore, besides traditional radio transceiver functionalities, the design should also support fast hardware level context saving and restoring.With this feature, a high performance transceiver can be used to process multiple IQ streams in fast switching TDM manner.Along with IQ buffers for each stream and transceiver consuming IQ samples much faster than IQ incoming into each buffer, buffer overflow can be avoided for each IQ stream.Through this way, multiple concurrent logical transceivers can be created from a single transceiver to serve multiple traffic classes, and therefore, multiple end-to-end virtual slices can be implemented efficiently without implementing multiple physical transceivers.(d) Resource Slicing Controller: In this SDR-SDN context, there are two types of resources.The first type refers to the chunk of radio resources that are allocated to a single radio slice (such as beams, spectrum, and time) and can be used by a signal for transmitting and receiving.The second type of resource refers to the operation mode of the transceivers.This type of resource is used to deliver services/traffic within a transceiver's radio slice.We call the first type of resource 'RF resource', and the second resource 'transceiver resource'.To use resources smartly and efficiently under diverse and dynamic requirements, a control software is needed for the real-time management of resources.
Although the control software in general is not computationally intensive, controlling resources in precise timing is needed when time slot is used in TDMA MAC, such as multi-frequency TDMA, multi-beam TDMA.(e) SDN Agent: At the AP or edge of the wireless network, a traditional SDN controller might not offer appropriate control functionality toward the AP or base station, because wireless equipments capabilities are more complicated than "just forwarding".However, the traditional SDN controller does know the requirements of traffic classes or users.Therefore a SDN agent that incorporates wireless domain knowledge and that is capable of interpreting (more abstract) SDN requirements and mapping those into control strategies of radio domain resources is needed.2. Architecture Design for Implementation: In order to meet the requirements mentioned in section 4, Fig. 2 depicts an initial architecture design for implementation.The proposed architecture supports both hardwarelike low latency performance and software-like flexibility [26].The platform is composed of RF front-end and digital baseband.The RF front-end can be any of the widely used devices, such as the FMCOMMS2 [27] or USRP [28].
To make a highly efficient design, the digital baseband chip should include not only hardware/FPGA for high-performance low-latency operation but also a processor system to support control and management functionalities in higher network layer.Therefore, System-on-Chip (SoC) architectures are good candidates, such as the Xilinx Zynq SoC [29].The Zynq SoC consists of two parts, the Programmable Logic (PL) part is mainly the traditional FPGA, and the Processor System (PS) part includes an ARM based multiprocessor system.Two parts are proposed to be implemented in FPGA/HW: the RF resource slicing module and the transceiver resource pool.The first part is used to construct the RF resources, such as beams, channels/bands and time slots, which set the boundaries for transceiver operation in the second block.Multi-channel transceivers are implemented in the second part, with hardware-level fast context switching support.Transceivers construct data path between diverse network traffic/service/user and RF resources under control from software side.For the high-speed and low-latency on-chip connection between hardware blocks and hardware-software, an Advanced Extensible Interface (AXI) stream bus can be used.On-chip software runs in the processor system.Three main software modules are needed: MAC and network protocol; resource slicing controller; SDN agent.As the hardware design supports virtualization, the corresponding MAC and network protocols should also support creating corresponding multiple instances to handle diverse traffic streams in line with the SDN agent.To control the resources in real-time, the resource slicing controller software communicates with the hardware block via the AXI LITE register interface.MHz WiFi channels, overlapping with eight 5 MHz ZigBee channels [30].A dual-standard preamble detector (part of the baseband receiver), with fast hardware context maintenance support, is implemented for the transceiver resource part.Based on the FPGA design, the resource slicing controller software in the processor creates 10 virtual preamble detector instances out of the single FPGA preamble detector block to serve 10 input IQ sample streams (2 WiFi, 8 ZigBee).From the user point of view, it is the same as having 10 parallel preamble detectors running concurrently in full-time, which can show packet count statistics of 10 concurrent live traffics in the air.In addition, in order to make the demonstration more user friendly, a Bluetooth Low Energy (BLE) transmitter is implemented in the FPGA.It encodes the packet count statistics information into the BLE broadcasting packet, and broadcasts it over the less busy channel according to packet count detected by 10 virtual preamble detector instances.Then any general purpose BLE scanner/sniffer can read the message on user's devices (phone, notepad, computer, etc.).

Conclusion
In this paper, a radio hardware virtualization oriented transceiver architecture is designed to bridge the gap between the diverse real-world applications and the scarce RF resources.This architecture softwarizes the lowest wireless network stack such as PHY and low MAC, while maintaining equally high performance and low latency as in the conventional hardware-defined network.With this radio hardware virtualization feature, the control plane can make efficient RF and hardware resource utilization according to dynamic network traffic/service requirements.The initial proof-of-concept demonstration shows the feasibility of radio hardware virtualization with limited hardware resources.
As the next step in the ORCA project, we will bridge real-time SDR and SDN with the help of radio hardware virtualization and exploit maximum flexibility at PHY, MAC and network levels, as a way to support very diverse application requirements by efficiently sharing limited RF and transceiver resources.

Fig. 1
Fig.1Network innovation driven by ORCA -the end-to-end view on SDN enabled wireless network[23].

Fig. 2
Fig. 2 Architecture proposed to meet the requirements presented in Section 4.

Fig. 3
Fig.3Demonstration of multiple virtual radios on a single chip.

3 .
Initial Validation: A proof of concept demonstration [26] has been developed based on FMCOMMS2 RF front-end and Xilinx ZC706 [29] board as shown in Fig. 3.In this demonstration, a Digital Down-converter (DDC) bank is implemented for the RF spectral resource slicing part.It slices the 40 MHz spectrum (partial 2.4 GHz ISM band) into two adjacent 20