Software Defined Radio Platforms for Wireless Technologies

Wireless connectivity standards have been developed by standardizing bodies to meet the requirements of various applications. A wireless transceiver should be equipped with a Radio Frequency (RF) transceiver to support a wireless standard. Traditional RF transceivers are designed and implemented on a radio chip or an embedded module in a System-on-a-Chip (SoC), ensuring small size, high performance, low power consumption, and cost. However, this traditional implementation design limits directly or indirectly the programmability and flexibility of the RF transceivers. An alternative solution to implement RF transceivers is using Software Defined Radio (SDR) platforms. In the market, SDR platform hardware exists with different configurations, performance, cost, size, etc., making it hard to select the minimum SDR platform necessary to satisfy the wireless standard requirements. This paper aims to provide a list of well-known General Purpose Processor (GPP) based SDR platforms that meet the minimum specifications of selected wireless standards. To this end, we first review the characteristics of selected wireless technologies. Then, we investigate existing SDR platform architecture and their maximal performance in terms of the frequency range, bandwidth, symbol rate, bitrate, and latency support. Finally, we intersect the wireless standard requirements with the corresponding SDR platform parameters and provide a list of GPP-based SDR platforms for some existing wireless technology implementations. All investigations related to the frequency, bandwidth, symbol rate, and bitrate parameters are supported by theoretical results, whereas latency results are obtained from experiments by benchmarking existing implementations.


I. INTRODUCTION
The number of wireless devices used by various wireless application domains such as Wireless Sensor Networks (WSNs) [1], Internet of Things (IoT) [2], cellular base stations [3], etc., has increased tremendously in the past decade. Several wireless technologies are standardized to enable the interconnection between the different wireless devices including NFC, RFID, IEEE 802.15x, IEEE 802.11x, LoRa, Sigfox, 3GPP 3G/4G/5G, etc., [3]- [5]. A wireless device can incorporate one or multiple wireless transceivers supporting distinct wireless technologies. Each transceiver performs all the physical (PHY) and a portion of the Media The associate editor coordinating the review of this manuscript and approving it for publication was Francesco Benedetto .
Access Control (MAC) layer operations through integrated analog and digital circuit blocks. Indeed, most of the PHY layer analog operations are implemented on a dedicated and integrated analog hardware such as amplifiers, radio frequency (RF) synthesizers, filters, etc. On the other hand, some PHY layer digital baseband and time critical MAC layer functions are fully implemented on a digital hardware such as Application Specific Integrated Circuits (ASICs), a Programmable Digital Signal Processor (PDSP), Application Specific Instruction Set DSP (DSP ASIP) or a mixed solution using ASIC hardware accelerators with PDSP or with DSP ASIP [6]. This traditional implementation considerably limits directly or indirectly the programmability and flexibility of the transceivers for upgrading or handling multiple wireless standards. Moreover, processors of wireless transceivers are mostly proprietary which prevent programmers and researchers from access to reprogram the instruction code.
An alternative solution to allow programmers and researchers to easily control the hardware and program the software of wireless transceivers is to use an implementation based on general-purpose processor (GPP) based Software Defined Radio (SDR) platforms, which is a reconfigurable and reprogrammable radio transceiver. In such platforms, the PHY layer digital baseband and MAC layer operations are implemented on a GPP, and the PHY layer analog RF/IF front-end operations are controlled using an analog device board supporting a wide range radio spectrum. This solution have been explored by many researchers to investigate the architecture, challenges and compare the performance of several SDR platforms [7]- [9]. In addition, as the PHY and MAC layers are performed in software by GPP host and due to the reconfigurability and reprogrammability of the radio transceiver, the SDR platform can be used to implement multiple wireless technologies. Such benefit has been exploited in many recent research works such as [10], [11]. These benefits conjugated with the continuous advancement in processing performance (hardware and software) and decreasing price of GPPs made GPP-based SDR platforms gain much attention for implementing and testing wireless technologies [12]- [16]. Moreover, it is also used to build testbeds and/or perform experimentation to study different features of communication systems and suggest performance improvement [17]- [19].
Currently, several SDR platforms are available in the market and research community. To implement a desired wireless technology, an appropriate SDR platform need to be selected. Previous research works such as [7] and [9] have presented the challenges during SDR platform selection process and compared the performance of SDR platforms in the general context. However, they abstain from addressing the specific considerations required by SDR platforms based on the requirement of wireless technologies. This problem is slightly addressed by other researchers and developers in two different perspectives, by designing a custom SDR architecture suited to a specific implementation such as [20]- [22], and/or providing list of recommended requirements to implement a certain wireless technology. Regarding the latter case, the recommendations are usually provided by SDR platform software implementations such as Software Radio Systems (SRS) [14], OpenAirInterface Software (OAI) [23], gr-IEEE-802.15.4 [15], gr-LoRa [24], etc. However, these recommendations are essentially formulated after multiple experimental tests. Nevertheless, as the experimental tests are not exhaustive, the recommended SDR platforms may be over-dimensioned and thus the minimal necessary configuration (carrier frequency and bandwidth, clock rate, communication interface support, GPP cores, GPP processing power, software architecture, etc.), can be exceeded.
The aim of this paper is to provide a list of possible GPP-based SDR platforms in terms of hardware components satisfying the minimum specifications of well-known wireless technologies. This is achieved by analyzing what a wireless technology requires at minimum in terms of frequency range, bandwidth, symbol rate, bitrate and latency, and the performance offered by GPP-based SDR platform components. The contributions of this paper can be summarized as: • we present a detailed study of the architecture of GPP-based SDR platforms, and analyze their capabilities in terms of the performance metrics; • we drive the minimum performance requirements of the most relevant wireless technologies. We use these requirements to draw mapping conditions in order to determine which GPP-based SDR platform is appropriate to successfully perform a targeted wireless technology; • we identify existing wireless technology implementations from the literature that use GPP-based SDR platforms, examine their performance metrics, and suggest a list of other possible SDR platforms to implement the use-cases described in the literature. Thus, the in-depth analysis of selected wireless technologies and SDR platforms allows researchers from both academia and industry to easily understand required parameters, software and hardware components of SDR platforms. We believe this paper will help researchers (SDR platform users and SDR software developers) looking for the appropriate SDR platform to implement a given wireless technology. To the best of our knowledge, this paper is the first to perform mapping several wireless technologies with GPP-based SDR platforms.
This paper is organized as follows: Section II provides classification and characteristics of well-known wireless connectivity technologies. Section III discusses the architecture of GPP-based SDR platforms and provides general background on the hardware and software components. Section IV provides a detailed study on the performance parameters of GPP-based SDR platforms and presents numerical results using selected GPP-based SDR platforms. Section V presents a mapping between SDR platform performance and wireless technology requirements. Open research challenges and future directions are given in section VI. Finally, section VII provides conclusions to this paper.

II. WIRELESS CONNECTIVITY TECHNOLOGIES
The interconnection between different wireless devices is enabled by a wide range of wireless technologies that can cover from very short distance (in centimeter range) to several kilometers. Thus, wireless connectivity technologies can mainly be classified into three groups based on the range they cover [25]: i) short-range wireless technologies, ii) Wireless Local Area Networks (WLANs), and iii) Wireless Wide Area Networks (WWANs). Within each of these categories, several wireless technologies are standardized, as shown in Fig. 1. The subsequent subsections present the main PHY and MAC layer characteristics of major wireless technologies. We note  that, the frequency requirement of wireless technologies stated in the tables is given based on their standard. However, the specific frequency band used by a wireless technology depends on its allocation for global and regional use and also countries regulation [26].  [32], [33]. They are high bandwidth technologies that supports the communication of bandwidth-intensive applications like streaming video, and enable wireless gateways with a high-speed interface to relay traffics requiring large bandwidth and IP connectivity [34]. Other standards promising for IoT and WSN deployment due to their low power and long range wireless communication support are IEEE 802.11ah (WiFi-HaLoW) [35] and IEEE 802.11p [36]. IEEE 802.11ah defines PHY and MAC layer specification for large scale sensor networks and extended range hotspot. It operates in the subGHz ISM bands. IEEE 802.11p is an amendment of 802.11 standard that operates in the 5.9 GHz band and offer wireless connectivity between mobile vehicles (and/or vehicles and roadside units) and designed to guarantee low latency [36]. Table 2 enlists their PHY and MAC layer characteristics.

C. WIRELESS WIDE AREA NETWORK -WWAN
WWANs are meant for large area coverage in the order of kilometers. The wireless communication technologies standardized for such wide coverage have mainly two groups: cellular networks such as 2G, 3G, 4G and 5G; and Low Power Wide Area Networks (LP-WANs). The latter also has two groups: licensed and unlicensed. The licensed LP-WAN consists of Narrow-Band IoT (NB-IoT), Enhanced Coverage-GSM IoT (EC-GSM-IoT) and Long   [37]. LP-WAN technologies are designed for Machine-to-Machine (M2M) and IoT applications that need to forward small payload data at low data rate and low power consumption [38], [39]. The cellular technologies (2G, 3G, 4G, and 5G), on the other hand, consume a lot of device energy which may cause a negative impact on low-power IoT devices. However, they are useful for IoT gateways or IoT devices running bandwidth-intensive applications. Table 3 quantifies the requirements of cellular and LP-WAN technologies.

