ETSI-Standard Reconfigurable Mobile Device With an Opportunistic Multi-Antenna System Based on Radio and Non-Radio Contexts

In state-of-the-art mobile devices (MDs), non-radio contexts (i.e., non-real-time data) provided by various sensors have been excluded in determining the modem configuration because of the problems in applying them in real-time modem operations. This paper presents a reconfiguration procedure and hardware implementation of a European Telecommunications Standards Institute (ETSI)-standard reconfigurable MD with a multi-antenna system. Borrowing the ETSI-standard architecture, the proposed MD can exploit a high-level abstraction of configuration-related operations, which consequently provides its application processor operating in non-real-time domain a uniform way of managing the multi-antenna-related hardware platform operating in real time. The configuration of the proposed MD is determined in accordance with non-radio and radio context information for opportunistically utilizing multiple antenna resources. From an implemented multi-antenna MD system operating in an indoor layout and computer simulations of the multi-antenna MD operating in a modeled outdoor layout, we verify that the MD configuration can be optimized in accordance with radio and non-radio contexts not only for fixed indoor but also for mobile outdoor environments. This enables the multi-antenna MD to efficiently utilize its antenna resources, such that the throughput maximization and/or power consumption minimization can be achieved.


I. INTRODUCTION
At present, most state-of-the-art mobile devices (MDs) are equipped with various sensors such as a gyroscope, an accelerometer, a global positioning system sensor, and a light sensor, which provide corresponding non-radio context information to MDs. On the basis of this context information combined with database information such as usage habits and historical patterns, MDs perform various handset operations, for example, controlling unused applications and/or changing the operational mode [1]- [3]. We claim that these non-radio contexts can also be used for modem reconfiguration to optimize key performance indicators (KPIs) The associate editor coordinating the review of this manuscript and approving it for publication was Abbas Jamalipour . such as throughput, latency, and/or power consumption. The radio context information mentioned in this paper denotes communication-related information obtained from the received signal of the present radio access technology (RAT), such as signal power, packet error rate, and available frequency band(s). By contrast, non-radio context information denotes the information obtained from MD sensors, such as MD location, MD velocity, and historical MD usage pattern. This paper presents a novel reconfiguration procedure using the European Telecommunications Standards Institute (ETSI)-standard reconfigurable MD [4]- [6] employing a multi-antenna system, whose configuration is determined by non-radio and radio contexts.
The legacy modems of reconfigurable MDs use radio context only because of problems in applying non-real-time data, i.e., non-radio contexts, to real-time modem operations. In other words, various non-radio contexts have not been considered for the modem reconfiguration pursuing the optimization of desired KPIs [7]- [12]. The radio context information, however, suffers from its intrinsic randomness, especially in the case of millimeter waves of 5th-generation mobile communications. The measurement of radio context itself may be unreliable due to its vulnerability to path loss and penetration loss [13]. Consequently, KPI optimization cannot in general be achieved with the radio context only [14]. By exploiting radio and non-radio contexts, the proposed system can opportunistically utilize all antenna resources to the target radio application (RA) to optimize its KPIs, such as throughput, latency, and/or power consumption [14], [15]. Through a hardware implementation of a prototype multi-antenna reconfigurable MD, we verify that the proposed system exhibits an excellent performance in comparison to conventional systems that use the radio context only. Fig. 1 illustrates a conceptual block diagram of the proposed reconfigurable MD adopting radio and non-radio contexts with which the application processor generates a modem reconfiguration command. The objective is to optimize important KPIs, such as throughput and/or power consumption, by opportunistically utilizing the antenna resources in accordance with radio and non-radio contexts. The legacy modems of reconfigurable MDs determine their configuration using only the radio contexts generated during modem operations. In particular, the non-radio contexts transferred to the application processor are excluded in the conventional modem reconfiguration.
The proposed MD can efficiently adopt radio and non-radio contexts provided to its application processor by considering the ETSI-standard architecture [4]- [6] to determine the modem configuration, which optimizes the desired KPIs. As explained in the next section, the ETSI-standard architecture provides a high-level abstraction of configuration-related operations, which consequently provides the application processor of the proposed MD a uniform way of managing its modem and radio frequency (RF) transceiver during the reconfiguration. The prototype MD presented in this paper employs the digital signal processor (DSP) of TMS320C6670 [16] as its modem and the universal software radio peripheral (USRP) X310 [17] as its RF transceiver.
The main contributions of this study can be summarized as follows. First, using the ETSI-standard reconfigurable MD architecture, we propose a novel reconfiguration procedure that adopts non-radio and radio contexts for optimizing desired KPIs. Previous works [18]- [21] have not explicitly specified how the non-radio contexts given to the application processor can configure the modem while the application processor for context information processing and the baseband processor for modem processing are operating in nonreal time and real time, respectively. Second, using a DSP and a USRP as the modem processor and RF transceiver, respectively, we present a hardware implementation of the proposed reconfigurable MD prototype. From various experimental tests, it is verified that the proposed MD, whose configuration is determined by radio and non-radio context information, outperforms conventional reconfigurable MDs by opportunistically utilizing antenna resources in accordance with the non-radio context information.

II. ETSI-STANDARD RECONFIGURABLE MD ARCHITECTURE
This section introduces the ETSI-standard architecture of reconfigurable MDs, which provides a uniform way for the application processor to manage its modem and RF transceiver for the reconfiguration. Through a reference model of the ETSI-standard architecture [5], this section explains how the application processor exploits high-level management for the modem reconfiguration using radio and non-radio contexts.

