RFI-ACT-SACT-02-2026_questionnaire.xlsx

READ ME

Alliance Future Surveillance and Control - enhanced Air Surveillance (AFSC eAirSurv) System-Survey to the Nations

PURPOSE

This survey allows Nations/Industry to offer potential alternative solutions for consideration to meet the operational requirement for the Alliance Future Surveillance and Control (AFSC) programme, "enhanced Air Surveillance (eAirSurv)" element. The information collected in this survey will be used in support of the Analysis of Alternatives (AoA) for this future AFSC eAirSurv capability to be conducted by HQ Supreme Allied Commander Transformation's (HQ SACT). This survey could help to find an adopt, buy or create solution and expedite the capability delivery.

Parties interested in responding to this survey for the AFSC eAirSurv capability programme are asked to complete this questionnaire, and are cordially invited to participate and submit in due time. Participants will be able to enhance their understanding of the programme as well.

Important note: NSPA and ACT are seeking innovative solutions to meet any of the needs/requirements outlined in the background section below with an expected implementation of capabilities initially set for 2027 and fully implemented by 2030. The primary focus is on Air Objects of Interest (AOI) 0-10K feet Above Mean Sea Level (AMSL) using an Incremental approach, with the ultimate goal of detecting AOIs up to 100K in follow-on Increments. It is perfectly acceptable if a proposed solution does not meet the full set of requirements; NSPA and ACT still welcomes alternate/partial solutions that serve the need and vision of the NATO.

BACKGROUND

Alliance Future Surveillance and Control (AFSC) programme seeks to distribute funcionality across a vast array of sensors and C2 nodes, by exploiting the ability to transport data across multiple high throughput channels and aggregate heterogenous information streams into a useful opertional picture. It is intended to achive an interconnected system-of-systems that together has a greater capability than the simple sum of its parts and enable of fusion of multi-domain infomation as a basis for multi-domain action.

"enhanced Air Surveillance" capability delivery will address the existing Air Surveillance gaps (with ground based and airborne Radar systems) in detecting, tracking, classifying and identifying of Air Objects of Interest (AOI). eAirSurv prioritizes gaps for lower altitudes and JDAs/JDOAs, as defined in DDA family of plans. It also aims to develop capabilities, using flexible WAS sensors for contested environment, and focused surveillance for denied areas. It will lead to capabilities to conduct secure real-time information exchange among constituent elements, which will be able to link with each other, to achieve fully interoperable surveillance networks.

Specifically, the vision under the scope of this survey will facilitate/deliver the following:

-Timely and reliable access to National/Commercial capabilities, -Cutting edge analysis and efficient air surveillance system information gathering, -Availability of passive and active sensors that could fit into AFSC eAirSurv capability.

INSTRUCTIONS

1. Interested parties are kindly requested to propose capabilities they assess as related to AFSC eAirSurv capability by completing the questions in Capability Overview Survey TAB as comprehensively as possible.

2. NSPA and ACT kindly request that Nations/Industry inform NATO of their interest and ability to provide their capability for NATO as a buy or create option.

3. If you want to ask or comment about the items here, please refer to the numbering of item given with the item, not excell page header.

4. Emailed responses of the completed survey should be sent to: both the Technical and Contracting POCs listed on page 2 of the letter document. Any questions regarding the survey may also be submitted to the POCs as well.

5. Include an information/data sheet with system specifications and primary POC.

&"Calibri"&10&K000000 NATO UNCLASSIFIED&1#_x000D_&"Calibri"&11&K000000&"Arial,Bold"&12NATO UNCLASSIFIED &"Arial,Regular"&12ENCLOSURE 1 TO

ACT/CAPDE/CAP/TT-8438/SR:NU

DATED MAR 24

&"Arial,Regular"&12&P&"Arial,Bold" NATO UNCLASSIFIED_x000D_&1#&"Calibri"&10&K000000 NATO UNCLASSIFIED

1. Capability Overview

2. List each relevant system/solution you propose (expand acronyms). For each, provide: system name, variant(s), sensor modality (passive/active; RF/EO/IR/acoustic/radar/other), typical platform (ground fixed/mobile, airborne payload, other), and whether it is a product, service, or both.

3. For each system/variant, state Technology Readiness Level (TRL) and operational status (prototype / fielded / in-service). If in service, state approximate scale (number fielded) and typical users (military/civil).

4. For each system/variant, state any export, licensing, or deployment constraints you expect could affect multinational use.

5. If any requested item is proprietary or not releasable, respond with the best available range/approximation and state the limiting reason (e.g., proprietary/export/not measured).

6. Describe the solution architecture at a system level (black-box): identify the main nodes (sensor node(s), processing/fusion node(s), gateway/mediation node(s), operator/monitoring function if any) and the external interfaces between them (what connects to what).

7. Identify where processing occurs (sensor edge / local node / regional hub / cloud / mixed). For each location, state the processing footprint as a coarse class (Small/Medium/Large) and the type of hosting supported (e.g., embedded, laptop/edge server, rack server, cloud). State whether continuous connectivity is required, and what happens if connectivity is lost (e.g., degrade/continue/buffer)