III. GPP-BASED SDR PLATFORM ARCHITECTURE
The implementation design of conventional wireless transceivers, in general, lacks reprogrammability, flexibility and scalability. Therefore, upgrading the software, changing the logic of the dedicated hardware or reusing the transceiver to implement a wireless standard other than the one the transceiver was designed for is limited or non-existent. Moreover, conventional wireless transceivers are mostly proprietary which prevent developers and researchers from access to reprogram the assembly instruction set. An alternative solution to mitigate these limitation is using SDR platforms. In addition to the programmability feature, the SDR platform also serve as a multi-technology gateway by performing multiple wireless technologies using a common set of radio transceiver [10], [11]. It also allows to reuse software across multiple radio devices and download software over-the-air to implement new standards and fix bugs [8]. Furthermore, it is recently being used to mitigate cross-technology interference problem faced by conventional technologies [42].
An SDR platform is a class of radio transceivers which controls the analog RF/IF part using an open-source analog device board, named SDR device, and implements all the digital part using programmable host processor. The programmable host processor can be GPP, DSP ASIP or FPGA. The scope of our study is limited to GPP-based SDR platforms due to its easy programmability using a high-level language and its flexibility for reconfiguration and handling complex algorithms [9]. The general architecture of GPP-based SDR platform is illustrated in Fig. 2. It is mainly sectioned into three parts as SDR device, communication interface and GPP host. Each component of the platform has its communication parameters that contribute to the overall performance of the SDR platform. This section investigates the GPP-based SDR platform.

A. SDR DEVICE
An SDR device is a small handheld type of device which is capable of transmitting and receiving signals at different frequencies. It typically consists of software controllable analog RF/IF and digital IF front-ends. The former is called as  daughterboard and the latter as motherboard. This subsection describes their respective tasks and characteristics.

1) DAUGHTERBOARD
The daughterboard is essentially responsible to perform analog RF/IF processing functions such as filtering, amplification, conversion of signals from RF to IF and vice-versa, etc. It is mainly characterized by the frequency band it covers, the analog bandwidth, RF performance, number of channels, channel's capability (only RX or TX/RX), mode of operation as a half (HD) or full (FD) duplex, etc. Mainly, the operating frequency range, width of analog bandwidth and channel's capability determines the scope of the daughterboard to implement a wide range of wireless technologies using SDR device. The daughterboard interfaces the antenna with the motherboard. Indeed, most daughterboards integrate multiple input/output circuits to connect multiple separated antennas enabling simultaneous transmission and reception capability [43], [44]. Also, daughterboards integrate analog inputs/outputs to connect motherboard ADCs and DACs. In the market, daughterboards are either stand-alone component or integrated with a motherboard forming a single board. Table 4 lists few commercially available daughterboards.

2) MOTHERBOARD
Motherboard is mainly responsible to perform digitization, channelization and sample rate conversion (digital up/down conversion [DUC/DDC]). To achieve these operations, motherboards integrate ADCs/DACs and a DSP processor that can be implemented using ASIC, DSP ASIP or FPGA. It also integrates one or more communication interfaces to connect with GPP host. It is mainly characterized by the maximum ADC and DAC sample rates, ADC and DAC resolution, DSP processor design and the supported communication interface. Table 5 provides characteristics of motherboards of selected SDR devices.
The motherboard, in SDR devices, interfaces daughterboard with a GPP host. It exchanges baseband samples with GPP host and IF analog signals with daughterboards.  [52]. To allow more flexibility in data transfer speeds, some SDR devices include multiple communication interfaces (see Table 5). The controllers of both SDR device and GPP host should implement the same interface standard but not necessarily the same version. Indeed, different versions of the same standard may create connection between the two ends but they need to be synchronized for efficient data exchange. In such cases, the communication standard with the lowest rate will be agreed by auto-negotiation (as for Ethernet [51]) or backward compatibility (for example between USB 2.0 and USB 3.0) or manually [53].

C. GPP HOST
A GPP host is a programmable device that can perform computational tasks based on instructions given by software programs using either high or lower level programming languages. As such a GPP host combines hardware and software, and is responsible to handle their interaction. The subsequent sections review these components highlighting the parts that impact the processing speed of a GPP host.

1) HARDWARE
The GPP host components are, mostly, assembled in a singleboard. This board contains SoC internal components such as GPP, internal memories, co-processors (GPU, DSP ASIP, etc.), and possible controllers for communication interfaces (see section III-B) and SoC external components such as external memories, expansion slots, etc.
A GPP, which can be either microprocessor or microcontroller, is responsible for performing the digital PHY, MAC, and upper layer operations. Unlike the conventional transceivers, it has the advantage of either high or low level programmability without modifying the hardware. Although it offers high user flexibility, the high-level programmability usually results in performance degradation of the processor to satisfy the requirements of intensive computation signal processing tasks [54]. Indeed, the performance (processing speed) of GPP is largely determined by a clock, where lower clock speed implies a slow processor and less energy consumption [55].
The GPP may be of single core or multi-core processor. However, most GPPs currently are based on multi-core (Dualcore, Quad-core, etc.,) processors on a single physical Central Processing Unit (CPU) [7]. Each core, in a multi-core single CPU system, represents a single processor or execution unit capable of executing processes concurrently with other processors. This increases the number of instructions to be processed per clock cycle. In addition to clock speed and number of cores, system bus architecture (bus width, its clock frequency, the number of data it can transfer per clock cycle, etc.,) significantly affects the speed of processing [55]. The size and level of cache a CPU has also affects the speed of its processing. Other parameters that could affect overall processing speed of GPP are number of threads, memory size, number of ALUs, hyper-threading support, size of Single Instruction Multiple Data (SIMD) units, etc. The SIMD units allow a processor to perform simultaneously the same instruction (operation) on multiple data units [56]. Recent GPPs support SIMD architecture to improve performance capabilities [57]. Table 6 provides few examples of GPP host hardware. To achieve more computing performance, GPPs are usually complemented with co-processors like GPU, FPGA and DSP ASIP as accelerators [56], [58], [59].

2) SOFTWARE
The software part of GPP host controls the operation of the processor, input/output traffic of communication controllers and the SDR device. It is generally layered into three on top of the hardware processor as instructions set, kernel space and user space. The instruction set is defined as a group of instructions a processor can execute. Thereby, an instruction code (object code) generated by a compiler or an assembler can only contain instructions from this set. The instruction set is one of two types of instruction set architecture (ISA) designs: Reduced Instruction Set Computers (RISC) or Complex Instruction Set Computers (CISC) [60]. The ISA of GPPs can be based on CISC or RISC. To exploit the advantages of both instruction sets, modern GPPs are more based on hybrid ISA (using CISC instructions externally, but RISC techniques internally) [61]. Moreover, the use of RISC architecture can also be enhanced by adding Very Long Instruction Word (VLIW) extensions, a technique that offer instruction level parallelism [62].
The middle layer of the software system architecture is the kernel. It is the heart of an operating system (OS), linking the user space with the hardware processor [63]. To interact with the hardware, the kernel includes hardware drivers such as processor driver, hard disk driver, network controller driver, etc. To interact with user space, the kernel includes Application Program Interface (API) allowing programs in user space to access system resources (e.g., file systems, GPP time, virtual memory, etc.,) and services (e.g., scheduling, swapping, interrupt request (IRQ) handling, context switching, etc). It is precisely these services that impact the kernel space performances in terms of latency and overhead. To reduce the latency, additional functions such as the IRQ handler, process scheduling, reducing number of context switches, etc., are required. On the other hand, kernel overhead is the time due to managing resources such as GPP time, memory, disk, etc. The increased overhead often results in reducing the GPP time occupation and consequently the GPP throughput. As reducing the kernel latency requires additional functions, the kernel overhead will increase. It is obvious that a trade-off between kernel latency and GPP throughput exists, and a balance should carefully be designed as per user need.
At the top of software system architecture is the user space that consists of a portion of memory in which user applications are executed. Hereby, the user applications are PHY and MAC functions of the wireless technologies. The user applications are mostly written using high-level programming languages like C, C++, Java, Python, Matlab, etc. It is also possible to generate the user applications code via data flow textual/graphical programming languages like G programming, Python, C++, etc. These programming languages (high-level and data-flow) are generally included in software development toolkits such as GNU Radio [64], LabVIEW [65], Matlab [66], etc. The toolkits provide DSP libraries for DSP functions, libraries for runtime and compilation, graphical tools for creating signal flow graphs and generating flow-graph source code, etc.
The user application compiler is an element of most importance in assisting the processor to achieve high performance in speed and execution time. It is responsible for generating the instruction code using the ISA of the target processor. When a large variety of target processors are supported, the compiler is said to be general (like the GNU Compiler Collection (GCC) [67]). The general compilers also implement optimizations to improve the GPP performance by increasing the parallelism levels through three mechanisms: instruction-level parallelism (ILP) which allows multiple instructions to be executed at the same time, thread-level parallelism (TLP) which allows multiple threads to run simultaneously or pseudo-simultaneously on single/multiple cores, and data-level parallelism (DLP) which enables performing multiple data-elements simultaneously. This entails an optimal source code generation in size and execution time, according to the target processor. Examples of optimizations are automatic vectorization [68], automatic parallelization [68], [69], inter-procedural optimization [70], and SIMD intrinsics (assembly-coded functions [71]). Table 7 lists well-known software implementation toolkits.

