DARPA-BAA-14-02_Communications_in_Contested_Environments_(C2E).pdf

Broad Agency Announcement

Communications in Contested Environments (C2E)

STRATEGIC TECHNOLOGY OFFICE

DARPA-BAA-14-02

December 20, 2013

DARPA-BAA-14-02, Communications in Contested Environments (C2E)

TABLE OF CONTENTS

Part Two: Full Text of Announcement

1. FUNDING OPPORTUNITY DESCRIPTION

1.1. PROGRAM OVERVIEW

1.1.1 Technical Area 1: Heterogeneous Networking and Advanced Communication Technologies Development and Demonstration

1.1.2 Technical Area 2: Reference Hardware Architecture

1.1.3 Technical Area 3: Software Architecture, Development Environment and

Tool Set, Verification Environment, and Repository

1.2 SCHEDULE

1.3 PROGRAM METRICS

2. AWARD INFORMATION

2.1 Fundamental Research

3. ELIGIBILITY INFORMATION

3.1 ELIGIBLE APPLICANTS

3.2 Procurement Integrity, Standards of Conduct, Ethical Considerations, and Organizational Conflicts of Interest

3.3 COST SHARING/MATCHING

3.4 OTHER ELIGIBILITY REQUIREMENTS

3.4.1 Collaborative Efforts

4. APPLICATION AND SUBMISSION INFORMATION

4.1 ADDRESS TO REQUEST APPLICATION PACKAGE

4.2. CONTENT AND FORM OF APPLICATION SUBMISSION

4.2.1 SECURITY AND PROPRIETARY ISSUES

4.3 CONTENT AND FORM OF APPLICATION SUBMISSION

4.3.1 Abstract and Proposal Information

4.3.2 Restrictive Markings on Proposals

4.4 FORMATTING CHARACTERISTICS

4.4.1 Proposal Abstract Format

4.4.2 Proposal Format

4.5 SUBMISSION DATES AND TIMES

4.5.1 Abstract Submission Deadline

4.5.2 Proposal Submission Deadline

4.6 FUNDING RESTRICTIONS

4.7 OTHER SUBMISSION REQUIREMENTS

5. APPLICATION REVIEW INFORMATION

5.1 EVALUATION CRITERIA

5.1.1 Overall Scientific and Technical Merit

5.1.2 Potential Contribution and Relevance to the DARPA Mission

5.1.3 Realism of Proposed Schedule and Cost

5.1.4 Proposer’s Capabilities and/or Related Experience

5.1.5 Plans and Capability to Accomplish Technology Transition

5.2 REVIEW AND SELECTION PROCESS

6. AWARD ADMINISTRATION INFORMATION

6.1 SELECTION NOTICES

6.2 ADMINISTRATIVE AND NATIONAL POLICY REQUIREMENTS

6.2.1 MEETING AND TRAVEL REQUIREMENTS

6.2.2 HUMAN SUBJECTS RESEARCH

6.2.3 ANIMAL USE

6.2.4 EXPORT CONTROL

6.2.5 SUBCONTRACTING

6.2.6 ELECTRONIC AND INFORMATION TECHNOLOGY

6.2.7 EMPLOYMENT ELIGIBILITY VERIFICATION

6.2.8 System for Award Management (SAM) Registration and Universal Identifier

Requirements

6.2.9 Reporting Executive Compensation and First-Tier Subcontract Awards

6.2.10 Updates of Information Regarding Responsibility Matters

6.2.11 Representation by Corporations Regarding Unpaid Delinquent Tax Liability or a Felony Conviction Under Any Federal Law – Fiscal Year 2013 Appropriations (Deviation 2013-O0010)

6.2.12 Representations by Corporations Regarding an Unpaid Delinquent Tax Liability or a Felony Conviction Under Any Federal Law – Fiscal Year 2014 Appropriations (Deviation 2014-O0004)

6.2.13 Cost Accounting Standards (CAS) Notice and Certification

6.2.14 Controlled Unclassified Information (CUI) on Non-DoD Information

Systems

6.3 REPORTING

6.4 ELECTRONIC SYSTEMS

6.4.1 Representations and Certifications

6.4.2 Wide Area Work Flow (WAWF)

6.4.3 i-EDISON

6.4 AGENCY CONTACTS

7. OTHER INFORMATION

7.1 INTELLECTUAL PROPERTY

7.1.1 Procurement Contract Proposers

7.1.2 NonProcurement Contract Proposers

8. APPENDIX 1: PROPOSAL SLIDE SUMMARY

9. APPENDIX 2: Volume 1 Cover Sheet Template

10. APPENDIX 3: Volume 2 Cover Sheet, Checklist and Sample Templates

Part One: Overview Information

Federal Agency Name – Defense Advanced Research Projects Agency (DARPA), Strategic Technology Office (STO)