A. BASIC SET OF ARCHITECTURAL ELEMENTS FOR MINIMUM RECONFIGURATION CAPABILITIES
This subsection introduces the basic sets of the ETSI-standard MD architecture, which provides the application processor with a uniform way to manage its modem and RF transceiver. Although the ETSI standard [5] provides a complete end-toend reconfiguration framework, exploiting all of the available features in prototype implementations may be challenging. To avoid major disruptive steps in the prototype design, how a basic set of architectural elements enable the installation, activation, configuration, execution, and finally de-installation of software components in a standardized way is explained here. Fig. 2 illustrates a reference model of the ETSI-standard architecture of a reconfigurable MD, which consists of an application processor and a radio computer operating in non-real-time and real-time domains, respectively. The application processor includes a driver, non-real time operating system (OS), and user applications, whereas the radio computer includes real-time OS called radio OS (ROS), radio platform, radio platform driver, and RA software. The RA software enforces the generation of the transmitted RF signals or the decoding of the received RF signals. Because all RAs exhibit a common behavior from the reconfigurable platform's perspective, these RAs are denoted as unified RAs (URAs) once they are downloaded into the target reconfigurable radio platform [4].
The communication services layer (CSL) and radio control framework (RCF) together with the interface between them, Reconfigurable MD architecture reference model [5].
denoted as the multi-radio interface (MURI) [6], are the key components for providing a minimum set of reconfiguration capabilities. As shown in Fig. 2, using the double-layered structure consisting of the CSL and RCF, which belong to the application processor and radio computer, respectively, the ETSI-standard architecture provides the application processor a uniform way of managing the radio platform containing the baseband processor and RF transceiver. Moreover, the double-layered structure enables the application processor to control the modem reconfiguration using radio and non-radio contexts. The CSL is an abstraction layer providing high-level management for RAs that are executed on a given radio platform. Specifically, the CSL abstracts each of the configuration-related operations performed on the RCF to provide a uniform way of managing the hardware platform, i.e., radio platform, installation/uninstallation of RA(s), and activation/deactivation of RA(s), which are the typical configuration-related operations performed on the RCF. The software entities defined in the CSL include the Administrator, Mobility Policy Manager (MPM), Networking Stack, and Monitor, all of which support the execution of multiple RAs. The functionalities of each software entity in the CSL can be summarized as follows: • Administrator: requests the (un)installation of the RA and creates or deletes instances of the RA. This entity typically includes the provision of information about the spectral and computational requirements for each RA and status of each RA.
• MPM: monitors the radio environments and reconfigurable platform capabilities, requests the (de)activation of the URA, and provides information about the URA list. It also makes a selection among different RATs and discovers peer communication equipment and the arrangement of associations.
• Networking Stack: sends and receives user data • Monitor: presents radio context information, such as received signal strength indicator (RSSI), packet error rate, and availability of frequency bands, from the URA to users or proper destination entities in the MD.  • Administrative services: These services are used by the Administrator to (un)install a new URA into the reconfigurable platform and create/delete an instance of the URA.
• Access control services: These services are used by the MPM to maintain the user policies and preferences related to the usage of different RATs and to make a selection between them. The MURI specification covers the information exchange of RAT selection decisions between the CSL and RCF.
• Data flow services: These services are used by the Networking Stack of the reconfigurable platform, such as the TCP/IP stack. Therefore, data flow services represent the set of (logical) link layer services, which are provided in a uniform manner regardless of which URAs are active. The minimum required features of the RCF, which provide a generic environment for the execution of URAs and a uniform way of accessing the functionality of the CSL and individual URAs, are as follows: • Configuration manager (CM): (un)installs and creates/deletes instances of URAs and manages access to the radio parameters of the URAs With these basic features, it is possible to • Enable the installation and activation of a URA • Parameterize the configuration, e.g., control the RF transmit power of the RA • Access to data flow services for sending and receiving user data regardless of the URA • Perform the de-activation and uninstallation of a URA Beyond the basic feature set introduced above, other entities and interfaces can support enhanced flexibility for more advanced implementations in the future [4].

