BAA 24-02 Amend 2 update PM.docx

AMENDMENT 2 TO BAA FA8750-24-S-7002

The purpose of this modification is to update the BAA Program Manager throughout:

1. Part I Overview Information, and Part II, Section VII Agency Contacts are updated as follows:

BAA PROGRAM MANAGER:

Lt. Tyler Horn

AFRL/RIGD

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315)330-2438 Email: tyler.horn.4@us.af.mil

No other changes are made.

NAICS CODE: 541715

FEDERAL AGENCY NAME: Department of the Air Force, Air Force Materiel Command, AFRL - Rome Research Site, AFRL/Information Directorate, 26 Electronic Parkway, Rome, NY, 13441-4514

BAA ANNOUNCEMENT TYPE: Modification

BROAD AGENCY ANNOUNCEMENT (BAA) TITLE: Networking the Fight

BAA NUMBER: FA8750-24-S-7002

PART I – OVERVIEW INFORMATION

This announcement is for an Open, 2 Step BAA, with a partial Closed-Staggered, 2 Step BAA for Technical Area 1 (TA 1), Technical Area 2 (TA 2), and Technical Area 3 (TA 3), which is open and effective until 14 Feb 2029. Only white papers will be accepted as initial submissions; formal proposals will be accepted by invitation only. While white papers will be considered if received prior to 11:59 PM Eastern Standard Time, 28 February 2024, the following submission dates are suggested to best align with projected funding:

Technical Area 1 (TA 1), Technical Area 2 (TA 2), and Technical Area 3 (TA 3) are structured as a Closed-Staggered, 2 Step BAA. Therefore, for TA 1, TA 2, and TA 3 ONLY:

The Government anticipates awarding three awards for Technical Area 1, and three awards for Technical Area 2, and one award for Technical Area 3. Therefore, white papers for TA 1, TA 2, and TA 3 are due on 11:59 PM Eastern Standard Time, 28 February 2024 and if requested, proposals are due on 11:59 PM Eastern Standard Time, 8 April 2024. Please note that white papers will still be accepted for TA 1, TA 2, and TA 3 after the 28 February 2024 date, however, the likelihood of funding being available is substantially reduced.

For all other Technical Areas:

The Government anticipates adding technical areas via BAA amendment in the future. All potential Offerors are requested to wait to submit white papers for all other Technical Areas (other than TA 1,TA 2 and TA 3) until the BAA announcement is amended with specific technology requirements and dates.

Offerors should monitor the Contract Opportunities on the System for Award Management (SAM) website at https://sam.gov/ in the event this announcement is amended.

CONCISE SUMMARY OF TECHNOLOGY REQUIREMENT: The Air Force Research Laboratory in Rome, New York, seeks innovative research proposals aimed at enhancing information sharing flexibility at the tactical edge. The focus of this research is to enable secure movement of information across security domains, and across "red-black" boundaries, spanning heterogeneous networks. This research will develop a capability to transmit and manage information flows seamlessly across various physical domains, including air, space, and ground. By integrating these technologies, the goal is to strengthen information sharing and collaboration in tactical environments, ultimately enhancing mission success.

The over-arching strategy of this 5-year open BAA is to quickly and efficiently execute research and development to deliver practical solutions to urgent problems. These efforts are anticipated to entail rapidly integrating a mission-focused modeling and simulation (M&S) framework, maturing that framework with existing and new capabilities to provide field testable, functional prototypes of solutions to military problems in three major Focus Areas:

Technical Area 1 (TA 1): Next Generation Cross Domain Solution Broker

Technical Area 2 (TA 2): Highly Dynamic Red/Black Networking

Technical Area 3 (TA 3): Modeling, Simulation, and Analysis (MS&A)

This strategy provides AFRL/RI Rome, NY a solicitation tool with the flexibility to solicit white papers and proposals for Contract or agreements to perform rapid prototyping of technical solutions to meet compelling Air Force needs.

BAA ESTIMATED FUNDING:

Funds are not presently available for this effort. No award will be made under this solicitation until funds are available. The Government reserves the right to cancel this solicitation. In the event the Government cancels the solicitation; the Government has no obligation to reimburse an Offeror for any costs.

Total funding for this BAA is approximately $70M. Individual awards will not normally exceed 36 months with dollar amounts normally ranging from $1M to $24M. There is also the potential to make awards up to any dollar value if the value does not exceed the available BAA ceiling amount. Any anticipated funding listed reflects estimated program funding only. This estimate is not a promise of funding. Funding is uncertain and is subject to change. Changes in availability may occur as a result of the exercise of Government discretion.