Funding Opportunity Title – Communications in Contested Environments (C2E) Announcement Type – Initial announcement.

Funding Opportunity Number – Broad Agency Announcement (BAA) 14-02 Catalog of Federal Domestic Assistance Numbers (CFDA) - Not Applicable Dates:

o Posting Date: December 20, 2013 o Proposer’s Day: December 19, 2013 o Proposal Abstract Due Date: January 21, 2014 o Proposal Due Date: February 14, 2014 o BAA Closing Date: June 30, 2014

Anticipated individual awards - Multiple awards are anticipated.

Types of instruments that may be awarded - Procurement contract or other transaction.

Agency contact:

o Points of Contact The BAA Coordinator for this effort may be reached at, electronic mail:

DARPA-BAA-14-02@darpa.mil

DARPA/STO

ATTN: DARPA-BAA-14-02

675 North Randolph Street Arlington, VA 22203-2114

Part Two: Full Text of Announcement

1. FUNDING OPPORTUNITY DESCRIPTION

The Defense Advanced Research Projects Agency often selects its research efforts through the Broad Agency Announcement (BAA) process. This BAA is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 35.016.

Any negotiations and/or awards will use procedures under FAR 15.4, Contract Pricing, as specified in the BAA. Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FedBizOpps) website, http://www.fbo.gov/. The following information is for those wishing to respond to the BAA.

DARPA is soliciting innovative research proposals in the area of heterogeneous communication networking and rapid capability deployment through a reference architecture. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems. Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

1.1. PROGRAM OVERVIEW

Adversary systems designed to intercept, deny and exploit U.S. tactical communications continue to evolve with increased capability and decreased cost of fielding, creating a highly contested region of the battle space for U.S. forces. To counter this threat, the DoD has advanced the link capacity of a wide range of data radio systems. These advances focus on the individual node performance but do not address the problem of overall network performance and network pervasiveness in particular. DARPA expects continued growth in sensor systems, unmanned systems and networked weapon systems will drive the need for larger, more pervasive networks. DARPA also expects adversary systems to continue to improve, causing a need for improved jamming resistant communication systems and difficult to detect communication systems. Finally, DARPA expects demand for more diverse services in the airborne battle space.

Prior military communications efforts have focused on solving all of these problems with a single, new radio system. However, the cost and logistical complexity of upgrading all aircraft platforms with a new radio system is untenable. Therefore, military forces will need to continue to make use of existing communication systems while new capabilities are provided on upgraded and future airborne platforms. The military cannot expect a single, new radio system to provide the required capability; rather networking solutions that make use of current communications capabilities along with progressively improving capabilities are desired.

Pervasiveness in commercial communications systems is accomplished with backhaul infrastructure. Fundamentally, this infrastructure provides heterogeneous networking. While the military cannot expect infrastructure to solve the airborne networking issues, it can seek heterogeneous networking technology to improve the size and performance of airborne networks while supporting legacy communications and allowing the evolutionary addition of new communications capabilities. Heterogeneous networking allows legacy communications to coexist with emerging capabilities.

An additional issue addressed by the C2E program is the inability to incorporate new technologies in our existing communications system architectures. The communications systems architectures used in today’s military systems provide rugged, reliable services but are inflexible and cannot be expanded to adapt to demands for increased or different performance.

Commercial communication systems have revolutionized flexibility in the last decade with the advent of the smart phone architecture. Consumers no longer purchase commercial communications technology with an expectation of a fixed capability; instead consumers expect continuous, evolutionary upgrades to purchased systems. The C2E program seeks a development environment and system architecture for military communications systems that provides similar flexibility, along with the capability to refresh our communications capabilities, to match application demands and changing adversary threats.

The development environment used in commercial communications systems allows for the incorporation of technology from third parties that are neither the hardware developer nor the core software provider. Providing third party technology access has enabled commercial systems to support an increasing variety of unanticipated applications, increased the pace of technology evolution and increased the competitiveness of the application market. The C2E program seeks to enable similar capabilities in military communications systems while retaining the resilience capability of today.

To address advances in adversary capabilities detailed above, the C2E program seeks innovations in three major technical areas (TAs):

1. TA1 – Heterogeneous Networking and Advanced Communication Technologies Development and Demonstration – Networking capability to improve pervasive services while accommodating legacy platform capabilities; communication technologies to increase data rate, improve jamming resistance, reduce detectability and decrease latency; development and demonstration of communication and networking technologies.

2. TA2 – Reference Hardware Architecture – Signal and data processing hardware architecture for nodes of a communication system that is used by TA1 performers and accommodates new and improved communications capabilities, and

3. TA3 – Software Architecture, Development Environment and Tool Set, Verification Environment, and Repository – A development environment that allows the incorporation of third party application and waveform technology and the rapid refresh of these capabilities by TA1 performers.

