The Department of Defense (DoD), specifically the Navy, is seeking innovative solutions through the Small Business Innovation Research (SBIR) program for the development of a dynamic scheduler for digital signal processing (DSP) in software-defined radios (SDRs). The objective is to create a stable control module that can adapt in real-time to changing mission priorities and signal environments, allowing for efficient scheduling of DSP algorithms on commercial off-the-shelf (COTS) processing cards. This technology is crucial for enhancing the operational capabilities of RF systems, enabling rapid reconfiguration and processing of diverse signal classes in complex environments. Proposals are due by May 21, 2025, with the opportunity to participate in both Phase I and Phase II of the project, and interested parties can find more information at the official SBIR website.

## Description

The Department of Defense (DoD) has historically procured progressively optimized receivers for each distinct class of radio frequency (RF) system functionality. Software Defined Radios (SDRs) have increasingly become a deployed reality and the diversity of signal definitions each transmitter is capable of emitting increases with fewer and fewer limitations. Fortunately, each class of generic hardware processor (i.e., Central Processing Unit (CPU), Graphics Processing Unit (GPU), and Field Programmable Gate Arrays (FPGA)) has also become more capable of being used for hosting multiple copies of different algorithmic techniques running simultaneously. The notion of using only multi-functional receiver systems capable of being reconfigured to function differently for different signal classes reflecting their distinct functional foci is a natural consequence of these trends. The Navy now desires technology that enables RF system reconfiguration of functionality to be performed dynamically at unit levels in operational environments. If significantly sub-second time scales reprogramming of the processors can be achieved, adaptive and cognitive responses to even densely populated instantaneous signal environments become conceivable. However, the time taken to first optimize an initial Digital Signal Processing (DSP) task list and then to reprogram and/or reconfigure the available DSP processors for the selected set of tasks must be verifiably bounded because no computation can be performed during reconfiguration. Additionally, this reconfiguration time also adds to the processing latency and shortens the time available for cognitive response to the sensor output. Conversely, too short an interval between reprogramming events can both potentially lead to chaotic system behavior and disrupt signal analysis of complex signals mid-stream, leading to un-converged results and a sub-optimal use of processor time. This SBIR topic solicits vendors with experience in the control of task scheduling/resource management to devise a generic parameterized scheduler for DSP processing on a diverse set of generic COTS processor cards. Innovations that reduce latency in both the optimization of the laydown of DSP techniques onto the processors and the implementation of such laydowns are desired. The topic&rsquo;s goals are optimization of a scheduler for stable operation, for devoting less than 10% of real-time set-up for the next batch processing epoch, and for maximizing the total priority assigned to individual signals whose processing can be accommodated by the decided upon laydown of techniques onto the DSP processors during these epochs. This includes the general tasks of generating software/firmware coding to optimize the processing laydown; initiating the processing code laydown on the processors; coordinating the retrieval of cued In-Phase and Quadrature (I&amp;Q) data; and ensuring timely delivery of data to the designated processor card/node. (Notice that we assume each time-frequency bounding box worth of new signal data can be associated with a specific signal class and that such cues (i.e., boxes + signal ID) can be manipulated by the scheduler without having to move the actual I&amp;Q data from its temporary memory location until the DSP will begin.) It is also desirable for an output of the cues that will not be processed in the next epoch to be provided, along with a notation in the cue of such status. Either Vita 49.2 extension packets or Protobuf messages may be used for such cue enhancements. Given the complexity of this topic, proposers may begin with a set of simplifying assumptions to be replaced with the more complex reality in later phases. For example, one initial assumption might be that a given signal&rsquo;s priority will be fixed, independent of how many instances the signal has in a given epoch and in how many epochs it has occurred. Determining the length of an epoch in terms of Vita 49.2 packet durations and execution times of the DSP techniques is one of the underlying challenges that requires careful reasoning and experimental verification. Later methods for the scheduler to learn the processing times of each DSP technique rather than requiring pre-calibration is desirable. Whether any signal is of such high priority that its processing can be continued over multiple epochs in order to be completed must also be decided. A study is needed of the consequences of failing to converge on the optimal technique laydown before beginning processing, as well as how to detect such an event. The threshold system ingest bandwidth shall be 500 MHz and objective 4 GHz or more per channel, based on Analog to Digital Converters clocking at over 10 GHz. The intent for this topic is to develop contributions in scheduling DSP reconfigurations within an open, modular system. Use of Red Hat Linux and PCIE5 or higher is expected. Review of proposals will include evaluation of whether the proposed technologies will support explicitly open and modular systems. The work to be performed beginning in Phase I will be considered CUI and ITAR controlled. In the event development becomes classified prior to Phase III, the facilities clearance status of the vendor&rsquo;s workplace and proposed workforce needs to be included in the initial proposal. All Phase I work will involve strictly unclassified waveforms and DSP techniques. The class and manufacturer of processor cards from combinations of CPUs, GPUs, and FPGAs will be left to the vendor. However, during Phase II, if awarded, there is expected to be a task designed to transition the new module&rsquo;s code into a less specific hardware dependent code such as VHDL. The Government will disclose other details of the expected open systems architecture (OSA) receiver as appropriate throughout the period of performance. This software/firmware module will take a list of signals to be processed and schedule the proper digital signal processing algorithms onto COTS processing cards available within the same server and ensure the signal data arrives on actionable timelines.Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by 32 U.S.C. &sect; 2004.20 et seq., National Industrial Security Program Executive Agent and Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Counterintelligence and Security Agency (DCSA) formerly Defense Security Service (DSS). The selected contractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances. This will allow contractor personnel to perform on advanced phases of this project as set forth by DCSA and ONR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material during the advanced phases of this contract IAW the National Industrial Security Program Operating Manual (NISPOM), which can be found at Title 32, Part 2004.20 of the Code of Federal Regulations.