IV. SDR PLATFORM PERFORMANCE ANALYSIS
To implement a wireless technology on SDR platforms or use existing implementations, it is necessary that the selected SDR platform (SDR device, communication interface and GPP Host) performance should meet at least the requirements of the target wireless technology. These requirements are mainly given in terms of operating frequency band, bandwidth, symbol rate, bitrate, latency, etc. In this section, a thorough theoretical analysis of these performance parameters in GPP-based SDR platform architecture is presented along with the minimal/maximal values offered by the components.

A. FREQUENCY BAND
The frequency band of SDR platforms is the operating frequency range covered by the SDR device. This is determined at the daughterboard from the local oscillator (LO) signals generated by the frequency synthesizer, such as Phase-Locked Loop (PLL) synthesizer. Large frequency band needs large LO frequency range, and consequently wideband frequency synthesizers. The operating frequency band of SDR devices are listed by the used daughterboard's datasheet (see Table 4 for well-known daughterboards). To cover the range of frequency bands supported by daughterboards, SDR device's need to use appropriate type of antenna [74].

B. BANDWIDTH
Any analog or digital signal has a bandwidth defined as the occupied range of frequencies carrying most of its energy. This range varies at each stage of the signal chain. Hence, it can be expressed differently (but related) according to the signal processing stage. Indeed, at the RF front end stage, it is expressed as the analog bandwidth or RF channel width. At the ADC/DAC stage, it is expressed as the DAC/ADC sample rates. When the signal is processed at the digital front end (DFE) stage, its bandwidth is expressed as the DFE sample rate. On the communication link between the DFE and GPP, the bandwidth is limited by the communication interface speed. At the GPP host, the bandwidth is expressed as the symbol rate. Fig. 3 illustrates the main points in the signal chain where the bandwidth of SDR platform is characterized. In this section, we examine the analog bandwidth, ADC/DAC and DFE sample rates. Sections IV-C, IV-D and IV-E will address the interface speed, symbol rate and bitrate.

1) ANALOG BANDWIDTH
This bandwidth, measured in Hz, is determined by the RF front end (daughterboard) of the SDR device. It is configured mainly by the analog baseband low pass filter (LPF) to vary from 0 Hz to the specified cut-off frequency, f cut . Thus, in a direct-conversion (Zero IF) I/Q modulator [75] both at the transmitter and receiver side, the analog bandwidth at RF front end is determined by the LPF and its f cut . It is equal to twice f cut for Ideal LPFs that completely eliminate (attenuate) all frequencies above the f cut . The excess bandwidth, defined as the transition band in LPF datasheets [76], of an Ideal LPF is null, and hence its Roll-off factor (ratio between passband and transition band) is null. In real-world, practical LPFs are not perfect and have a transition region where some high frequencies above the f cut can pass. Consequently, the real analog bandwidth is greater than twice f cut and can be formulated as follows: where the Roll-off factor is in the range [0,1]. Equation (1) assumes signals spectra that would occur after theoretical cut-off point. Thus, the Roll-off factor shifts the bandwidth towards the transition band so that we can minimize loss of information.
Most of the LPFs are programmable and can take different f cut values where each f cut is assigned a roll-off factor. The maximal real analog bandwidth is achieved by the highest f cut scaled by [1 + Roll-off factor]. Table 8 summarizes the analog bandwidth as theoretically computed from (1) and the maximal ideal analog bandwidth (twice f cut ) as indicated on the daughterboard's datasheet.

2) ADC/DAC SAMPLE RATE
The DAC sample rate, given on Samples per Second (S/s), allows to determine the time interval between two samples VOLUME 10, 2022  applied to the input of a DAC. The ADC sample rate determines the time interval between two samples at the output of an ADC. Both sample rates are related to the input signal spectrum by the Nyquist-Shannon sampling theorem [77]. Theoretically, for a given ADC/DAC sample rate, the maximum frequency that can be reproduced is half the sample rate (Nyquist frequency) to avoid aliasing effect. As the maximum frequency of an equivalent complex baseband (a complex valued representation of the real baseband) is [real analog bandwidth / 2], the sample rate needs to be greater than the real analog bandwidth (see (1)). The more sample rate is greater than the real analog bandwidth, the more the band gap increases between the real analog bandwidth copies repeated at multiples of sample rate resulting on zero-loss on bandwidth. This band gap has an amount of [ADC sample rate -real analog bandwidth] Hz.
In motherboard of SDR devices, the integrated ADC/DAC can support one or multiple sample rates where one at a time can be selected. The highest sample rate value determines the largest analog bandwidth. Table 9 shows the supported sample rates by well-known SDR devices. This table also shows whether the SDR device has fixed or selective sample rates. Using selective sample rate is preferable than fixed rate to adapt the real analog bandwidth to the necessary bandwidth asked by applications' rate requirement and expressed by the DFE sample rate (see section IV-B3). When the nearest sample rate is greater than the DFE sample rate, an adjustment through interpolation and decimation process is necessary [49].

3) DIGITAL FRONT END (DFE) SAMPLE RATE
This rate, given on Samples per second (S/s), defines the constant speed by which I/Q samples are exchanged between the DUC/DDC (interpolation/decimation) stages and the interface controller. It can be specified either explicitly by the user or implicitly from the real analog bandwidth of the channel. The sample size (in bits) is determined by the DAC/ADC resolution. At the transmitter side of an SDR  device, arriving I and Q data samples from the GPP host (in a format configured by the user, e.g., 32-bit float) join their corresponding queue waiting for service by the DFE. The arrival rate at the queue is constant over time and is determined by the bitrate of GPP host. The interpolation stage of the DFE retrieves samples from the queue at DFE sample rate, which is the service rate of the queue system. As the DFE sample rate can take very high values, it is extremely important that the arrival and service rates should be equal after normalization to avoid waiting for the queues to become non-empty (underflow). Then, the interpolation stage increases the DFE sample rate of input samples to higher output rate equal to the DAC sample rate (see Fig. 4). The applied interpolation factor is equivalent to the ratio of the DAC sample rate to the DFE sample rate.
At the receiver side of an SDR device, as shown in Fig. 5, the DFE receives samples at a speed of ADC sample rate. It performs decimation to decrease the input ADC sample rate to a lower rate equal to the DFE sample rate. The applied decimation factor is equivalent to the ratio of ADC clock rate to the DFE clock rate. The output samples are, then, inserted into the I/Q queues waiting to be transmitted to the GPP host. A queue overflow occurs when the GPP host cannot retrieve samples as fast enough. As in the transmitter side, it is extremely important that the DFE sample rate be close to the bitrate of GPP host.
From the above discussion, as the DFE sample rate should be close to the bitrate of GPP host, it can be used to define the necessary channel bandwidth required by user application in the GPP host. Since the necessary channel bandwidth is included in the real analog bandwidth (see section IV-B1), the DFE sample rate should be smaller than the real analog bandwidth. Also, the DFE sample rate should be increased or reduced to fulfill the DAC and ADC clock rates. Some SDR devices require a strictly-integer interpolation and decimation factors, and it is strongly desirable for that factors to be even and it's much better if the factors are in power of two [78]. Thus, specifying appropriate DFE sample rate is another requirement to be considered by the user.

4) THE MAXIMAL GPP-BASED SDR PLATFORM BANDWIDTH
Since GPP-based SDR platform's bandwidth is concave, it takes the lowest value between analog bandwidth, ADC/DAC sample rate and DFE sample rate. The maximal DFE sample rate is achieved when its value reaches to ADC sample rate and DAC sample rate at unity decimation and interpolation factor, respectively. However, as stated above, DFE sample rate cannot be greater than real analog bandwidth. Consequently, the maximal GPP-based SDR platform bandwidth (in Hz) is the minimum from maximal DFE sample rate and analog bandwidth.