ANTICIPATED INDIVIDUAL AWARDS: Multiple awards are anticipated. However, the Air Force reserves the right to award zero, one, or more Procurement Contracts or Other Transactions for all, some, or none of the solicited effort based on the offeror’s ability to perform desired work and funding fluctuations. There is no limit on the number of OTs that may be awarded to an individual offeror.

TYPE OF INSTRUMENTS THAT MAY BE AWARDED: FAR based Procurement contracts, CFR based grants and cooperative agreements or other transactions (OT) under 10 USC 4021, 10 USC 4022 and 10 USC 4023(previously 10 USC 4002, 2371, 10 USC 4003, 2371b and 4004, 2373) depending upon the nature of the work proposed.

In the event that an Other Transaction for Prototype agreement is awarded as a result of this competitive BAA, and the prototype project is successfully completed, there is the potential for a prototype project to transition to award of a follow-on production contract or transaction. The Other Transaction for Prototype agreement itself will also contain a similar notice of a potential follow-on production contract or agreement.

AGENCY CONTACT INFORMATION: All white paper submissions and any questions of a technical nature shall be directed to the cognizant Technical Point of Contact (TPOC) as specified below (unless otherwise specified in the technical area):

BAA PROGRAM MANAGER:

Lt. Tyler Horn

AFRL/RIGD

525 Brooks Rd Rome, NY 13441-4505 Telephone: (315)330-2438 Email: tyler.horn.4@us.af.mil

Questions of a contractual/business nature shall be directed to the cognizant contracting officer, as specified below (email requests are preferred):

Amber Buckley Email: Amber.Buckley@us.af.mil

Emails must reference the solicitation (BAA) number and title of the acquisition.

Pre-Proposal Communication between Prospective Offerors and Government Representatives: Dialogue between prospective offerors and Government representatives is encouraged. Technical and contracting questions can be resolved in writing or through open discussions. Discussions with any of the points of contact shall not constitute a commitment by the Government to subsequently fund or award any proposed effort. Only Contracting Officers are legally authorized to commit the Government.

Offerors are cautioned that evaluation ratings may be lowered and/or proposal rejected if proposal preparation (Proposal format, content, etc.) and/or submittal instructions are not followed.

PART II – FULL TEXT ANNOUNCEMENT

BROAD AGENCY ANNOUNCEMENT (BAA) or ADVANCED RESEARCH ANNOUNCEMENT TITLE: Networking the Fight

BAA NUMBER: BAA FA8750-24-S-7002

CATALOG OF FEDERAL DOMESTIC ASSISTANCE (CFDA) Number: 12.800

I. TECHNOLOGY REQUIREMENTS:

1. Program Overview

The Air Force Research Laboratory is soliciting white papers under this Broad Agency Announcement (BAA) for research, development, integration, test, and evaluation of technologies/techniques that revolutionize the way information is shared at the tactical edge while appearing seamless to operational users. This capability will allow mission critical data to move across both multiple security domains and across different physical domains traversing aerial, space, and ground nodes. The agile exchange of time sensitive data across any network (and security domain) at the tactical edge is poised to re-envision how information is shared and delivered supporting the vision of Joint All-Domain Command and Control (JADC2) and improve communication resiliency in a degraded environment.

Today current network architectures are not well suited to allow timely movement of critical mission data across security domains and networks at the tactical edge. There are two major impediments towards removing this barrier: 1) Cross domain solutions (CDS) typically require enterprise reach-back to handle complex mission data, dynamic changes in policy, and multiple security domains; and 2) mission data cannot be dynamically re-routed in-mission and lack resiliency in degraded networks as encryptors require manual configuration and are limited to static networks. Mission critical data exists on multiple networks that operate in different security domains, which may or may not be encrypted, or encrypted at least once. The boundaries across heterogenous networks, red-black boundaries pose S&T challenges as data must traverse across both different security domains and across the different physical domains (air-space-ground). Control of these networks and levels of visibility across boundaries play a key role in design of networking techniques to deliver flexible information sharing at the tactical edge.

The future fight will require interoperability across all operating domains and require a cohesive infrastructure to ensure that missions are executed at scale and at speed. It necessitates a transition from today's pre-planned information transport across kill-chains to realize the future's resilient, dynamic, ad-hoc information transport across kill-webs. This transition requires innovative approaches to move information across security domains, coupled with dynamic network management and control of information flows over highly dynamic heterogeneous network topologies across ground, air, and space. The Networking the Fight (NtF) program ultimately seeks to transform communication and information sharing at the tactical edge, through the development of software-defined, modular extensible technology, which can be hosted on Size, Weight, Power, and Cost (SWaP-C) constrained platforms. The capabilities developed under NtF will ensure resiliency within currently fragile networks and blend the distinctions between security domains and amongst the black core and red networks, resulting in greater operational agility. The program will begin with the development and integration of a testbed that is capable of simulating and evaluating the performance gains from leveraging its technologies (Phase 0), which will be matured to TRL 5 (Phase 1) and then to TRL 6 (Phase 2) to demonstrate operational relevancy, informing mission planning and operational exercises. By the end of the program the deliverable is expected to be at TRL 6 capability as well as an in-house AFRL MS&A testbed capability that is applicable for a multitude of uses.