Proposers may bid on any or all technical areas or a subset in one or more proposals. Proposers are encouraged to understand the modularity goal of the program, which envisions a cooperating group of performers updating different parts of the composite system independently and at different times, and offer an approach that meets this goal and highlights their strengths. In light of this goal, bidders are encouraged to focus on the areas where they can make the most significant contributions and proposals to address the entire program are not necessary.

1.1.1 Technical Area 1: Heterogeneous Networking and Advanced Communication Technologies Development and Demonstration The C2E program solicits research on networking methods to create a pervasive communication environment allowing communication to, from, and between the wide variety of airborne platforms, both existing and expected, in a variety of situations and in support of a variety of missions. Communications between air vehicles, to and from air vehicles and ground platforms, and to and from sea vehicles are included in the scope of this program.

The platforms of interest are both small and large, manned and unmanned, and with all combat and support roles. Vehicles may include manned fighters, bombers, command and control (surface or airborne), and support vehicles (such as tankers) and unmanned vehicles (surface or airborne) acting as sensors or weapons. The platforms may include legacy vehicles that cannot be modified, legacy vehicles that may be modified, and new vehicles that have not yet been deployed or designed. The C2E program expects that support for networks larger than 300 vehicles is required.

The airborne network is a complicated system of systems. It is far more complicated than the communications system deployed today. However, the C2E program requires that the operator burden is less than that required today. It is imperative that pre-flight configuration is minimal and that in-flight operation and reconfiguration is automatic. It is not acceptable to burden the pilot with network configuration tasks.

The goals of this technical area are two fold – a) to develop networking technology to improve pervasiveness while accommodating legacy and emerging communications capability (heterogeneous networking) and b) to develop new communications technology for increased capacity, improved jamming resistance, reduced probability of detection and reduced latency.

1.1.1.1 Heterogeneous Networking

The C2E program seeks significant advances in networking technology. It is unlikely that integration of existing networking technology will meet the goals of the program; such approaches are discouraged.

The following section discusses some of the expected airborne networking problems and some recent networking ideas to stimulate thought on possible solutions. It should be noted that none of these ideas have been proven in practice. These problems are open research areas and novel solutions are sought.

Deployed airborne communication systems are less sophisticated than current ground based MANET technology. A typical airborne “network” is a shared channel—all receivers must be in range of the transmitter and there is no support for forwarding of data traffic. Ground based MANET programs on the other hand have developed a plethora of protocols to route traffic along multiple hops from a source to a destination. However, the ground MANET research results are not sufficient for the airborne environment as they lack the scalability required for the future airborne network.

Information theory results have proven that MANET networks which move data globally along routes cannot scale infinitely [P. Gupta and P. R. Kumar, The capacity of wireless networks, IEEE Transactions on Information Theory, 46:388–404, 2000] and that even the simple task of maintaining knowledge of all neighboring nodes cannot scale infinitely [Parker et al., DARPA Far Out Networking Symposium (FONS), 20131]. Existing MANET protocols based on link-state routing, with its heavy dependence on globally propagated data, collapse relatively quickly, particularly when dynamic characteristics of airborne platforms are considered. The collapse can be delayed by the provision of additional capacity, but it is unlikely that sufficient capacity can be created to satisfy the needs of the airborne network in this manner.

However, some recent results indicate that network protocols designed with the right restrictions may be able to scale sufficiently to meet the airborne network scale requirements. The maximum network scale is heavily dependent upon the amount of global traffic, in both the data and control planes. Thus limiting or controlling the spread of data throughout the network is required, so that for the most part, the network usage appears local. Some traffic may still be distributed globally but heterogeneous systems must consider local dissemination as much as possible and be able to differentiate between global and local traffic by application needs. There has been some analysis of the effect of varying the proportions of local and global data, but more research is needed in this area. [Ramanathan, FONS, 2013; Abouzeid, FONS, 2013; Parker et al., FONS, 2013].

Airborne network protocols follow new paradigms that provide a variety of data sharing primitives that take into account the information requirements of the network nodes, the available resources, the situation, and the mission. Recent papers have called this type of protocol Information Sharing Patterns [Hammel, FONS, 2013] or Application Specific Networking Patterns [Parker, et al., FONS, 2013]. The approaches differ in the specific patterns proposed, but share the idea of tailoring the distribution approach to the actual data sharing needs of the applications. Recently, a data sharing pattern approach has been successfully demonstrated on a 50-node statically deployed network [DARPA ADAPT Program]. Other data-centric approaches, such as opportunistic caching and redistribution of data from multiple nodes may lessen the overall network load [DARPA CBMEN Program].

