Department of the navy (don) 18. 1 Small Business Innovation Research (sbir) Proposal Submission Instructions introduction

DESCRIPTION: The technology to be developed should:

a. Provide a VHF (30MHz - 300MHz) coupler system that incorporates technologies such as comb-filters and pre-distortion for up to 16 frequency channels that include single or multiple high-power amplifier(s) for each channel with frequency hopping, and at least 50dBW transmit power output without incurring significant interference effects (>3 dB). The output of the amplifiers should provide sample transmitted signals so the transmissions can be cancelled from the separate receive antenna. Optionally, the prototype HDR MCA may directly incorporate the interference cancellation feature; however, the samples of the transmitted signal must be provided as discreet outputs. The VHF coupler system supports 16 hopping transmit channels with 5 dBm input per channel. The number of channels supported should scale to 36 channels.

b. Provide an UHF (300MHz - 3GHz) coupler system and UHF amplifier with support for up to 24 frequency channels.

c. Provide linear amplification with Simultaneous Transmit and Receive (STaR) interference mitigation for Multi-Frequency Time Division Multiple Access (MFTDMA) carriers over the full High Frequency (HF) band (3MHz - 30MHz) with at least 50dBW total transmit power output and support MFTDMA channels with 5dBm input power.

PHASE I: Design an architecture for a HDR MCA that directly interfaces or integrates into the Digital Modular Radio (DMR) to yield high dynamic range amplification in VHF and UHF bands. Additionally, the HDR MCA shall facilitate hosting of emerging advanced waveforms such as HF Over-the-horizon Communication (HFORCE) in the HF band on DMRs and emerging HF radio systems (e.g., PRC-117G). Establish whether the amplifier can be produced as a single entity or a combination of multiple discreet amplifiers. If multiple discreet amplifiers are to be utilized, provide a management and control architecture concept required to easily integrate the HDR MCA into the target system. Develop the supporting amplifier architecture concept that will address high individual carrier power variations and mitigate the resulting intermodulation interference.

Identify the near term HDR MCA Pre-Planned Product Improvement (P3I) required for HFORCE's HF MFTDMA implementation in the 2025 timeframe.

Develop prototype plans for Phase II.

PHASE II: If multiple discreet amplifiers are to be utilized, then provide a management and control architecture required to easily integrate the HDR MCA in to the target system (initially DMR). Develop the supporting amplifier architecture that will address high individual carrier power variations and mitigate the resulting intermodulation interference. Develop a set of performance specifications for HDR MCA for interfaces and/or direct integration into DMR. Develop the prototype HDR MCA based on Phase I work for demonstration and validation in DMR. Identify the preliminary lifecycle support strategies and concepts for HDR MCA to include Lowest Replaceable Unit (LRU), depot/contractor facility repair and/or maintenance, and sparing.

Establish a working relationship with a candidate HFORCE waveform contractor (Program Office will assist in the identification and introduction) to perform initial development of any necessary Pre-Planned Product Improvement (P3I) requirements to integrate HFORCE into DMR.

PHASE III DUAL USE APPLICATIONS: Refine, fully develop, and integrate the Phase II prototype HDR MCA into DMR. Integrate HDR MCA into a prototype HFORCE system for initial performance assessments.

Perform Formal Qualification Tests (FQT) of HDR MCA Production Representative Article (PRA) in the DMR against the performance specification for HDR MCA.

Support the fielding and maintenance of HDR MCA by implementing the lifecycle support strategies and concepts with the DMR and HFORCE waveform contractors.

The current trends in commercial 5G communications technology selection indicates the potential application of multi-carrier waveforms with highly varying peak to average power. HDR MCA technologies may provide a solution for future 5G baseband towers with limited application on user terminals.

REFERENCES:

1. General Dynamics Mission Systems. Digital Modular Radio (DMR): Software-Defined Communications for the U.S. Navy, 2017, https://gdmissionsystems.com/radios/digital-modular-radio/

2. RF Power Amplifier. https://en.wikipedia.org/wiki/RF_power_amplifier