The over-arching strategy of this five (5) year open BAA is to quickly and efficiently execute research and development to deliver practical solutions to urgent problems. These efforts are anticipated to entail rapidly integrating a mission-focused modeling and simulation (M&S) framework, maturing that framework with existing and new capabilities to provide field testable, functional prototypes of solutions to military problems in three major Focus Areas:

Technical Area 1 - Next Generation Cross Domain Solution Broker: This is a broker service that provides a discoverable, reconfigurable Cross Domain Solution (CDS) framework that meets throughput and latency requirements for tactical deployment at scale and supporting network Quality of Service (QoS). This effort does not seek to develop a new CDS, but rather enables key capabilities with National Cross Domain Strategy and Management Office (NCDSMO) baseline CDSs.

Technical Area 2 – Highly Dynamic Red/Black Networking: This will provide the ability to pass metadata from the red side to the black side enabling the black network to make routing decisions and provide resilient forwarding over black networks. The red network is characterized by segmentation, and the black network must be “stitched” together. Today visibility across red-black boundaries poses a variety of S&T challenges.

Technical Area 3 – Modeling, Simulation, and Analysis (MS&A): This Technical Area will establish a non-proprietary multi-vendor MS&A Testbed. The scope will specifically be focused on: development and integration of digital models that implement Technical Area 1 & 2 designs, models for end-to-end ground/air/space nodes representing mission thread scenarios and conduct of analyses that assess performance across mission scenarios with and without NtF capability. Technical Area 3 offeror must propose to develop the Technical Area 1 & 2 functional digital models. However, the government may opt to select Technical Area 1 or Technical Area 2 offerors to produce the digital models for Technical Area 3 integration. Teaming between offerors across Technical Areas is encouraged to achieve this objective.

The challenges in each of these three technical areas will be addressed and matured in a phased approach. Phase 0 will focus on the development and integration of a mission driven MS&A Framework enhanced with Next Gen CDS Broker (TA 1) and Red/black networking (TA 2) capabilities. Phase 1 and Phase 2 will mature these capabilities, informed by performance analysis, to a TRL 5 demo and TRL capstone demo, respectively. Operator feedback is critical to success and key to feedback and update of all technology developments throughout all phases of NtF.

1.1 Program Structure

Figure 1 provides an overview of capabilities envisioned for each of the NtF technical areas and how they are intended to interact. Section 3 provides an overview of the objectives for each phase of the program.

Figure 1:Functional Components for Networking the Fight architecture, and their association of the Technical Areas sought in this BAA.

1.2 Technical Area Descriptions

Networking the Fight (NtF) will address three technical areas: (1) Next Generation Cross Domain Solution Broker, (2) Highly Dynamic Red/Black Networks, and (3) Modeling, Simulation, and Analysis (MS&A).

1.2.1 Technical Area 1: Next Generation Cross Domain Solution Broker

The goal of TA 1 is to design and develop a discoverable, reconfigurable Cross Domain Solution (CDS) Broker that meets throughput and latency requirements needed for tactical deployment at scale and supports network Quality of Service (QoS). The CDS Broker service envisioned is not developing a cross-domain guard. Development of a CDS guard is out of scope. Existing CDSs will be utilized, and the broker service will provide new capabilities as an overlay. The CDSs to be utilized must be certified and/or in the Lab Based Security Assessment (LBSA) process per DODI 8540.1 and meet National Cross Domain Strategy and Management Office (NCDSMO) Raise-The-Bar (RTB) security controls and requirements. The NCDSMO maintains a baseline of CDSs that have been certified, which is available on the NCDSMO classified portals.

The broker service will provide services on either side of guards to support capabilities not generally associated with a guard device, including data normalization, metadata pre-processing, and sharing control messages with peer instances of the broker service in other security domains. The broker service must also manage connections with multiple CDSs simultaneously, and these CDSs may be from different manufacturers. The broker service is also envisioned to interface with existing Information Management System(s) (IMS) in each respective security domain. The IMS(s) will provide edge networking to enable distributable battle management command and control in highly contested environments. Development of the IMS(s) though is not in scope of this effort.

