SEDR RFI Questions Updated 9Dec25.xlsx
XLSX spreadsheet 21 KB Posted
- Solicitation number
- C3NK-SEDR-0001
About this file
This document is a Request for Information (RFI) from the Air Force Life Cycle Management Center seeking vendors to port the Secure Enhanced Data Rate (SEDR) waveform onto existing software-defined radios. The RFI focuses on porting the SEDR portion of the STANAG 4372 Edition 4 source code, which includes C++ and VHDL, with key technical requirements including TSVCIS 3.1.1 minimum voice encryption, NINE tactical IP data encryption, and support for both airborne and ground-based platforms.
Critical technical specifications include a preference for QAM modulations, potential AES TRANSEC implementation, and flexibility in radio form factors. The government will provide source code and a reference hardware platform for testing, with expectations that vendors will handle airworthiness and security certifications for their own radio platforms. While Type-1 certification for COMSEC is desired, vendors have latitude in specific implementation, with the primary goal of porting the SEDR waveform onto operational software-defined radios for potential future acquisition.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| SEDR RFI Questions Updated 8Dec25.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. | |
| What TRANSEC algorithm for SEDR does the RFI assume? AES TRANSEC or SAT-002, or both? | That is a great question and we don’t really know what the timeline is going to be. In theory it would be great to move on to AES-256 but practically speaking it may not happen in time and legacy will also need to be supported. | |
| Do you think the RFI assumes a CPFSK or QAM modem? | The new Phy will have QAM modulations unfortunately. That said the two low rate modulations are shifted versions to reduce the amplitude variations and hopefully require less backoff. I am also looking into perhaps designing them as differently encoded to allow simpler RX architectures for disadvantaged terminals so to speak. | |
| If a QAM modem is required, would the option that Jeff previously shared remain viable, assuming the specification is updated to allow participants/nodes to declare their modulation capabilities (for constant modulus)? | Yes see above. We've have been thinking it would be important to allow less complicated RX structures. How that is advertised we're not sure. |
File details come from the government source that posted it. Updated .