Some nodes may support multiple physical implementations and some may support only one implementation. It is conceivable that two adjacent nodes with the need to exchange data cannot communicate directly because they do not share a common physical layer implementation. The network protocol must discover a means to share this data, automatically, and without user configuration or intervention. Knowledge of the local network topology may be beneficial, but global topology knowledge is likely as cost prohibitive as global routing.

Certain nodes may have excess capability and be in a position to assist other nodes. Concepts such as virtual infrastructure, in which a set of more capable and more stable nodes unite to supply a network backbone that emulates the wired infrastructure of a traditional cellular system and provides support services to the more mobile and less capable nodes, may be useful. It may also be possible to alter the network topology in support of the current information sharing needs by configuring the physical communication interfaces or even by redeploying platforms.

[Krishnamachari, FONS, 2013; Santi, Paolo. "Topology control in wireless ad hoc and sensor networks." ACM Computing Surveys (CSUR) 37.2 (2005): 164-194. ]

1 FONS papers referenced in this solicitation can be found at:

http://www.darpa.mil/Our_Work/STO/STO_NewsEvents.aspx

A viable airborne network will have to adopt novel concepts such as these. Offerors should thoroughly describe their networking approach and demonstrate that it meets the pervasiveness goals of the C2E Program.

1.1.1.2 Advanced Communication Technology and Implementation

The contested communications environment will require performance improvements in several areas to counter the increased sophistication of our adversaries, namely:

Increased Jamming Resistance Reduced signal detectability Reduced latency for remote controlled systems Increased data rate

Advanced communications technologies are sought to meet these expanding needs while retaining interoperability with legacy communications capabilities.

TA1 will consist of four spirals as shown in Figure 7 (Section 1.2). The first two spirals will focus on networking with Spiral 1 demonstrating basic interoperability with legacy systems and Spiral 2 showing advanced, heterogeneous networking as described in the previous section.

Spiral 3 will incorporate AJ and LPD improvements and Spiral 4 will incorporate capacity and latency improvements. The specific requirements for Range, Rate, Jamming Resistance, Detectability and Latency will be coordinated with the Government team and the contractors during the first year of the program. For the purposes of proposal preparation, the following thresholds for Spiral 3 and Spiral 4 performance should be assumed:

Spiral 1 Spiral 2 Spiral 3 Spiral 4

Frequency L‐band L‐band L‐band, microwave band L‐band, microwave band

Range (nmi) 100 100 100 300

Data Rate 2 Mbps max rate 1Mbps at range

2 Mbps max rate 1Mbps at range

2 Mbps max rate 1 Mbps at range

20Mbps max rate 5 Mbps at range

Jamming resistance (over non‐AJ mode)

None None >30 dB >40 dB

Detectability (over unenhanced waveform)

None None <‐20 dB <‐30 dB

Latency (us) 10 ms 10 ms 10 ms 250 us

Other features Interop with Link 16 and one other L band waveform

Networking using more than 1 waveform

Networking using spatial signal control

Reference HW Implementation (see section 1.2)

V1 V1 V2, V3 V4

The objective performance requirements will be mutually determined by the selected contractors and the government team during the high level design phase depicted in Figure 7.

1.1.1.3 Development and Demonstration Plan

The development and demonstration of network architecture and advanced communication technology are sought. The network architecture must support the pervasive communications among heterogeneous ground and airborne platforms at the intended scale of more than 300 nodes. The architecture must solve the interrelated problems of distributing data in support of application needs, managing or overcoming disjoint topology, and adapting to security concerns.

It must support usage of multiple physical layer implementations. It must lessen or eliminate the operator configuration burden. It must support the easy substitution of new or modified components. And it must allow evolution to include new capabilities at all layers—physical, network, and application.

A notional schedule is shown in Section 1.2. Proposals may propose deviations from this schedule with supporting data and rationale. A final program wide schedule must be coordinated across all task areas. A notional development plan is shown in the following table. Each spiral should be priced separately as an option. Proposals should detail the capabilities to achieve in each spiral.

High Level planning effort

Network Architecture, Protocol Emulation

Anti‐Jam, Detectability, Latency, Capacity and Range requirements coordination

Demonstration Plan coordination

Spiral 1

Link‐16 and second L‐band waveform implementation on V1 reference hardware

Initial Network protocol implementation on V1 reference hardware

Spiral 2

Full network protocol implementation on V1 reference hardware

Spiral 3

LPD/AJ waveform implementations on V2 reference hardware

Network protocols extended to support AJ/LPD requirements (V2 hardware)

Network protocol implementation on V3 (small form) hardware implementation

Spiral 4

New waveforms for high capacity, low latency on V4 high performance hardware

Proposals must include a mechanism to demonstrate performance which may involve analysis, simulation, emulation, and/or flight data collection. The government team will coordinate test and demonstration plans during the first spiral. Proposals should detail the expected demonstrations and provide estimated demonstration costs to assist with test and range planning.