TA 1 will develop 2 new functions: 1) Discoverability and 2) Reconfigurability for Next Generation CDSs capability.

1.2.1.1 CDS Discoverability

NtF must provide a discoverable CDS broker service, defined as the ability of a network node to locate CDS service(s) that can pass mission-required information among all necessary security echelons and enclaves without violating security protocols of the network or compromising operational security. The criteria used to assess discoverability includes interoperability with different information management systems (e.g., Common Tactical Edge Network (CTEN)).

A key aspect of discoverability is the CDS Broker’s ability to leverage an information management service that maps cross domain services and capabilities across security levels using publish/subscribe or similar mechanisms. This ensures that nodes at different security levels are aware of each other and associated metadata (e.g., publish/subscribe) on a need-to-know basis. The challenge lies in sharing information between higher and lower classification domains while maintaining mission security. The stability and reachability of the information management service in a contested, Denied, Disrupted, Intermittent, and Limited (DDIL) environment must be considered, along with the trade-offs between availability, consistency, and partitioning.

1.2.1.2 CDS Reconfigurability

The second function for Technical Area 1 is reconfigurability. The CDS must be programmable (pre-mission), with approved filter sets available to be added to the CDS to support unique mission needs. Using the CDS Broker, operators must have the ability to add and/or configure new mission-selectable data flows quickly and easily to support composable filtration during mission. The criteria used to assess reconfigurability includes interoperability with different CDSs and the ability for adaptation of each CDS to different data flows. Reconfiguration of the CDS during mission operations requires remote management access to the CDS. Using remote management, the admin will have the ability to activate a new data flow (and associated rules sets) quickly and easily and/or modify an existing filter orchestration in to order to meet new mission requirements.

1.2.2 Technical Area 2: Highly Dynamic Red/Black Networks

The goal of TA 2 is to design and develop message-oriented (e.g., mission level) resilient forwarding over Red/Black network boundaries that optimizes delivery assurance and mission impact and to optimize network hops by dynamically utilizing all available networks. The red network is characterized by segmentation, and the black network must be “stitched” together. “Red” refers to classified plain-text data. “Red” end nodes do not need to belong to the same network so long as they exist at the same classification level. “Black” is defined by any information in cipher text on any classified, unclassified, government or non-government owned network. “Grey” can consist of any combination of these Black network connections. Today visibility across red-black boundaries poses a variety of S&T challenges including: 1) identification and utilization of Red/Black dynamic pathways, 2) the ability to assess and optimize these pathways, and 3) the ability for black core to prioritize the encrypted red data by leveraging metadata and avoiding any sensitive data compromise.

Technical Area 2 will develop 3 new functional capabilities: (1) Message Oriented, (2) Resilient Forwarding, and (3) Mission Impact.

1.2.2.1 Message Oriented

NtF will provide network implementations of protocols that are aware of red information flows to identify prioritization and ensure delivery of packetized data within the black core. The receiver of data is aware of where one message ends and another begins. This function will provide the following capabilities:

· Identification and distribution of metadata that can be captured and conveyed from red networks to black networks. This metadata must enable the black core to intelligently route (or forward) and handle multiple packets without compromising the disseminated information.

· Develop the means to obfuscate this metadata in such a way to minimize impact if it were nefariously collected.

· Characterize how priority changes are handled by the protocols.

· NtF will demonstrate how the fault case is handled where black side notifies the red side that data has changed (e.g., data integrity).

1.2.2.2 Resilient Forwarding

NtF will provide the ability to maintain efficient forwarding of network traffic regardless of current network conditions to minimize data loss, to include seamless hand-off when a given network path experiences an outage. This function will provide the following capabilities:

· Determine the balance required between probing the black core to understand network variability and the associated overhead.

· Develop a technique to ensure that data are not lost by considering and implementing intermediate acknowledgements.

· Characterize the balance between a singular flow being distributed over multiple pathways and the consumption of network capacity.

· Handle message criticality when determining the level of resiliency needed for a specific payload/packet.

· Identify the number of red/black encryptors required to support forwarding to multiple red/black domains.

Intermediate nodes must be aware of whether the data to be forwarded is still useful to the end/receiving node or if it is no longer necessary. This awareness will require input from other defined features and may involve a load-balancing mechanism that can provide insights through statistical analysis. Potential technologies to achieve this could include monitoring the black network for a better understanding of variability, employing a protocol that necessitates intermediate acknowledgments, or using packet-level acknowledgment. A “High Assurance Internet Protocol Encryptor (HAIPE) discovery protocol” is needed to discover red side addresses attached to a given black node across the network. Other protocols such as Media Access Control Security (MacSec), Ethernet Data Encryption (EDE), Internet Protocol Security (IPsec), and (Transport Layer Security) TLS may be considered.

