Protected Anti-Jam Tactical SATCOM Enterprise Mission Management (PATSEMM) Sources Sought Request for Information (RFI)

Section I: PTES Description & Background The Protected Tactical Enterprise Service (PTES) is the ground system designed to provide anti-jam (AJ) wideband Satellite Communications (SATCOM) capability utilizing the Protected Tactical Waveform (PTW) for the Protected Anti-Jam Tactical SATCOM (PATS) Family of Systems. PTES consists of a Mission Management System (MMS), a Key Management System (KMS), and Joint Hubs (JHs) to enable transponded PTW via WGS, Protected Tactical Satellite Global (PTS-G) and commercial satellites, and processed PTW in space via Protected Tactical Satellite Prototype (PTS-P) satellites. The user equipment consists of existing wideband terminals with upgraded PTW modems. PTW modems for user terminals include the Air Force-Army Anti-Jam Modem (A3M) and the Navy Wideband Anti-Jam Modem System (WAMS). The user terminal segment, not included in this acquisition, may utilize the low-cost PTW modem upgrades enabled by the A3M and WAMS programs. Requirements for PTW mission management have evolved and grown since the inception of the PTES Program, to include the requirements for other programs of record and management of PTW SATCOM over commercial satellite constellations. Additionally, the Government desires to implement a more rapid and flexible approach to delivering PTW mission management capabilities to meet urgent operational needs, in alignment with Agile and Software Pathway Program principles. This RFI specifically requests information related to development and fielding efforts as outlined within this document. Responses to this RFI will be considered as Market Research in accordance with FAR Part 10 to inform the Government s procurement strategy. The Government may or may not compete or award this requirement. Additional market research may or may not be conducted. Responses from small businesses and small disadvantaged businesses are highly encouraged. The anticipated NAICS code for this acquisition is 517810 and the size standard is $40,000,000. Section II: RFI Objective While PTW over WGS (PTWoW) provides an initial operational baseline, the Government emphasizes that this RFI seeks information from industry regarding the acquisition and integration of additional mission planning and mission management services beyond PTWoW alone, applicable across the broader PATS Family of Systems. Responses should address scalability, extensibility, and applicability to multiple satellite system implementations. The Government encourages responses from vendors capable of rapidly addressing the full scope of mission planning and mission operations functions, as well as from vendors proposing solutions that address one or more discrete subsections of the scope described in Section III. Respondents should clearly identify which specific subsections of Section III their response addresses and describe any assumptions regarding external services, integrations, or complementary capabilities provided by other vendors or the Government. The Government anticipates that capability?based responses may be combined in future acquisition strategies to assemble a complete mission management solution. Section III: RFI Scope: PATSEMM This new approach is the Protected Anti-Jam Tactical SATCOM (PATS) Enterprise Mission Management, or PATSEMM. PATSEMM scope includes mission planning, mission operations, mission product generation, and systems integration functions required to support operational PTW satellite communications missions. The PATS Family of Systems currently includes PTW over WGS (PTWoW), Protected Tactical Satellite - Global (PTS-G), Protected Tactical Satellite - Prototype (PTS-P), Enhanced Protected Tactical Satellite Prototype (Enhanced PTS-P), and PTW over Commercial (PTWoC). The Government seeks information from industry regarding capabilities to rapidly develop and provide mission planning and mission management services in support of the PATS Family of Systems architecture, spanning both classified Secret Internet Protocol Router Network (SIPR) and Non-classified Internet Protocol Router Network (NIPR) environments. III.1 Mission Planning (SIPR) Mission planning workflows, including mission request ingest, analytics, and mission product generation. Mission request supportability analysis (benign/contested), including feasibility impacts from payload/terminal/JH constraints and threat/interference data, supportability against other users such as non-PTW, blocked bandwidth for users. SATCOM resource determination across constellations (e.g., power/bandwidth) to support independent and/or aggregated solutions. SATCOM resource scheduling/allocation and management for current and future mission requests. Mission-request and approval workflows PATS Mission Request (PMR), Pre-Satellite Access Request (SAR), Satellite Access Authorization (SAA) and post?solution mission plan generation (PMP). Operator mission planning user experience, including map-based views and guided workflows to reduce workload and data entry errors. Implementing planning-side interfaces, including the MMS to EM&C interface (documented in the MMS to EM&C ICD). Creating and maintaining the MM Planning to MM Ops ICD and the MMS to EM&C ICD and testing the interfaces to external systems Capturing and publishing required metadata for planning outputs (e.g., provenance/lineage, markings/handling, and descriptors needed for enterprise discovery). Operating within a Government?defined security accreditation boundary, including scenarios where mission planning capabilities are integrated with, layered atop, or partially replaced from existing Government?provided functionality III.2 Mission Operations (SIPR) Building and integrating MMS Operations functions: packaging/publishing, dissemination paths, and enterprise-service integration. Execution of approved PATS Mission plans (PMPs) C2 (or Government-directed control interfaces) for PTW ground elements (e.g., JHs/JHVs) and dynamic operations across satellite constellations and orbits (e.g., GEO to MEO satellite handover). Generation of configuration files, mission service plans, and key mission packages Support for mission replanning and updates Preparation of mission products for cross?domain transfer Creating and maintaining the MMS to KMS ICD and the MMS to KLIF ICD III.3 Cross-Domain Data Preparation Prepare mission products for bidirectional transfer across Government?provided Cross Domain Solutions (CDS) Ensure data formatting, labeling, and compliance with cross?domain requirements Operate within Government?approved CDS workflows without direct CDS ownership or operation Vendors shall not assume responsibility for CDS accreditation, operation, or sustainment. III.4 Mission Operations (NIPR) Receipt and processing of cross?domain mission products Generation and distribution of configuration files and mission artifacts for downstream systems Coordination with Government? or contractor?operated network and host systems Mission operations on NIPR shall coordinate with, but not exercise operational control of, external network management, host, or payload execution systems. III.5 Interfaces and Integration Mission command and control systems Enterprise mission management platforms Network management and configuration systems Government?defined ICDs across security domains The Government retains authority over interface definition and approval; vendors are expected to implement against Government?provided or Government?approved ICDs with minimal disruption to fielded interfaces. III.6 Transition and Operational Cutover Build upon existing mission management capabilities Knowledge transfer and operational cutover Risk identification and mitigation during transition Section IV: Execution Assumptions and Government Constraints The following ground rules and assumptions apply to the PATSEMM effort: The Government intends to be intimately involved in the incremental definition and prioritization of capabilities for this effort (i.e. product owner), and as such, requires the ability to rapidly pivot vendor development activities (within a few days) in response to operational priorities, not solely software development cycles. The Government is seeking solutions that will minimize impacts to existing interface control documents. The Government may provide software development and production environments at IL4-IL6, as required. Use of the Government environments is not a requirement. Should a vendor choose to NOT use the Government environments, then Government access to non-Government development libraries and production/test environments is a requirement. Additionally, non-Government software environments must be proven to decrease the risk to the Government. Government access includes auditability sufficient to support cybersecurity assessments, mission assurance, and continuity of operations. Vendors can propose to build on top of the existing PTES mission management capability, start anew, integrate/modify…