B. RECONFIGURATION PROCEDURES USING THE BASIC SET OF ETSI-STANDARD ARCHITECTURAL ELEMENTS
This subsection introduces two typical reconfiguration procedures necessary for optimizing the desired KPIs using the basic set of ETSI-standard architectural elements for minimum reconfiguration capabilities, as explained in the preceding subsection. The objective is to optimize the desired KPIs by opportunistically utilizing all the hardware resources to the target RA, which is selected in accordance with the reconfiguration command generated in the application processor based on radio and non-radio contexts. As the MD in this study is assumed to have multiple antennas, our interest is focused on how the entire antenna resources can be exploited for a given RA selected by the reconfiguration command transferred from the application processor, considering radio and non-radio contexts.
In the example shown in this subsection, we assume, for simplicity but without loss of generality, that the RF transceiver of the reconfigurable MD contains two antenna ports and two corresponding RF chains. The first reconfiguration procedure considered is to deactivate one of the two RF chains allocated for receiving/transmitting the unchosen RAT signal. The second reconfiguration procedure is to activate two-antenna multiple-input-multiple-output (MIMO) operations utilizing the entire antenna resources, including the one previously deactivated. The objective of the first and second reconfigurations is to minimize the power consumption and maximize the system capacity, respectively.
Through the reconfiguration procedures shown in this subsection, we intend to verify that the reconfiguration command generated in accordance with the radio and non-radio contexts by the CSL (operating in non-real time) can efficiently be executed by the RCF (operating in real time). Furthermore, it is verified that the double-layered structure of the CSL and RCF, with the MURI in between the CSL and RCF, enables the reconfiguration command to be executed regardless of the specific hardware platforms. Fig. 4(a) illustrates a sequence diagram of a reconfiguration procedure for deactivating a specific RA and its corresponding RF chain, denoted as RA #2 and RF chain #2, respectively. The objective is to reduce the power consumption by switching off the corresponding hardware resources allocated to the unchosen RA. In this reconfiguration procedure, it is assumed that the RAT #1 and RAT #2 signals have VOLUME 8, 2020 been received/transmitted with RA #1 and RA #2 through RF chain #1 and RF chain #2, respectively, in a signalinput-single-output (SISO) mode until the reconfiguration procedure shown in Fig. 4(a) begins.
In contrast to the proposed reconfigurable MD whose configuration is determined in accordance with the radio and non-radio contexts, conventional MDs adopting radio contexts should only maintain connections to all the potential RAT signals to confirm which of the RAT signals is the most appropriate to be selected as the MD configuration. Consequently, even when a particular RAT signal falls into long-term adverse signal conditions, the hardware resource corresponding to that RAT signal cannot be switched off because the MD has to keep detecting all the potential RAT signals consistently. By contrast, if the MD is informed about various special signal conditions, for instance, intentional blocking of a particular RAT signal(s) for a specific timeslot and the locational coverage hole of a particular RAT signal(s) through corresponding non-radio and radio contexts, then the MD does not have to reserve hardware resources for receiving/transmitting that RAT signal. We claim that the reconfiguration procedure of deactivating a particular RA and its corresponding hardware resources, shown in Fig. 4(a), will be necessary to optimize the power consumption in the signal environment described above. The reconfiguration procedure of Fig. 4(a) can be summarized as follows.
Step x: The Monitor acknowledges the MPM with the arrival/availability of new context information by transferring the ContextInfo message, which includes the address of its memory where this context is stored. With this context information, the MPM decides to deactivate the RA #2 and its corresponding RF chain.
Step y: The MPM transfers the DeactivateRAReq command, which includes the identification of RA #2 to the RCM to deactivate RA #2. As the transfer of the DeactivateRAReq signal comes from the CSL and RCF, it is performed via the MURI using the access control service of the MURI discussed in Subsection II. A.
Step z: The RCM executes the DeactivateRA operation on the ROS to deactivate RA #2.
Step {: RA #2 transfers the StopStreaming signal, which includes the identification of RF chain #2, to the RF transceiver to deactivate the receive/transmit streaming of RF chain #2.
Step |: RF chain #2 terminates the receive/transmit streaming and acknowledges the termination to the RA #2 by transferring the StopStreamingCnf message, which includes its identification.
Step }: The RCM transfers the DeactivateRACnf message, which includes the identification of the RA #2 to the MPM using the MURI. Fig. 4(b) illustrates a sequence diagram of a reconfiguration procedure for activating a particular (set of) RF chain(s) for a specific URA to exploit all the available antenna resources in the MIMO mode. The MD can opportunistically exploit the unused antenna resource(s), i.e., RF chain #2 in this example, for a specific RA, i.e., RA #1 in this example, to switch its configuration from the SISO mode to the MIMO mode. As in the example in Fig. 4(a), it is assumed that the reconfigurable MD shown in Fig. 4(b) is equipped with the basic set of ETSI-standard architectural elements discussed in Section II. The objective of this reconfiguration procedure, which changes the MD configuration from SISO to MIMO using the unused antenna resource(s), is to optimize the link performance by increasing the total throughput and/or decreasing the packet error rate. The reconfiguration procedure shown in Fig. 4(b) can be summarized as follows.
Step x: The Monitor acknowledges the MPM with the arrival/availability of new context information by transferring the ContextInfo message, which includes the address of its memory where this context is stored. If unused RF chain(s) are found from this context information, then the MPM decides to activate an MIMO mode for a specific RA to opportunistically exploit the corresponding RF chain(s).
Step y: To change the MD configuration from SISO to MIMO mode (which can be either spatial multiplexing, beamforming, or diversity), the Administrator transfers the RAParamsChangeReq command to the CM in the RCF. As the transfer of the RAParamsChangeReq command goes from the CSL to the RCF, it is performed via the MURI using the administrative service of the MURI discussed in Subsection II. A.
Step z: Upon receiving the RAParamsChangeReq command from the Administrator through the MURI, the CM executes the reconfiguration command on the ROS, which includes the activation of RF chain #2 for receiving/transmitting the RAT #1 signal with RA #1 and changing the transmission mode of RA #1 from SISO to MIMO.
Step {: To receive/transmit the RAT #1 signal in the MIMO mode with RF chain #1 and RF chain #2, RA #1, which is operating only in the SISO mode with RF chain #1, transfers the StartStreaming signal to RF chain #2. The StartStreaming signal includes the identification of RF chain #2 and the RF parameters of the RAT #1 signal, such as the center frequency, bandwidth, and transmit power.
Step |: RF chain #2 starts receiving/transmitting the RAT #1 signal with the RF parameters of the RAT #1 signal by executing the Streaming operation.
Step }: RF chain #2 transfers the StartStreamingCnf message to RA #1 to confirm the beginning of data streaming with RA #1. The StartStreamingCnf message includes the identification of RF chain #2 and the RF parameters of the RAT #1 signal. Step~: RA #1 changes its configuration from SISO to MIMO.
Step : The CM acknowledges the completion of the MD reconfiguration by transferring the RAParamsChan-geReqCnf message to the Administrator.
The key part of the ETSI-standard architecture applied in our examples is that the application processor can manage the radio platform without having to consider platform-specific application programming interfaces (APIs). Consequently, using the ETSI-standard architecture, the reconfiguration command generated with non-radio and radio context(s) in the application processor operating in the non-real time domain can efficiently be executed to control the MD configuration in the radio platform operating in the real-time domain. By adopting radio and non-radio contexts, the MD reconfiguration can always be selected in such a way that the desired KPIs are optimized.

