SEDR RFI Questions - Final.xlsx

XLSX spreadsheet 13 KB Posted Dec 8, 2025

Attached to: RFI - Enhanced Data Rate (SEDR) Waveform onto Operational Radios
Solicitation number: C3NK-SEDR-0001
Issued by: Department of the Air Force Materiel Command Lifecycle Management Center

About this file

Written by GovTribe AI · Dec 8, 2025

This is a Request for Information (RFI) from the Air Force Life Cycle Management Center seeking vendor expertise for porting the Secure Enhanced Data Rate (SEDR) waveform onto existing software-defined radios. The RFI focuses on implementing SEDR, which is based on STANAG 4372 Edition 4, with specific technical requirements including:

Key technical specifications include support for TSVCIS 3.1.1 voice encryption, NINE tactical profile for IP data encryption, and compatibility with airborne or ground-based radio platforms. Vendors are expected to provide their own radio hardware, handle airworthiness and security certifications, and potentially support both Type-1 and Type-2 encryption options. The government will provide source code (C++ and VHDL) and a reference hardware platform for testing. While Link-22 is not applicable, the effort requires porting the SEDR portion of the STANAG standard, with an emphasis on flexible implementation that meets operational requirements across different radio platforms.

View the file

Other files

File	Type	Posted
SEDR RFI Questions Updated 9Dec25.xlsx	XLSX spreadsheet	Dec 16, 2025
SEDR RFI Questions Updated 8Dec25.xlsx	XLSX spreadsheet	Dec 11, 2025
RFI SEDR Porting Revised 03NOV25.pdf	PDF	Nov 3, 2025
RFI SEDR Porting FINAL.pdf	PDF	Jul 15, 2025

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Sheet1

Contractor Question	Government Answer
What is the intended processing environment (3U-VPX SOSA aligned cMSDR, AN/ARC-210, etc.)?	The hardware is to be supplied by the vendor, and the government will consider any and all form factors applicable to airborne or ground-based use, but not having vendors port it onto another vendor's radio.
What is the source of the porting?	The source code is provided GFI. Source consists of C++ and VHDL
What version of SATURN is the source code to be ported (e.g., STANAG 4372 ED4?)	The source code is based on STANAG 4372 Edition 4. However, the provided SEDR source code includes a number of updates and changes that will be considered part of the future Edition 5 of the STANAG. A full US SEDR specification will be provided along with the source.
Is LINK-22 (UHF) desired as a part of this effort?	No, Link 22 is not applicable to this effort.
Is crypto modernization (TSVCIS) development part of the scope of this effort? Or is integration with existing modernized, or legacy, Crypto part of the scope of this effort?	While the optimal and required solution for a full production port is an embedded TSVCIS 3.1.1 minimum, the specific implementation depends on the vendor's platform and timeline. For preliminary or experimental porting, it may be possible to omit voice encryption. Vendors should assess what works best for their use cases, noting that if a short fielding turnaround is needed, legacy crypto might be required in addition to modern crypto.
Will a reference waveform implementation be made available for interoperability testing? If so, what will the reference platform be?	Yes, a reference implementation will be available for testing. A government reference hardware platform running the same source code will be made available for full power, over-the-air testing. This will be a government developed reference radio if requested, as has been done for vendors in the past, and the SEDR reference software implementation is also available from the JTNC DoD IR.
SEDR is approximately 50 pages out of 250 of the SATURN STANAG-4372.

a. Does the RFI look to the complete SATURN STANAG-4372 including SEDR?

b. Or does the RFI look to address only the SEDR part?

This RFI is only concerned with a port of the SEDR portion of the STANAG. While SEDR and the separate SATURN waveform have some common elements like voice encryption and TRANSEC, the complete SATURN waveform is not part of this effort.

2. What is NSA Type-1 certification required for?

a. TRANSEC?

b. Or COMSEC?

i. If COMSEC: SEDR will be designed to support radio-internal COMSEC (ICU) and external COMSEC (ECU). If NSA Type-1 certification of a COMSEC is asked for, then is it required to implement COMSEC inside the radio?

NSA Type-1 certification is required for COMSEC, which for SEDR includes TSVCIS voice encryption and the NINE tactical profile for IP data. The purpose of this RFI is to port SEDR onto existing radios, and vendors must make their own assessment of the best COMSEC solution for their platforms. The expectation is that voice encryption will be embedded, and while data encryption is generally embedded as well, some applications could support external ECUs.

3. RFI requests a Type-1 certification.

a. Our understanding is that security certification usually is done for COMSEC algorithms, not TRANSEC. Is this your understanding?

b. Is your expectation that COMSEC algorithms for encryption of voice and IP data are implemented inside the radio, i.e., as internal crypto unit (ICU)?	Yes, it is our understanding that security certification is for COMSEC, not TRANSEC. Generally, TRANSEC is housed on the black side of the radio. Our expectation is for COMSEC functions like voice (TSVCIS) and data (NINE) encryption to be embedded within the radio, though there may be applications that could support external data encryption. Ultimately, vendors need to assess the best COMSEC solution for their radio platforms, as a particular implementation is not being required.
	Do you envision any specific SEDR CONOPS that would drive any unique performance or functional requirements above and beyond the waveform standard requirements?	No, there are no unique CONOPS driving requirements beyond the standard. The current physical layer design already takes into account the latest requirements driven by updated threat analysis and numerous flight tests, and all known scenarios are being considered.
	Our SEDR capable handheld radio supports two form factors: one with embedded Type-1 encryption and one without Type-1 encryption. Do you see any advantages to offering a non-Type-1 form factor option?	A non-Type-1 option could certainly be advantageous for international sales requiring Type 2 encryption. Within the US, Type 1 for voice is required. However, the final decision rests with the vendors, who should choose based on their platforms and the typical use cases for their customers. The government is not requiring a particular COMSEC implementation, only that vendors make responsible choices.
	Are there any unique requirements that must be satisfied to certify a SEDR-capable radio for use in an airborne application?	There are no unique SEDR-specific requirements that we are aware of. Any radio must still meet the typical platform requirements for airborne use, such as achieving a stage 4 transmit authorization and passing platform-specific standards for things like EMC and airworthiness.
	What COMSEC encryption algorithm is used to support SEDR?	The COMSEC voice algorithm should be TSVCIS 3.1.1 compliant at a minimum. Data should support a NINE tactical profile either type I or II
	Are there any SWaP-related requirements associated with UAS deployment?	No, there are no specific SWaP requirements as part of this RFI. While SWaP is always a concern for UAS operations, those specific requirements are determined by the size of the UAS and are best answered by the UAS program offices who would be acquiring the SEDR radios.
	Has the hardware of the target platform for the software port already been certified by the USAF for Airworthiness or by NSA for security?	The hardware is expected to be vendor-supplied, as the government is only providing the waveform source code. Since the effort is focused on porting to a suitable vendor radio, it would be on the vendor to determine and handle the airworthiness and security certifications for its own platform.
	What contractor action is expected if the government-provided hardware is the root cause of a failure of either Airworthiness or Security testing?	This is not applicable, as the government is not providing hardware. The contractor is responsible for their own radio platform and any associated airworthiness or security testing.
	Will the software be subjected to specific certification requirements and or specifications (e.g. DO-178C)?	Depending on the level of security certification being pursued, the NSA may impose certain certification levels, which are sometimes addressed through the use of real-time approved operating systems.

File details come from the government source that posted it. Updated Dec 8, 2025.