3. Bawa, Sangeeta. Pal, Maninder, and Gupta, Jyoti. “Pre-distortion Based Linearisation Technique for power Amplifiers of Wideband Communications Systems.” International journal of Scientific & Engineering Research, Volume 4, issue 5, May 2013, ISSN: 2229-5518. pp 726-733. https://www.ijser.org/researchpaper/Pre-distortion-Based-Linearisation-Technique-for-Power-Amplifiers-of-Wideband-Communication-Systems.pdf

4. Comb Filter. https://en.wikipedia.org/wiki/Comb_filter

KEYWORDS: HF; VHF; UHF; Multi-Carrier Amplifier; High Dynamic Range; Wideband; DMR; BFTN; HFORCE

N181-089

TITLE: Multi-Domain Data Management (MDDM)

TECHNOLOGY AREA(S): Information Systems

ACQUISITION PROGRAM: PEO C4I, PMW 120, Distributed Common Ground Station – Navy Increment 2 (DCGS-N Inc 2)

OBJECTIVE: With an expected exponential increase in data sources available to the DCGS-N Inc 2 Analyst, the intent of this SBIR topic is to provide an automated data management component within the Multi-Domain Federated Query (MDFQ) architecture to optimize information aggregation of structured and unstructured/heterogeneous data streams coming from multiple security domains into the highest classification domain (e.g., Top Secret/Sensitive Compartmented Information (TS/SCI)), enabling critical and relevant information queries to be rapidly returned, not only to the DCGS-N Inc 2 Analyst working in the TS/SCI domain, but also to users working in other domains (e.g., Secret General Services (GENSER) and Secret Releasable (REL) security domains, etc.).

DESCRIPTION: To maintain maritime supremacy, the U.S. Navy must collect, understand, and leverage ever-increasing volumes, variety, variability, velocity, and veracity of sensor and intelligence information to ensure proper force application across greater distances under ever-compressing time constraints. Distributed Common Ground System- Navy (DCGS-N) is the intelligence system principally responsible for providing Navy Commanders that understanding. To this end, DCSG-N must quickly aggregate, correlate, and fuse “All Domain/All Source Intelligence” to produce current and predictive, operational to tactical, battlespace awareness required to make better decisions faster.

The Distributed Common Ground System- Navy Increment 2 (DCGS-N Inc 2) Program of Record (PoR) seeks to employ novel data management techniques to optimize data query across multiple heterogeneous data repositories (e.g., Accumulo) provisioned at different security levels. Multi-Domain Data Management (MDDM) must aid the DCGS-N Inc 2 system in facilitating multi-domain analytics, real-time analytic processing and multi-domain information dissemination, post event analyses, and perform multi-domain nodal analysis to support a host of Navy Intelligence mission functions (e.g., building Intelligence Preparation of the Environment (IPOE) products, developing Strike Packages, producing Indications and Warnings, etc.). In addition, MDDM will enable Electromagnetic Maneuver Warfare/Integrated Fires (EMW/IF) capabilities which require unprecedented levels of data integration and interoperability between disparate systems fielded by different Office of the Chief of Naval Operations (OPNAV) Resource Sponsors across Command, Control, Communications, Computers, and Intelligence (C4I) and Combat Systems (CS) networks.

Current data management methodologies fail to stage, mark-up, and otherwise provision data for multi-domain analytics and subsequent rapid information product dissemination across multiple security enclaves. The MDDM capability must be able to rapidly warehouse an ever-increasing volume, variety, variability, velocity, and veracity of ingested data to allow for analysis and subsequent distribution required of the DCGS-N Inc 2 PoR, this SBIR topic seeks to advance current state-of-the-art data management methodologies to enable this capability. MDDM seeks to solve the ongoing problem of designing architectures for EMW/IF that avoid the enduring costs required to maintain a similar capability enabled by an ensemble of Cross Domain Solutions (CDS). This approach was initiated and guided by the Joint Worldwide Intelligence Communications System (JWICS) accrediting authority (Navy Intelligence Information Assurance (NAVINTEL IA)) as a valid, potentially more cost-effective approach to rapid Multi-Domain Information sharing from the JWICS network to Secret Internet Protocol Router (SIPRNET). While not alleviating the need for network CDS’s, this would allow users to access releasable information in JWICS via a more expedient, cost-effective means