1.1.2 Technical Area 2: Reference Hardware Architecture

The Communications in Contested Environments program places diverse requirements on hardware implementation. A contested communications concept of operations involves networking among airborne and surface platforms such as UAVs, fighters, bombers, and ISR sensor systems and Command and Control systems operating in graded contested environments.

Operators in the graded contested environment experience varying levels of electronic counter measures (ECM), signature exploitation and other threats. Additionally, the architecture must support increased number of nodes, higher capacity, improved connectivity over larger ranges, increased robustness to interference, higher reliability network operations while achieving new state of art in terms of affordability, flexibility, scalability, maintainability, and upgradeability.

Existing networking and node architectures are monolithic, stove-piped, and rigid; over-constraining innovation, technology insertion, and interoperability. A new approach is needed to support diverse platforms with the flexibility to evolve in relevant timeframes. The C2E program approach is to address diversity and flexibility with a two-pronged approach – a new hardware architecture (described in this section) and an application/waveform development environment described in section 1.1.3.

The goal of the reference hardware architecture is to enable the incorporation of new communication technology into a contested environment in a timely manner. The current approach to hardware implementation on platforms in this environment is illustrated notionally in Figure 1.

Figure 1, Notional Architecture used in existing airborne systems

In the existing architecture, programmable Software Defined Radios (SDR) are used to implement each waveform that might be needed on a platform. While these products profess flexibility due to their programmability, each radio is still a stovepipe implementation, interactions between radios is difficult to control, and verification of a large “stack” of radios is difficult. As a result, it is a long and difficult process to add, change or modify the communications capability of a system implemented in this manner.

The C2E concept is illustrated in Figure 2 to contrast C2E from the current approach.

Figure 2, Notional C2E communications architecture

The C2E architecture divides radio functions into three parts – Applications Processing, Waveform Processing, and Transceivers. The Applications Processing combines all of the non-real-time processing functions that are needed by a collection of waveforms. The Waveform Processor provides the real-time processing functions needed to create, synchronize and/or receive a collection of waveforms needed by a platform. Finally, individual transceivers convert the waveforms to/from the frequencies and beams needed to support the platform’s operation. (In this construct, transceivers are no longer dedicated to specific waveforms but instead are allocated to providing access to particular spectrum and beamshape to/from the platform.)

This architecture is meant to improve the interaction between applications and between waveforms by separating and then amalgamating the similar functions. Both the applications and waveforms can be better supported by a development environment and a scalable reference architecture can support system complexity ranging from simple platforms that may only need a couple of simultaneous waveforms to complex platforms support dozens of waveforms. Co-site issues and verification faults can be more easily mitigated by this separable architecture. Finally, each element of the architecture – application hardware, application software, waveform processing hardware, waveform processing software/firmware and transceivers – can be refreshed at independent, technologically appropriate intervals – achieving the C2E goal of adding, modifying and changing communication capability in a relevant timeframe.

It is the Government’s intention to establish a Government controlled reference architecture consistent with Figure 3 for contested environment platforms. Numerous, specific implementations of this architecture – suitable for platforms ranging from small UAVs and weapons to large, complex aircraft – are possible such that a common reference development environment is practical. Based upon selected approaches TA2 performers will contribute details to the government controlled reference architecture and create specific implementations of the architecture for small and medium size implementations. The reference architecture is intended to be an evolving standard.

Figure 3, Notional Reference Architecture

The applications processors, waveform processors, and transceivers are expected to be interface aware so that they can learn the capabilities of the devices to which they mate. “Plug and play” between applications processors, waveform processors, and transceivers is expected and the reference architecture is intended to ensure this compatibility. Strict interface definitions between Applications processors, Waveform processors, and transceivers is not planned to allow evolution of these components and their interfaces as technology advances. Instead, an interface definition that supports discovery of evolving capabilities is desirable.

In addition to these general features, the reference hardware architecture should also address the following program objectives:

a. Independent refresh of applications and hardware refresh intervals

1. 18 month typical upgrade cycles for the processor hardware

2. 3 year typical upgrade cycle for waveform firmware

3. 5 year typical upgrade cycle for waveform hardware

b. Ability to configure and concurrently run several waveforms

1. Small platforms – 2 to 4 waveforms (e.g., UAV, missile)

2. Medium platforms – 4 to 6 waveforms (e.g., pod or communications subsystem)

3. Large platform – 18 to 24 waveforms (e.g., complex aircraft or sensor system)

c. Legacy waveform support (e.g., TTNT and Link-16 waveforms for demo in Spiral 1)

d. Expandability to support additional waveforms and signal complexities:

1. Other legacy waveforms (e.g., MADL, IFDL) in future upgrade cycles

2. Future waveforms enabling directional, multi-antenna communication