III. IMPLEMENTATION OF AN ETSI-STANDARD RECONFIGURABLE MD PROTOTYPE ADOPTING BOTH RADIO AND NON-RADIO CONTEXTS
This section introduces an implementation of an ETSI-standard reconfigurable MD prototype employing an RF transceiver with a 2-antenna system. As the proposed MD adopts non-radio and radio contexts for generating its reconfiguration command, the objective is to opportunistically exploit the antenna resources for a specific RA during the period when the context information (based on radio and non-radio contexts) selects that specific RA. The RCF can efficiently execute the reconfiguration command transferred from the CSL by borrowing the double-layered structure consisting of the CSL and RCF introduced in the ETSI-standard architecture [22], although the CSL and RCF operate in non-real time and real time, respectively. As discussed in VOLUME 8, 2020 Section II, to avoid major disruptive steps in the prototype implementation, the proposed reconfigurable MD prototype includes essential entities required only for the minimum set of reconfiguration capabilities specified in the preceding section. Fig. 5(a) illustrates a block diagram of the implemented ETSI-standard reconfigurable MD prototype system, whereas Fig. 5(b) presents a photograph of the corresponding system. The implemented prototype system shown in Figs. 5(a) and (b) is based on the reconfigurable MD architecture reference model shown in Fig. 2, employing the minimal set of architectural elements discussed in Section II.
As shown in Fig. 5(a), the implemented prototype system consists of two main parts, the application processor and radio computer. The former includes the CSL, containing the Administrator, MPM, Networking Stack, and Monitor, which operate on Ubuntu 16.04 LTS, a non-real-time OS. The latter consists of three layers: the ROS layer, radio platform driver layer, and radio platform layer. The ROS layer includes two ROSs, Texas Instruments Real-Time OS (TI-RTOS) Kernel 6.45.5.55 and Linux Kernel 4.4. The two URAs, a Long-Term Evolution (LTE) [23] URA and a wireless fidelity (Wi-Fi) [24] URA, implemented for our prototype system, operate on the RCF, which is part of the TI-RTOS Kernel 6.45.5.55, i.e., a real-time OS. The two RATs, LTE and Wi-Fi, are selected as URAs in the implemented MD because they are the most typical RATs for the cellular network and wireless local area network, respectively. The radio platform driver layer includes a USRP hardware driver and a TI-RTOS driver. The former is for the Linux Kernel 4.4 to access the RF transceiver, whereas the latter is for the TI-RTOS Kernel 6.45.5.55 to access the baseband processor. The Linux Kernel 4.4 executes the transfer of the RF parameters from the CSL to the RF transceiver via the 10 gigabit Ethernet (10GbE). The Linux Kernel also executes the transfer of the transmitted/received data of the RF transceiver from/to the external memory via the 10GbE. The TI-RTOS Kernel 6.45.5.55 executes the transfer of the transmitted/received data between the external memory and baseband processor via the PCI express (PCIe) interface. The radio platform layer includes three entities: the baseband processor, RF transceiver, and antennas.
In the hardware perspective, the entire system consists of four parts, namely, the CPU, modem, RF transceiver, and antennas, which are implemented with i5-5820K, TMDEVM6670L [16], USRP X310 [17], and VERT2450, respectively. These parts are denoted in blue, red, yellow, and green colors in Figs. 5(a) and (b), respectively. In our prototype system, the three core entities (i.e., CM, RCM, and FC) in the RCF are implemented on the TI-RTOS Kernel 6.45.5.55 to support the minimal set of reconfiguration capabilities discussed in Section II. Fig. 5(a) also shows that the RCF in the radio computer is interconnected to the CSL in the application processor via the MURI, such that the reconfiguration command generated from the CSL is transferred to the RCF via the MURI.
Regarding the RA, which is denoted as the URA after it is downloaded onto the radio computer, as shown in Fig. 5(a), we prepared an LTE RA code and a Wi-Fi RA to set up the configuration of the DSP-based baseband processor and to convey the corresponding RAT signals. Table 2 shows the system parameters of each RAT signal of the corresponding URA.
The variable RF parameters for the USRP X310 include the center frequency, bandwidth, and transmit power gain [17]. The USRP X310 can transmit/receive two independent signals of different frequency bands using two independent RF chains. It supports the 2.4-2.5 GHz and 4.9-5.9 GHz bands at each antenna port, which is connected with VERT2450 omnidirectional antennas in our prototype system. In order to provide the SISO mode, each of the two antennas and corresponding RF chains is respectively assigned to the LTE and Wi-Fi. On the other hand, for supporting the LTE 2 × 2 MIMO mode, all the two antennas and corresponding RF chains are assigned solely for the reception/transmission of the LTE 2 × 2 MIMO.
In the following subsections, we explain how the RA codes of the LTE and Wi-Fi are implemented using the DSP-based  baseband processor in the radio computer. In the implementation of the RA code, as the most critical part is to satisfy the real-time constraint required by the LTE and Wi-Fi protocols, the key effort is focused on how to exploit as many as possible computational resources available in the DSP (TMS320C6670) in the most efficient way. Fig. 6 illustrates a block diagram showing the mapping of functional blocks in the LTE and Wi-Fi RATs into the DSP computational resources. Particularly, it shows how the physical downlink shared channel (PDSCH) decoding and data field decoding, the most time-consuming physical layer procedures in LTE and Wi-Fi, respectively, are processed using the computational resources available in the DSP (TMS320C6670). As the LTE and Wi-Fi RATs are based on an orthogonal frequency division multiplexing (OFDM) scheme, the two procedures shown in Fig. 6 are quite similar to each other, except that the LTE employs the turbo decoder coprocessor 3 (TCP3D), whereas the Wi-Fi employs the Viterbi decoder coprocessor 2 (VCP2), due to different channel coding methods in each RAT. As the DSP provides another coprocessor, a bit rate coprocessor (BCP), as an LTE-specific bit processing module, the procedure of software demodulation, descrambling, and rate de-matching can be processed using the BCP. Meanwhile, because the DSP does not provide a specific coprocessor for the Wi-Fi RAT, the decoding of the Wi-Fi signal, which includes software demodulation, de-interleaving, and rate de-matching, should be performed using a programmable resource instead of using the BCP. In addition, as the BCP of the TMS320C6670 DSP is optimized for LTE downlink encoding and LTE uplink decoding only, it cannot be used directly for downlink decoding or uplink encoding [16].

A. UTILIZATION OF COPROCESSORS
As a part of uplink decoding, the channel de-interleaving, demodulation, and descrambling of the LTE physical uplink shared channel (PUSCH) is performed using the soft slicer (SSL), a sub-module inside the BCP. Different from PDSCH decoding, PUSCH decoding includes the channel de-interleaving procedure. Fig. 7 shows how the BCP prepared for LTE PUSCH decoding can be used for LTE PDSCH decoding [25].
As the SSL of the BCP is originally prepared for PUSCH decoding, we should first convert the PDSCH subframe structure into the PUSCH subframe structure, as shown in the left-most box in Fig. 7. Consequently, the SSL sub-module of the BCP is activated with the PDSCH data after converting its subframe structure into the PUSCH subframe structure. Because the SSL sub-module performs the channel de-interleaving, as shown in Fig. 7, the reverse function (i.e., PUSCH channel interleaving) is performed using the enhanced direct memory access (EDMA) module [16] presented in Fig. 7. Then, rate de-matching is performed at another sub-module of the BCP, denoted as BCP (RD) in Fig. 7. Through the procedure described above, the BCP, which is originally prepared for PUSCH decoding, can be used for PDSCH decoding.

B. UTILIZATION OF LOOK-UP TABLES
When the same data are to be used repeatedly, unnecessary data generation can be avoided by generating and storing VOLUME 8, 2020 the data in a look-up table (LUT) to use them during the runtime. For example, in the case of Wi-Fi, the pilot data for channel estimation and/or the scrambling sequence for descrambling can be generated and stored in memory as an LUT before the activation of the Wi-Fi URA. The objective is to save execution time, which will otherwise be required for generating the data repeatedly. Whenever the pilot data or scrambling sequence is needed from the LUT, the data are loaded onto the L2 cache memory via the EDMA to be used in the corresponding arithmetic operation.

C. UTILIZATION OF THE EDMA MODULE
The EDMA module [16] is used to support data transfers from the external memory, i.e., the DDR3 DRAM, to the internal memory, i.e., the L2 SRAM, or from the shared memory to the L2 SRAM. The EDMA module enables the data transfer by specifying the memory address of the desired data transfer in advance of the runtime. The EDMA in our prototype system is used for the layer de-mapping (Fig. 6), for the PUSCH interleaving (Fig. 7), or for transferring the LUT from the DDR3 DRAM (i.e., external memory) to the L2 cache (i.e., internal memory).

D. UTILIZATION OF DSP INTRINSIC FUNCTIONS
For the physical layer processing of the LTE and/or Wi-Fi, a large number of complex-valued arithmetic operations, including complex-valued vector/matrix computations, is required. Complex operations corresponding to those functions can be optimized in accordance with the given DSP hardware by providing some frequently or necessarily used functions as intrinsic functions. As for the TMS320C6670 [16], the intrinsic functions are directly mapped into some special functions that are optimized in the C programming language. Intrinsic functions can be simply called as an ordinary function call. For instance, for the channel estimation shown in Fig. 6, the intrinsic function _complex_mpysp enables the complex conjugate multiplication of the reference signal (or pilot signal) to the fast Fourier transform (FFT)'ed received signal for each of the four-instruction cycles.