Optimally, MDDM will leverage Commercial-off-the-Shelf (COTS) and Government-off-the-Shelf (GOTS) tools and services (e.g., large data storage hardware and analytics processes employed in DCGS-N Inc 2 PoR, such as data engines like Hadoop and MongoDB, queue/topic managers like Kafka, and display tools like CJMTK), as required in developing the database design and ultimate implementation. MDDM data provisioning will enable the automated combining of high volumes of data from differing intelligence communities, National Technical Means (NTM) systems, and multi-domain network feeds to aid DCGS-N Inc 2 in building a more coherent view of the battlespace, while simultaneously staging multi-domain data queries originating from security enclaves below the TS/SCI level (e.g., SECRET GENSER).

MDDM must be able to handle multiple data sources arriving simultaneously to differing nodes (ashore and afloat) and accommodate varying volumes, velocities, varieties, to include data bursts/blooms. The capacity to develop and maintain data Object Identification (OID) and Global Unit Identification (GUID) tagging for the MDFQ Relational Data Manager System (RDMS), in order to optimize data analysis and distribution of new and evolving data sources and formats, will be critical to this effort. It must be able to process data use by DCGS-N Inc 2 multi-domain analytics and or other key system functions. The higher security levels’ ingest and analytic functions must have access to all data ingested at lower security levels. Relationships, correlations, and updates need to be consistent—though not necessarily identical—vertically through the environment.

Data tagging—not to be confused with security labels—and data normalization must be accomplished through the ingest process in accordance with Extensible Markup Language (XML) Data Encoding Specification for Intelligence Communication (IC)- Enterprise Data Header (EDH) V4 6 Sep 13. This ingest process must send a copy of the original message plus the EDH to be persisted and indexed. Security Domain separation, control, and management must be via a secure type-1 hypervisor with a properly configured Domain 0 to enable Multiple Independent Levels of Security (MILS) control over the hosted virtual machines (VMs).

While it would be desirable to have a single physical Multi-Level Security (MLS) data store, the accreditation challenges are effectively show-stopping. Logical separation within a contiguous database would require burdensome, extensive proof. Therefore, data storage for each security domain should be separate with something like the OID/GUID providing any needed high-side linkages. Physical separation is preferred by the accreditors; however, secure VM separation (MDFQ) may be acceptable.

The system must implement to basic premises of the Bell-La Padula (BLP) model of computer security—the definition and enforcement of a security classification lattice or matrix. These fundamentals can be summarized as: “Fixed (Trusted) Security Levels”, “Read-Down” and “Write-Across”, and “Downgrade and Release”. It is understood that “Downgrade and Release” is an extremely complex challenge for certification and accreditation. However, it is still a desired capability even in a most basic form.

With the eventual goal of full accreditation, the proposal needs to address Navy Risk Management Framework (RMF) security controls for categorization and characterization [Ref 8, 9, 10]: Confidentiality = High, Integrity = High, and Availability = Moderate (Previously PL-4 under the DoD Information Assurance Certification and Accreditation Process).

The volume and velocity of data coming into the DCGS-N Inc 2 system varies widely; MDDM must dynamically adjust to the changes in data delivered, with the data provisioning goal not to exceed 30 seconds after ingest to consumer availability. For estimation purposes, ingest data traffic will be measured in “messages” at 10KB per message at DCGS-N Inc 2 specified ingest rates.

It is also critical the MDDM mechanism enable rapid retrieval (within 2 seconds) of stored data to meet the demands of operators working in different security enclaves in a tactical environment.

MDDM needs to be flexible in handling a combination of streaming, bulk, and standing order data with an importance placed on the expedience of data availability, from data acquisition to consumer availability without system degradation. MDDM must support the ability to cleanse, de-duplicate, and re-ingest data in the event of data ingestion errors. MDDM must also be scalable in a virtualized/cloud environment, capable of managing multiple data sets in parallel, handle inconsistent loads, and have the ability to synchronize, replicate, and federate.

Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. owned and operated with no foreign influence as defined by DoD 5220.22-M, National Industrial Security Program Operating Manual, unless acceptable mitigating procedures can and have been implemented and approved by the Defense Security Service (DSS). The selected contractor and/or subcontractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances, in order to perform on advanced phases of this project as set forth by DSS and SPAWAR in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material IAW DoD 5220.22-M during the advanced phases of this contract.