C. COMMUNICATION INTERFACE SPEED
This speed, given in bit per second (bit/s), refers to the PHY layer net bitrate of the wired interface between GPP host and SDR device. The PHY layer net bitrate defines the amount of transferred bits, excluding the PHY layer protocol overhead, per second over a communication link. Obviously, its value (specified by the standard) is less than the real transmission rate defined at the PHY layer gross bitrate that includes the PHY layer overhead (channel coding, modulation, physical framing, guard interval, etc). For example, the PHY layer net bitrate of the Gigabit Ethernet is 1 Gbit/s and the real transmission rate is 1.25 Gbit/s due to the 8B/10B encoding [79]. Since I/Q samples, exchanged between GPP host and SDR device, are encapsulated in frames of the used interface, their rate is limited by the communication interface speed. In the upcoming discussion, the I/Q sample rate is the equivalent of DFE sample rate defined in bit/s and related by [DFE sample rate × I/Q symbol format].
The communication interface speed, despite it excludes the PHY layer protocol overhead, it includes upper layer protocols head such as link layer head, network layer head, etc. Based on this remark, the peak (maximum achievable) rate of encapsulated I/Q samples (useful data rate) is limited by the communication interface speed weighted by a factor of [payload size / data link frame size], known as the link efficiency. Higher the link efficiency, closer the peak I/Q sample rate to the communication interface speed. The peak I/Q sample rate is an instantaneous rate that doesn't consider link occupancy. Consequently, its value will be very large to be taken as an acceptable upper bound, otherwise the real I/Q sample rate will be under-constrained. Thus, it is necessary to include the link occupancy on the upper bound to get the maximal acceptable I/Q sample rate (or maximal acceptable DFE sample rate). To do so, the peak I/Q sample rate weighted by the link occupancy, expressed as [peak I/Q sample rate × link occupancy], will give us the maximal acceptable I/Q sample rate. Henceforth, we limit the I/Q sample rate or DFE sample rate by the maximal acceptable I/Q sample rate.
The maximal acceptable I/Q sample rate is affected by three factors: the communication interface mode, GPP host application mode and SDR device capability. The communication interface between the GPP host and SDR device motherboard can work in either half or full duplex modes. With full-duplex interface mode, the communication link can simultaneously be fully occupied in both directions (Host→SDR and SDR→Host) allowing to benefit from full-speed on each direction. In this case, the transmit and receive links have independent occupancy of up to 100% each at any time. With half-duplex interface mode, the communication link is used to either exclusively transmit or receive. In this case, the link occupancy is shared so that transmitting and receiving occupancies are 100%'s complement. One could think that full-duplex interfaces always achieve highest performance but in reality it depends on the GPP host application and SDR motherboard capability (half or full-duplex transceiver). Indeed, half and full duplex interfaces can have similar performance when: • The GPP host application is one-way communication.
So, using either half or full duplex is the same, as the communication needed is only to transmit or receive. This implies the link occupancy of the used direction can attain 100%, allowing a maximal acceptable TX or RX I/Q sample rate equal to the peak rate (on the used direction) and always null on the other direction. Thus, using only half-duplex interface is sufficient when the GPP host application is one-way communication; • The GPP host application is non-overlapped two-way communication. Both directions between SDR device and GPP host cannot be used simultaneously since transmission and reception are separated in time. So, the occupied time for transmission doesn't consume the time of reception and vice versa. Consequently, the sum of TX and RX link occupancies can go to 100% allowing a maximal acceptable TX rate of [peak rate × TX link occupancy] and maximal acceptable RX rate of [peak rate × (1 − TX link occupancy)]. Thus, using only half-duplex interface is sufficient when GPP host user application is non-overlapped two-way; • The SDR device is half-duplex. As SDR device can either receive or transmit, only single direction on the link between SDR device and GPP host is solicited. Such SDR device capability is suitable for GPP host user applications using one-way communication or twoway communication without temporal overlap between transmission and reception. Since only single direction is being used, its link occupancy can go to 100% allowing a maximal acceptable rate equal to the peak rate (null for the unused direction). Hence, using only half duplex interface is sufficient for one-way and nonoverlapped two-way communications when SDR device is half duplex. Full-duplex interfaces become necessary when the GPP host user application is temporally overlapped two-way communication. In addition, SDR devices should also be full-duplex. In this scenario, TX and RX link occupancies are independent and can simultaneously go to 100%. Now, the maximal acceptable TX and RX rate can attain the peak I/Q sample rate. Table 10 shows the maximal supported I/Q VOLUME 10, 2022 sample rates of Host-SDR interface solutions for both full and half-duplex SDR transceivers.

D. SYMBOL RATE
This rate, given in Symbol per second (Sym/s), refers to the constant rate at which symbols occur. One symbol can carry one or more bits according to the digital modulation format. For example, in a BPSK system, each symbol represents one bit; in a 64-QAM system, each symbol represents 6 bits. Symbol rate is determined from the symbol duration as [1 / symbol duration], where symbol duration is the sum of the useful symbol duration and the potential guard interval expressed as [useful symbol duration + guard interval]. The guard interval is used between two successive symbols to reduce inter-symbol interference that results from multi-path fading or band-limited channels [80]. It is given by the wireless technology specification. The useful symbol duration is the time used to carry the useful data and is related to the number of samples per symbol and the sampling interval time. It can be formulated as [number of samples per symbol × sampling interval]. The sampling interval parameter is the inverse of the DFE sample rate, [1 / DFE sample rate]. As the DFE sample rate for quadrature sampling systems is equal to the occupied baseband bandwidth, the sampling interval will be the inverse of the occupied baseband bandwidth. The number of samples per symbol parameter can be computed from the frequency domain based on the total number of spectral lines [80].
The number of samples per symbol is equal to the number of spectral lines in quadrature sampling systems and twice in direct-sampling systems. The number of spectral lines is related to the number of carrier/sub-carrier frequencies. Considering quadrature sampling system, when a conventional single-carrier modulation is applied (like in IEEE 802.15.4, . . . ), the number of spectral lines is equal to one and hence the number of samples per symbol will be one. When multiple sub-carrier modulation technique is used (like in IEEE 802.11ac, . . . ), the number of spectral lines is equal to the total number of used and unused sub-carriers. In general, the total number of sub-carriers is specified by the used FFT size [80]. To summarize, the useful symbol duration is expressed as [number of spectral lines / occupied baseband bandwidth].
In some wireless systems spread spectrum techniques such as Frequency-Hopping Spread Spectrum (FHSS), Direct Sequence Spread Spectrum (DSSS), Time-Hopping Spread Spectrum (THSS) and Chirp Spread Spectrum (CSS) are used to prevent interference by transmitting symbols at low power density over a wide band. This band is named as spread occupied baseband bandwidth. The spreading process is achieved by multiplying the symbols with a spreading code, known as chip sequence, having a faster rate than the input symbol rate (symbol rate before spreading). Thus, the spread occupied baseband bandwidth is larger than the original baseband bandwidth by a factor of chip sequence size, [original occupied baseband bandwidth × chip sequence size]. The spread occupied baseband bandwidth is always given as the channel size of wireless systems using spread spectrum techniques. The spreading process has no effect on the useful symbol duration. However, as the given channel size is the spread baseband bandwidth and not the original occupied baseband bandwidth, the useful symbol duration needs to be relied on the spread baseband bandwidth and the chip sequence size. Based on the fact that the symbol duration before spreading is [number of spectral lines / original occupied baseband bandwidth] and the original occupied bandwidth is [spread baseband bandwidth / chip sequence size], the output symbol duration can be written as [number of spectral lines × chip sequence size / spread occupied baseband bandwidth]. It is obvious that the input and output useful symbol duration are the same.
In general, the useful time duration with/without spreading process can be formulated as [number of spectral lines × chip sequence size / channel size]. Fig. 6 depicts an example of possible single/multiple carrier and spreading/non-spreading cases of digital baseband transmitter. Table 11 provides equations of the symbol rate for each path-end. By applying these equations, users can generate the symbol rate for their desired wireless technology and can also be verified from the corresponding specifications [31], [33], [35], [39]- [41]. The software programmer at user space should consider both symbol rate and symbol format. The symbol rate can be either explicitly set or implicitly driven from the DFE sample rate and the number of used subcarriers. The symbol format, on the other hand, should be explicitly specified (e.g., complex int16, complex int32, etc). When using a complex int16, the I and Q samples of each symbol are coded each by 16 bits, and so 32 bits per I/Q sample are transmitted to the communication interface. This transmission has a rate of [symbol rate × symbol format]. The communication interface considers the received data as a data payload and performs its operation related to its technology.

1) MAXIMAL SYMBOL RATE AT SDR DEVICES
From the equations depicted in Table 11, the theoretical maximal symbol rate at SDR device can be attained when the channel width (bandwidth) is at its maximal value, and the number of spectral line, guard interval and chip sequence size are at their lowest values. The highest channel width can  be set to the maximal bandwidth of SDR device; the lowest number of spectral lines can be set to one; the lowest guard interval can be set to zero (without guard interval) and the lowest chip sequence size can be set to one (i.e., without spreading). Consequently, the maximal symbol rate takes the maximal bandwidth of the SDR device. On the other hand, as symbols should traverse the communication interface between the GPP host and the SDR device and vice versa, the maximal symbol rate at the SDR device is bounded by the communication interface speed (after normalization). This latter value is given by [(interface speed × link efficiency × link occupancy) / symbol format] in Sym/s. Since, we have two theoretical upper bounds, the maximal symbol rate will take the minimum value between them, i.e., minimum (maximal bandwidth of SDR device, [(interface speed × link efficiency × link occupancy) / symbol format]). See Table 13 in subsecion IV-D3 for the maximal theoretical upper bound of the symbol rate at SDR devices.