IV. EXPERIMENTAL RESULTS
This section presents the experimental results obtained from our prototype system implemented with the architecture shown in Figs. 5(a) and (b). First, we show the overall performance of the implemented system employing the LTE and Wi-Fi RA codes. Then, we present the experimental RF test results obtained from an indoor signal environment to verify the effectiveness of our prototype system. In addition to the experimental tests, we also present computer simulation results at the end of this section for verifying the excellent performance of our prototype MD adopting radio and non-radio contexts in fixed indoor and mobile outdoor environments.

A. OVERALL PERFORMANCE OF THE IMPLEMENTED RA CODES
Figs. 8(a) and (b) illustrate the mapping of functional blocks in each RAT into the multi-core DSP for the implementation of the LTE and W-Fi RA codes, respectively. In Fig. 8, for the functional blocks using coprocessors or the EDMA module, we have specified the utilized hardware resource of the DSP. The other functional blocks that do not employ coprocessors or the EDMA module are executed on the programmable resources, i.e., the DSP cores. For LTE and Wi-Fi, Core 0 is used to receive the data from the RF transceiver (USRP) via the PCIe interface into the DSP. The other cores are employed for decoding the corresponding RAT signals. The LTE and Wi-Fi RA codes are executed using every core in parallel with the processing order set as a pipeline in the order of Core 0, Core 1, Core 2, and Core 3.
In the case of LTE RA code execution, the received signal at Core 0 is first processed for the operation of the FFT and channel estimation/equalization at Core 1. Then, Core 1 finishes decoding the control channels, which includes the physical broadcast channel (PBCH), physical control format indicator channel (PCFICH), physical hybrid ARQ indicator channel (PHICH), and physical downlink control channel (PDCCH). As the payload length of the control channel is much shorter than that of the data channel, all the decoding procedures for the control channel, including demodulation, rate de-matching, descrambling, and channel decoding, are performed within the DSP Core 1 (i.e., a programmable core) instead of using coprocessors. On the basis of the control information decoded at Core 1, Core 2 and Core 3 decode the data channel PDSCH. Core 2 performs the soft demodulation and de-scrambling operations using the SSL sub-module of the BCP and the rate de-matching operation using the RD sub-module of the BCP, as mentioned earlier. In Core 3, the turbo decoding and cyclic redundancy check (CRC) are performed using the TCP3D. As explained in the preceding section, to perform PDSCH decoding using the BCP, originally prepared for PUSCH decoding, Core 2 performs PUSCH de-interleaving at the beginning stage of the SSL sub-module.
In the case of Wi-Fi RA code execution, the data received at Core 0 are first processed for the operation of the FFT and channel estimation/equalization at Core 1. Then, Core 2 performs the soft demodulation, de-interleaving, and rate de-matching, after which Core 3 performs the Viterbi decoding and descrambling. The multi-core pipelining shown in Fig. 8(b) can be applied to decode the Wi-Fi data fields corresponding to LTE PDSCH and the Wi-Fi signal field corresponding to the LTE PDCCH. Table 3 shows the processing time required for each functional block of LTE and Wi-Fi RA code implemented in our prototype system. Considering that the processing time can be measured differently depending upon the transmission scheme, modulation scheme, and/or coding rate involved at each RAT, we measure the processing time of each functional block based on the configuration shown in Table 2. The configuration for the LTE and Wi-Fi RATs shown in Table 2 is determined in such a way that the maximum throughput of 3GPP Release 11 and IEEE 802.11ac, respectively, is provided. For the values shown in Table 3, the processing time for each functional block of the LTE and Wi-Fi RA codes is computed as an average value from approximately 100,000 measurements.
In the case of the LTE RA code shown in Table 3 (a), the processing time for the configuration of 2 × 2 MIMO is longer than that for 1 × 1 SISO because there are two independent data streams to be processed in the case of MIMO. Moreover, the processing time of the channel estimation and equalization functional block for the case of MIMO is increased by approximately 3.8 times compared with the case of 1 × 1 SISO due to the channel estimation for the four channels of the 2 × 2 MIMO system. On the contrary, because the DSP provides three FFTCs and three TCPs, which are the coprocessors supporting the FFT operation and turbo decoding, respectively, the corresponding processing time for the MIMO configuration is not increased much as compared with the case of SISO, although the amount of data to be processed is nearly doubled. In the case of BCP, however, because the DSP provides a single BCP only, the processing time for using the SSL and RD sub-modules of the BCP in the MIMO configuration is nearly doubled compared with the case of SISO. After all, as the total processing time for SISO and MIMO, shown in Table 3 (a), is much less than 1 ms, our LTE RA code implemented in the prototype system fulfills the real-time constraint of a 1 ms transmission time interval (TTI) period.
In the case of the Wi-Fi RA code shown in Table 3 (b), the processing time for each functional block is presented for the SISO configuration only because our prototype system does not support the MIMO. First, the Viterbi decoding, which is the most critical bottleneck in real-time processing of Wi-Fi RAT, is performed using the four VCPs provided in the DSP. Borrowing the merit of the parallel processing of each four-symbol unit with the four coprocessors, the processing time for the VCP to perform the Viterbi decoding for each of the four-symbol units is quite comparable to that required to support a single OFDM symbol. The processing time for each four-symbol unit for the Viterbi decoding turns out to be 2.2 us, whereas that for a single OFDM symbol is 1.87 us. Meanwhile, as the DSP provides three FFTCs, the FFT/IFFT operation for the four-symbol unit is performed using the three FFTCs in parallel too. Other than the FFT and Viterbi decoding, all the other procedures for processing the four-symbol unit take about four times longer than the case of processing a single symbol because all the other procedures should be performed using the programmable core instead of using multiple coprocessors in parallel.
As the processing time shown in Table 3 (b) is for processing each four-symbol unit, the average processing time for a single OFDM symbol can be found to be 1/4 of that value. Consequently, the total processing time for our prototype system to process each Wi-Fi symbol is much less than one symbol duration, i.e., 4 us, which means that the implemented prototype system fulfills the real-time constraint of IEEE 802.11ac.