1.2.2.3 Mission Impact

NtF will provide the ability to optimize data flows across both red and black networks based on the prioritization of many simultaneous missions and applications. This function will provide the following capabilities:

· Characterize the hierarchical levels of prioritization that must be considered (e.g., packet-level, flow-level, destination-specific) and the inter-dependencies between these levels of hierarchy.

· Develop techniques to renew the importance and identify the staleness to reduce traffic loads on black core and ensure the best possible support for critical traffic.

· Design predictions to prepare the network for expected volatile traffic loads (e.g., the proximal convergence of two specific assets).

Development of methodologies includes the abstraction of higher-level mission controls and planning applications into orchestration service routines and prioritization; deriving inter- and intra-dependency trade space metrics to inform hierarchical network needs; and creating network prediction methods to understand network convergence potential for various traffic, data types, priorities, and mission loads.

1.2.3 Technical Area 3: Modeling, Simulation, and Analysis (MS&A)

The goal of TA 3 is to develop and integrate modeling and simulation tools to assess the viability of artifacts from Technical Area 1 & Technical Area 2 with integrated of digital models capturing functionality of Technical Areas 1 and 2 and performance in mission context. The input to TA 3 is the mission scenarios, which will take the form of information exchange requirements (IERs), which will be provided by the government. These IERs must be input into the MS&A framework such that the scenario can be changed across different mission threads. The MS&A framework will be developed and integrated to support the ability to instantiate the mission scenario and represent the key functions of TA 1 and 2. These key functions are the output digital models from TA 1 and 2 and must be integrated into the MS&A framework.

For Technical Area 3, it is desired that white papers/proposals consider utilizing the following currently available tools: Advanced Framework for Simulation, Integration, and Modeling (AFSIM), Extendable Mobile Ad-hoc Network Emulator (EMANE), Tactical Network Modeler (TNM), and/or Common Open Research Emulator (CORE). Proprietary custom solutions, solutions that are not interoperable with other government frameworks, and frameworks that are not easily modifiable or adapted by external parties are not desirable. Include in the white papers/proposals how other Offeror solutions can be integrated into the proposed M&S solution space and the plan on how to support a multi-Offeror Interface Control Document (ICD) approach utilizing the chosen frameworks.

The MS&A framework will undergo performance analysis by the Offeror across Key Performance Parameters (KPPs) as relevant to each of the TAs, in context of end-to-end mission performance. This performance analysis, as all of aspects of technology developed under this BAA, will be evaluated by the government team.

The core NtF MS&A testbed, comprising compute resources and key simulation/emulation tools, will be hosted at the AFRL/RI facility in Rome, NY. Access to these resources may be granted with a user account and through a remote government provided security token enabled device (or alternatively a Yubikey if this is not feasible). The host environment is controlled and governed by CUI, ITAR, EAR restrictions. The core implementations under NtF will be hosted within this testbed and milestone demonstrations ran from these resources to ensure that all performers have common access and can contribute collaboratively. This environment does not prohibit day-to-day development within each performer’s environment with recurring deliveries to the larger repository. This testbed will host work at the unclassified-CUI level but there will be procedures to port implementations to higher classification networks as deemed necessary.

Technical Area 3 performers will:

· Integrate modeling and analysis tools and approaches to inform design and implementation of solutions for Technical Areas 1 & 2.

· Input mission IERs that map multiple different mission scenarios (not simultaneously) to a kill web and allow for varying of network node types, data types, labeling of “mock” security domains, network scale, node mobility, and “mock” red/black boundary conditions integrated into the MS&A framework.

· Provide modeling tools capable of consuming probabilistic models of the environment and delivering statistical assessments.

· Combine mission-level simulations with network level simulations and emulations.

· Establish the appropriate balance and/or combination of emulation and simulation.

The focus is on leveraging modeling, simulation, and analysis to identify the necessary interface controls, ports, and information for the proposed solution's system and subsystem designs. To address this technical area, several aspects must be considered:

A. System Architecture: Develop a comprehensive system architecture that outlines the key components, subsystems, and their interconnections. This step will provide a clear understanding of the overall system structure and aid in identifying the essential interface controls and ports.

B. Interface Controls and Standards: Determine the most suitable interface controls and standards for each connection between components and subsystems. This will ensure compatibility and facilitate seamless communication within the system.

C. Modularity Analysis: Analyze the system architecture to identify opportunities for modularity and evaluate the potential benefits and challenges of implementing a modular design. This analysis should consider factors such as ease of integration, flexibility, scalability, and maintainability.