8. Describe how the solution scales from a small deployment (few nodes) to a larger network (many nodes) at a system level. Provide any published or demonstrated limits (e.g., max nodes, max simultaneous tracks, max throughput) and what primarily drives those limits (bandwidth/compute/operator workload).

9.Describe any operator display/application required for normal operation. State whether the solution can run without the vendor UI by publishing outputs (detections/tracks/features) to external C2/ISR systems. If the UI is optional, explain what functions are lost without it (e.g., local health monitoring, sensor control).

10. Confirm the low-altitude surveillance envelope your solution is designed to support: 0–10,000 ft AGL. State any performance limitations by altitude band within that envelope.

11. Explain how your solution can complement existing national/NATO capabilities (e.g., AEW/AWACS, CRC/CAOC, deployable C2, fixed radars). Describe what your solution adds at low altitude (e.g., persistence in clutter, detection of low-RCS, classification support, redundancy, track continuity/quality improvement).

12. Describe how your solution supports networked sensing (multiple nodes cooperating). Include: whether nodes share detections and/or tracks, whether sensors cue each other, and whether fusion is centralized or distributed.

13. Describe how the solution supports safe operations in dense civilian airspace at high level: false-alarm management, classification confidence, track continuity, and operator workload controls, and coordination with civilian airspace authorities.

14. Specify node layout parameters: node spacing (km), expected overlap intent (single/dual/triple detection intent), and assumed node elevation/mast height.

15. Describe timing and synchronization needs for multi-node fusion (if any). State whether GNSS timing is required and what alternatives exist if GNSS is degraded. If you support PTP (Precision Time Protocol) or other methods, describe at high level.

16. Explain how cueing works between modalities (e.g., passive cueing active confirmers; EO/IR cueing). State what triggers transmissions for active sensors (if applicable).

17. List any material assumptions/constraints that affect feasibility or performance (e.g., line-of-sight, RF congestion, site access, permissions, power availability).

18. Describe fusion approach at a high level: what is fused (detections, tracks, features), where fusion runs (edge vs central), and what correlation approach you use in general terms (e.g., time/position/kinematics/ID features).

19. Describe outputs provided to external C2/ISR systems: what you output (detections/tracks/features), metadata included (confidence, classification, source attribution), and whether outputs are real-time or near-real-time.

20. Describe how your solution integrates into existing operational pathways at high level (e.g., how tracks could be consumed by national/NATO systems through gateways/mediation services) without requiring a proprietary COP.

21.Describe track quality controls at a high level (what controls exist, not how they are implemented): de-duplication, handling intermittent detections, suppression of false tracks, and how track confidence is managed.

22. Describe whether your solution includes (or can integrate with) a feature/signature repository (acoustic and/or other passive features) and how it improves classification and reduces false alarms.

23. Early warning beyond AoR (decision-time based): For low-altitude (0–10,000 ft AGL) air objects, describe how your solution could support early warning beyond the NATO AoR boundary. Provide feasible early-warning distance vs decision-time options by threat type and operating concept.

24. Threat-dependent geometry: Provide your recommended detection/track envelope for at least these threat families: (a) LSS UAS, (b) terrain-following cruise missiles, (c) high-speed/hypersonic threats (if applicable). Include how altitude, speed, and RCS/IR/RF signature assumptions change achievable early warning.

25. Airborne podded : If you propose using airborne payloads (podded or integrated) as part of the early warning concept, describe the minimum set of assumptions required (platform class, altitude/orbit, endurance, comms, cueing). State whether you require new platform acquisition or can use national host platforms when available.

26. Alternatives to airborne pods: If airborne pods are not feasible/available, describe any alternative approach to achieve additional warning time (e.g., elevated sensors, distributed passive networks, multi-static concepts, third-party data feeds). Explain trade-offs (coverage, latency, survivability, constraints).

27. Outputs and latency to NATO pathways: For your proposed early warning concept, describe how detections/tracks would be produced and delivered to external systems (interfaces/standards supported), including end-to-end latency from “first detect” to externally consumable track. (Provide latency values in the early warning template table and list interfaces/standards used.)

28. Constraints and risks: Identify key dependencies and risks for beyond-AoR early warning (e.g., EMCON constraints for any active sensing, spectrum availability, comms denial, weather/icing, certification/integration for airborne payloads, data rights).

29. State whether your system can publish tracks/outputs via open or widely used interfaces without vendor-developed custom adapters. If adapters are needed, describe what is needed and typical effort drivers.

30. Describe how your solution exchanges data with airborne contributors (e.g., national UAV payload feeds) when those feeds are available. Specify assumptions about platform-provided comms/timing and any certification or integration constraints at high level.

31. Describe cybersecurity posture at a high level: patching/update approach, ability to operate with limited connectivity, and any relevant hardening features you can describe without disclosing sensitive internal design.