PHASE I: Working in conjunction with the DCGS-N Inc 2 Government team, generate a feasible novel design or design approach for a MDDM to address automated OID/GUID data tagging for data analytics and distribution in the DCGS-N Inc 2 MDFQ Architecture. The proposed design must be capable of managing and disseminating varying types and formats of multi-domain data in varying volumes, velocities, variability, and veracity, to include multiple data sources (e.g., Navy Message traffic, Electronic Intelligence (ELINT), Communications Intelligence (COMINT), Acoustic Intelligence (ACINT), etc.). The proposed design must account for the Certification and Accreditation (C&A) requirements of the DCGS-N Inc 2 PoR as a primary design constraint, be able to manage and disseminate new multi-domain data types, and address changes in formats/fields of existing data types/feeds.

PHASE II: Develop, along with the DCGS-N Inc 2 Government team, a cloud-enabled MDDM prototype capability that can demonstrate the following: 1.) Data Management and appropriate OID/GUID tagging of multi-domain data ingested via the DCGS-N Inc 2 system, and 2.) Data distribution of multi-domain information products to users operating at different security levels via the DCGS-N Inc 2 MDFQ architecture. Produce a prototype data management virtual machine for employment within the DCGS-N MDFQ architecture, while also meeting the C&A requirements of the DCGS-N Inc 2 PoR.

It is probable that the work under this effort will be classified under Phase II (see Description section for details).

PHASE III DUAL USE APPLICATIONS: Continue Phase II efforts to complete necessary engineering, system integration, packaging, and testing to field the capability into the DCGS-N Inc 2 PoR. Make the design construct available to other Navy Program Offices and Programs of Record, and commercialize the capability for technology transition to the wider defense and intelligence communities, as well as the broader commercial Cyber Security and Business Intelligence (BI) sectors.

REFERENCES:

1. Kulkarn, A. “Security Model: Bell-lapadula model.” Tata Consultancy Service, 2015. https://securitycommunity.tcs.com/infosecsoapbox/articles/2016/02/25/security-model-bell-lapadula-model

2. Zheng, Yu. “Methods for Cross-Domain Data Fusion: An Overview.” IEEE Transactions on Big Data, TBD-2015-05-0037, pp 1-18, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiLhL6__NnVAhXJ8YMKHccIA3wQFggmMAA&url=https%3A%2F%2Fai2-s2-pdfs.s3.amazonaws.com%2Ffe9d%2F375dd02a8504b7c5c011e3696e6e6f63f537.pdf&usg=AFQjCNGquUei392zVcqklMn9E5QMIVwMPQ

3. Li, Y., Shen, D., Nie, T., Yu, G., Shan, J., and Yue, K. “A Self adaptive Cross Domain Query Approach on the Deep Web.” Lecture Notes in Computer Science book series (LNCS, volume 6897) (2011), pp. 43-55, https://books.google.com/books?id=S_2qCAAAQBAJ&pg=PA43&lpg=PA43&dq=A+Self-adaptive+Cross-Domain+Query
+Approach&source=bl&ots=3N5S0DP08o&sig=4Rk9FniejwC2b0gpHvFznDauVhc&hl=en&sa=X&ved=0ahUKEwigvIj59oHVAhUL5mMKHZjGAMYQ6 AEIKjAB#v=onepage&q=A%20Self-adaptive%20Cross-Domain%20Query%20Approach&f=false

4. Agrawal, H., Karandikar, A. “Study of Multidomain Query Optimization and Answering.” International Journal of Computer Science & Engineering Technology (IJCSET), Vol. 4 No.06 Jun 2013, pp. 794-708. http://www.ijcset.com/docs/IJCSET13-04-06-121.pdf