3. Future Anti-jam (AJ) capabilities

4. Future Low probability of detect (LPD) and low probability of intercept (LPI) capabilities

5. Heterogeneous networking services (described in TA1)

6. Beyond-line-of-sight (BLOS) communications capabilities

e. Support for communications security and transmission security

f. Support for autonomous communication system management (to minimize preflight operations and pilot work load)

TA3 performers are creating a development environment to support the reference architecture and the reference implementation will be used by the TA1 performers for development and demonstration of waveform and networking technology. To provide this interaction, the TA2 Reference Architecture must be defined 3 months after contract award and a “golden master” - a version of the reference architecture that is built, tested and provided to TA1, TA2 and TA3 performers by the end of Q2FY15 as shown in Section 1.2 (Target Design). This “golden master” implementation of the reference architecture will be used for development and for interoperability compliance testing of future instantiations of the reference architecture from the developer community.

Three upgrades to or variations of the “golden master” are planned – a version to support additional frequency bands and spatial signal control (Revision 2: AJ/LPD), an example implementation for small form factor use (Revision 3: Small Form Factor), and a revision for increased processing power in the applications processor and waveform processor (Revision 4:

High Performance). Notional timelines for these revisions are shown in section 1.2 but proposers are expected to propose a timeframe that can be accomplished and performance that can be achieved for these versions.

This process is similar to the process used in commercial industry communications standards bodies. For example, the 802.11 standards body, made up of vendors in the 802.11 space, decides upon a reference architecture and members create specific implementations of the standard. Early in the process, one or more vendors equipment is designated the “golden master” and provided to all members of the standards body to verify their own hardware and software implementations of the standard. In the C2E version of this process, the government will maintain the reference architecture; industry will contribute to the architecture and create specific implementations of the architecture for target platforms.

Proposers should include test procedures, processes, and jigs as required to test the developed hardware.

The chief goal of the C2E program is to open the development of network protocols and waveforms to a multitude of third party developers in order to spur quality improvement, reduce or eliminate hardware porting costs, decrease development and verification timelines, and allow rapid evolution of capabilities in fielded systems.

1.1.3 Technical Area 3: Software Architecture, Development Environment and Tool Set, Verification Environment, and Repository The C2E program develops software technology to allow rapid development, verification, insertion, and operation of communication technology in new and existing systems. The key areas are the following:

1. A Software Architecture, that allows applications, protocols, and waveforms to be developed and verified independently from other applications, protocols, and/or waveforms.

2. A Development Environment that provides all tools required to develop software or firmware for C2E systems.

3. A Verification Environment that supports the testing and verification of newly developed applications meets functional and quality metrics.

4. An Application Repository for the storage and refresh of new and innovative applications.

The interaction between the major elements of TA3 and TA2 are depicted in Figure 4.

Figure 4, Vision for C2E Verification Flow End-to-End

1.1.3.1 Software Architecture (SA)

The Software Architecture supports the development and operation of software and firmware on the Application processor and Waveform processor described in section 1.1.2. Applications and Waveforms are developed independently by multiple performers. Applications and Waveforms support multiple instantiations of hardware, similar to how applications and waveforms developed in the smart phone world can be installed on different vendor’s products and may be used on phones as well as tablet versions of hardware. A notional depiction of the Software Architecture is shown in Figure 5.

Protected functions support the security and survivability of the platform while easing the development of applications by presenting applications programming interfaces to native applications and peripheral functions. Protected functions support standardized code constructs for commonly used functions, protect intellectual property as needed and ensure regulatory compliance when necessary.

Native applications can access protected functions through loosely coupled APIs appropriate for the specific functions. Other APIs and device drivers support peripheral access for the system.

Native applications can be added or modified as mission needs evolve much like Smart Phone applications evolve as customer needs change.

Figure 5, Notional Software Architecture

The software architecture should provide all common software function as well as those specific to the C2E mission. Proposals should detail the expected functions and interfaces.

In particular, proposals should describe the expected interfaces between waveforms and the hardware transceivers and between waveforms and higher layer network and application modules. Of prime importance is the abstraction describing these interfaces to allow commonly programmed and portable access to features while preserving the full performance potential of the layers. The application interfaces shall evolve over time as new features are added at various levels. The software architecture shall support, not inhibit, this evolution.

1.1.3.2 Development Environment (DE)

The Development Environment supports the development of applications, waveforms, and critical functions. A notion of the process flow supported by the development environment is illustrated in Figure 6.

The Development Environment includes all tools—editors, compilers, linkers, debuggers, emulation environments—to support the development of network protocols and waveforms. It includes support for using a variety of computing engines—general CPUs, DSPs, FPGAs, GPUs—present in the reference hardware architecture. The Development Environment should abstract from the developer the notion of specific hardware functional units (e.g. GPP, FPGA, and GPU) or brands and provide tools to support the efficient usage of the computing engines available on the various hardware reference designs.

