Abstract
In order for a Mobile Device (MD) to support the Licensed Shared Access (LSA), the MD should be reconfigurable, meaning that the configuration of a MD must be adaptively changed in accordance with the communication standard adopted in a given LSA system. Based on the standard architecture for reconfigurable MD defined in Working Group (WG) 2 of the Technical Committee (TC) Reconfigurable Radio System (RRS) of the European Telecommunications Standards Institute (ETSI), this paper presents a procedure to transfer control signals among the software entities of a reconfigurable MD required for implementing the LSA. This paper also presents an implementation of a reconfigurable MD prototype that realizes the proposed procedure. The modem and Radio Frequency (RF) part of the prototype MD are implemented with the NVIDIA GeForce GTX Titan Graphic Processing Unit (GPU) and the Universal Software Radio Peripheral (USRP) N210, respectively. With a preset scenario that consists of five time slots from different signal environments, we demonstrate superb performance of the reconfigurable MD in comparison to the conventional nonreconfigurable MD in terms of the data receiving rate available in the LSA band at 2.3–2.4 GHz.
1. Introduction
Global mobile data traffic is expected to grow up to 24.3 exabytes per month by 2019, which is nearly a tenfold increase compared to the traffic in 2014 [1]. To cope with this explosive increase in data traffic, various enabling technologies, such as full dimensional multiple-input multiple-output, device-to-device communication, and new waveform designs, such as nonorthogonal multiple access, have been actively researched [2, 3]. In particular, the World Radio Communication conference in 2015 (WRC-15) of the International Telecommunication Union-Radio (ITU-R) communication sector considers spectrum sharing technology to be a key methodology that is applicable in the 5th Generation (5G) mobile communications [4]. Among the various spectrum sharing techniques, Licensed Shared Access (LSA), which is a framework for sharing the spectrum among a limited number of users [5], has been the focus of research, especially in Europe. The Electronic Communications Committee (ECC) performed a comprehensive study of the regulatory aspect of LSA. They also released the results of their research on the applicability of the LSA concept in the 2.3–2.4 GHz band using Time-Division Duplexing (TDD) [6]. The Cognitive Radio Trial Environment (CORE) demonstrated an LSA live test in the LSA band at 2.3–2.4 GHz [7], while Mustonen et al. introduced a novel network architecture, namely, self-organizing networking features [8], to support LSA. During this time, Working Group (WG) 1 of the Technical Committee (TC) on the Reconfigurable Radio System (RRS) of the European Telecommunications Standards Institute (ETSI) has been developing LSA-related standards. In addition, [9–11] introduced an early-stage overview of the LSA system concept, LSA system requirements, and architecture for operation of mobile broadband systems, respectively. All the LSA-related developments introduced above, however, have only considered the LSA technology from the viewpoint of network or infrastructure systems but not from the viewpoint of Mobile Device (MD). This is problematic because the previous work has not specified the functionalities required in MDs in order to operate using LSA. For example, if a MD does not support TDD Long Term Evolution (LTE) at the frequency band of 2.3–2.4 GHz, an additional spectral band for LSA, that is, 2.3–2.4 GHz [9], would provide very little advantage [12]. Consequently, in order to fully exploit spectrum sharing, MD must be able to adaptively change its configuration appropriately for the radio application (RA) defined in a given LSA band. Therefore, it seems that reconfigurability is a mandatory characteristic of MD in order to fully exploit the benefits of LSA-based spectrum sharing.
Recently, WG2 of TC-RRS of ETSI developed a standard architecture and related interfaces for reconfigurable MDs. In [13], WG2 released a standard reconfigurable MD architecture with its main effort focused on resolving the problem of portability between the RA code and the MD hardware platform. WG2 has also defined standard interfaces in accordance with the standard architecture for reconfigurable MDs in [14, 15].
The main contribution of this paper is to show how the reconfiguration of MDs should be achieved for realizing LSA demonstrated by WG1 of TC-RRS of ETSI in [9] where it is assumed that the target MD is compliant with the standard architecture released by WG2 of TC-RRS of ETSI [13]. If the target MD is reconfigurable, there is no restriction on the RA in an LSA region. For example, a MD is configured with TDD LTE in the frequency region at 2.3–2.4 GHz in order for the scenario in [9] to be valid because TDD LTE has been defined as the designated RA in the LSA region of the 2.3–2.4 GHz band [12]. Since we do not know in general which RA will be adopted in the LSA region, the LSA technology is not useful for nonreconfigurable MDs. In order to verify the reconfiguration of MDs for LSA, we specify in this paper which interactions should occur in what order among the software entities in the reconfigurable MDs using the ETSI-standard architecture. The systematic interactions among the software entities of the reconfigurable MD are referred to as a “procedure” in this paper. We also present implementation of the reconfigurable MD prototype that realizes the proposed procedures. The implemented test-bed using the MD prototype is compliant with the reference model of the standard architecture [13] released by WG2 of TC-RRS of ETSI. The modem and Radio Frequency (RF) of the prototype MD are implemented with the NVIDIA GeForce GTX Titan Graphic Processing Unit (GPU) and Universal Software Radio Peripheral (USRP) N210, respectively. Assuming the LSA region adopts TDD LTE, as shown in [12], we demonstrate superb performance of the reconfigurable MD compared to a conventional nonreconfigurable MD in terms of the data receiving rate available in the LSA band at 2.3–2.4 GHz. In addition to the experimental tests performed with the implemented test-bed, computer simulations have also been presented considering a scenario of multiple users in an LSA band. It was verified through the computer simulations that the reconfigurable MDs not only increase the total sum rate itself but also increase the number of users satisfying a given QoS.
The rest of this paper is organized as follows. Section 2 introduces the standard architecture for a reconfigurable MD developed by WG2 of TC-RRS, based on which the procedure is set up in the following section. Section 3 proposes the procedures that specify the interactions among the software entities of the ETSI-standard reconfigurable MD for realization of the LSA. Section 4 introduces the implemented reconfigurable MD, while Section 5 presents the experimental results obtained from the implemented MD and performance evaluations obtained from the computer simulations considering the scenario of multiple users. Finally, Section 6 concludes this paper.
2. Architectural Model for Reconfigurable MD
WG2 of TC-RRS of ETSI has developed a standard architecture for reconfigurable MDs and related interfaces with the intention that any desired Radio Access Technologies (RATs) can be realized in a reconfigurable MD by downloading the target RA code from the public domain, for example, the RadioApp Store [16], regardless of the hardware platform of the MD. This section introduces a brief summary of the standard architecture and related interfaces based on which a systematic procedure is developed in the following section in such a way that the software entities in the reconfigurable MD interact with one another for implementing the LSA.
2.1. Architecture for Reconfigurable MD
Figure 1 illustrates the reconfigurable MD architecture and related interfaces proposed by WG2 of TC-RRS of ETSI. As shown in the figure, the architecture consists of a Communication Services Layer (CSL), Radio Control Framework (RCF), Unified Radio Applications (URAs), and radio platform [13]. Although the four components are shown in the figure, the necessary part of the ETSI standard includes the four entities in CSL, that is, the Administrator, Mobile Policy Manager (MPM), networking stack, and monitor, as well as the five entities in RCF, that is, the Configuration Manager (CM), Radio Connection Manager (RCM), Flow Controller (FC), multiradio controller (MRC), and Resource Manager (RM). This means that the radio platform is vendor-specific and the URA is the downloaded RA code consisting of functional blocks, metadata, and other software needed for the processing of context information [13–15].
The functionality of each of the four entities in the CSL can be summarized as follows. Administrator entity requests (un)installation of URA and creates or deletes instances of URA. The MPM entity monitors the radio environments and MD capabilities, requests (de)activation of URA, and provides information about the URA list. The networking stack entity sends and receives the user data. The monitor entity transfers the context information from the URA to the users or the proper destination entity in a MD.
The functionality of each of the five entities in the RCF can be summarized as follows. The CM entity (un)installs, creates, or deletes instances of URA and manages access to the radio parameters of the URA. The RCM entity (de)activates URA according to user requests and manages user data flows. The FC entity sends and receives user data packets and controls the flow of the signaling packets. The MRC entity schedules the requests for radio resources issued by concurrently executing URAs as well as detecting and managing the interoperability problems among the concurrently executed URAs. The RM entity manages the computational resources in order to share them among the simultaneously active URA. This guarantees their real-time execution.
The RA code, that is, the software that enforces generation of the transmit RF signals or the decoding of the received RF signals, becomes a URA once it is downloaded into a reconfigurable MD. Since all RAs exhibit common behavior from a reconfigurable MD perspective once they are downloaded in a reconfigurable MD, the downloaded RA code is called URA, which consists of functional blocks that exhibit the required modem functions of the corresponding RAT.
The radio platform shown in Figure 1 is part of the MD hardware that relates to the radio processing capability. It includes the programmable components, hardware accelerators, RF transceiver, and antenna(s).
2.2. Interfaces for Reconfigurable MD
As shown in Figure 1, there are three types of interfaces, the Multiradio Interface (MURI), Unified Radio Application Interface (URAI), and Reconfigurable RF Interface (RRFI), with which entities from the CSL, RCF, and radio platform can interact with one another.
The MURI interfaces each entity of the CSL and RCF. It provides three types of services: administrative services, access control services, and data flow services [14]. The URAI interfaces each entity of the RCF and URA. It provides five types of services: RA management services, user data flow services, multiradio control services, resource management services, and parameter administration services [17]. The RRFI interfaces the URA and the radio platform. It provides five types of services: spectrum control services, power control services, antenna management services, transmit (Tx)/receive (Rx) chain control services, and radio virtual machine protection services [15].
3. Proposed Procedures for LSA in Reconfigurable MD
In this section, we present an LSA procedure for reconfigurable MD in which the architecture is specified as the ETSI standard briefly summarized in the previous section. The procedure introduced in this section specifies how the entities in the CSL and RCF shown in Figure 1 interact with one another.
Figure 2 illustrates a conceptual view of realizing LSA, in which the basic scenario has been demonstrated by WG1 of TC-RRS of ETSI [9]. The National Regulation Authority (NRA) shown in Figure 2 manages the LSA Repository in such a way that it provides the LSA Repository information about LSA license regarding the right of using the LSA band and receives a report regarding the use of LSA spectrum from the LSA Repository. The LSA Repository contains a database of spatial and temporal information regarding the spectrum use of the incumbent user. Based on the information provided from the LSA Repository, the LSA controller determines the availability of the spectrum that can be shared using LSA. In cases when the spectrum is available, the network management system, which is denoted as “Operation, Administration, and Maintenance (OAM)” in Figure 2, acknowledges the availability of the spectrum to the corresponding base station.
The use case of expanding the bandwidth using LSA has been released by WG1 of TC-RRS of ETSI in [9]. This is the basis of the LSA procedure introduced in this section. The use case can be summarized as follows. Let us first consider a case where a Mobile Network Operator (MNO) providing a Frequency Division Duplexing (FDD) LTE service wants to switch the spectral band from its own FDD LTE band to the LSA band at a specific time. Note that, as shown in [12], the LSA region is assumed to be supported with TDD LTE in the band at 2.3–2.4 GHz. Assuming the MNO has held the individual authorization for using the extra band at 2.3–2.4 GHz, the LSA controller shown in Figure 2 decides which base stations can be granted use of the extra spectral band for the required time period. Receiving the information regarding the availability of the extra spectral band from the LSA controller, the OAM shown in Figure 2 notifies the availability of the spectrum to those base stations which may use the extra spectral band at 2.3–2.4 GHz. In order to implement this use case, we propose a procedure for updating the configuration of MD with a new RA defined in a given LSA region, that is, TDD LTE in this use case.
Figure 3 illustrates the procedure of updating the configuration of MD with an arbitrary RA required for LSA. The procedure shown in Figure 3 can be summarized in the 17 steps shown as follows.
Step 1. In order to install a new URA, the the Administrator sends a DownloadRAPReq signal including the Radio Application Package (RAP) identification (ID) to the RadioApp Store.
Step 2. The Administrator receives a DownloadRAPCnf signal including the RAP ID and RAP from the RadioApp Store.
Step 3. Upon the download of RAP from the RadioApp Store, the Administrator sends an InstallRAReq signal including the RAP ID to the CM to request installation of the new RA.
Step 4. The CM first performs the URA code certification procedure in order to verify its compatibility, authentication, and so forth.
Step 5. The CM performs installation of URA and transfers an InstallRACnf signal including the URA ID to the Administrator.
Step 6. In order to deactivate the current URA, the MPM transfers the RCM HardDeactivateReq signal, which includes the RA ID.
Step 7. Upon a request from the RCM, the Radio Operating System (ROS) deactivates the designated URA.
Step 8. After the ROS completes hard deactivation of the URA, the RCM acknowledges completion of the deactivation procedure by sending a HardDeactivateCnf signal to the MPM.
Step 9. In order to create an instance of a new URA, the MPM transfers an InstantiateRAReq signal including the ID of the URA to be instantiated to the CM.
Step 10. The CM transfers an RMParameterReq signal and an MRCParameterReq signal including the ID of the URA in order to get the parameters needed for URA activation to the RM and MRC.
Step 11. The CM receives an RMParameterCnf signal including the ID of the URA and the radio resource parameters from the RM.
Step 12. The CM receives an MRCParameterCnf signal including the ID of the URA and computational resource parameters from the MRC.
Step 13. The CM transfers the URA ID and the received parameters for performing the URA instantiation to the ROS.
Step 14. After creating an instance, the CM transfers an InstantiateRACnf signal including the URA ID to the MPM.
Step 15. In order to activate the new URA, the MPM transfers an ActivateReq signal including the ID of the URA to the RCM.
Step 16. Upon request from the RCM, the ROS activates the designated URA.
Step 17. After the ROS completes activation of the URA, the RCM sends an ActivateCnf signal back to the MPM.
Note that Steps 3 and 5 utilize the administrative services of the MURI [14], Steps 6, 8, 9, 14, 15, and 17 make use of the access control services of the MURI [14], Steps 7 and 16 utilize the radio application management services of URAI [17], and Steps 4 and 13 make use of the parameter administration services of URAI [17]. Steps 10, 11, and 12 are related to the interactions among the entities in the RCF, which are vendor-specific.
Through the procedure shown in Figure 3, the MD reconfiguration can be achieved by updating the present URA with a new one. Note that, in the use case presented by WG1 of TC-RRS of ETSI in [9], the present URA is FDD LTE, and the new one is TDD LTE. It is also noteworthy that the feasibility of the standard architecture and related interfaces can be verified from Figure 3 through the observation that the desired RA code is first downloaded from the RadioApp Store, then installed, instantiated, and activated in a given reconfigurable MD.
4. Implementation of a Reconfigurable MD for LSA
This section presents implementation of the prototype reconfiguration MD used as a test-bed for obtaining the experimental results of LSA introduced in Section 5. The implemented prototype system is compliant with the standard architecture of ETSI TC-RRS WG2 [13].
Figure 4(a) illustrates a reference model of the reconfigurable MD architecture introduced in [13]. According to the standard architecture of the reconfigurable MD defined by WG2 of TC-RRS of ETSI, operations supported by the Application Processor are based on non-real-time processing. The operations supported by the Radio Computer are based on real-time processing, while the dotted part in between these two parts shown in Figure 4(a) is either non-real-time or real-time depending upon the vendor’s choice. This option means that the Operating System (OS) of the Application Processor must be a non-real-time OS such as Android or iOS, while that of the Radio Computer, which is referred to as ROS in Figure 4(a), has to be a real-time OS including RCF, as indicated in Figure 4(a). The Application Processor in Figure 4(a) includes the following components: (1) a driver that activates a hardware device, such as a camera or speaker, in the part of the Application Processor on a given MD and (2) a non-real-time OS for execution of the Administrator, MPM, networking stack, and Monitor [13], which are part of the CSL, as described previously. The Radio Computer includes the following components: (1) ROS for executing the functional blocks of the given RAs; (2) a radio platform driver, which is for the ROS to interact with the radio platform hardware; and (3) a radio platform, which typically consists of programmable hardware, dedicated hardware, RF transceiver, and antenna(s).
![(a) Reference model of the ETSI-standard reconfigurable MD architecture [13]](https://static.hindawi.com/articles/misy/volume-2016/8035876/figures/8035876.fig.004a.jpg)
(a) Reference model of the ETSI-standard reconfigurable MD architecture [13]
(b) Implemented reconfigurable MD test-bed architecture
Figure 4(b) illustrates a block diagram of the reconfigurable MD prototype architecture that has been implemented as a test-bed based on the architecture shown in Figure 4(a). As shown in Figure 4(b), the Application Processor part of the test-bed consists of Ubuntu 12.04 [18] and CSL, while the Radio Computer part consists of a Linux kernel, RCF, radio platform driver, and radio platform. For the purpose of experimental tests, we have not adopted a real-time OS for the Radio Computer part because the primary purpose of the test-bed is to verify the feasibility of the standard architecture for the functionality of LSA-based spectrum sharing rather than the real-time functionality of the RA code execution. Furthermore, the test-bed system does not include all the entities of the CSL and the RCF defined in the ETSI standard. Specifically, in the test-bed system shown in Figure 4(b), CSL consists of an Administrator and MPM only, while RCF consists of CM, RCM, RM, and MRC only. Also, it can be observed from Figure 4(b) that the Linux kernel, which plays the role of ROS in the test-bed system, supports the execution of the functional blocks of a given RA code. The RA code prepared for our test-bed system consists of FDD LTE and TDD LTE which are compliant with 3GPP Rel. 10 [19]. The RA code is executed on a GPU in radio platform of the test-bed. GPU in general, since it contains a great number of powerful threads, is appropriate for parallel computing. In order to utilize the number of threads efficiently, the RA code containing FDD LTE and TDD LTE has been implemented using Compute Unified Device Architecture (CUDA), that is, a C-based programming language provided by NVIDIA. The GPU adopted in our test-bed is NVIDIA’s GeForce GTX Titan that is capable of 4,494 GFLOPS using 2,688 CUDA core processor cores [20]. In addition, the radio platform driver shown in Figure 4(b) includes the CUDA driver and the URSP Hardware Driver (UHD) through which the Linux kernel can access the radio platform consisting of a NVIDIA GeForce GTX Titan GPU and USRP N210 [21], respectively.
The key issue in RA code implementation is to maximize the degree of parallelization among the large number of threads in a given GPU. In fact, the parallelization can be considered in multiple layers, that is, among grids, blocks, and/or threads in a given GPU. Note that each grid contains multiple blocks and each block includes multiple threads. In order to maximize the degree of parallelization, each function block of the RA code should be partitioned into as many pieces as possible such that we can maximize the number of threads to be activated for executing a given task. For example, the procedure of channel estimation along the frequency axis [19], which is a function block needed in both FDD and TDD LTE, has been partitioned in our RA code implementation in such a way that a single grid containing 200 blocks each of which includes 6 threads in the NVIDIA GeForce GTX Titan GPU has been activated. It means that totally 1,200 threads are activated in parallel for the function block of the channel estimation along frequency axis. Similarly, for the function block of channel estimation along time axis [19], totally 8,400 threads, that is, 14 threads in each block and 600 blocks in a single grid, have been activated in parallel.
Figure 5 illustrates a photograph of the implemented test-bed of the reconfigurable MD. The test-bed realizes the architectural model shown in Figure 4(b). As shown in Figure 5, the test-bed system consists of two parts, an ordinary Personal Computer (PC) and an RF transceiver. An ordinary PC, which provides a NVIDIA GeForce GTX Titan GPU and Central Processing Unit (CPU), was used to implement all the components of the reconfigurable MD shown in Figure 4(b) except for the RF transceiver, which has been separately implemented with USRP N210, as shown in Figure 5. In our implementation, the RF transceiver is connected with the PC through a Giga-bit Ethernet (GbE), as shown in Figures 4(b) and 5. All the functional blocks in a given RA code are executed on the NVIDIA GeForce GTX Titan GPU board in the PC, while all the functionalities of the RF transceiver, including analog-to-digital and digital-to-analog conversions as well as frequency-up and frequency-down conversions, are performed in the USRP N210. Note that the lower part shown by a dotted line in Figure 4(b) corresponds to the RF transceiver implemented with USRP N210, while the other part shown by a solid line in Figure 4(b) corresponds to all the other parts of a reconfigurable MD implemented with the ordinary PC shown in Figure 5. Since an ordinary PC only provides a GPU and CPU, the implemented prototype system does not include Field Programmable Gate Arrays (FPGA) or Digital Signal Processors (DSP) in the part of the radio platform shown in Figure 4(b), while the GPU supports all the functional blocks required in the FDD LTE and TDD LTE that are needed in the LSA. The CPU in the PC was used to realize the functionalities of RCF as well as to control the GPU and USRP through the CUDA driver and UHD in the radio platform driver, respectively, as mentioned earlier. The Graphic User Interface (GUI) shown in Figure 5 provides monitoring of the video data stream, which is the result of decoding the received FDD or TDD LTE signals, as well as a set of environmental parameters such as data throughput and Bit Error Rate (BER). The spectrum analyzer shown in Figure 5 was used to observe the center frequency and bandwidth of the RF signals of FDD and TDD LTE.
5. Numerical Results
5.1. Experimental Tests
This subsection presents the experimental results of the LTE data throughput obtained from a test-bed consisting of an Evolved Node B (eNB) and MD operating in the signal environment of the use case considered in Section 3, that is, the use case of expanding bandwidth using LSA. In the experimental tests, we considered two types of MD for comparison purposes. One is a legacy MD of which the configuration is fixed with FDD LTE, and the other is capable of changing its configuration between FDD LTE and TDD LTE depending on the given signal environment. In general, a MD performs a horizontal handover; that is, it moves to an adjacent base station, when the Quality of Service (QoS) drops down to a preset threshold value. If the given QoS cannot be satisfied through a horizontal handover, a reconfigurable MD performs a vertical handover; that is, it changes the present radio application to another one that can bring about satisfactory QoS [12]. In this paper, the required QoS was set up with a preset level of LTE data throughput. Therefore, when the preset level of the LTE data throughput is not achieved through a horizontal handover, the MD checks the availability of the TDD LTE of the LSA band in order to perform a vertical handover from FDD LTE to TDD LTE. As we have implemented a single eNB for simplicity, however, the reconfigurable MD performs a vertical handover directly when the present LTE data throughput becomes lower than the threshold level. Consequently, whenever the QoS is not maintained, assuming the LSA band is available in the present region, a reconfigurable MD changes its configuration from FDD LTE to TDD LTE. As for the legacy MD, the configuration is always fixed with FDD LTE, whether or not the QoS is satisfied. In this subsection, we have summarized the LTE data throughput obtained from both the reconfigurable MD and legacy MD in a signal environment where the QoS and availability of the LSA band vary as a function of time. For the experimental tests introduced in this subsection, the MD prototype shown in Section 4 was used for the reconfigurable MD, while the dual mode eNB supporting FDD and TDD LTE shown in our previous work in [22] was used.
Figure 6 illustrates a functional block diagram of the dual mode eNB [22] that supports both FDD and TDD LTE and that of MD. Both eNB and MD were implemented with a PC including a GPU for base band signal processing and USRP N210, which plays the role of the RF transceiver. As shown in Figure 6(a), eNB encodes the video data stream in accordance with the data format of both FDD and TDD LTE. The encoded data are transferred to the RF transceiver of USRP N210 via GbE and radiated through the transmit antennas. For FDD LTE, the center frequency was set to 1.7 GHz, a licensed band, with its bandwidth being 10 MHz, while TDD LTE uses 2.35 GHz as its center frequency with its bandwidth being 15 MHz. For the experimental tests of LSA, eNB transmits the FDD LTE signals continually, while the TDD LTE signal is transmitted only for a preset period of time, which means eNB in our test-bed system transmits both FDD and TDD LTE signals only for a preset period of time, except for the FDD LTE signal, which is transmitted from eNB. Figure 6(b) illustrates a common functional block diagram for both reconfigurable MDs and legacy MDs. As shown in Figure 6(b), the RF signal transmitted from eNB is captured at the receive antenna of MD, and the frequency-down and analog-to-digital are converted at the RF transceiver of USRP N210. Then, the FDD and/or TDD LTE signal is decoded and retrieved into the video data stream.
(a) Functional block diagram of eNB
(b) Functional block diagram of MD
Table 1 shows the scenario set up for the experimental tests in terms of QoS satisfaction and LSA band availability. Each time interval in Table 1 was set to 60 seconds. The experiment was performed for five time intervals starting at and ending at . For example, during the first time interval, , that is, from to , the signal environment was set up in such a way that QoS was satisfied, and the LSA band is not available. The condition whether or not QoS is satisfied is determined, as mentioned earlier, depending on whether or not the data throughput at the receiving MD exceeds the preset threshold value. The value for the threshold has been arbitrarily set up to 10 Mbps. The signal environment where the QoS was satisfied was set up by allocating all the spectral resources of FDD LTE to the target MD. The other signal environment where QoS was not satisfied was implemented by allocating only a half of the entire spectral resources of FDD LTE to the target MD. For the availability of the LSA band, the LSA band becomes available only when the dual mode eNB transmits the video stream data in both FDD and TDD LTE. When eNB transmits the video stream data only in FDD LTE, the LSA band is not available. In our experiment, assuming that the LSA band is available for the time intervals of and , the availability of the LSA band is set up for and as shown in Table 1, which means the procedure for the LSA controller to notify the availability of the LSA band to OAM has been omitted in our experiment. Note that since the MD normally operates in FDD LTE mode, the availability of the LSA band does not have to be checked as long as QoS with FDD LTE is satisfied. Consequently, if QoS with FDD LTE is not satisfied, the reconfigurable MD starts to set up its configuration with TDD LTE of the LSA band, while the conventional nonreconfigurable MD has to stay in FDD LTE mode with unsatisfactory data throughput.
Figure 7 shows an image of the experimental test for measuring the data throughput of the reconfigurable MD and legacy MD. The system parameters for FDD and TDD LTE were set up as shown in Table 2. Since the received data throughput for TDD LTE is determined by the uplink/downlink configuration type and the special subframe configuration type, the types in Table 2 were set up in such a way that the maximum throughput of FDD and TDD LTE becomes approximately the same.
Figure 8 illustrates the throughput values measured at the receiving MD. The data throughput shown in Figure 8 was obtained from the experimental environment shown in Figure 7 in which the eNB and MD use the system parameter values shown in Table 2 according to the experimental scenario shown in Table 1. Table 3 shows an average Rx throughput for each time interval together with Key Performance Indicator (KPI), which indicates whether or not the configuration of the reconfigurable MD has been correctly set up in accordance with a given signal environment. More specifically, KPI tells whether or not the configuration of the reconfigurable MD has been correctly changed from FDD/TDD LTE to TDD/FDD LTE during the time interval /. Therefore, KPI is set up to 1 or reset to 0 depending on whether the configuration of the reconfigurable MD is performed successfully or not. Consequently, throughput of the receiving MD would have become greater than 10 Mbps/14.5 Mbps during the time interval of / if the configuration of the reconfigurable MD was successfully performed, that is, from FDD/TDD LTE to TDD/FDD LTE during the time interval of /. The solid line in Figure 8 corresponds to the performance of the reconfigurable MD, while the dotted line corresponds to the legacy MD. It can be observed from Figure 8 that, during the first time slot , both the reconfigurable MD and legacy MD exhibit almost the same maximum throughputs, 14.88 M bits per second (bps) and 14.80 Mbps, respectively, with FDD LTE because the first time slot was set up for QoS to be satisfied with FDD LTE. Note that, with the signal environment of QoS being satisfied, as mentioned earlier, it is implemented by allocating all of the spectral resources transmitting eNB to the target MD. Note that the maximum throughput of FDD LTE, 14.88 Mbps, can be calculated from the system parameters shown in Table 2 as 744,336 (number of 16 QAM symbols per frame) 0.5 (channel coding rate) 4 (number of bits per 16 QAM symbol)/10 ms (frame length). During the second time slot, , the signal environment was set up for QoS not being satisfied and the LSA band not being available, as shown in Table 1. Setting the threshold value for determining whether or not QoS is satisfied to be 10 Mbps at the receiving MD, we have allocated only half of all the spectral resources of eNB to the target MD in order to implement the signal environment as QoS not being satisfied. It can be observed that, with half of all the spectral resources transmitting eNB, the maximum throughput is nearly 14.88/2 = 7.44 Mbps, which is far less than the threshold value of 10 Mbps. During , eNB transmits data with only half of the entire spectral resources with which the throughput cannot exceed the threshold; therefore, QoS is not satisfied. Since the signal environment during does not provide the LSA band either, both the reconfigurable and legacy MDs cannot help staying in FDD LTE with nearly the same throughputs, 7.32 Mbps and 7.33 Mbps, respectively. During , since eNB transmits the signal in both FDD and TDD LTE, meaning that the LSA band is now available, the reconfigurable MD can exploit the throughput of TDD LTE, 14.39 Mbps, by switching its configuration from FDD LTE to TDD LTE of the LSA band. The legacy MD, however, stays in FDD LTE with only a half throughput. Note that the maximum throughput of TDD LTE, that is, 14.5 Mbps, available with the system parameters shown in Table 2 can be calculated as 47,986 (number of 64 QAM symbols per frame) 0.5 (channel coding rate) 6 (number of bits per 64 QAM symbol)/10 ms (frame length). During , as eNB transmits the signals of FDD LTE that satisfy the QoS requirement, the legacy MD can secure the maximum throughput comparable to the one obtained during . Since the throughput is maintained above the threshold, the reconfigurable MD stays in TDD LTE. Since the throughput of TDD LTE has been arbitrarily set up a little bit lower than that of FDD LTE in our test-bed system, the throughput of the reconfigurable MD happens to be slightly lower than that of legacy MD during . During , as the LSA band is no longer available, the reconfigurable MD changes its configuration back to FDD LTE from TDD LTE with its throughput returning to the one obtained during . Note that the lengths of the time intervals could be related to the possible interferences to/from primary/secondary users of the spectrum. In addition, since the transition in between the configuration changes takes about 5–10 ms in our test-bed, the lengths of and where the LSA band is available should not be too short for the MDs using the LSA band to exploit the benefit of LSA. But it should not be too long because, otherwise, the MDs occupying the LSA band could interfere with the primary users.
From our experimental tests performed in accordance with the preset scenario shown in Table 1, it is clear that, in order to fully utilize the benefits of the LSA band, the configuration of MD should be adjustable to the radio application used in the LSA band, which is set to TDD LTE in our experiments.
5.2. Computer Simulations
In the test-bed implemented for the experimental tests, the number of the reconfigurable MDs and that of legacy MDs were only 1 as shown in Figure 7. In this subsection, we introduce computer simulations performed for a scenario of multiple users in a given LSA band. The system parameters shown in Table 2, which were used for the experimental tests, have been adopted again in the simulations. The total number of users, which consists of the reconfigurable MDs as well as legacy MDs, is set to be 100 in the simulations. For simplicity but without loss of generality, we assume that the number of MDs that can be allowed using the LSA band is limited to 30 by the NRA shown in Figure 2 [5] in our simulations. Furthermore, the Rx throughput of each user has arbitrarily been set up with a random number between 30 Kbps and 300 Kbps where the threshold value that determines whether or not QoS is satisfied has been set up to 100 Kbps. Therefore, those MDs whose throughput is below the threshold, that is, 100 Kbps, are to apply for the LSA band by changing their configurations from FDD LTE to TDD LTE. Among those MDs, not more than 30 MDs are randomly selected for using the LSA band in our simulations. Consequently, the Rx throughput of each reconfigurable MD that has been allowed using the LSA band would be changed from a random number between 30 Kbps and 100 Kbps to another random number between 100 Kbps and 300 Kbps, if the reconfigurable MDs have been accepted to use the LSA band.
Figure 9 illustrates accumulated sum rates when the portion of the reconfigurable MDs is 0%, 10%, 50%, 70%, and 100% of the entire 100 users. As shown in Figure 9, since the LSA band is not available until the end of , the accumulated sum rates for all the cases are quite comparable. As the LSA band becomes available during the time interval of and , the sum rates increase more rapidly as the portion of the reconfigurable MDs is higher. Note that the number of the reconfigurable MDs whose throughputs are improved due to the LSA technology increases as the portion of the reconfigurable MDs is higher. From Figure 9, it can be observed that more number of reconfigurable MDs improves the accumulated sum rate more conspicuously.
Figure 10 illustrates Cumulative Distribution Function (CDF) according to the normalized user throughputs for the cases of the different reconfigurable MD portions, that is, 0%, 10%, 50%, 70%, and 100% of the entire 100 users. The normalized user throughput has been obtained by normalizing the throughput of each user with the maximum user throughput. As shown in Figure 10, when the entire user group consists of purely legacy MDs, for instance, the Rx throughput of nearly 70% of the entire users is less than 60% of that of the maximum user throughput. In contrast, when the entire user group consists of the reconfigurable MDs, only 30% of the entire user suffers from the low throughput, that is, 60% of that of the maximum user throughput. In other words, the other 70% of the entire users can enjoy the Rx throughput of higher than 60% of that of the maximum user throughput. From Figure 10, it can be concluded that more number of the reconfigurable MDs brings about more number of users satisfying the QoS.
6. Conclusion
In order to fully exploit the merits of LSA, the configuration of MD should be adjustable to the RA adopted in the LSA band. This paper shows the performance evaluation of reconfigurable MD in terms of system throughput in comparison to legacy MD in a preset test signal environment. For experimental tests, we implemented a prototype of reconfigurable MD with a system architecture that is compliant with the ETSI-standard reference architecture suggested by WG2 of ETSI TC-RRS [13]. The prototype MD has been implemented using NVIDIA GeForce GTX Titan GPU and USRP N210 as its modem and RF transceiver, respectively. In order to set up the configuration of MD in accordance with the radio application adopted in the LSA band, we also developed a systematic procedure for transferring control signals among the software entities defined in the reference architecture. The procedure shown in this paper is based on the use case of expanding bandwidth using LSA released by WG1 of TC-RRS of ETSI in [9]. Through the experimental tests performed with the prototype MD and computer simulations in a simple test environment, it has been verified that the reconfigurability of MD is a necessary condition for LSA technology to fully obtain its benefits.
Competing Interests
The authors declare that they have no competing interests.
Acknowledgments
This research was supported by the MSIP (Ministry of Science, ICT & Future Planning), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2015- H8501-15-1006) supervised by the IITP (Institute for Information & Communications Technology Promotion).