2) MAXIMAL SYMBOL RATE AT GPP HOST
In GPP-based SDR platforms, all symbols are either generated or consumed by GPP host. Therefore, GPP host can impact the maximal symbol rate supported by the platforms.
To determine the maximal speed at which symbols are generated or consumed at a GPP host, a continuous data transmission/reception without MAC operations, physical framing, channel coding and spreading is considered. Consequently, the executed physical layer in software should incorporate only bit generator and digital modulator blocks at the transmission side (baseband TX path); or bit sink and digital demodulator blocks at the receiving side (baseband RX path). Hence, only Bit stream and Digital Modulator blocks in Fig. 6 are used to determine the upper bound of symbol rates supported at GPP hosts.
Each symbol generation/consumption requires a time duration in the baseband TX/RX path, when inverted gives the symbol rate. This duration represents the makespan (execution time) of an executable file, created after compiling the TX/RX path blocks, from generating a stream of bits to delivering the corresponding output symbol or from taking a symbol as input and delivering its corresponding bits. Several hardware and software parameters of the GPP host impact the makespan. The hardware parameters include: number of cores, speed of cores, ISA design, pipeline stages, caches, accelerators, hyperthreading support, SIMD support, etc. The software parameters include: user program quality, compiler optimization to enhance the degree of ILP/TLP/DLP, user threads and their degree of TLP, kernel type (non-preemptive and preemptive) and its operations (scheduling, context switching, etc). Multiple parameters can be merged into some big factors such as the minimum number of cycles per instruction (CPI), the number of executed instructions and overheads (due to kernel and memory access operations). The minimum execution time supported by GPP hosts to generate/consume one symbol is achieved when the number of input/output symbols reaches a threshold value (K ) to fully benefit from the high degree of parallelism (ILP/TLP/DLP). Above this threshold value, the execution time will increase due to the high CPU load and overhead. Thereby, the minimal makespan can be formulated as in (2): where I is number of executed instructions to generate/consume K symbols, Inf CPI represents the lowest CPI, T is clock cycle duration given by 1 GPP clock speed , and 2 HT = 2 if hyperthreading or 1 otherwise. VOLUME 10, 2022 Using (2), numerical results are conducted and illustrated in Table 12. Some parameters such as the threshold number of symbols K and the number of executed instructions are obtained from experimental data by benchmarking specific functions. To this end, a baseband TX/RX python program is written using GNU Radio software. This program includes source/sink and digital modulator/demodulator. To cover the various types of baseband processing in multiple wireless technologies, different modulation formats are considered such as GFSK, GMSK, BPSK, QPSK, 8-PSK, 16QAM, BPSK OFDM-64 (BPSK with 64-point IFFT), QPSK OFDM-64, and 16QAM OFDM-64. By running the baseband TX/RX python program on different GPP hosts based on Intel core processor, the maximum number of supported symbols (K ) that achieves the lowest makespan per symbol is examined. An average maximum value equivalent to fifty six million symbols is obtained. At this threshold value, other parameters such as the total number of instructions, Inf CPI and overhead were also recorded via perf stat tool [81].
The results depicted in Table 12, show the minimal makespans and maximal data symbol rates supported by different GPP hosts according to the applied digital modulator. As the consecutive transmit or receive symbols are independent of each other, a high degree of parallelism ILP/TLP/DLP is expected. Thus, GPP hosts having more cores with faster clock speeds and hyperthreading support achieve higher symbol rates by fully exploiting the parallelism. It is important to note that hyperthreading can enhance performance when TLP is very high, otherwise, it might create negative impacts.

3) MAXIMAL SYMBOL RATE SUPPORTED BY GPP-BASED SDR PLATFORMS
The maximal symbol rate supported by a given GPP-based SDR platform corresponds to the smallest value between the maximal symbol rate at the used SDR device and at the GPP host. Table 13 gives the maximal symbol rates supported by selected GPP-based SDR platforms according to the type of digital modulation. As the table depicts, for small modulators such as GFSK and GMSK, the maximal symbol rate of the SDR platform is generally limited by the symbol rate of SDR devices, except when X310 is used as SDR device and hyperthreading is enabled for high core and faster clock speed hosts. As the modulator goes higher, the symbol rate starts to be limited by the rate of the GPP host. This is true specially for lower GPP core and slower clock speed. On the other hand, when hyperthreading is disabled, the symbol rate of the SDR platform is mostly limited by the rate of the GPP host for lower core and slower clock speeds. At higher GPP core and clock speed, specially for 8 core and 3.6 GHz host, the SDR platform symbol rate is limited by the symbol rate of the SDR device except for X310 and Lime.

E. BITRATE
This rate, given by bits per second (bit/s), refers to the net bitrate at which data is transferred between the MAC sublayer and the PHY layer of the wireless technology, both implemented in software. It includes the user data and all headers from the application layer to the MAC sublayer. This rate can be expressed based on the wireless PHY layer gross bitrate by excluding from the physical layer frames the error-correction codes and physical layer header. Since the rate of error-correction codes is [code rate] and the rate of physical layer headers is [physical framing], the bitrate can be written as [wireless physical layer gross bitrate × code rate × physical framing]. The wireless physical layer gross bitrate is related to the symbol rate, the number of bits per symbol (resulted from bit-to-symbol mapper) and to the number of data subcarriers (if OFDM system is used) to carry data in parallel. It can be expressed by the formula [symbol rate × # bits per symbol × # data subcarriers]. All the parameters (code rate, physical framing, symbol rate, number of bits per symbol and number of data subcarriers) are stated in the wireless standard technical specifications. Thus, bitrates and maximal bitrates of wireless technologies can simply be obtained from the bitrate formula. Please refer to section II for the maximal bitrate of selected wireless technologies.

1) THEORETICAL MAXIMAL SUPPORTED BITRATE BY GPP-BASED SDR PLATFORMS
The theoretical maximal bitrate that can be achieved by a GPP-based SDR platform depends on the highest values of the wireless physical layer gross bitrate, code rate and physical framing supported by the platform. It can be formulated as maximal wireless physical layer gross bitrate × maximal code rate × maximal physical framing , where the maximal wireless physical layer gross bitrate is computed according to the used digital modulator by maximal symbol rate × involved # of bits per symbol × involved # of data subcarriers . The maximal symbol rate supported by GPP-based SDR platforms is computed in the previous section (see Table 13) using continuous data  transmission/reception without MAC operations, physical framing (i.e., maximal physical framing is set to one), channel coding (i.e., maximal code rate is set to one) and different types of digital modulation techniques. The number of bits per symbol as well as the number of data subcarriers are related to the digital modulation on which the maximal symbol rate is computed. Table 14 illustrates the maximal supported bitrates by SDR platforms.  Like the symbol rate, the maximal supported bitrate by a given GPP-based SDR platform increases with GPP core and clock speed, and varies with the used modulation technique and number of data subcarriers. It is also shown that hyperthreading support offers higher maximal bitrate than hyperthreading disabled GPP host. From the SDR device's perspective, those with the highest maximal symbol rate also gives the highest maximal supported bitrate. Thus, for a given wireless technology (i.e., if required modulation type and number of data subcarriers are known), one can easily determine the type of GPP host that can support this requirement. Hence, the candidate SDR platforms with respect to supported maximal symbol rate and bitrate can be determined. For instance, as shown in Table 14, executing GMSK modulator provides a maximal bitrate of (26.76, 40.14, 112.39 and 192.68) Mbit/s, with (2, 4/1.5GHz, 4/3.6GHz and 8) core hyperthreading enabled GPP hosts, respectively. Depending on the SDR device employed, the GPP-based SDR platform will have a maximal bitrate value as illustrated in the table. Therefore, a wireless technology supporting GMSK modulator (such as EC-GSM-IoT having a maximal bitrate of 240 kbit/s), can be implemented using any of the SDR platforms listed in the table with/without hyperthreading support. These findings are used for mapping wireless technologies with SDR platforms in section V.

F. LATENCY
In GPP-based SDR platforms, a latency refers to the time delay spent by a MAC frame (data, control and management) in the transceiver chain between the MAC layer at the GPP host and the antenna connected to the SDR device. As frames can traverse the transceiver chain while being transmitted or received, two types of latencies can be distinguished: GPP-based SDR platform TX latency and RX latency. Both of these latencies contain the same components and results from an accumulation of latencies at each stage of the corresponding path. Since TX/RX path stages are shared between the GPP host, communication interface and SDR device, the GPP-based SDR platform TX/RX latency components can be grouped as: SDR latency, communication interface latency and GPP host latency, as shown in Fig. 7. These latencies are examined below in detail, and we drive the minimal total latency.

1) SDR DEVICE LATENCY
This latency consists of three components: DFE latency, ADC/DAC conversion latency and RF front end (RFFE) latency. It may be asymmetrical, providing a varying delay between the case when the SDR device is used for transmitting or for receiving.
At the transmitter side, as shown in Fig. 8, the SDR device latency is the sum of DFE latency, DAC output latency and RFFE latency. The DFE latency is related to both the queuing time of I/Q samples in the SDR buffers (one queue for each type of samples) and the DUCs output latency. The queuing time depends on the arrival rate (i.e., symbol rate), the service rate (i.e., DFE sample rate) and the buffer capacity (limited by dedicated buffer memory space located in the motherboard). The queuing model of the sample buffers can be identified as a D/D/1/buffer_capacity queuing system. Thus, as the I/Q sample rate is always less than or equal to the DFE sample rate, the expected waiting time (in seconds) can be calculated from Little's Law [82] and is given by [ Table 15 gives theoretical minimal latencies of well-known SDR devices at the transmitting side.
The SDR latency at the receiver side has the same components as the transmitter side, namely RFFE latency, ADC conversion latency and DFE latency, shown in Fig. 9. The RFFE latency remains negligible for the receiver side due to the high frequency bus. The latency part related to the ADC conversion can be expressed similarly as for DAC The waiting time can be given by [(buffer_capacity + 1) (in Sym) / symbol rate (in sym/s)]. The minimal waiting time, therefore, is achieved when the symbol rate attains its maximum, i.e., maximal DFE sample rate, which in turn has its maximum value equivalent to ADC sample rate. Consequently, the minimal waiting time can be approximated to [(buffer_capacity + 1) (in Sym) / ADC sample rate (in Sym/s)]. Table 15 gives theoretical minimal SDR device latency in the receiving side (RX side).