D. Simulation and Prototyping: Utilize simulation tools and create prototypes to validate the proposed system design and its modular aspects. This step will help identify potential issues and optimize the design before full-scale implementation.

E. Performance Metrics and Analysis: Establish performance metrics for evaluating the effectiveness of the proposed solution and its modularity. Perform a thorough analysis of the system's performance under various conditions and scenarios to ensure that it meets the required objectives.

This Technical Area will provide insights into the critical-path interfaces and the necessary interface controls, ports, and information for the proposed system.

Work scope must be entirely separable for each Technical Area, enabling the Government to select individual awards for Technical Areas 1, 2, and 3. A single Offeror may be awarded multiple Technical Areas. Multi-Offeror approaches, including teaming, are acceptable and encouraged. Providers are not required to address all Technical Areas (Technical Area) but must have a strategy to interoperate across Technical Area 1 and Technical Area 2 implementations. The identification of network information exchange requirements (IERs) and definition of interface control documents (ICDs) of each network and node type are critical to support effective mission execution. Input/output level specification must exist across the Technical Areas to ensure interoperability across the technologies and across multiple Offerors. In this context, IERs refer to the essential information elements that must be exchanged among nodes, while ICDs specify the interfaces and protocols necessary for seamless integration and compatibility amongst nodes. To ensure interoperability and avoid “Offeror-lock” incompatibilities, the community, including Offerors, government (potentially augmented by Federally Funded Research & Development Centers (FFRDCs), University Affiliated Research Centers (UARCs), and Systems Engineering and Technical Assistance (SETAs)) will ensure solutions are Open Mission Systems (OMS) complaint. Offerors will be allowed to implement their own solutions, but they must provide solutions with unlimited data rights and ICD between their internal design/implementation and the standard representation when exchanging information. By considering these critical factors, we aim to identify and develop next-generation communication capabilities to effectively meet the demands of the future fight that are software defined and are extensible beyond current implementation.

The government may provide Government Furnished Information (GFI) for this technical area of the Information Exchange Requirements (IERs) for related efforts.

2. Evaluation Support

A Government-led team (potentially augmented with Government, Federally Funded Research and Development Centers (FFRDCs), and/or University Affiliated Research Center (UARC) personnel) will design and conduct technical reviews and empirical performance evaluations throughout the life of the program. The Government intends to have the evaluation team provide representative evaluation mission scenarios and evaluation metrics to the technology development teams. The government team will continue to work with Technical Area 1, 2, and 3 performers during Phase 0 to provide an evaluation framework that will assist the development and assessment of component technologies. During Phase 1 and beyond, the government team will work directly with the Technical Areas 1 & 2 performers to connect the integrated NtF capability to operational data sources.

Table 1: Measurable Goals

3. Program Phased Effort

This program will span three phases across three years. Phase 0 will focus on Mission Information Exchange Requirements (IERs) and Modeling, Simulation, and Analysis (MS&A). Phase 1 will be Testbed Maturation and Demonstration. Lastly, Phase 2 will provide an Operational Mission Capability Demonstration.

The NtF Program will be executed via a phased approach, having three (3) Phases (0,1,2) with decision gates between Phases 0-1, and 1-2. Successful advancement to each successive next Phase will require written authorization from the Contracting Officer, and the decision to proceed to each next Phase will be based upon Performance Metrics (to be specified in SOW), Programmatic Metrics (specified in SOW), and available funding. In order to enable a down-select of performers, the Government may request that proposals include separately priced options for Phase 1 (12 months) and Phase 2 (15 months).

All awards (for Technical Areas 1, 2, and 3) are intended to execute with concurrent Periods of Performance (PoPs) having synchronized start and end dates to the greatest extent possible. The overall PoP for the Program is 36 months, with Phase 0 (9 months), Phase 1 (12 months), and Phase 2 (15 months).

Anticipated funding breakdown per phase, per TA:

3.1 Phase 0 (9 months)

For the initial Phase 0 of the Program, the Government intends to select a single Offeror to perform the work for Technical Area 3 (the MS&A Testbed), and at least three Offerors each for Technical Area 1 (next-generation CDS), and Technical Area 2 (red-black networking). The designs for Technical Area 1 and Technical Area 2 will be captured in Digital Models from the multiple Offerors and integrated into the MS&A Testbed.

Tech demonstrations in Phase 0 will be necessary to evaluate the Technical Area 1 & 2 designs against the stakeholder mission threads over emulated end-to-end ground, air, and space network communications paths. The digital models for Technical Area 1 & 2 capture the designs in a responsive and re-useable digital framework which reduces risk, saves time and money, and improves overall quality.