The Development environment should include code libraries, modules, and building blocks which support the C2E mission of developing pervasive heterogeneous commination capability.

Reference implementations of commonly used blocks should be provided.

The proposer should detail the tools and building blocks proposed.

Proposers should note that four variations of hardware implementation are expected over the life of the program as described above under TA2.

Figure 6, Notional Process Flow for the Reference Development Environment

1.1.3.3 Verification Environment (VE)

Verification of new or modified communications systems is a costly and time-intensive task. The C2E program wants to reduce the time and expense by conducting verification and validation on smaller modules as they are created or modified. This verification may be performed on a single module or in a complete test and verification suite.

The Verification Environment may include simple hardware emulators for the various computing engines included in the reference hardware architecture to hardware in the loop emulation systems for complete, multi-mode systems.

The proposer should propose an appropriate mix of tools and models to satisfy the goal of accelerating and simplifying the verification of new waveforms and network protocols.

1.1.3.4 Application Repository (AR)

The Application Repository is a clearing house for the storage and distribution of developed applications. The repository enables hardware vendors to access and incorporate a multitude of value added applications into their platforms. It offers third party developers a centralized place to obtain existing support libraries and applications and a market place for the distribution of new and innovative applications. The repository mimics a combination of the application stores used in the commercial Smart Phone industry as well as the libraries supported by the development tools used in the Smart Phone industry. Some applications may be freely available and other applications may be restricted or have a cost.

A software architecture, development environment and tool set, verification environment, and repository are sought. The software development environment, tool set, and reference implementations must support the development, testing, integration, and fielding of pervasive communications among heterogeneous airborne platforms at the intended scale of a few hundred nodes. It must support development, testing, and fielding of novel networking protocols. It must support development, testing, and usage of multiple physical layer implementations. It must lessen or eliminate the operator configuration burden. It must support the easy substitution of new or modified components, and it must allow evolution to include new capabilities at all layers—physical, network, and application.

The software development environment, tool set, and reference implementation should be completed with three releases approximately 1 year apart. Each release should be priced separately as options. Proposals should detail the intended release and the capabilities that will be achieved in each release. Proposals must include a mechanism to evaluate performance which is based on the quality of support supplied to the networking developers.

A notional schedule is shown in Section 1.2. Proposals may propose deviations from this schedule with supporting data. A final program wide schedule must be coordinated across all task areas. This effort is executed in conjunction with the TA1 and TA2 performers to ensure that the development environment and reference hardware architecture are appropriate to support network implementation in later stages. A development environment for networking software is expected to be supplied by the end of the first release on at least one reference hardware platform.

Later releases provide support to the TA1 network developers to produce multiple waveforms, enhance the development environment, tool set, and building blocks as necessary to support additional waveforms, and provide a release update to support additional hardware platforms.

Many of the features of the software architecture and development environment may be met by standard, off-the-shelf components. Proposers are advised to emphasize the features of their approach that satisfy the unique C2E goals and challenges. For example, a recitation of the features of the Linux operating system, the Eclipse development environment, and the git repository system is unlikely to distinguish your approach from many others.

The chief goal of the C2E program is to open the development of network protocols and waveforms to a multitude of third party developers in order to spur quality improvement, reduce or eliminate hardware porting costs, decrease development and verification timelines, and allow rapid evolution of capabilities in fielded systems.

1.2 SCHEDULE

C2E will initiate all three technical areas concurrently and impose milestones ensuring cooperation across the program. Effort on the three task areas is not expected to be tightly coupled. Independent effort and independent refresh of capability is one of the goals of the program. In particular, the development and refresh of networking protocols and waveforms may proceed decoupled from hardware and software development environment revisions.

Figure 7: Notional C2E Schedule

1.3 PROGRAM METRICS

In order for the Government to evaluate the effectiveness of a proposed solution in achieving the stated program objectives, proposers should note that the Government hereby promulgates the following program metrics that may serve as the basis for determining whether satisfactory progress is being made to warrant continued funding of the program. Although the following program metrics are specified, proposers should note that the government has identified these goals with the intention of bounding the scope of effort, while affording the maximum flexibility, creativity, and innovation in proposing solutions to the stated problem.

Proposals should cite the quantitative and qualitative success criteria that the proposed effort will achieve by the time of each spiral’s program metric measurement.

Metric Value

Number of waveforms implemented on common hardware platform, hardware platform variation

2 (small form factor) > 4 (medium form factor) > 12 (large form factor)

Number of waveform vendors ≥ 4

Common code for waveform on more than one platform ≥ 90%

Common code for network protocol on more than one platform ≥ 99%

Time to implement new waveform ≤ 6 months