2) COMMUNICATION INTERFACE LATENCY
This latency is related to data exchange between GPP host and SDR device through communication interfaces such as Gigabit Ethernet, USB3.0, PCIe, etc. The data packets are used to carry symbols, where each symbol is pushed in one packet as data payload and followed by a set of header fields. The time spent by a data packet to travel from one communication interface controller, of GPP host or SDR device, to another is defined as the communication interface latency. It includes the waiting time of data packets at both communication interface controllers and the propagation time. The waiting time at each communication interface controller combines the queuing time and the service time. Fig. 10 depicts the components of the communication interface latency.
The queuing system consists of two symmetric queuing networks that can work either simultaneously in case of Fullduplex interfaces, or only one at a time in case of Half-duplex interfaces. Each queuing network comprises a TX buffer linked to a RX buffer through the communication interface link. From the TX buffer to RX buffer, the communication interface controller collects I/Q samples (generated by the user application or received from the DFE) and creates data packets according to the used interface standard (data packet size, header fields, etc). These data packets are queued at the TX buffer waiting for transmission to the RX buffer. When a packet is transmitted, it will travel over the communication link with signal propagation speed in a medium. Finally, the communication interface controller intercepts the received packets, extracts the I/Q samples and puts them into the RX buffer for delivery (to the DFE or to the user application). For the queuing network parameters: • The arrival rate at the TX buffer, expressed in packets/s, takes the same value of the symbol rate as each symbol is carried by a single data packet; • The service rate of the TX Buffer can be derived from the interface speed and the TX link occupancy, and converted into packets/s using the following formula: • The arrival rate at the RX buffer, expressed in Sym/s, takes the same arrival rate of the TX buffer (i.e., symbol rate) if this later is less than or equal to TX buffer service rate (normalized interface speed). Otherwise, it takes the normalized interface speed; • The service rate of the RX buffer, expressed in Sym/s, is symbol rate. The communication interface latency can, therefore, be regarded as the total waiting time of the queuing network. Thus, it's the result of the sum of the waiting time of data packets at TX/RX buffers and the propagation time. Two cases need to be distinguished: when the symbol rate is less than or equal, and when it's greater than the normalized interface speed (i.e., the interface speed, averaged and converted). In the first case, the expected waiting time in the TX buffer is [1 / normalized interface speed] seconds, and the expected waiting time in the RX buffer is [1 / symbol rate] seconds. Hence, the total waiting time is given by [(1 / normalized interface speed) + (length of the medium / speed of signal propagation) + (1 / symbol rate)] (seconds). The minimal waiting time is achieved when the symbol rate attains its maximum, i.e., the normalized interface speed, the limit imposed by the condition of the 1 st case. Consequently, the total minimum waiting time is [(2 / normalized interface speed) + (length of the medium / speed of signal propagation)] (seconds). In the second case, the expected waiting time in the TX buffer is [(TX buffer capacity (in packets) + 1) / normalized interface speed] seconds, and the expected waiting time in the RX buffer is [1 / symbol rate] seconds. Hence, the total waiting time is given by (TX buffer capacity (in packets) + 1) / normalized interface speed + (length of the medium / speed of signal propagation) + (1 / symbol rate) (seconds). The minimal waiting time is achieved when the symbol rate attains its maximum, i.e., the DFE sample rate, and it is given by (TX buffer capacity (in packets) + 1) / normalized interface speed + (length of the medium / speed of signal propagation) + (1 / DFE sample rate) (seconds). Table 16 gives theoretical minimal interface latency with 100% TX link occupancy.

3) GPP HOST LATENCY
This latency is the time a wireless MAC frame (data, management or control) passes in GPP host between the MAC layer and the interface controller due to TX and RX activities. It mainly includes the processing time due to the MAC layer operations such as access mechanism, MAC framing, generating/transmitting/receiving control and management frames, transmitting/receiving data frames, etc., and the PHY layer operations such as channel coding, digital modulation, PHY framing, etc. The time to forward/retrieve symbols to/from the interface controller should also be added. To perform all these operations require a GPP time and additional extra-time related to the kernel operations and external memory read/write should be considered. Estimating the GPP host latency is a very complex work, due to the high number of hardware and software factors that affect the execution time of the user program (wireless technology implementation). Indeed, the GPP host hardware and software configurations (see section III-C) affects the execution speed and hence impact the response time of all tasks. Consequently, we illustrate the minimum GPP host latency experimentally by benchmarking existing software implementations of selected wireless technologies.
The selected wireless technologies were run on Intel x86_64 microprocessor with different number of cores and speeds (2 GHz Dual-core, 1.5 GHz Quad-core and 3.6GHz Octa-core). Each core has L1/L2/L3 cache sizes of 64KB/256KB/6144KB and access time of 1.2ns/3.6ns/12ns. All the applications listed below are tested on Ubuntu 18.04.2 LTS: NFC based on gr-nfc [84], IEEE 802.15.6 based on a prototype proposed in [85] for NB-WBAN, IEEE 802.15.1 based on scapy-radio for Bluetooth [86], IEEE 802.15.4 based on gr-IEEE 802.15.4 [15], IEEE 802.11ac and IEEE 802.11ah are based on GNU Radio implementation of gr-IEEE 802.11 [16]; EC-GSM-IoT based on gr-GSM [87]. LTE is measured using eNodeB and user equipment (UE) PHY downlink (DL) shared channel (PDSCH) and NB-IoT using Narrowband PDSCH (NPDSCH) PHY modules from srsRAN [14]; and LoRa based on gr-lora [24]. The parameters involved in the experimental latency result like number of executed instructions and CPI are measured using perf stat tool. The results are depicted in Table 17.
From Table 17, we can see that under the same hardware and kernel settings at the GPP host, wireless technologies provide different latencies according to the total number of executed instructions and the inherent parallelism in the instruction code. This parallelism defines on one hand the level of TLP exploited by the scheduler to split execution of threads between physical/virtual cores, and on the other hand by the level of TLP exploited by the processor to perform multiple instructions simultaneously within the same core which reduces (on average) the number of required CPI. Based on the total number of executed instructions and parallelism, the latency increases when the number of instructions increases and parallelism degree decreases and vice versa. Thereby, since the total number of executed instructions of IEEE 802.15.4 is 861,073,678/858,617,170 for TX/RX and the CPI is 0.8772 for both TX and RX, the latencies under hyperthreading for Dual/Quad/Octa-core are 94.417ms/62.944ms/13.113ms for TX and 94.147ms/62.765ms/13.076ms for RX, respectively. Also, we note that the latency is lower with hyperthreading enabled than hyperthreading disabled for all tested technologies, from 0.009% upto 54.31% improvements. The major contributor of the high percentage improvements provided by some tested technologies is due to the large number of threads in the program; and with high-TLP, theoretically, we might expect to have upto 50% improvement due to hyperthreading. However, this depends on the resource contention between threads on hyperthreaded cores. High resource contention often leads to latency degradation.

4) MINIMAL THEORETICAL GPP-BASED SDR PLATFORM LATENCY
The latency of GPP-based SDR platforms related to TX/RX operations is the result of cumulative latencies over three stages: SDR device, communication interface and GPP host. The minimal latency at both SDR device and communication interface stages is theoretically expressed by modeling the internal architecture using queuing theory. While the minimal latency at the SDR device varies from several nanoseconds to few milliseconds depending on the buffer size, it varies from microseconds to few milliseconds at the communication interface. At the GPP host stage, the minimal latency is investigated experimentally based on multiple parameters such as number and speed of cores, hyperthreading, number of executed instructions, number of threads, degree of ILP/TLP/DLP, kernel scheduler, I/O management (e.g., cache/memory/disk access), etc. Table 18 gives the total minimal latency of GPP-based SDR platforms related to TX/RX operations of some wireless technologies. For the communication interface a link occupancy of 100% and symbol rate less than or equal to the normalized interface speed is used. Table 18 demonstrates that large part of the total latency is due to the GPP host. Comparing the minimal GPP-based SDR platform latency for TX/RX paths with latencies at the three components (SDR device, communication interface and GPP host), we see that for some wireless technologies the GPP host contributes upto 99% of the total (such as in NFC, IEEE802.15.6, IEEE802.15.1, etc). It is shown that the latency at the GPP host stage could be minimized by using high TLP, high clock rate, hyperthreading (with lower resource contention), etc. One can also see that, TX and RX latencies are different. This is due to the specific operations on each path. Moreover, there's significant difference in TX and RX latencies of SDR devices (see section IV-F1) that also contributes to the total latency. The values in Table 18 indicate the capability of the SDR platforms in executing wireless technologies. For instance, to perform a TX operation of NFC using Hack SDR device and USB2.0 communication interface on a (2 core, 2 GHz, hyperthreading enabled) GPP host, it takes 122.855ms (shaded cell). However, to determine whether a given SDR platform meets the latency required by a wireless technology, one needs to carefully map the two (see section V for the mapping). Note that the latency analysis illustrated in this paper can also be exploited to investigate other SDR platforms and wireless technologies.

V. MAPPING PARAMETERS OF WIRELESS TECHNOLOGY WITH GPP-BASED SDR PLATFORM
In the previous sections, we have carried out investigations to determine the requirements of well-known wireless technologies and the minimum performance of GPP-SDR platform in terms of frequency, bandwidth, symbol rate, bitrate and latency. In this section, we intersect the wireless standard requirements with the SDR platform performance to build a list of possible GPP-based SDR platforms that can successfully implement a given wireless technology.

A. MATCHING CONDITIONS
A successful matching between a wireless technology requirements and a GPP-based SDR platform performance can occur when matching conditions are satisfied. These conditions are applied to perform a simple comparison between similar metrics of the two sets. Further details on the matching conditions are discussed below.

