In defining the SA API, the SAWG decided to follow the model-driven architecture (MDA) approach. The main objective of MDA is to enable the portability and/or reusability of architectural models across different platforms[5]. In order to achieve this objective, a model should first be defined independently of a specific technology or implementation platform, with the resulting model referred to as a platform-independent model (PIM). Once the PIM is complete, the various functionalities defined by the model can then be mapped to a specific platform. This model is referred to as the platform-specific model (PSM).

Figure 2 illustrates the PIM of the SA API that has been developed by the SDR Forum's SAWG group. This PIM consists of three groups of facilities: SAControl facilities, SASynchronization facilities, and SAAlgorithm facilities. The SAControl facilities, shown in Figure 3, include the base SAControl component along with control interfaces for the RF/IF component and the other two groups of facilities. The SAControl inherits from the synchronization control interface, the algorithm control interface, and the RF control interface, allowing this component to control the RF/IF component, SASynchronization facilities, and the SAAlgorithm facilities as appropriate. The RFControl interface is designed to control multiple RF/IF components, since a smart antenna system inherently requires multiple RF chains.

The synchronization facilities of the SA API, illustrated in Figure 4, are for calibration. The SASynchronization component is realized by inheriting interfaces from calibration and latency as shown.

The algorithm facilities are used to execute all the algorithms for beamforming, DOA, channel estimation, spatial multiplexing, and STC. Figure 5 illustrates algorithm facilities. SAAlgorithmDevice is a core component of SASystem and parent component of all algorithm components. Because all algorithm components, such as SABeamformingDevice, SASTCDevice, SACEDevice, SASMDevice, and SADOAEstimationDevice, are generalized from the same parent component, i.e., SAAlgorithmDevice, a unified control interface can be provided.

The SAWG group has chosen the common object request broker architecture (CORBA) and extensible markup language (XML) as a target platform for the initial PSM of the SA API. Figure 6 illustrates a deployment diagram of SA API, showing how each component is deployed to a hardware device. The SAControl component, which performs mainly logical operations, is loaded into a GPP, while the SAAlgorithm and SASynchronization components, which require high-speed digital signal processing, are loaded into an FPGA or DSP as appropriate. Since CORBA for DSPs and FPGAs is not yet commonly used, adaptors are needed for SAAlgorithm and SASynchronization to bridge between the FPGA or DSP device interface and CORBA.

Previous 1 2 3 4 Next

RSS    Save to Del.icio.us  Digg This