Time to verify new waveform operation with existing system ≤ 3 months

Time to implement new network protocol ≤ 6 months

Metric Value

Time to verify new network protocol operation with existing system ≤ 3 months

Time to port complete system to new hardware platform ≤ 3 months

Time to verify complete system on new hardware ≤ 3 months

Time to discover and configure interface ≤ 30s

Time to reconfigure system to support waveform ≤ 5s

Time to discover local topology ≤ 30s

Time to establish path between two nodes that must share data, with common waveform, direct neighbors

≤ 5s

Time to establish path between two nodes that must share data, without common waveform, ≤ 2 intervening hops

≤ 30s

Time to establish path between two nodes that must share data, without common waveform, > 2 intervening hops

≤ 5 minutes

Network overhead ≤ 10%

Waveforms supported

Link‐16, additional L‐band signals, jamming resistant waveforms low detection waveforms low latency waveforms high capacity waveforms

2. AWARD INFORMATION

Multiple awards are possible. The amount of resources made available under this BAA will depend on the quality of the proposals received and the availability of funds.

The Government reserves the right to select for negotiation all, some, or none of the proposals received in response to this solicitation, and to make awards without discussions with proposers.

The Government also reserves the right to conduct discussions if it is later determined to be necessary. If warranted, portions of resulting awards may be segregated into pre-priced options.

Additionally, DARPA reserves the right to accept proposals in their entirety or to select only portions of proposals for award. In the event that DARPA desires to award only portions of a proposal, negotiations may be opened with that proposer.

Awards under this BAA will be made to proposers on the basis of the evaluation criteria listed below (see section labeled “Application Review Information”, Sec. 5.), and program balance to provide overall value to the Government. The Government reserves the right to request any additional, necessary documentation once it makes the award instrument determination. Such additional information may include but is not limited to Representations and Certifications. The Government reserves the right to remove proposers from award consideration should the parties fail to reach agreement on award terms, conditions and cost/price within a reasonable time or the proposer fails to timely provide requested additional information.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Proposers are advised that if they propose grants or cooperative agreements, DARPA may select other award instruments, as it deems appropriate. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the program. For more information on publication restrictions, see the section below on Fundamental Research.

2.1 Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 established the national policy for controlling the flow of scientific, technical, and engineering information produced in federally funded fundamental research at colleges, universities, and laboratories. The Directive defines fundamental research as follows:

“Fundamental research means basic or applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein either cannot be met by proposers intending to perform fundamental research or the proposed research is anticipated to present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Therefore, the Government anticipates restrictions on the resultant research that will require the contractor to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate.

For certain research projects, it may be possible that although the research being performed by the prime contractor is restricted research, a subcontractor may be conducting contracted fundamental research. In those cases, it is the prime contractor’s responsibility to explain in their proposal why its subcontractor’s effort is contracted fundamental research.

The following statement or similar provision will be incorporated into any resultant non-fundamental research procurement contract or other transaction:

There shall be no dissemination or publication, except within and between the contractor and any subcontractors, of information developed under this contract or contained in the reports to be furnished pursuant to this contract without prior written approval of DARPA’s Public

Release Center (DARPA/PRC). All technical reports will be given proper review by appropriate authority to determine which Distribution Statement is to be applied prior to the initial distribution of these reports by the contractor. With regard to subcontractor proposals for Contracted Fundamental Research, papers resulting from unclassified contracted fundamental research are exempt from prepublication controls and this review requirement, pursuant to DoD Instruction 5230.27 dated October 6, 1987.

When submitting material for written approval for open publication, the contractor/awardee must submit a request for public release to the PRC and include the following information: (1) Document Information: document title, document author, short plain-language description of technology discussed in the material (approx. 30 words), number of pages (or minutes of video) and document type (e.g., briefing, report, abstract, article, or paper); (2) Event Information: event type (conference, principal investigator (PI) meeting, article or paper), event date, desired date for DARPA's approval; (3) DARPA Sponsor: DARPA Program Manager, DARPA office, and contract number; and (4) Contractor/Awardee's Information:

POC name, e-mail and phone. Allow four weeks for processing; due dates under four weeks require a justification. Unusual electronic file formats may require additional processing time. Requests may be sent either by-mail to prc@darpa.mil or via 675 North Randolph Street, Arlington VA 22203-2114, telephone (571) 218-4235. Refer to the following for link for information about DARPA’s public release process:

http://www.darpa.mil/NewsEvents/Public_Release_Center/Public_Release_Center.aspx.

3. ELIGIBILITY INFORMATION

3.1 ELIGIBLE APPLICANTS

All responsible sources capable of satisfying the Government's needs may submit a proposal that shall be considered by DARPA.

Federally Funded Research and Development Centers (FFRDCs) and Government entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations and cannot propose to this BAA in any…