SEDR RFI Questions Updated 8Dec25.xlsx
XLSX spreadsheet 13 KB Posted
- Solicitation number
- C3NK-SEDR-0001
About this file
This document is a Request for Information (RFI) regarding the Enhanced Data Rate (SEDR) Waveform porting onto operational radios, issued by the Air Force Life Cycle Management Center's Aerial Networks Division. The RFI seeks to identify qualified vendors capable of porting the SEDR source code (based on STANAG 4372 Edition 4 with updates for future Edition 5) onto existing software-defined radios, with a focus on airborne and ground-based applications. Key technical requirements include supporting TSVCIS 3.1.1 voice encryption, NINE tactical profile data encryption, and potentially NSA Type-1 certification, though vendors have flexibility in specific implementation.
The government will provide the source code (C++ and VHDL) and a reference hardware platform for testing, with no specific hardware being delivered. Vendors are expected to supply their own radio platforms and handle airworthiness and security certifications. The RFI does not mandate a specific form factor or crypto implementation but emphasizes the need for responsible solutions that can support both U.S. and international requirements. The effort is not focused on Link-22 or the complete SATURN waveform, but specifically on the SEDR portion, with no unique operational concept (CONOPS) driving additional requirements beyond the standard waveform specifications.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| SEDR RFI Questions Updated 9Dec25.xlsx | XLSX spreadsheet | |
| SEDR RFI Questions - Final.xlsx | XLSX spreadsheet | |
| RFI SEDR Porting Revised 03NOV25.pdf | ||
| RFI SEDR Porting FINAL.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
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. | |
| Bidder Questions in Rows 2, 16, and 17 - We assume from the Govt responses that the contractor supplied hardware will be used to demonstrate proof of concept only, and that the hardware itself will not be delivered to the Government. Please advise if this is correct. | The hardware does not need to be delivered to the government after proof of concept demonstrations. |
File details come from the government source that posted it. Updated .