5. Bkakriax, A., Cuppens, F., and Cuppens-Boulahia, N. “Preserving Multi relational Outsourced Databases Confidentiality using Fragmentation and Encryption.” pp. 39-62. http://isyou.info/jowua/papers/jowua-v4n2-3.pdf

6. McSherry, F. “Privacy Integrated Queries.” SIGMOD’09, June 29–July 2, 2009, Providence, Rhode Island, USA. https://people.eecs.berkeley.edu/~raluca/cs261-f15/readings/sigmod115-mcsherry.pdf

7. eXtensible Markup Language (XML) Data Encoding Specification for Intelligence Communication (IC)- Enterprise Data Header (EDH) V4 6 Sep 13.

8. Director of National Intelligence. “Intelligence Community Directive Number 503.” Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation. September 15, 2008. https://www.dni.gov/files/documents/ICD/ICD_503.pdf

9. Committee on National Security Systems (CNSS). “CNSS Instruction No. 1253, Security Categorization and Control Selection for National Security Systems.” National Security Agency, March 27, 2014. http://www.dss.mil/documents/CNSSI_No1253.pdf

10. National Institute of Standards and Technology (NIST). “Draft NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations.” U.S. Department of Commerce, August 2017. https://csrc.nist.gov/csrc/media/publications/sp/800-53/rev-5/draft/documents/sp800-53r5-draft.pdf

KEYWORDS: Multi-Level Security; Multi-Domain Cloud Data Services; Data Management; Relational Data Management System; Multi-Domain Query; Cross-Domain Data Distribution; Data Confidentiality

TECHNOLOGY AREA(S): Electronics, Space Platforms

ACQUISITION PROGRAM: Mobile User Objective System (MUOS)

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with section 5.4.c.(8) of the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.

OBJECTIVE: Develop a tactical communications payload for small commercial satellites that enables communications with tactical users without the need for new radio terminals or modifications on ships, aircraft, or other platforms.

DESCRIPTION: The loss of a single communications link should not lead to disaster for our warfighters. Diverse communications paths are required to ensure reliable communication in a variety of austere scenarios. A number of “new space” satellite communications (SATCOM) constellations are being designed and developed to provide ubiquitous worldwide coverage to a variety of customers. The Federal Communications Commission (FCC) recently approved U.S. operation of a new non-geosynchronous orbit (NGSO) satellite constellation. The Navy and other Department of Defense users could leverage these constellations for improved coverage and capacity in a number of scenarios. A key roadblock is the high cost to integrate new radio terminals on ships, aircraft, and other platforms. One solution to this problem is to develop a tactical communications payload that can be hosted on a commercial constellation(s) and translate the communications waveform and protocol to ones already supported by existing tactical radios.

The envisioned architecture would likely include a ground entry point where tactical data joins the commercial SATCOM network(s). The commercial SATCOM system would route the data to the appropriate satellite and then pass the data to the onboard tactical communications payload. From there, the data would be translated into a tactical waveform/protocol and sent to tactical users on ships, planes, and other platforms. If the service used is bi-directional (i.e. not a broadcast), data could also flow in the opposite direction, from tactical users back to the ground entry point.

The tactical communications payload must provide an open interface [Reference 1] to a variety of commercial constellation satellites. The interface to the commercial network is to be determined, but would likely use serial, Ethernet, or other common spacecraft electrical protocols. The system must act as a node on the host satellites’ communication network so it can receive data from the network that is intended for tactical users.

The tactical communications payload must communicate with existing ship, air, and other platform radios. The payload should include all radio frequency components necessary to communicate, including an antenna. The payload is only expected to use one protocol/waveform at once. The ability to switch or update waveforms is of interest but is not required.

The following are examples of possible tactical communications protocols/waveforms; however, this list is not exhaustive and other commonly used tactical protocols/waveforms may be proposed. Ultra-High Frequency (UHF) SATCOM waveforms/protocols could include the Integrated Waveform, Integrated Broadcast Service, or Common Interactive Broadcast (CIB). Link 16 (i.e., tactical data link that is specified in MIL-STD-6016) is a possibility in the L-band (i.e., operating frequency range of 1–2 GHz in the radio spectrum).