## Objective

Develop a stable control module for a wideband receiver that adapts in real time to changing mission priorities and the signal environment. This software/firmware module will take a list of signals to be processed and schedule the proper digital signal processing algorithms onto commercial off-the-shelf (COTS) processing cards available within the same server and ensure the signal data arrives on actionable timelines.

## Phase I

Design a concept for the scheduler&rsquo;s instruction set, needed inputs, and desired outputs. Conduct a preliminary design review (PDR) with the government sponsor. Describe approaches to both static and opportunistic reassignment of DSP techniques over COTS processors, then present a notional plan for doing rapid (sub-millisecond) dynamic reprogramming in an operational setting, defined in terms of the required components, with identification of technological component maturation and technical risks involved. Ensure that the technical approach addresses distinct cases of how many SOIs may be present and populated in the electromagnetic environment; for example, cases to consider include where it is not necessary to fully analyze every event of a specific signal class, when the execution time of each technique is not uniform, and how to minimize time wasted by processors being idle when the received environment is inherently sparse for a given signal class. Include a lab demonstration of the planned method on a synthetic sensor processor having one DSP processor and time varying numbers of signals with known/available DSP processing algorithms present. (Note: It is undesirable for the base demo to be limited to the case where the signal density is low enough to accommodate all the signals present. If so, this demonstration shall be extended in the option period, if exercised, to the case where not all the instances of signals present can be accommodated.) If the Phase I Option is exercised, improve upon the initial demonstration in a hardware realization. Prepare a Phase II plan.

## Phase II

Develop the design into a tangible realization and conduct a laboratory demonstration, possibly in simulation, of the desired reconfigurable DSP activity. Work to scale up the number of simultaneous DSP processes that can be stably managed of same and different sorts. Devise a scheme for dealing with waveforms that take a significantly longer time to completely process and how to optimize the system throughput and control the number of instances of a given signal to analyze out of every batch of occurrences. Expand the system to the case containing all 3 classes of mass market DSP processors and where a prioritized list of signals ready to be processed are presented to the scheduler module. (Note: This new module will then work with algorithms having different execution times and processing resource requirements.) Describe a conceptual calibration scheme. Provide an approach for an automated system to learn how much of an idle time margin must be given for maintaining stable system control. If the Phase II Option is exercised, work with the sponsor to define additional issues to address and participate in system level demos at U.S. based test events/ranges. Prepare a Phase III commercialization/transition plan. It is probable that the work under this effort will be classified under Phase II (see Description section for details).

## Phase III: Dual Use Applications

Participate in the development of Navy RF systems utilizing the delivered products and others running simultaneously from multiple vendors, consistent with the same system architecture constraints and interface definitions. Computationally intensive applications involving big data, such as voice recognition and speech processing utilized by emerging Artificial Intelligence applications and sensor fusion required for autonomous vehicles, require complex systems controls to prevent chaotic, continual reprogramming of the DSP resources to maximize impact of processing time.

Topic

Agency

Program

Topic Link

Additional Information