B. EXPERIMENTAL RF TESTS IN AN INDOOR LAYOUT
In this subsection, we present some experimental RF tests performed in an indoor layout. The test scenario is set up to optimize the desired KPIs, such as throughput and/or power consumption, by opportunistically operating the antenna resources of the prototype MD system in the indoor signal environment. The key point of the implemented MD system is that the architecture of the prototype MD system is based on the ETSI-standard structure shown in Fig. 5(a), such that the double-layered structure consisting of the CSL and RCF allows non-radio and radio contexts to be adopted to determine the modem configuration of the prototype MD system. Using the non-radio contexts, such as location information, usage habit, and historical pattern, and radio contexts, such as signal power and packet error rate, the reconfigurable MD system opportunistically utilizes its entire antenna resources in such a way that the desired KPIs are optimized. Fig. 9 illustrates the layout of the indoor experimental environment with a dimension of 18,700 mm × 7,500 mm. Fig. 10 is a photograph showing the experimental environment. The view of Fig. 10 is taken from the center between the LTE small cell base station (SBS) and test point B in the direction of test point A. As shown in Figs. 9 and 10, the two-antenna system of the LTE SBS is located at a height of approximately 2.7 m, whereas the Wi-Fi AP is located at about the same height in the external corridor. Both systems radiate signals with approximately 5 dBm transmit power. The implemented prototype MD system is located at either test point A or B with its antenna height at 1.6 m.

1) EXPERIMENTAL TEST SCENARIO
For our experimental tests, the minimum throughput required for the prototype MD system to initiate the data reception is arbitrarily set to 30 Mbps. Test point A is located inside a glass booth with non-line-of-sight (NLOS) paths from the LTE SBS and Wi-Fi AP. The location of test point B is given a line-of-sight (LOS) path from the LTE SBS with a NLOS path from the Wi-Fi AP.  In the following subsection, the prototype MD system is operated at test points A and B to present the performance of the prototype MD system, of which the configuration is determined by radio and non-radio contexts through the procedures introduced in Figs. 4(a) and (b).