32. Describe resilience to electromagnetic interference/EW at high level: expected impacts and mitigations for jamming, spoofing, meaconing, and high RF congestion.

33. For active sensors (if applicable), describe emission control features at a high level that minimize unnecessary transmissions (e.g., cued transmit, low duty cycle, controlled beams/power).

34. Describe environmental qualification and operating limits: temperature, wind, precipitation, icing, salt fog (as applicable). State any standards tested against if available.

35.Describe reliability/availability at high level: typical MTBF/MTTR if known, maintenance intervals, and main failure drivers.

36. Describe deployability: setup time, teardown time, crew size, transport method, and site requirements (power, comms, mounting).

37.Describe endurance in austere locations: typical power consumption, generator/battery options (if any), and whether continuous 24/7 operation is supported for the vignette configurations.

38. Describe backhaul options (fiber/cellular/SAT/other) and minimum bandwidth/latency needed to publish tracks reliably.

39. Describe sustainment concept at high level: spares, calibration needs, software updates approach, field service model/needs, and typical support footprint.

40. Operator model: identify roles required to operate and sustain the solution (operators, maintainers, analysts, network/cyber). Provide typical staffing per deployed site and per network for the vignette configurations.

41. Training: describe available training packages (operator/admin/maintainer), typical duration, delivery methods, and whether training can be delivered in a multinational setting.

42. Facilities/infrastructure: describe what is required for storage, maintenance, testing, and training (high level).

43. Describe feasible organizational options for operating and sustaining the solution (e.g., organic organizational support, service-provider support) and what changes/assumptions are needed for each.

44. Provide a rough-order cost structure by major elements: sensors, comms, processing/fusion, integration/adapters, training, support tools. Provide ranges if exact values are not available. [Cost table (ranges allowed)]

45.Provide rough annual O&M cost drivers: personnel support, licensing/subscriptions, spares, calibration, field service. Provide ranges if needed.

46. Licensing/IP/data rights: identify constraints affecting multinational operation/integration/third-party support. State whether outputs/interfaces can be used without vendor lock-in (high level).

47. Evidence: list trials/exercises/deployments relevant to low-altitude air surveillance and networked sensing. For each, state what was demonstrated (high level) and provide public references if available. [Table + citations (if public)]

48. Provide a 12–36 month roadmap for improvements relevant to low-altitude detection/tracking/classification, integration, and resilience (high level).

49. Identify which parts of your solution are mature as-is and which parts would require additional engineering or certification for platform integration (for airborne payloads, if applicable).

50. Provide any additional information important for fair comparison (assumptions, constraints, unique strengths, known limitations).

&"Calibri"&10&K000000 NATO UNCLASSIFIED&1#_x000D_&"Calibri"&11&K000000&"Arial,Bold"&12NATO UNCLASSIFIED

&"Arial,Regular"&12 2&"Arial,Bold" NATO UNCLASSIFIED_x000D_&1#&"Calibri"&10&K000000 NATO UNCLASSIFIED

Additional Parameters Below parameters can be considered to further expanding the RFI questionaire, taking into account the eAirSurv CRB, AFSC CONOPS, AFSC SoS Architectures and AFSC MMR.

Should be deleted before releasing of the RFI.

HAZMAT

Producability

Look down into clutter capability

RefinedRFIQuestionnaire

V1 land border (mixed urban–rural): Mixed urban/rural land border with heavy civilian RF/road traffic, cluttered background, and frequent low-alt (0–10,000 ft AGL) incursions; expect false-alarm pressure and need continuous tracking along key crossing corridors and nearby critical sites.

V2 coastal/open sea: Coastal and open-sea approaches with sparse fixed infrastructure, salt/fog/icing exposure, and line-of-sight limits over water; aim to detect/track low-alt (0–10,000 ft AGL) threats approaching from sea and through island chains/sea gaps.

V3 mountainous/complex terrain: Mountainous/complex terrain with deep valleys, ridgelines, and strong line-of-sight masking; low-alt (0–10,000 ft AGL) threats use terrain-following routes and pop-up profiles; access and power may be limited at high sites.

The early warning template table: Threat family, Assumed target alt band (ft AGL), Assumed target speed band, Signature Assumption (RCS/IR/RF), Proposed sensor(s)/modality, Proposed platform concept (surface/elevated/airborne/mixed), Achievable warning distance beyond AoR (NM/Km), Resulting decision time (minutes), Track maturity at handoff (detect/tentative track/track/classified), End-to-end latency to external consumer (sec), Key constraints/assumptions

Airborne Payload Integration & Orbit Concept Table: Payload type (EO/IR / ESM / radar / other), Host platform class (e.g., UAS class / fighter / other), Integration status (existing / requires integration), Certification implications (high level), Orbit/altitude concept (no classified detail), Data link/backhaul needs, Cueing method (from passive? from C2 tasking?), Interfaces / outputs supported, Minimum support footprint (crew/kit), Key constraints/risks