Overall, the model-based testbed will be an ongoing contribution to this effort (in Phases 1 & 2), as well as for broader application as a leave-behind for DoD use beyond this effort. Figure 2 displays an example of the iterative process that is expected for establishing the MS&A framework. Use case scenarios will be developed by the government and refined to detail end-to-end use-case scenario(s) to be used for MS&A, testing, demonstration, and validation. The MS&A testbed will be established at AFRL Rome. This testbed will integrate Technical Area 1 & 2 Digital Models and additional use-case/scenario-driven traffic loading and models to capture all NtF-relevant end-to-end ground, air, and space network communications paths. Performance metrics will be established for Technical Areas 1 & 2 by defining and documenting threshold and objective performance metrics for latency, scalability, and Quality of Service (QoS), relative to each mission-specific use-case scenario to be used in testing and demonstration. The figure uses three iterations of this process as an example, the result is a demonstration that can be used as input for Phase 1. Each iteration may introduce new use-cases/scenarios that should be incorporated. Additionally, the resulting testbed and design output from Phase 0 will continue to be leveraged and improved throughout Phases 1 and 2. Phase 0 output will provide continued analysis, performance measurement, and demonstration.

Figure 2: Phase 0 Iterative Assessment Process Phase 0 of the project is focused on developing a mission-oriented Modeling, Simulation, and Analysis (MS&A) capability. This phase is comprised of three core components, each with specific objectives, output deliverables, test assets/support, test data descriptions, and data capture, management, and control.

The input to Phase 0 is the mission scenarios, in the form of information exchange requirements (IERs), which will be provided by the government. The IERs, specify a mission, platforms, message types, representing the mission scenario.

Next is the System Test Framework description for IER flows. The objective of this component is to develop system design documents capturing architecture, interfaces, functional diagrams, data flows, and mission data information types. The output deliverable is documentation of the system framework, and the testing will involve products that use mission thread IERs as test use cases. The test data will include the System Test Framework documentation, and the data capture, management, and control will ensure that the documentation resides at the appropriate security level and is accessible by the government team.

The third component is Modeling, Simulation, and Analysis (MS&A) for assessment. The objective of this component is to establish an in-house Technical Areas 1 & 2 MS&A testbed for algorithm implementation to test performance metrics (latency, scalability, Quality of Service (QoS), relative to mission-thread IERs). The output deliverables include the development of a Virtual Machine (VM) of High Technology Readiness Level (TRL) CDSs and its implementation in the MS&A testbed, the development of a CDS Broker Service enabling dynamic discovery and dynamic reconfigurability functions for CDS, and the implementation, test, and validation of the CDS Broker Service in the MS&A testbed. Additionally, this component will develop models for operationally relevant end-to-end ground, air, and space network communications paths. The test support involves evaluating mission thread IERs against Technical Areas 1 & 2 performance metrics (latency, scalability, QoS) for end-to-end ground, air, and space network communications paths. The data includes MS&A hardware and software, and the data capture, management, and control will be performed in-house at AFRL/RI.

3.2 Phase 1 (12 months)

Phase 1 will be focused on developing a mature testbed capability for Engineering & System Test. The objective of this phase is to develop a high-maturity hardware build out for system-level integration and implementation of Technical Areas 1 & 2. The output deliverable will be a TRL – 5 capability that includes performance parameters, system level integration and validation on both hardware and software.

The demonstrator will show:

Tech demonstrations in Phase 1 are necessary to show that a reference implementation of the Technical Area 1 & 2 designs are implementable in hardware/software and the demonstrations will yield data necessary to validate functional performance of Technical Areas 1 & 2 in a relevant environment at TRL 5, over-the-air (e.g., Emerald Flag).

3.3 Phase 2 (15 months)

Phase 2 will develop system-level integrated implementations of Technical Areas 1 & 2 in a relevant environment at high fidelity. The output will be a TRL – 6 capability and include a hardware and software demonstration in a relevant venue to showcase the maturity and features to stakeholders.

Tech demonstrations in Phase 2 are necessary to exemplify an integrated multi-Offeror interoperable capability from Technical Areas 1 & 2 in an operationally relevant environment at TRL 6.

4. Schedule and Deliverables

This program will span three years and entail multiple deliverables under each Technical Area across each phase. Additionally, there are specific program milestones identified and measurable values used to determine both progress and success.

4.1 Schedule

NtF will span FY24 – FY27 across three phases, however Phase 0 will continue to have impacts throughout the entirety of the program. This is showcased in Figure 3. The figure shows how MS&A, developed in Phase 0, will be utilized throughout the phases to perform validation.

Figure 3: Planned Schedule

4.2 Deliverables

