STRS: Space Telecommunication Radio System

• STRS is a modular space telecommunication radio system defined by a layered architecture that enables reconfigurable software-defined radio functionalities.
• It uses standardized APIs and interfaces like DDS, SQL, and UHD to ensure seamless interoperability across diverse hardware platforms and waveform components.
• The system demonstrates effective closed-loop calibration, achieving target SNR within minimal iterations, thereby enhancing adaptive waveform control in space communications.

The Space Telecommunication Radio System (STRS) is a modular architecture and interface standard developed to address the requirements of adaptable, reconfigurable, and platform-agnostic software-defined radios (SDR) in space telecommunication contexts. Originating from NASA Glenn Research Center (GRC), STRS enables disparate waveform components—potentially spanning FPGAs, general-purpose computers, and embedded processors—to interoperate using a well-defined application programming interface (API) structure. The STRS design, as instantiated in adaptive SDR testbeds such as that by Xiong et al., emphasizes a layered decomposition of the end-to-end radio stack and prescribes a minimal, standardized API to maximize reusability, extensibility, and hardware-independence (Xiong et al., 2017).

1. Layered STRS Reference Architecture

The STRS architecture divides the radio system into four principal layers, fostering clear module interfaces and facilitating platform-agnostic component development. Control, signal processing, hardware abstraction, and physical interfacing are each encapsulated within a distinct subsystem, interconnected by robust data and control interfaces.

Server / Controller GUI (Java) │ (commands, scenario-definition) ▼ DDS (Data Distribution Service) PHY Processing (Matlab) │ (waveform generation, coding, framing, modulation) ▼ Database (MySQL) GNU Radio HW Control Layer (C++/Python) │ (parameter setup, buffer I/O) ▼ UHD (USRP Hardware Driver) USRP RF Front-End + Antenna

A feedback path is simultaneously maintained: USRP → GNU Radio → Database → PHY → Server, enabling closed-loop calibration and status reporting (Xiong et al., 2017).

2. Functional Decomposition of Components

2.1 Controller GUI / Scenario Server

Implemented in Java, this module manages scenario definition and system orchestration, serving as the human-in-the-loop interface. It configures multi-node SATCOM environments—specifying nodes (terminals, hubs, jammers), carrier settings, bandwidths, target SNRs, and ACM policies—and synchronizes modules by publishing configurations and polling for system feedback via the Data Distribution Service (DDS).

2.2 PHY Processing Layer

Typically implemented in Matlab, this layer is responsible for waveform library execution (including DVB-S2 mode/codes), channel coding, framing, modulation, and pulse shaping. It translates high-level scenarios (e.g., “QPSK-½ at 2 MHz BW”) into streams of I/Q baseband samples and RF configuration parameters (center frequency, sampling rate, gain/target SNR). These outputs are written to a MySQL database, separated as TX_Data (baseband buffers) and TX_Config (control metadata).

2.3 GNU Radio Hardware Control Layer

Running as a set of modular C++/Python GNU Radio blocks, this layer reads configuration commands from the database for the relevant USRP serial. It configures the RF front end (through the UHD API), streams baseband I/Q buffers, and writes measurement feedback (RSSI, SNR) back to the database for further processing.

2.4 USRP RF Front-End

Comprising Ettus USRP family devices (e.g., N210) under UHD control, this hardware block up/down-converts between baseband and RF, handling all DAC/ADC operations and antenna interfacing.

3. The STRS “Standard API”

STRS specifies a streamlined API which all waveform and hardware modules implement. Communication primitives are serialized via DDS (for control) and SQL (for waveform and feedback buffers), while UHD network interfaces provide real-time RF streaming.

Minimal STRS API calls include:

API Call	Input/Output	Functionality
strsInstantiate	char* role, char* instance_name	Instantiate a waveform, return handle
strsInitialize	uint32_t handle, strsConfig_t* config	Configure waveform parameters
strsLoadWaveform	uint32_t handle, void* payload, size_t length	Load (enqueue) I/Q data
strsStart / strsStop	uint32_t handle	Activate or halt the transceiver
strsGetStatus	uint32_t handle, strsStatus_t* status	Obtain receiver metrics/state

Control primitives are transported through DDS topics, buffer and metric data through SQL tables, and I/Q streaming through UHD (Xiong et al., 2017).

4. Typical Workflow: Waveform Generation and Transmission

Operational control follows a tightly orchestrated sequence using the STRS API constructs:

1. An operator uses the Server GUI to instantiate a new terminal via strsInstantiate("TX","Term1").
2. The server configures with strsInitialize for desired waveform parameters (e.g., QPSK-½, 2 MHz, 2.2 GHz, 10 dB SNR).
3. The PHY block, notified via DDS, generates I/Q samples and writes TX_Data/TX_Config via strsLoadWaveform.
4. The GNU Radio layer polls TX_Config for matching USRP IDs, configures the UHD sink, and pulls sample buffers.
5. GNU Radio streams samples to the USRP device via UHD.
6. The USRP transmits the modulated signal via the physical antenna.
7. The receiver mirrors this control sequence, retrieving received samples, estimating $\widehat{\mathrm{SNR}}$.
8. The system uses strsGetStatus for metric feedback.
9. The server compares measured SNR to target, updating TX gain in the configuration.
10. The transmit-power/SNR calibration loop iterates until $$|\widehat{\mathrm{SNR}} - \mathrm{SNR}_{\mathrm{target}}| \leq 0.5$$ dB.

5. Closed-Loop Calibration and Performance Evaluation

Xiong et al. report performance with specific reference to link-level SNR calibration, rather than comprehensive throughput or BER quantification. The control loop uses the update rule:

$$P_{\mathrm{tx}}[n+1] = P_{\mathrm{tx}}[n] + \left(\mathrm{SNR}_{\mathrm{target}} - \widehat{\mathrm{SNR}}[n]\right),$$

where $P_{\mathrm{tx}}$ is the USRP gain setting in dB. SNR convergence to within 0.3 dB of the target is observed in under five iterations (Xiong et al., 2017). No complete end-to-end BER or throughput measurements are reported. The testbed illustrates adaptive response and effective system reconfiguration facilitated by the STRS architecture.

6. Significance of STRS and Extensions

STRS demonstrates the systematic decoupling of software radio functions and physical layers, leveraging standardized APIs for rapid prototyping, interchangeability, and scalability. The architecture supports multi-node SATCOM emulation and real-time adaptive waveform control. A plausible implication is that the modularity and abstraction present in STRS may accelerate cross-platform waveform deployment and algorithmic experimentation in radio communication research.

Further extensions could theoretically build on the reported modular testbed to integrate richer waveform sets, advanced adaptation policies, and networked multi-agent scenarios, guided by the STRS specification as implemented in the NASA GRC testbed (Xiong et al., 2017).