Topic

OUSD (R&E) CRITICAL TECHNOLOGY AREA(S): Integrated Network System-of-Systems; Mission Readiness & Disaster Preparedness; Advanced Computing and Software 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 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/evolve, demonstrate and standardize a protocol for secure peer to peer off-grid or private networked systems optionally bridged to the internet or securely to other enclaves through the internet. The protocol, reference implementation and hardware should be designed and implemented with resilience in the presence of disrupted, degraded, distributed and low-/no-infrastructure communications in mind. The resulting protocol should be runnable by existing low end embedded radio hardware (often of foreign manufacture) or newly developed US-sourced hardware with low cost, size, weight and power. Other use cases may include low power enabled hardware in a remote location that is connected to sensors for other hardware to collect and report data from. The protocol should be configurable to support many use cases without burdening less capable hardware. DESCRIPTION: Support for global position information, acquired from a host or embedded hardware, should be optional and leveraged for tracking and network traffic assistance when possible. The hardware should optionally have its own GNSS or leverage the location from the host system/sensor and be capable of supporting a wide variety of existing standards as well as those developed/implemented here. The protocol should provide a means for hardware to be power- and position-aware and optimize the device- and system-power (transmit power and remaining battery) to maximize network capabilities. If the network architecture is better optimized for a particular purpose it should be possible to easily configure in any combination of a star-, federated- or purely peer-to-peer network. The protocol should allow for either authorized-only, or a mix of open and authorized traffic, and the ability to pass authorized traffic silently across open network nodes optionally through intermediate nodes specifically integrated to these nodes. The protocol, implementation and hardware should all be exportable in accordance with a Department of Commerce EAR-99 classification (and therefore be “non-ITAR”). The hardware should have compatibility with earlier network protocols. The protocol should be targeted to be useful for low-cost sensor networks, trackers for logistics and human digital communications (ground to ground, local ground to air and ground/air to space) purposes. The protocol should also be able to handle transmitting and loading third party payloads for embedded systems or side loading them, easy integration with sensor boards/systems (optionally via wireless protocol such as Bluetooth) and “gateways” (to other communications architectures such as cellular or satellite), and be integratable with existing mobile applications. It is desirable, but not required, that the lowest levels of the stack optionally provide for a transmission layer with low probability of detection/intercept, which can be switched out for the public standard discussed above. That lowest layer need not be EAR-99. The resulting protocol/implementation may be based on an existing protocol. Non-exhaustive example standard protocols/implementations which might be modified/merged/extended to meet this topic include LoraMesh, LoraWan, LoraP2P, Dash7, Meshtastic, Cluster Duck Protocol, Zigbee, Wi-SUN and Thread. PHASE I: The feasibility study for the proposed technology should have assessed various aspects to substantiate that the technology is at an acceptable stage to award a D2P2. The technology should support optional global position information acquisition from a host or embedded hardware and leverage this information for tracking and network traffic assistance, while being capable of supporting a wide variety of existing standards and those developed/implemented. The protocol should provide a means for hardware to be power- and position-aware and optimize the device- and system-power to maximize network capabilities. The network architecture should be configurable in any combination of a star-, federated- or purely peer-to-peer network. The protocol should allow for either authorized-only, or a mix of open and authorized traffic, and the ability to pass authorized traffic silently across open network nodes. The hardware, protocol, and implementation should all be exportable in accordance with a Department of Commerce EAR-99 classification, and the technology should have compatibility with earlier network protocols. The protocol should be targeted to be useful for low-cost sensor networks, trackers for logistics and human digital communications, and be able to transmit and load third-party payloads for embedded systems or side loading them. The feasibility study should have provided sufficient evidence of the technology's ability to meet these requirements. Based on these expectations, the proposer's technology should be at an acceptable stage to award a D2P2. PHASE II: Support for global position information, acquired from a host or embedded hardware, should be optional and leveraged for tracking and network traffic assistance when possible. The hardware should optionally have its own GNSS or leverage the location from the host system/sensor and be capable of supporting a wide variety of existing standards as well as those developed/implemented here. The protocol should provide a means for hardware to be power- and position-aware and optimize the device- and system-power (transmit power and remaining battery) to maximize network capabilities. If the network architecture is better optimized for a particular purpose it should be possible to easily configure in any combination of a star-, federated- or purely peer-to-peer network. The protocol should allow for either authorized-only, or a mix of open and authorized traffic, and the ability to pass authorized traffic silently across open network nodes optionally through intermediate nodes specifically integrated to these nodes. The protocol, implementation and hardware should all be exportable in accordance with a Department of Commerce EAR-99 classification (and therefore be “non-ITAR”). The hardware should have compatibility with earlier network protocols. The protocol should be targeted to be useful for low-cost sensor networks, trackers for logistics and human digital communications (ground to ground, local ground to air and ground/air to space) purposes. The protocol should also be able to handle transmitting and loading third party payloads for embedded systems or side loading them, easy integration with sensor boards/systems (optionally via wireless protocol such as Bluetooth) and “gateways” (to other communications architectures such as cellular or satellite), and be integratable with existing mobile applications. PHASE III DUAL USE APPLICATIONS: The expected TRL at Phase III entry would be around TRL 6-7, indicating that the technology has been demonstrated in a relevant environment, and is ready for deployment in an operational environment. This would entail the successful integration of the protocol with various sensor boards/systems and "gateways" (to other communications architectures such as cellular or satellite), as well as its compatibility with existing mobile applications. In terms of transition planning, the project would need to address regulatory compliance, such as ensuring the hardware and protocol adhere to export control regulations. Additionally, the project would need to consider the development of a business or transition plan, outlining the strategy for commercialization or broader adoption of the technology. This would include identifying potential markets, partners, and customers, as well as a plan for ongoing support, maintenance, and updates to the technology. The expected Phase III effort for this project would involve further development and refinement of the proposed global position information protocol, aimed at supporting low-cost sensor networks, trackers, and human digital communications. This would include the finalization of the protocol's design, ensuring its compatibility with existing communication standards, and its integration with host or embedded hardware. The hardware component would be designed to optionally include its own GNSS or leverage the location from the host system/sensor, with exportability in accordance with a appropriate government classification/requirements. Commercial or private industry uses for the products/prototypes developed through this topic could include low-cost sensor networks for agriculture, environmental monitoring, and industrial automation, as well as secure peer-to-peer communication between drones or other autonomous vehicles. These networks could be used for data collection, real-time monitoring, and control of remote devices in environments with limited or no cellular coverage. The protocol's ability to optimize device and system power, as well as its configurable network architecture, would make it well-suited for a wide range of commercial and industrial applications. Additionally, the protocol's low latency and high resilience could make it useful for real-time data transfer in edge computing applications, where data is processed close to the source rather than in a centralized cloud. Finally, the protocol could be used for secure communication in Internet of Things (IoT) devices, protecting against potential cyber threats and ensuring the privacy of sensitive data. REFERENCES: 1. https://www.semtech.com/lora/what-is-lora KEYWORDS: LoraMesh; LoraWan; LoraP2P; Dash7; Meshtastic; Cluster Duck Protocol; Zigbee; Wi-SUN; thread