Major deliverables for NtF include an updated government-owned MS&A environment and government-owned reference implementations. Each Offeror will be responsible for first demonstrating interoperability of their approach within the government owned MS&A environment and furthermore with the government owned reference implementations prior to acceptance of product delivery. The government owned ICD will be built through direct collaboration between the Offerors working across each Technical Area led by the government team. Testing will verify compliance to interoperability test cases driven by/derived from the ICD. In Phase 2, the Offerors will be required to perform system integration across Technical Areas 1 and 2 and demonstrate the full capability with end-to-end interoperability across both Technical Areas. Required components of the Interoperability Test Plan & Certification Process deliverable outlined in Section 5.2 include:

1) Separately classified security enclaves and appropriate filtering between them.

2) Controlled data flows over a surrogate black network between two red networks.

3) Updated data flow set, message support, and red/black information flows in response to a change in a simulated change in commanders’ intent (mission change) in real-time.

NtF will identify the appropriate software services required to control the underlying network hardware and the functional components required but does not prescribe the specific implementation within the underlying hardware infrastructure.

· Digital Models for Technical Areas 1 and 2

· Updated Simulator plugins for security domain simulation and crypto boundaries

· MS&A Testbed infrastructure

· Models to represent relevant end-to-end scenarios

· Interoperability Test Plan and Certification Process (Phases 0, 1, 2)

· LBSA (Lab based Security Assessment) Documentation for Reference Hardware Implementation deliverable (Phases 1 and 2)

· MS&A results capturing NtF Performance improvements (Phases 0,1,2)

Table 2: Deliverables

4.3 Milestones

· Detect flaws at earlier stages in the development process, saving time and money and improving overall quality

· Reduce risk

· More quickly enable concept validation, observations, and analytics

· Enhance scalability

Table 3: Milestones

5. Program Metrics

Each Technical Area will have key metrics used to assess performance. These metrics will also be used to demonstrate the value NtF adds when executing stakeholder provided mission threads. It is critical that these metrics be capturable in the MS&A testbed.

5.1 Technical Area 1: Next Generation CDS Broker Metrics

An important metric used to assess the value NtF provides is latency, the elapsed time for a message to transit the network of networks and the time required to configure links/CDS.

Mission requirements will dictate different latency requirements for a variety of reasons (data type, mission sensitivity, hardware, etc.). Latency demands may not align with mission needs for specific payloads, e.g., prioritization strategies might be considered to address such challenges. The proposed CDS Broker must convey latency data to the local information management system to facilitate optimized end-to-end route calculations.

Another important metric used for determining NtF performance is scalability by maintaining flow of information across heterogenous networks as network size and complexity vary (# nodes, # classification levels, message volume, # CDSs). Understanding the dimensionality of scale for communication needs is crucial to evaluate how data flows adapt based on the changing number of nodes with potentially different capabilities available for performing distributed CDS operations. The CDS Broker data flow capacity must be able to scale up or down depending on the mission load, constraints of a DDIL environment, available CDSs, data types of each CDS, etc.

Lastly, the ability to dependably manage CDS workloads via the CDS Broker to meet mission requirements and to pass sufficient information/metadata to allow downstream traffic management to effectively manage Quality of Service (QoS) at the application/mission level will be assessed and reported as a performance metric. This information may include Simple Network Management Protocol (SNMP)/CDS Management Information Base (MIB) data to track CDS workload, as well as network link information (e.g., bandwidth, jitter, packet delay (latency), packet loss). QoS enables the effective management of 'red overlay' on a black network, providing insight into red/black network operations.

The CDS test strategy will be a phased approach, beginning with implementing a lab test environment with a virtualized CDS (e.g., X-ARBITOR). The test environment will also provide for the necessary network services, including pub/sub. Initial testing will validate functionality between two simulated security domains. Development and testing will leverage an agile, iterative approach to add functionality (e.g., additional filters, remote management capability) and scalability (e.g., additional simulated security domains). This testbed will be used for MS&A of different use case scenarios, including failed message transfers due to policy violations, and constraining communications to simulate a contested environment. The MS&A will also assess performance of the proposed approach, including latency, QoS and resiliency. Next, additional development, integration and scalability testing will be conducted, including interfacing with multiple CDSs, each supporting different data types. The next phase of testing will leverage operational equipment from targeted airframes to validate functionality. The demonstration will support both structured and unstructured data types, using different CDSs. At completion of this proposed effort, the prototype will demonstrate the two key objectives of discoverability and reconfigurability for a simulated mission operation, with data transfer between three simulated security domains. Final stage of testing will include flight testing.

Several Key Performance Parameters (KPPs) will be assessed during each phase. Some of the targeted KPPs for TA 1 include:

• Number of Security domains supported simultaneously

· Number and types of CDSs supported simultaneously