The transceiver facility defines reference content for APIs to access a specific transceiver implementation from the baseband software.^[3] The facility is composed of “features,” with each feature corresponding to an elementary prime capability that may be implemented in a transceiver sub-system (Figure 2). The use of features in this manner allows the transceiver facility to easily scale to the needs of a specific transceiver implementation. Each proposed feature includes an extensive set of APIs and performance attributes that enable the radio developer to manage the various transceiver interfaces and characterize their performance. For instance, the feature “transmit” proposes a reference function to send the packets of baseband samples toward the transceiver, called pushBBSamplesTx, with associated performance attributes such as the expected sample rate and size of the samples packet.

The features are based on a certain number of “common concepts,” which are captured independently from the features themselves. Common Concepts have no content directly usable as API definition, but capture key radio-domain concepts on top of which the features are built. For instance, the notion of baseband signal power level is defined as a common concept that is used by the “receive” feature to characterize the nominal output level and the “AGC” feature to characterize signal level ranges for the AGC.

The transceiver development activity is built upon solid methodological foundations using the model-driven architecture (MDA) approach.^[4] The essential objective of this approach is to enable the portability and/or reusability of architectural models across different platforms. In order to achieve this, the transceiver facility must first be defined independent of any technology or implementation, with the resulting model referred to as a platform-independent model or PIM. Once the PIM is complete, the various functionalities defined by the model can then be mapped to a specific platform, creating what is referred to as a platform-specific model (PSM).

The transceiver facility can be used from either a waveform characterization viewpoint or a transceiver characterization viewpoint. From a waveform characterization viewpoint, each feature of the transceiver Facility provides a certain number of functions and performance attributes that are given specific waveform-dependent values. The subset of features necessary to support a given waveform is identified, and the values of the associated attributes are defined. For instance, for FM3TR one can state that for the transmit feature, the sampling rate shall be equal to 100 kilosamples per second (ksps), which is a value specific to the FM3TR waveform definition. The organization of the facility into features avoids the need to mandate unnecessary APIs for a given waveform, so the transceiver facility does not lead to overspecification.

From a SDR platform characterization viewpoint, the transceiver supports a number of waveform configuration states, which can be defined by referencing the waveform-specific characterizations that used the facility as exposed beforehand. Additionally, some features that would not be specific to a certain waveform can be captured thanks to direct usage of the facility in setting boundaries on the implementation, saying for instance that the carrier frequency may range from 2 MHz to 2 GHz independent from any other setting.

A flexible SDR transceiver is capable of accommodating the needs of different waveforms and switching between the configuration states needed for each supported waveform. A dedicated feature must harness the associatedreconfiguration needs, with the corresponding control functions proposed to the reconfiguration software. It is then sending the suitable reconfiguration commands to the transceiver through this management API, which can be product-specific or standard. The facility proposes the standard “Device“ interface (from SCA and OMG) as one possible solution.

Previous 1 2 3 Next