1) FREQUENCY BAND MATCHING
Wireless technologies are defined to operate in a single or multiple frequency bands of the radio spectrum. On the other hand, SDR device daughterboards are defined to operate in a wide contiguous frequency band. Given a wireless technology, frequency band matching consists of ensuring that the SDR device daughterboard frequency range covers the frequency bands of the wireless technology.

2) BANDWIDTH MATCHING
Wireless technologies divide their operating frequency bands to single/multiple overlapping/non-overlapping channels of predefined widths. However, the really occupied bandwidth can be less than the channel width depending on the type of modulation. Given a wireless technology, bandwidth matching consists of ensuring that the maximal SDR platform bandwidth is at least equal to the real occupied bandwidth in the channel width defined by the standard.

3) SYMBOL RATE MATCHING
The specifications of wireless technologies provide the symbol duration, and hence the symbol rate, either explicitly or implicitly through related PHY parameters (see equations in Table 11). Given a wireless technology and a GPP-based SDR platform, symbol rate matching ensures that the maximal supported symbol rate by the GPP-based SDR platform is greater than or equal to that defined by the wireless standard.

4) BITRATE MATCHING
Based on PHY parameters (spectral lines, code rate, PHY framing, digital modulation) and symbol rate of wireless technologies, specifications provide a list of supported bitrates. On the other hand, GPP-based SDR platforms support a maximum bitrate according to the used SDR device, communication interface and GPP host capabilities. Given a wireless technology and a GPP-based SDR platform, full bitrate matching ascertains that the maximal supported bitrate by the GPP-based SDR platforms is greater than or equal to the highest bitrate of the wireless technology. However, partial matching can also occur when the maximal supported bitrate by the SDR platform is between the highest and lowest bitrates of the wireless technology. In this case, the SDR platform can still perform the implemented wireless technology but in lower bitrates.

5) LATENCY MATCHING
Wireless devices operate in a shared wireless medium, and hence, require a MAC protocol to organize access to a channel. In general, MAC protocols can be classified as either contention-based or contention-free protocols [88]. Despite their significant differences in terms of coordination, they define inter-frame times to handle waiting periods between transmission of frames (data, control and management). For example, IEEE 802.15.4 uses slotted CSMA/CA as a contention based protocol and Guaranteed Time Slot (GTS) allocation mechanism as a contention-free protocol. Both protocols define inter-frame times to cover the period from receiving a data frame and transmitting an explicit acknowledgment frame. The smallest inter-frame time among all inter-frame times is defined as the latency. Wireless devices should respect the latency to ensure optimized network performance. Examples of latency for the well-known wireless technologies are given in Tables 1, 2 and 3.
As GPP-based SDR platforms will play the role of wireless device, they should fulfill the latency constraint by completing execution of all operations within the dedicated time period as defined by the specific MAC protocol. The concerned operations are often related to transmission and/or reception of frames. Thus, during the latency period, frames should traverse the transceiver chain in one or both directions based on the objective of MAC operations. Consequently, the latency of GPP-based SDR platforms related to the implemented wireless technology can include latency values of only in TX or RX path, or both TX and RX paths depending on the covered operations desired by the implemented technology.
Given a wireless technology and a GPP-based SDR platform, full latency matching occurs when the minimal latency supported by the GPP-based SDR platform is below the latency of the wireless technology. Such matching allows the GPP-based SDR platform to perform the TX/RX operations efficiently and ensure normal communication with legacy transceivers. However, when the minimal latency supported by the GPP-based SDR platform exceeds the latency of wireless technology and/or some other (perhaps all) interframe times, frame exchange with legacy transceivers will be affected. In other words, as TX/RX operations at the GPP-based SDR platform are delayed, the overall network (in presence of one or more legacy transceivers) performance will degrade. To illustrate this, consider the following two cases: • Case 1: Assume that a GPP-based SDR platform has won the channel access. A delayed frame transmission may cause collisions at legacy receivers in the presence of concurrent transmissions; • Case 2: Assume that a GPP-based SDR platform is receiving a unicast data frame from a legacy transceiver. A delayed processing of the received frame and transmitting a response (e.g., ACK) may cause the data frame retransmission after response timeout, or starting concurrent transmissions by other devices; It should be noted that with or without matching, GPP-based SDR platforms can still perform some tasks successfully such as: a) receiving broadcast/multicast frames as they are not acknowledged, and b) acting as a wireless sniffer.

B. MAPPING PERFORMANCE OF GPP-BASED SDR PLATFORMS WITH WIRELESS TECHNOLOGY REQUIREMENTS
Based on the theoretical performance of GPP-based SDR platforms calculated in section IV and the requirements of wireless technologies listed in section II, the matching conditions can be performed. For this purpose, a list of selected wireless technologies and GPP-based SDR platforms are considered. List of wireless technologies include: NFC, IEEE802.15.6, IEEE802.15.1, IEEE802.15.4, IEEE802.11ac, IEEE802.11ah, LTE, NB-IoT, EC-GSM-IoT, and LoRa. There are also cases where SDR based wireless networks (such as 2G GSM) are also implemented with limited features using OpenBTS, Sysmocom, OsmoNITB, UmTRX SDR based platforms [87]. The list of GPP-based SDR platform contains several SDR devices connected to different GPP hosts via their fastest supported communication interface. The SDR devices and their fastest supported communication interface considered are: HackRF with USB2.0, USRP-X310 with 10Gigabit Ethernet, USRP-B210 with USB3.0, Microsoft Sora with PCIe (x8), and LimeSDR with PCIe (x4). The GPP hosts are: 2 GHz Dualcore processor, 1.5 GHz Quad-core processor and 8 GHz Octa-core processor.
To match the two lists, according to the matching conditions, a mapping table is created (see Table 19). In this Table, as the maximal frequency band and maximal bandwidth of SDR devices are determined irrespective of the wireless technology and GPP host type, they are defined only once. Whereas, the other three parameters (maximal symbol rate, maximal bitrate and minimal latency), as they are determined for each technology on the three GPP host types, their values are indicated separately as per the technology. Moreover, the minimal latency supported by GPP-based SDR platform for each wireless technology is set based on TX path and RX path latencies computed for each technology. For example, the minimal latency supported by a GPP-based SDR platform when performing IEEE802.15.4 based slotted CSMA/CA protocol should take the sum of TX path and RX path latencies. This is due to the fact that slotted CSMA/CA protocol latency represents the Turn around Time (TT) which covers the delay for a receiver device to receive a data frame on RX path and if successfully decoded, transmit an ACK on TX path.
From Table 19, we see that SDR platforms that have wider range of operating frequency (HackRF, USRP-X310 and USRP-B210) satisfies the frequency requirements of all wireless technologies except for IEEE 802. 15   802.11ah and IEEE 802.11ac, while the first partially matches with HackRF and fully with other SDR platforms, the second partially matches with all SDR devices connected to any GPP host type. For the latency matching, the requirement of most of the wireless technologies is several orders of magnitude less than what is offered by any of the SDR platforms. Thus, except NB-IoT, all the other technologies have no match. NB-IoT have full match with all SDR platforms interfaced with Quad-core and Octa-core GPP hosts.
As illustrated by the mapping table and discussion given, most GPP-based SDR platforms fully or partially satisfy the frequency, bandwidth, symbol rate and bitrate requirements of most wireless technologies. However, meeting the latency condition was a bit of a challenge, and thus, both software and hardware improvements should be made. For the software part, compiler and kernel should be optimized to increase the degree of parallelism according to the used processor capabilities. For the hardware part, increasing the number of cores can be efficient in case of applications having high degree of parallelism. Otherwise (with low degree of parallelism), processor with a higher clock speed or using hardware accelerators such as GPUs, DSPs and FPGAs are necessary. Several software projects exist to enable hardware accelerators usage like RAPIDS cuSignal [89] and Compute Unified Device Architecture (CUDA) [90] for GPU, RF Network-on-Chip (RFNoC) [91] and Nutaq's Real-Time Data Exchange (RTDEx) [92] for FPGA, meta-sdr OpenEmbedded layer [93] and liquidsdr [94] for DSP.

C. WHAT OTHER GPP-BASED SDR PLATFORMS FOR EXISTING WIRELESS SDR IMPLEMENTATIONS
Implementations of wireless technologies using SDR platforms were considered by several researchers. These implementations are accompanied by a limited, if not a single, recommended GPP-based SDR platforms. Moreover, the implementations doesn't show/demonstrate how the SDR platforms were selected nor there are studies to map several wireless standards with commercial SDR platforms. VOLUME 10, 2022 Table 20 presents examples of recommended GPP-based  SDR platforms for selected wireless technologies. Now,  based on the mapping table given in previous section, new  opportunities appear to perform the existing implementations  of wireless technologies. Thus, new possible GPP-based  SDR platforms, listed in Table 20, become candidates and may be more convenient for some users in terms of cost, hardware availability, etc. Of course the list of the proposed GPP-based SDR platforms are not exhaustive, but it can be easily extended for other SDR devices and GPP hosts based on the theoretical analysis of our work. For example, a user having a GPP host with Quad-core 3.4 GHz processor can follow our theoretical analysis to determine its eligibility to perform a desired wireless technology through computing the supported bitrate, symbol rate and latency metrics. However, it should be noted that the same latency problem might occur as discussed in section V-B. The following paragraphs demonstrate how to determine the candidate SDR platforms for few existing wireless SDR implementations. The proposed NB-WBAN evaluation platform by [85] uses USRP-N210 and GNU Radio to test different modulation techniques (DBPSK, DQPSK, D8PSK, GMSK) at operating frequency of 950MHz and bandwidth of 0.4MHz. The frequency band and bandwidth help determine the candidate SDR devices, and hence, from our matching conditions and mapping table, HackRF, USRP-X310, USRP-B210, Sora, and LimeSDR are possible candidates. The maximal symbol rate and bitrate for this implementation is 0.6MSym/s and 0.971Mbit/s, respectively, allowing us to choose any communication interface from (USB2.0, USB3.0, Gig.Eth, 10Gig.Eth and PCIe). The listed SDR devices also matches with the required symbol rate. For the target modulation techniques, symbol rate and bitrate, a GPP host having 2 core, 2.0 GHz processor without hyperthreading support is sufficient (see Table 12). Hence, from the list of SDR platforms considered in this paper, HackRF with USB2.0, USRP-X310 with Gig.Eth or 10Gig.Eth, USRP-B210 with USB3.0, Sora with PCIe, and LimeSDR with USB3.0 or PCIe can be used along with Dual-core, Quad-core or Octa-core GPP hosts.