2) EXPERIMENTAL RESULTS
Figs. 11 and 12 illustrate the RSSI as a function of time and the cumulative distribution function (CDF) of the RSSI measured for the two RATs at test points A and B, respectively. The data shown in Figs. 11 and 12 are the historical RSSI patterns measured at test points A and B, which is a hybrid context information with radio (RSSI) and non-radio contexts (location). This hybrid context information is used to determine the configuration of the prototype MD when it is operated at test point A or B. To obtain this context information, the RSSIs of LTE and Wi-Fi are measured for 60 minutes with an interval of 10 ms at each test point. As will be described later, this hybrid context information is the most important context for opportunistically utilizing the antenna resources of the implemented MD prototype.
The horizontal distance of test point A from the LTE SBS and Wi-Fi AP is approximately 5 and 22 m, respectively. The RSSI values for LTE and Wi-Fi are measured at approximately −55 and −83 dBm, respectively. As shown in Fig. 11(b), test point A belongs to a coverage hole region for Wi-Fi data reception because the probability for the Wi-Fi RSSI level to exceed −82 dBm (i.e., the minimum RSSI required for the reception of Wi-Fi with the lowest modulation and coding scheme value) is even lower than 20% [24].
The horizontal distance of test point B from the LTE SBS and Wi-Fi AP is approximately 12 and 7 m, respectively. The RSSI values for LTE and Wi-Fi were measured at approximately −58 and −65 dBm, respectively. Moreover, the RSSI level for the LTE signal measured at test point B does not fluctuate as do the values measured at test point A because of the LOS path existing between test point B and the LTE SBS. As for test point B, although the LTE RSSI value is approximately 7 dBm higher than that of Wi-Fi, the data throughput of Wi-Fi is rather higher than that of the LTE because our prototype system operates LTE and Wi-Fi with 10 and 20 MHz bandwidths, respectively. The superiority of Wi-Fi in terms of throughput still remains even with 2 × 2 MIMO and 1 × 1 SISO being applied to LTE and Wi-Fi, respectively. The main reason for this is that the Wi-Fi VOLUME 8, 2020 RSSI value at test point B, although it is weaker than the LTE RSSI value, is high enough to employ the 256 QAM for the Wi-Fi signal, where the highest modulation order for the LTE of Release 11 is 64 QAM, as shown in Table 2. In general, the RSSI value conveys the possible maximum modulation order and coding rate for each RAT. Thus, the throughput can be roughly estimated from the RSSI value for each RAT [26].
Next, we compare our prototype MD system, which adopts radio and non-radio contexts for determining its configuration with another MD that uses radio contexts only at test points A and B. For an ordinary MD using radio context(s) only, whether it is located at test point A or B, LTE and Wi-Fi signals should be received consistently to decide which of the two RATs is more appropriate for the MD configuration. More specifically, the ordinary MD using radio context will only keep utilizing one of the two antenna resources on detecting the Wi-Fi signal strength, even in the situation where the current location, e.g., test point A, corresponds to a coverage hole for the Wi-Fi signal. As for test point B, an MD adopting radio contexts only and the other MD adopting radio and non-radio contexts will select Wi-Fi not LTE, although the LTE strength is higher than the Wi-Fi strength. The reason is, as discussed above, the RSSI levels of LTE and Wi-Fi detected from each of the two antennas at test point B show that the average throughput will be maximized by the Wi-Fi RAT, even with the 1 × 1 SISO mode. The superiority of the MD adopting radio and non-radio contexts in the signal environment at test point B is that the hardware resources corresponding to the unused RAT can be turned off, whereas the MD adopting radio context only has to keep detecting the radio context of LTE and Wi-Fi consistently.
With the radio and non-radio context information discussed above, the operation of the prototype MD system at test point A can be summarized as follows. First, using the location information transferred from the positioning sensor, the prototype MD system recognizes that the system is at present located at test point A. In addition, the prototype MD is informed from its Monitor entity of the CSL that the current position is in the Wi-Fi coverage hole. Furthermore, usage habit, a non-radio context information stored at the Monitor, shows that the MD system will stay at the present position, test point A, for quite a long time, once the system gets to this point. According to all the hybrid context information, as soon as the MD system is in the area of test point A, the prototype MD system first deactivates the execution of the Wi-Fi URA and corresponding RF hardware resource(s) through the procedure introduced in Fig. 4(a) of Subsection II. B. As a result of deactivating the Wi-Fi URA and its corresponding RF transceiver chain, the prototype MD operates with a single antenna in the LTE mode. Thereafter, because the required cutoff throughput, i.e., 30 Mbps, cannot be achieved with the 1 × 1 SISO of LTE, the deactivated RF chain and antenna resource are activated for the 2 × 2 MIMO configuration mode of the LTE through the procedure shown in Fig. 4(b) to use all the RF hardware resources as the 2 × 2 MIMO mode for the LTE RAT.
Similarly, when the prototype MD is in the area of test point B, the operation of the prototype MD can be summarized as follows. First, using the location information transferred from the positioning sensor, the prototype MD system recognizes that the system is presently located at test point B. Then, the prototype MD discovers that the user will stay in this area for quite a long time and that Wi-Fi will provide a higher throughput even with 1 × 1 SISO using the context information from the Monitor. In accordance with this context information, the prototype MD deactivates the LTE URA and its corresponding RF resource(s) through the procedure shown in Fig. 4(a) to optimize the KPI regarding the power consumption. Consequently, the prototype MD operates with 1 × 1 SISO for the Wi-Fi RAT, once it is in the area of test point B.
Figs. 13(a) and (b) illustrate the throughput performances measured at test points A and B, respectively, for 10 minutes according to the various MD configurations. In Figs. 13(a) and (b), the first two (left-hand side) results are reference results that are given for the purpose of comparison with the third and fourth results obtained from the MDs using the radio context only and radio and non-radio contexts, respectively.
The throughput performance shown at the third position (from the left-most side) in Fig. 13 is obtained from the MD adopting the radio context only. Thus, the RAT is selected according to the instantaneous RSSI value in our prototype system. As mentioned earlier, the RSSI value explicitly conveys the possible maximum modulation order and coding rate for each RAT, such that the expected throughput can roughly be estimated from the RSSI value [26]. The performances shown at the fourth position in Fig. 13 are obtained from the MD, which adopts radio and non-radio contexts for determining its modem configuration. As mentioned earlier, this MD sets up its configuration in such a way that the desired KPIs, such as power consumption and/or throughput, are optimized through the procedures shown in Fig. 4(a) and/or (b), respectively. First, the throughput results shown at the first and second (from the left-most side) positions in Fig. 13(a) are obtained when the configuration of the MD is fixed with Wi-Fi and the LTE RAT, respectively, at test point A. As mentioned earlier, test point A corresponds to the coverage hole for the Wi-Fi RAT, such that its data, for which the throughput is presented at the left-hand side position of Fig. 13(a), can either be received only with an extremely low modulation and coding scheme (MCS) index or cannot be received at all. Consequently, the average throughput is even lower than 6.5 Mbps, which corresponds to the throughput with the lowest MCS index. As for the second throughput result, representing the case that the MD configuration is fixed with the LTE RAT, the throughput does not exceed the cutoff value of 30 Mbps, mainly because test point A is blocked with a glass booth from the LTE SBS in our test signal environment. The third result represents the throughput performance obtained from an MD adopting radio context information only, i.e., the instantaneous RSSI value. As the Wi-Fi RSSI level at test point A is extremely low in our signal environment layout, the VOLUME 8, 2020 configuration of the MD is eventually fixed to the LTE RAT, which results in exactly the same performance shown in the second case. Finally, the fourth result shown in Fig. 13(a), representing the case of the proposed MD adopting radio and non-radio context information, is obtained by driving the MD through the procedure shown in Fig. 4(a) and (b) in Subsection II. B. In other words, when the MD is in the region of test point A, the Wi-Fi URA and its corresponding hardware resources are deactivated through the procedure of Fig. 4(a) and the deactivated hardware resources are used for the selected LTE RAT to have the MD operate in the 2 × 2 MIMO mode, through the procedure shown in Fig. 4(b). By allocating the unused hardware resources to the selected RAT, such that the LTE RAT is set to operate in the 2 × 2 MIMO mode, the total throughput becomes much higher than the cutoff value of 30 Mbps.
Next, the throughput performances shown at the first and second (from the left-most side) positions in Fig. 13(b) represent the average throughput obtained when the implemented MD operates in the LTE SISO and LTE 2 × 2 MIMO modes, respectively. Here, neither the LTE SISO nor the LTE 2 × 2 MIMO provides the cutoff throughput of 30 Mbps at test point B. The performance shown at the third (from the left-most side) position in Fig. 13(b) represents the average throughput when the prototype MD is set to select one RAT out of the two using the instantaneous RSSI value (radio context) only. Meanwhile, the fourth (from the left-most side) position in Fig. 13(b) shows the average throughput observed from the prototype MD, which is set to determine its configuration using radio and non-radio contexts. As discussed earlier, the method of adopting either radio context only or the radio and non-radio contexts drives the prototype MD to select the Wi-Fi RAT to achieve as high as possible throughput under the given RSSI level. Consequently, the third (i.e., the case of adopting the radio context only) and fourth (i.e., the case of adopting radio and non-radio contexts) cases exhibit the same throughput because both cases select the Wi-Fi RAT. In this situation, the proposed MD can optimize the KPI regarding the power consumption by deactivating the hardware resources that are occupied by the unused LTE RAT through the procedure described in Fig. 4(a). In the case of the MD that adopts radio context only, the hardware resources corresponding to the LTE RAT, i.e., not selected at test point B, and the Wi-Fi RAT, i.e., selected, should continuously be activated. In the case of the MD that adopts radio context only, the RSSI levels of LTE and Wi-Fi should continuously be detected all the time to identify the RAT signal that provides the higher level of RSSI.

C. COMPUTER SIMULATIONS IN AN OUTDOOR LAYOUT
In the preceding subsection, we present the RF test results obtained from the two-antenna MD prototype, of which the configuration is determined by the radio and non-radio contexts in an indoor layout. The main purpose of this subsection is to verify the excellent performance of the proposed reconfigurable MD in mobile outdoor environments as well as in the fixed indoor environments presented in the preceding subsection.

