# A Baseband Wireless Spectrum Hypervisor for Multiplexing Concurrent OFDM Signals
## 6 Proof of Concept Prototype  
In this section, we describe a proof of concept prototype developed to verify the performance of proposed spectrum hypervisor architecture in real-world experiments. Figure 8 depicts the high-level architecture of the implementation of the proposed architecture. As can be seen, the prototype is composed of several modules, namely PHY communicator control, \(M\) vPHYs, and the hypervisor control module, which is in turn, composed of the modules hypervisor Tx and Rx. The prototype is an open-source software-defined PHY layer designed to multiplex and receive (i.e., demultiplex) the signal of several vPHYs [14]. It is implemented based on the srsLTE library [49]. srsLTE is an open-source and free LTE software-based library [49]. The prototype can run on top of several Ettus software-defined radio (SDR) devices such as the Ettus USRP X family or National Instruments' (NI) RIO SDR devices [50; 51] by using the Universal Software Radio Peripheral (USRP) Hardware Driver (UHD) software Application Programming Interface (API) [17; 52]. Therefore, the prototype accesses the SDR device through the UHD driver and its APIs [53]. The communication between the prototype and the upper layers is carried out through a set of three well-defined messages, which are exchanged over a ZeroMQ bus [54], i.e., the prototype and the upper layers are interconnected through a publish-subscribe messaging system known as ZeroMQ [54]. ZeroMQ is a high-performance asynchronous messaging library, designed to be used in distributed or concurrent applications [54]. The set of vPHY messages is designed with Google's Protocol Buffers (protobuf) [55]. Protobuf is used for data serialization and works perfectly with the 0 MQ messaging library [54]. The first two vPHY messages, called, Tx and Rx Control, are used to control and configure the transmission and reception of user data, respectively. The parameters in these two control vPHY messages should be configured and sent to the individual vPHYs by the upper layers before the transmission of every new subframe. Each vPHY control message, as the name suggests, controls the operation of only one vPHY. The remaining message, called Rx statistics vPHY message, is used to give upper layers feedback on the operation of each individual vPHY. Figure 8: High-level architecture of the implemented prototype. **Tx control** messages transport the user data to be transmitted (i.e., TBs) and transmission parameters such as vPHY ID, vPHY Tx BW, MCS, Tx gain, Tx channel, number of resource blocks used by that user, data length, and data. The vPHY ID field is used in all messages to specify to which one of the vPHY's a control message is meant to or received from. **Rx control** messages are used to configure reception parameters such as vPHY ID, vPHY Rx BW, and Rx channel. **Rx statistics** messages carry the vPHY ID, received decoded user data, and reception statistics such as Received Signal Strength Indication (RSSI), Channel Quality Indicator (CQI), decoded MCS, cyclic redundancy check (CRC) error counter, etc. The vPHY messages and their parameters are summarized in Table 2.  
Next, we describe each one of the modules composing the prototype. * **PHY Communicator Control**: this module is responsible for the exchange of messages with several and possibly independent upper layers, e.g., the MAC layers from different users or operators. This module works on a subframe basis, meaning that the connected upper layers always send/receive in one control message to/from the module the content of a subframe as the minimum unit of data exchange. The received control messages, carrying user data, are then relayed to the respective vPHY by using the vPHY ID in the control message. The decoded user data is sent to the respective upper layer also by using the vPHY ID. * **vPHY**: modulates and demodulates the user data.