2) LTE
srsRAN is one of the most popular open-source SDR implementation of LTE that has been tested with USRP, LimeSDR and BladeRF SDR devices; USB3.0, Gig.Eth and 10Gig.Eth as communication interface; and ARM based processors as GPP host [14]. It operates for LTE frequency bands and all current LTE bandwidths. As per the modulation, it supports LTE modulation coding scheme upto QAM256 in DL direction. The maximal bitrate achievable by the current srsRAN release is 75Mbit/s DL and 50Mbit/s uplink in 20MHz bandwidth and single-input single-output configuration. To determine other possible SDR platforms, we check for each parameter. The operating frequency for this implementation (LTE bands) ranges from 0.41 to 5.9GHz, which is supported partially by Sora SDR devices as discussed in the mapping table. For the bandwidth, Sora is capable to handle the implementation. The symbol rate and bitrate are also supported by the PCIe communication interface of Sora. As per the GPP host, the maximal symbol rate and maximal bitrate demanded by srsRAN are attained by Dual/Quad/Octa-core processors in both hyperthreading enabled and disable mode as demonstrated by our result in Table 12. Thus, from the list of SDR platforms considered in this paper and using the mapping table, Sora with PCIe interfaced with any of the three GPP hosts are suggested as possible SDR platform to test srsRAN in addition to those recommended by srsRAN.

D. EXPLOITATION OF THE MAPPING BETWEEN SDR AND WIRELESS TECHNOLOGIES
The mapping Table 19  Unlike SDR software developers, regular users employ GPP-based SDR platforms as a testbed to experiment their applications (upper layers) without relying on expert knowledge on how the wireless standards (lower layers) are implemented or performed. Indeed, they only need to know how to select the appropriate SDR platform and how to run the selected wireless technology. For a given application, they first determine its characteristics in terms of data type (sensory data, voice, video, etc.), traffic model (event-driven, continuous or query-driven), number of sensors, geographical area, etc., [4], [5]. Then, they express the application characteristics as a set of specific requirements such as range, data rate, energy consumption, etc. After, they select a set of candidate wireless technologies that can theoretically meet the application's requirement. To experiment the application with the selected wireless technologies, regular users can use a single SDR platform due to the reconfigurable and reprogrammable hardware. In order to determine the suitable SDR platform that can support the selected wireless technologies, regular users can refer to our mapping table. They can also refine their selection by choosing an SDR platform capable of satisfying the requirement of most of their selected wireless technologies.

VI. OPEN CHALLENGES AND FUTURE DIRECTIONS
Using GPP-based SDR platforms for wireless prototyping have been extensively accepted by many researchers and companies. Despite its continuing expansion, several existing research challenges have not yet been addressed. This section presents some open challenges and trends related to the performance enhancement of GPP-based SDR platforms to successfully perform wireless transceivers.

A. HARDWARE AND SOFTWARE OPTIMIZATIONS
To improve the performance of GPP-based SDR platforms in dealing with the computational requirements of wireless standards, hardware and software optimizations should be addressed. From the hardware side, GPP-based SDR platforms performance can be enhanced by different solutions such as: a) increasing the processing speed of GPP host by using more number of cores (as reported by our work) with higher clock speed, memory and cache, and b) using external hardware accelerators such as GPU, FPGA and DSPs. In literature, these solutions were more or less studied theoretically (using GPU [58], [59], [103], FPGA [56], [91], [104], [105], DSPs [93], [94]) but it's still an open challenge to fully investigate experimentally. In addition, the latency due to the interface between the GPP and external accelerator should be considered.
From the software side, various optimizations can be applied to enhance the execution time of the wireless transceiver code at the GPP host. Few examples include using increased number of threads (multi-threaded GPP), vectorization, automatic parallelization, inter-procedural optimization, SIMD and look-up tables (LUTs). These solutions are well investigated theoretically and experimentally in a general context. With respect to the SDR platform, there are few studies conducted by applying these solutions such as [20], [48], however, satisfying the full requirements of wireless transceivers still remains an open challenge. Another important point that seeks research attention is satisfying the real-time requirements (e.g., respecting response time) of wireless transceivers, which has been slightly addressed by researchers using Xenomai Real-Time OSs (RTOSs) [106]. However, the real-time performance of GPP-based SDR platforms need to be investigated more based on the real-time demands of different wireless standards using other RTOSs such as Real-time Linux [107], Real-Time Application Interface (RTAI) [108], and ChronOS [109].

B. VIRTUALIZATION IN SDR PLATFORMS
GPP-based SDR platform can use different type of SDR devices to implement one or more wireless transceivers. Two problems could arise: on one hand the PHY layer software portability, and on the other hand running multiple parallel wireless transceivers. For the first problem, as different types of SDR devices are considered, transceiver software portability can be insured by virtualization to abstract the hardware resources. In literature, the common solution to this problem consists of including a dedicated virtual machine (VM), named as radio virtual machine (RVM), on each SDR device image [11], [110], [111]. However, this solution introduces an extra cost in terms of overhead and latency, and limiting their effect remains an open challenge. The second problem concerns gateways (e.g., IoT gateways in home automation box) that require multiple transceivers to communicate with the deployed end-devices through heterogeneous wireless technologies. To enable this role on the GPP-based SDR platform, multiple VMs should be run in parallel at the GPP host where each VM is dedicated to one wireless transceiver [112]. However, in spite of the benefits gained, the performance of each implemented wireless transceiver maybe seriously degraded due to the competition of GPP host and SDR device resources between the co-located wireless transceivers and additional costs of VMs. These problems are not yet addressed and needs to be explored.

C. MOBILITY AND ENERGY CONSUMPTION
The majority of commercially available GPP-based SDR platforms (Desktop PC or Laptop based) consume high energy to achieve high performance, hence rely on main power supply. However, this is unsuitable for mobile application where SDR platforms can be used as mobile wireless transceivers. Indeed, many projects such as [113], [114] are developed addressing mobile applications where sensors are deployed on vehicles (e.g., car, drone, train) with an on-board SDR platform powered by the vehicle's battery like any mobile wireless device. All these projects report the negative impact of GPP-based SDR platforms on the life-time of vehicle's battery. It becomes necessary to build mobile SDR platforms consuming less energy and at the same time offer expected performance. One discussed solution in literature [42], [115], [116] is to use low power embedded computer boards such as Raspberry Pi, ARM Cortex processor, etc., as GPP hosts. Nevertheless, prototypes based on this solution lack offering adequate performance to support the requirement (specially, the frequency, bandwidth, latency) of most wireless technologies. Thus, building energy efficient SDR platform using embedded computer boards with performance objective is still an open issue. Another alternative solution discussed in literature is to remove the GPP host by migrating its capabilities to the SDR device to form a standalone SDR platform. Examples of such SDR platforms are USRP-E3xx [117], BladeRF [118], µSDR [119]. They are designed to offer high performance, be energy efficient and suitable for mobile applications. However, they require more experimental investigations on their performance in terms of frequency, bandwidth, symbol rate, bitrate and latency.

VII. CONCLUSION
Selecting SDR platform to implement and perform a wireless technology is challenging as it comprises, on one hand, to satisfy design requirements both at the hardware and software level. On the other hand, previous recommendations by researchers/developers of wireless technologies suggest to fulfill the proposed hardware and software list to successfully perform their open-source implementations. However, the proposed list is often restrictive in terms of hardware (SDR devices and GPP hosts) and doesn't take into account the use-case desired by users. This paper has reviewed and presented a large list of GPP-based SDR platforms that satisfy the minimum requirement of wireless technologies.
We believe that the study conducted in this paper will help users to determine, for a given wireless technology, which GPP-based SDR platform configuration is necessary to fully or partially perform the MAC and PHY functions. Additionally, through this study, users who already possess a GPP-based SDR platform can identify possible applications that could be implemented. To determine the candidate SDR platform, the paper first evaluated the performance of selected GPP-based SDR platforms through theoretical and experimental analysis. Then, we proposed matching conditions and created a mapping table between the minimum requirements of well-known wireless technologies and performance of GPP-based SDR platforms. Thereby, a list of candidate GPP-based SDR platforms is established for each wireless technology. This list indicates if the matching is complete, incomplete or negative. The two latter are mainly due to the high latency of GPP hosts. A summary of some of the existing implementations were discussed and using the mapping table we suggested other possible GPP-based SDR platforms to be used. Finally, we highlighted some of the research challenges and future directions to be considered by the research community.