1) SIMULATION SCENARIO
Fig. 14 illustrates an outdoor layout in a typical suburban area consisting of a parking lot (60 m × 80 m), 10-meterwide highway, and large buildings around the parking lot, and Table 4 shows the parameter values related to our simulations. It is assumed that an LTE MBS and Wi-Fi AP are installed at the top of a building located at the right-hand side of the highway and another building in the parking lot, respectively, as shown in Fig. 14.
As for the channel modeling, we use WINNER II-C1 propagation scenario for a suburban macrocell [27], whereas the LOS and NLOS propagation conditions are determined by the layout shown in Fig. 14. The layout is set up in such a way that ''Path 3'' is an NLOS path for the LTE MBS, whereas ''Path 1'' and ''Path 5'' are NLOS ones for the Wi-Fi AP. For simplicity but without loss of generality, it is assumed that there is no other MD but the target MD attached to the LTE MBS or Wi-Fi AP while the target MD is traveling along the trajectory of Paths 1, 2, 3, 4, and 5, as shown in Fig. 14. Furthermore, for LTE and Wi-Fi, the TTI is set to 1 ms.
According to the channel model, the received signal power at the mobile vehicle is determined during the time period for the vehicle to move along the trajectory of Paths 1 to 5. Once the received signal power is determined at every observation point along the target trajectory, the link performances, such as throughput and/or packet error rate, can be driven in accordance with a given set of environmental parameters, such as the transmit power from the base station, antenna type/gain, MD mobility, and noise power, as shown in Table 4 [28].
In our simulations, each scheduler in LTE MBS and Wi-Fi AP adaptively determines the MCS for the MD to adopt in such a way that the block error rate or packet error rate does not exceed 1% in a given SNR. Table 5 shows the latency required for the reconfiguration procedure to deactivate/activate a particular RA and  corresponding RF chain(s) in our implemented MD prototype. To compute the total latency for switching an RAT with another RAT, the processing times shown in Table 5 should be added up because the old RA and its corresponding RF chain should first be deactivated and the new RA and its corresponding RF chain should be activated. Here, it is assumed that all the potential RAs (i.e., LTE and Wi-Fi) are already loaded as URAs. Consequently, the RAT switching latency is approximately 22.63 (2.91 + 19.72) ms, which corresponds to approximately 23 TTIs. Hence, the prototype MD implemented in this paper cannot process data reception/transmission for approximately 23 TTIs whenever its configuration is switched from one to another.

2) SIMULATION RESULTS
Figs. 15(a) and (b) illustrate the throughput performances of the target MD while it travels along the trajectory of Paths 1 to 5, shown in Fig. 14. Fig. 15(a) presents the throughput when the configuration of the target MD is fixed with one of the Wi-Fi SISO or LTE SISO or LTE 2 × 2 MIMO modes, whereas Fig. 15(b) reflects the throughput to be achieved when the target MD adaptively switches its configuration according to the context information. Each point of through- put shown in Fig. 15 is obtained by averaging the values for every 100 TTI.
The results shown in Fig. 15 (a) are given as reference results for the purpose of comparison with the other results shown in Fig. 15 (b). The switching latency computed in Table 5 should not be considered in Fig. 15(a) because the configuration is fixed in this case. For the throughput computation of the MD shown in Fig. 15(b), whose configuration is adaptively switched in accordance with the radio and/or non-radio contexts, however, the reconfiguration latency, i.e., 23 TTIs, is considered in such a way that the receive/transmit data processing is suspended whenever the reconfiguration occurs.
First, when the configuration is fixed with Wi-Fi SISO in Fig. 15(a), the throughput is relatively very low because Paths 1 and 5 correspond to NLOS for the Wi-Fi AP. By contrast, the throughput becomes its maximum value for Paths 2, 3, and 4 because those paths all correspond to LOS for the Wi-Fi AP. Second, for the case of MD with its configuration fixed to LTE SISO in Fig. 15(a), the throughput remains very low for Path 3 because it is an NLOS path for the LTE MBS. For Paths 1, 2, 4, and 5, which correspond to LOS for the LTE MBS, however, the throughput becomes its maximum value. Lastly, for the case of LTE 2 × 2 MIMO in Fig. 15(a), the throughput is nearly twice higher than that of the LTE SISO due to the spatial multiplexing gain. Furthermore, because Paths 2 and 4 correspond to LOS for LTE MBS and Wi-Fi AP, the maximum throughput is provided for LTE SISO and Wi-Fi SISO, and the maximum throughput of the latter is much higher (approximately 55 Mbps) than that of the former (approximately 35 Mbps) because the bandwidth of the latter is about twice of that of the former.
As mentioned earlier, in the case of MD that adopts the radio contexts only, the configuration is determined in such a way that the expected throughput is maximized with the chosen RAT according to the RSSI level. Consequently, the MD adopting the radio context only will be attached to the LTE MBS for Paths 1 and 5 (which correspond to NLOS for the Wi-Fi AP) and to the Wi-Fi AP for Paths 2, 3, and 4. On the contrary, the MD adopting radio and non-radio contexts, its antenna resources can be utilized opportunistically in a predictive manner using the historical RSSI pattern, which is hybrid context information with radio (RSSI) and non-radio (historical movement pattern at each location). Moreover, the MD sets up its configuration with the LTE 2 × 2 MIMO by cognizing that Paths 1 and 2 correspond to LOS for the LTE MBS to maximize its throughput. Later, considering that Path 3 corresponds to NLOS for the LTE MBS and LOS for the Wi-Fi AP, the MD not only activates its hardware resources corresponding to Wi-Fi but also deactivates all its hardware resources corresponding to LTE, which can save power consumption. Then, for Paths 4 and 5, considering that they correspond to LOS for the LTE MBS, the MD goes for the LTE 2 × 2 MIMO for accomplishing the maximum throughput as for the previous case of Paths 1 and 2. Consequently, the MD adopting radio and non-radio contexts can determine its configuration with LTE 2 × 2 MIMO for Paths 1, 2, 4, and 5, accomplishing the maximum throughput, which cannot be realized by the MD adopting the radio context only. In addition, Path 3 saves the power consumption by deactivating its hardware resources corresponding to the unused LTE RAT. Our simulations show that the average throughput (58.3 Mbps) provided by the MD of adopting radio and non-radio contexts is approximately 15% higher than that of the one adopting the radio context only (50.8 Mbps).

V. CONCLUSION
A reconfigurable MD prototype system is implemented using a DSP and USRP as its modem and RF transceiver, respectively. The configuration of the implemented MD system is determined by non-radio and radio contexts such that hardware resources, especially the antenna resources, are opportunistically fully utilized to the selected RAT. The proposed prototype MD system can generate the configuration command from the application processor and efficiently execute it at the baseband processor through high-level abstraction of configuration-related operations by using the ETSI-standard architecture based on a double-layered structure comprising an application processor and a baseband processor, operating in non-real time and real time, respectively. Through the hardware implementation of a prototype multi-antenna MD system that opportunistically fully utilizes its antenna and RF resources to the selected RAT, we verified the effectiveness of the proposed prototype MD system whose configuration is determined by non-radio contexts (e.g., MD location and historical usage pattern) and radio contexts (e.g., RSSI and packet error rate). Our experimental RF tests also verified that the excellent performance of the prototype MD adopting radio and non-radio contexts is obtained by optimizing the desired KPIs, such as throughput and/or power consumption. Furthermore, computer simulations showed that the optimization of the desired KPIs are available in mobile outdoor environments as well as in the fixed indoor layout.