OSW-FutureG SBIR OSW26BZ06-DV032: Smart Manufacturing, Open-Source Private 5G
Quick Answer
OSW26BZ06-DV032 is a Direct to Phase II SBIR topic under the OSW FutureG Office, FY26 SBIR Broad Agency Announcement, Release 6. No Phase I award will be issued. The government wants a private 5G network for factories built entirely from open-source software, with no proprietary core, RAN Intelligent Controller, or Service Management and Orchestration component anywhere in the stack, demonstrated in a real metal-heavy industrial environment with at least three cells. The award must not exceed $2,153,927 over 18 months, with a 20-page technical volume. The topic opens September 23, 2026 and closes October 21, 2026 through the Defense SBIR/STTR Innovation Portal.
The stack is named and mandatory: OCUDU for the Centralized Unit and Distributed Unit, SD-Core for the 5G core, SD-RAN for the Near-Real-Time RIC, and the OSC stack for the Non-Real-Time RIC and SMO. A commercial core or a vendor RIC does not meet the topic.
The performance targets are specific and, unusually, so is the price point. The dominant performance classes are ultra-reliable low-latency communication and high-mobility reliability: sustained sub-30 millisecond threshold to sub-15 millisecond objective latency for machine-vision backhaul, at least 99.5 percent handover success at operational automated guided vehicle and autonomous mobile robot speeds, and at least five-nines availability for safety-critical services, all in dense, metal-heavy RF environments. And the target commercial packaging is a CBRS-based as-a-service offer at $100,000 to $250,000, which is the number that decides whether the business case closes.
The topic is also refreshingly honest about what it is not claiming. On Wi-Fi roaming it says modern standards substantially mitigate fixed-access-point handoff behavior when properly deployed, and that the real advantages sought are deterministic network-scheduled access on interference-managed spectrum, standardized network-controlled mobility management, and quality-of-service guarantees enforceable under load. A proposal that argues Wi-Fi cannot roam is arguing against the topic's own text.
One thing to know before drafting. The topic repeatedly directs proposers to key performance metric tables and to "Section 3.0." No such tables and no numbered Section 3.0 appear in the published document. That gap has its own section below and it is the most important question to ask before the topic closes.
Topic At a Glance
Topic number: OSW26BZ06-DV032
Title: Smart Manufacturing
Agency: Office of the Secretary of War, FutureG Office, under OUSW(R&E)
Solicitation: OSW FutureG Office, FY26 SBIR Broad Agency Announcement, Release 6, Proposal Submission Instructions
Program type: Direct to Phase II only. This topic is accepting Direct to Phase II proposals only, and a formal Phase I award will not be issued
Award: must not exceed $2,153,927
Period of performance: 18 months
Technical volume limit: 20 pages maximum, structured as Part 1 Phase I Justification at 5 pages maximum and Part 2 Phase II Technical Proposal at 15 pages maximum, with the Technology Transition and Commercialization Strategy at no more than 2 pages counting toward the 15
OUSW (R&E) Critical Technology Areas: Applied Artificial Intelligence (AAI), Contested Logistics Technologies (LOG)
Component Technology Priority Areas: FutureG, Advanced Infrastructure and Advanced Manufacturing, Sustainment and Logistics
Projected CMMC level requirement: Level 2. Note that this topic states Level 2 without the parenthetical self-assessment qualifier that appears on the other two topics in this release
Export control status: no topic-level ITAR or EAR restriction paragraph appears on this topic
Mandatory stack: OCUDU plus SD-Core plus SD-RAN plus OSC, with no proprietary core, RIC, or SMO component anywhere
Dominant performance classes: ultra-reliable low-latency communication and high-mobility reliability
Stated performance targets: sub-30 ms threshold and sub-15 ms objective latency for machine-vision backhaul, at least 99.5 percent handover success at operational AGV and AMR speeds, and at least five-nines availability for safety-critical services
Stated commercial price point: a CBRS-based as-a-service offer at $100,000 to $250,000
Market: roughly 50,000 U.S. manufacturing firms in the 20 to 99 employee band alone, with several thousand more in the 100 to 250 range
Use cases: proposers must address at least two of four, and must identify which their reference architecture and pilot deployment are designed to validate
Mandatory common work package: OCUDU baseline benchmarking and upstream enhancement, Tasks A, B, and C, required regardless of use cases selected
Additional mandatory task: representative facility-specific RF network planning and site engineering
Upstream requirement: all modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process
Demonstration site: must be representative of the target deployment class in RF character, meaning metal-heavy and multipath-rich industrial construction, and in scale, meaning a footprint and cell count of at minimum three cells sufficient to exercise inter-cell handover at operational AGV and AMR speeds
Out of scope for Phase II: hard-real-time machine motion control, meaning isochronous traffic with cycle times of approximately 0.5 to 2 milliseconds per 3GPP TS 22.104
Technical and Business Assistance: up to $50,000 per Phase II project, in addition to the cost ceiling and not subject to profit or fee, using the mandatory SBIR/STTR TABA Request Form in Volume 5
Percentage of Work: the FutureG Office will not accept any deviation to the POW requirements
Company Commercialization Report: information contained in the CCR will be considered during proposal evaluations
Topic open date: September 23, 2026
Proposal deadline: October 21, 2026
Submission portal: DSIP at dodsbirsttr.mil
Keywords: smart manufacturing, AI, robotics, smart factories, Industry 4.0, 5G connected warehouse
The Feasibility Bar, Which Is the First Thing to Check
This topic is accepting Direct to Phase II proposals only, so a formal Phase I award will not be issued.
To qualify for a Phase II award, proposers must submit Feasibility Documentation as part of their proposal package demonstrating that they have already completed Phase I-type research and development. The purpose of this documentation is to prove that the underlying technology is mature, scientifically sound, and ready to transition immediately into the Phase II prototyping and testing environment.
What the government will accept
The Government will accept a wide variety of documentation styles. Proposers do not need to have a perfect, finished product, but they must show that their core ideas have been successfully tested. One or more of the following items should be included to prove technology readiness.
Test data and metrics: real-world measurements, performance charts, or network test data from previous lab environments or early field trials.
Technical reports and white papers: written summaries explaining your previous research, system designs, or software integration efforts.
Prototype designs and simulation models: diagrams, architectural blueprints, or computer simulation results showing how your proposed software and hardware components interact.
Previous project outcomes: success criteria, milestone reports, or commercialization results from prior private, academic, or non-SBIR federally funded work.
This is among the most accommodating feasibility framings in the 2026 cycle. One or more of the four suffices, simulation models are explicitly acceptable, and the government states you do not need a finished product.
The restriction that still applies
The FutureG Direct to Phase II guidelines impose a hard constraint the topic-level text does not repeat.
Feasibility documentation cannot be based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work. Work submitted within the feasibility documentation must have been substantially performed by the proposer or the principal investigator. If technology in the feasibility documentation is subject to intellectual property, the proposer must either own the IP or must have obtained license rights to such technology prior to proposal submission, to enable it and its subcontractors to legally carry out the proposed work.
The Volume 2 instruction phrases it as "must not be solely based on" prior or ongoing federally funded SBIR or STTR work, which is weaker. Plan against the stricter formulation.
Notice that the topic's own fourth evidence category names "prior private, academic, or non-SBIR federally funded work," which is consistent with the restriction and tells you where to look. Private, academic, and non-SBIR federal work are all fine. Prior SBIR and STTR work is the problem, and open-source 5G integration work in the United States has been substantially SBIR funded, so audit the provenance of every result you intend to cite.
If the proposer fails to demonstrate technical merit and feasibility equivalent to the Phase I level as described in the topic, the related Phase II proposal will not be evaluated.
The Missing KPM Tables, and What the Topic Does Tell You
The topic refers to KPM tables repeatedly. It says other suggested KPMs for the various use cases and system requirements are given below for reference. It says each use case is defined in terms of the operational scenario, the connectivity requirement, and "the corresponding KPM table." Task A requires a baseline against the Phase II KPMs "including the General System and Architectural Requirements." The deliverables require Key Performance Metrics "see Section 3," MVP documentation reporting "the KPI results achieved against Section 3.0 thresholds," and a baseline benchmark report with "measured baseline results against Section 3.0 KPMs." A scope note refers to "the latency-class scope note in Section 3.0."
No KPM tables appear in the published document, and there is no numbered Section 3.0 or General System and Architectural Requirements section.
The governing principle is stated, even though the tables are not
This topic, unlike its companion DV031, spells out how the KPMs are meant to work, and that paragraph is what lets you proceed.
The KPM values in the tables are suggested reference values, not pass or fail contract requirements. Proposers shall propose specific, justified KPM targets in the Technical Volume, calibrated to their selected use cases, demonstration environment, spectrum plan, and channel bandwidth. Deviations from the suggested values must be technically justified. Threshold values represent the intended standard of Phase II demonstration success, and objective values are stretch goals, some of which are expected to mature during Phase III or along the FutureG evolution path. Final KPM targets will be agreed with the Government at kickoff and confirmed at the Critical Design Review. Consistent with the key milestones, partial achievement within a defined and documented scope may be considered successful.
So the practical approach is to propose your own KPM set with threshold and objective values, calibrated to your use cases, demonstration environment, spectrum plan, and channel bandwidth, justify each, and note that final targets are agreed at kickoff and confirmed at CDR. State plainly that you are doing so because the referenced tables do not appear in the published instructions.
Ask anyway. DSIP Topic Q&A closes October 7, 2026, and requesting the tables or a pointer to them is the single highest-value question on this topic.
The numbers the topic does state in its text
Four performance figures appear in the body and you should treat them as the anchors.
Sustained sub-30 millisecond threshold to sub-15 millisecond objective latency for machine-vision backhaul.
At least 99.5 percent handover success at operational AGV and AMR speeds.
At least five-nines availability for safety-critical services.
And a worked example: "The platform must sustain a session success rate greater than 99.5% for AGV/AMR connections while handing over between at least 3 small cells at speeds up to 10 mph."
The topic also names the KPM categories to address: session success rate, handover success rate, latency, jitter, and service availability.
The latency measurement definition, which is unusually precise
Latency KPMs in this document denote round-trip application-layer latency measured between the user equipment application interface and the local edge application endpoint served behind the on-site or edge User Plane Function, meaning device to edge through the RAN and core user plane, excluding external wide-area network transport.
Handover time denotes user-plane interruption time at the RAN, per 3GPP definitions.
For each latency KPM adopted, proposers shall specify the measurement reference points, the traffic type and packet size, and the measurement methodology, for example key performance indicator definitions per 3GPP TS 28.554, and shall include in the Critical Design Document a latency budget decomposition across the air interface, DU and CU processing, fronthaul and F1 transport, core user plane, and application processing.
That latency budget decomposition is a specific, named CDR deliverable across five segments. It is also a genuinely useful engineering discipline and one of the more concrete requirements in the topic. Do not treat it as boilerplate.
The latency scope note, which limits what you must demonstrate
Hard-real-time machine motion control, meaning isochronous traffic with cycle times of approximately 0.5 to 2 milliseconds per 3GPP TS 22.104, is outside the Phase II demonstration scope.
The latency KPMs in this topic target AGV and AMR supervision and control-plane traffic, machine-vision backhaul, and safety alerting.
Proposers shall, however, address in their FutureG evolution path the OCUDU enhancements required to approach the 1 millisecond latency class over time, including deterministic and priority scheduling, Time-Sensitive Communication support, and mini-slot and preemption features.
This is the government being realistic, and it matters. You are not being asked to close a motion-control loop over 5G in 18 months. You are being asked to hit sub-30 to sub-15 milliseconds for supervision, vision backhaul, and alerting, and to document the roadmap toward the 1 millisecond class. A proposal that promises isochronous motion control in Phase II is not more ambitious, it is out of scope.
What the Government Is Actually Buying
The objective
The objective of this Phase II effort is to design, validate, and demonstrate a fully open-source, private 5G network platform for smart manufacturing that integrates OCUDU, SD-Core, SD-RAN, and OSC components into a secure, vendor-neutral architecture.
This platform will deliver highly reliable, low-latency connectivity to support autonomous robotics, machine vision, and connected-worker safety, providing a cost-effective, FutureG-ready solution for both commercial manufacturers and dual-use defense logistics facilities.
The market, as the government describes it
The realistic near-to-mid-term serviceable addressable market for private 5G among U.S. small and medium-sized manufacturers is not all manufacturers. It is the subset with real mobility, reliability, coverage, or security pain: plants using automated guided vehicles, autonomous mobile robots, machine vision, connected workers, outdoor yards, large indoor spaces, or metal-heavy RF environments.
Manufacturing is already among the leading sectors for private mobile network deployments worldwide, and published case studies show double-digit productivity gains and lower infrastructure capital expenditure versus Wi-Fi deployments.
Based on data compiled by the National Association of Manufacturers, roughly 50,000 U.S. manufacturing firms fall in the 20 to 99 employee band alone, with several thousand more in the 100 to 250 range.
Note the qualification. The market is not 50,000 plants, it is the subset of them with one of six named pain characteristics. Your commercialization strategy should segment on those characteristics rather than quoting the headline firm count, because the topic already told you the count is not the addressable market.
How this segment buys, and what stops it
This segment buys on simplicity, speed, fit, and economics, not on global platform standardization.
Its stated barriers to adoption are consistent and compounding: return-on-investment ambiguity, legacy equipment and retrofit costs, spectrum and regulatory fragmentation, uneven device ecosystems, information technology and operational technology integration complexity, in-house skills shortages, and tight capital budgets.
A proprietary platform from a tier-one vendor addresses almost none of these barriers directly. It is priced and supported for large campuses and multi-site accounts, not a single plant with one connectivity problem to solve.
Seven named barriers. That list is effectively a scoring rubric for your commercialization strategy, and addressing each one explicitly is cheap differentiation.
The open-source argument and its honest cost
An all-open-source stack removes the structural cost and lock-in that makes proprietary platforms a poor fit for this segment. Because OCUDU's O-CU and O-DU communicate with the rest of the network over open, standardized interfaces, especially the O-RAN 7.2x split to the O-RU, the network can be assembled from whichever radio unit vendor best fits a given plant's bands, form factor, and budget, rather than a single bundled radio line.
Together, OCUDU, SD-Core, SD-RAN, and OSC form one integrated, fully open-source 5G stack that a smaller solution provider or systems integrator can deploy, support, and price as a right-sized, as-a-service offer for a single plant, instead of selling a broad, vendor-locked platform.
That directly answers this market's stated preference for outcome-first, economically flexible offers, and it supports a Wi-Fi-coexistence posture, meaning private 5G for the hard problem zones and Wi-Fi where it already works, rather than a rip-and-replace sale.
The trade-off is that the burden of proving interoperability, stability, and security shifts from a single vendor's warranty to the integrator and the open-source community itself. Small and medium manufacturer buyers, who by their own account lack in-house cellular and associated cybersecurity expertise, have little tolerance for integration failures discovered after deployment.
This is exactly the gap the ongoing OCUDU Testing and Validation Plan, and its RTEC-centered extensions, are designed to close: independently witnessed, multi-vendor testing of device diversity, RU diversity, outdoor RF performance, Core, RIC, and SMO integration, and security. The proposal should leverage the current, ongoing testing and evaluation activities in RTECs and associated results.
Take the Wi-Fi-coexistence framing seriously. The topic explicitly rejects a rip-and-replace posture, and a proposal that positions private 5G as replacing plant Wi-Fi is arguing against the solicitation's own commercial logic. Private 5G for the hard zones, Wi-Fi where it works, is the stated sale.
The generalization requirement
Although this topic is anchored in a specific vertical to ensure a concrete deployment environment, real users, and a defensible commercialization path, proposers should recognize and are required to present the technical work in terms of the generic network performance classes it advances.
Improvements made to the OCUDU O-CU and O-DU under this effort, meaning scheduler behavior, mobility management, uplink capacity, stability under sustained load, and security features, are expected to generalize across verticals and to benefit the broader community of RAN developers building on OCUDU.
The Technical Volume shall include a mapping of each selected use case, and its associated KPMs, to the performance class or classes it exercises, and shall identify which anticipated OCUDU code or feature enhancements correspond to each class.
This is a required Technical Volume element stated with "shall." It is easy to omit while writing about factories. Reserve space for it.
The Three Research Questions
Research and development for this effort should address, at minimum, the following three questions. Note that this topic asks three where its venue companion asks four; the ISAC evolution question is absent here.
All-open-source economics
What is the fully loaded cost, covering integration, support, spectrum, and hardware, of an OCUDU plus SD-Core plus SD-RAN plus OSC deployment relative to a proprietary platform at small and medium manufacturer scale, and how should that be packaged as a CBRS-based, as-a-service offer within the price point buyers require, stated as $100,000 to $250,000?
The stated price band is the most actionable number in the topic. It bounds the whole design: how many radio units, what class of hardware, how much integration labor, and what recurring service margin. Build a cost model against it and show that it closes, because a technically excellent platform that lands at $600,000 per plant does not answer the question that was asked.
Use-case-first automation
Which of the use cases defined below deliver the fastest, most measurable return on investment on the open-source stack, and what RTEC-executed interoperability tests across Device, RU, Core, RIC and SMO, and Infrastructure dimensions are needed to validate each one end-to-end?
Trust in open source
How does RTEC-executed testing of the full open-source stack, not just OCUDU, reduce the integration risk and skills-shortage barrier that small and medium manufacturer buyers most often cite, and what evidence package best converts community-maintained, no-license-fee software into a procurement-ready proof point for a buyer with no in-house cellular expertise?
That third question is the commercial crux and the one most proposals will answer weakly. The implied deliverable is an evidence package: what does a plant manager with no RF staff need to see, in what form, to sign a contract for a network with no vendor warranty behind it? Treat it as a document design problem, not a testing plan.
Solutions leveraging artificial intelligence and machine learning for predictive maintenance, network optimization, or automated fault resolution are encouraged but not required. The government will consider any novel concept that increases the reliability, economics, and trustworthiness of an all-open-source private 5G and FutureG platform for the manufacturing vertical. Dual-use opportunities are expected across both commercial small and medium manufacturers and DoW facility networks.
Phase II Scope
This Phase II effort will design, validate, and demonstrate a fully open-source private 5G network platform purpose-built for manufacturing facilities, integrating OCUDU, SD-Core, SD-RAN, and the OSC stack with no proprietary core, RIC, or SMO components.
The platform addresses four manufacturing-specific needs: high-mobility connectivity for automated guided vehicles and mobile plant equipment; low-latency video and camera backhaul for quality inspection and process monitoring; worker and plant safety communications; and outdoor yard and logistics coverage extending beyond the factory floor.
Phase II work will produce a validated reference architecture, RTEC-executed interoperability testing across RU, Core, RIC and SMO, and infrastructure dimensions, and a working minimum viable product demonstrated at a representative manufacturing site, along with a documented technical bridge path toward FutureG capability.
Anticipated benefits include a lower-cost, vendor-neutral alternative to proprietary industrial wireless systems, improved reliability for mobile robotics and safety-critical communications in dense industrial RF environments, and a reusable open-source deployment model.
The Four Use Cases, Of Which You Must Address Two
Proposers must address at least two of the following four use cases in their Phase II Statement of Work, and must identify which use cases their reference architecture and pilot deployment are designed to validate.
Device-class diversity and RedCap, which applies across all use cases
Each use-case set spans device classes from full-capability user equipment, meaning equipment modems, cameras, and broadcast and production units, to reduced-capability Internet of Things endpoints, meaning sensors, wearables, tags, and trackers.
Proposers shall address how the platform serves reduced-capability device classes, including 3GPP Release 17 Reduced Capability, RedCap, and Release 18 eRedCap user equipment, and shall identify any OCUDU scheduler or feature enhancements required to support RedCap operation. Such enhancements are strongly encouraged as upstream contributions under the common OCUDU benchmarking and enhancement work package.
Where RedCap-certified devices are not commercially available for a given endpoint type at demonstration time, proposers may demonstrate with available device classes or emulated RedCap user equipment profiles, and shall document the RedCap migration path.
That final allowance is worth using, since RedCap device availability in CBRS bands remains limited.
Industrial IoT service characteristics, which are specific to this topic
For the manufacturing vertical specifically, proposers shall additionally address Industrial IoT service characteristics as framed by 3GPP TS 22.104 on service requirements for cyber-physical control applications, including four things.
The mapping of selected use cases to TS 22.104 communication service classes.
Support for private-network, meaning Non-Public Network, operation.
Awareness of Time-Sensitive Communication and IEEE Time-Sensitive Networking integration concepts in the platform architecture.
And secure information technology and operational technology segmentation for IIoT traffic, for example via network slicing or 5G-LAN group management.
This requirement has no counterpart in the venue topic and it is a genuine technical scope addition. The TS 22.104 service class mapping in particular is a concrete artifact a reviewer can check, and IT and OT segmentation is the requirement that plant IT departments will care about most.
Use Case 1: AGV and AMR connectivity and mobility
Automated guided vehicles and autonomous mobile robots move continuously across the plant floor, between production cells, and into staging or storage areas, requiring an uninterrupted control-plane and telemetry connection as they roam. Roaming interruptions have historically been a common source of dropped sessions and stalled vehicles in Wi-Fi-served plants.
The topic then does something unusual and important. It concedes the counterargument. Modern Wi-Fi roaming standards, meaning IEEE 802.11k neighbor reports, 802.11r fast BSS transition, and 802.11v BSS transition management, substantially mitigate fixed-access-point handoff behavior when properly deployed on capable client devices. The more fundamental challenges in this environment are contention-based access on unlicensed, shared spectrum and the severe attenuation, multipath, and reflection conditions of metal-heavy plants, which degrade any RF system absent careful network planning.
The advantage sought under this topic is therefore not that Wi-Fi cannot roam, but that a 3GPP system provides deterministic, network-scheduled access on interference-managed spectrum, standardized mobility management under network control, and quality-of-service guarantees that remain enforceable under load.
This use case requires the platform to sustain low-latency, high-reliability connectivity and seamless handover as AGVs and AMRs move between small cells, indoors and where applicable into adjoining outdoor areas.
It additionally requires on-floor localization of AGVs, AMRs, and tagged mobile assets for fleet management, geofencing, and safety zoning. Network-native positioning using 3GPP NR positioning methods from Release 16 and 17 is preferred. Hybrid approaches that fuse NR positioning with existing plant localization systems may be proposed with justification.
Two things to take from this. First, do not write a Wi-Fi-cannot-roam argument; the topic pre-refuted it and a reviewer will notice. Make the case on deterministic scheduling, interference-managed spectrum, network-controlled mobility, and enforceable quality of service. Second, localization is a requirement inside this use case, not an optional extra, and network-native NR positioning is preferred over fusion with existing plant systems.
Use Case 2: Machine vision backhaul
Quality-inspection and process-monitoring cameras generate continuous, high-bandwidth video or image streams that must reach an on-premises or edge analytics system with minimal delay and jitter to support real-time defect detection and line-stoppage decisions.
This use case requires the platform to sustain high uplink throughput with low jitter for multiple simultaneous camera streams, including in metal-heavy or RF-reflective areas of the plant where Wi-Fi performance typically degrades.
Note that this is the use case the sub-30 and sub-15 millisecond latency targets attach to, and it is an uplink-heavy problem, which is the harder direction for a 5G system. Uplink capacity is also one of the named OCUDU enhancement areas in Task B, so this use case connects directly to the mandatory work package.
Use Case 3: Connected-worker safety
Plant personnel increasingly carry or wear connected devices such as gas and hazard sensors, push-to-talk radios, panic buttons, or health and location monitors, that must reliably reach a monitoring system without gaps in coverage, including in areas such as mezzanines, tank farms, and loading docks that legacy Wi-Fi does not reliably reach.
This use case requires the platform to sustain consistent, low-latency coverage for safety-critical alerting across the full indoor plant footprint.
This is where the five-nines availability target lives, and it is the use case most likely to involve RedCap and eRedCap devices, since wearables and sensors are exactly the reduced-capability endpoint class.
Use Case 4: Secure outdoor yard and logistics coverage
Loading docks, staging yards, rail sidings, and outdoor storage areas typically fall outside indoor Wi-Fi coverage entirely, yet increasingly require connectivity for yard trucks, RFID and asset tracking, outdoor cameras, and inventory handling equipment.
This use case requires the platform to extend secure, private coverage into outdoor areas immediately adjacent to the plant, using the same OCUDU-based infrastructure rather than a separate outdoor Wi-Fi buildout.
Note that outdoor RF performance is named as one of the dimensions the RTEC testing program covers, which makes this use case comparatively well supported by existing validation work.
Choosing your two
Use Cases 1 and 2 are the most tightly coupled to the topic's stated performance classes, since Use Case 1 carries the handover success target and Use Case 2 carries the latency targets, and together they exercise both dominant performance classes of URLLC and high-mobility reliability. They also both live indoors on the same RF design, which is the cheapest pairing.
Use Case 3 is the natural pair with either, since it shares the indoor footprint and adds the RedCap and availability dimensions at modest additional hardware cost. Use Case 4 requires outdoor cell planning and additional radio units.
The Contested Logistics Technologies Critical Technology Area designation points toward Use Case 4 and the depot and logistics defense narrative, so if the defense transition story matters to you, weigh that.
The Mandatory Common Work Package
All performers under this topic shall execute the following common work package, which is a required element of the Phase II Statement of Work regardless of the use cases selected.
Not optional, and not scoped by your use case choice. Budget and staff it separately.
Task A: Baseline Benchmark
Establish a quantified performance baseline of the integrated open-source stack, meaning OCUDU plus SD-Core plus SD-RAN plus OSC, against the Phase II KPMs relevant to the selected use cases, including the General System and Architectural Requirements.
An emulated end-to-end configuration, using emulated radio units and user equipment, RF channel emulation, or synthetic load generation, is acceptable and encouraged for the baseline, provided the benchmark methodology, tooling, configurations, and results are fully documented and reproducible.
Where an RTEC-validated reference configuration already exists for the proposed RU, Core, RIC, and SMO combination, the baseline shall incorporate available RTEC results rather than duplicate them.
Baseline methodology and results shall be presented to the OCUDU Test and Evaluation Working Group.
The baseline benchmark report is expected by Month 3, which means your emulation environment must stand up in the first weeks of the award.
Task B: Code and Feature Enhancement
Identify the gaps between baseline performance and threshold and objective values, and develop the OCUDU code improvements and features required to close them, for example scheduler and quality-of-service enhancements, mobility and handover optimization, uplink capacity improvements, stability hardening, and security features.
All modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process. Enhancements that cannot be upstreamed shall be documented with rationale.
Progress against each targeted KPM, and the status of each upstream contribution, shall be reported in the Monthly Status Reports presented to the OCUDU Test and Evaluation Working Group.
Two consequences worth confronting in your proposal. Your code improvements go into a public project on that project's review timeline, which is schedule risk you do not own, and the deliverable log explicitly includes review status because acceptance is not guaranteed. And your commercial differentiation cannot be the OCUDU code itself; it has to be the integration, the RF engineering, the evidence package, the service model, and the support relationship. Say so in the commercialization strategy.
Note that mobility and handover optimization and uplink capacity improvements are both named enhancement examples, and both map directly onto Use Cases 1 and 2. That alignment is worth making explicit in your performance-class mapping.
Task C: Benchmark and Regression Harness
Deliver the emulation-based end-to-end benchmark suite developed under Task A as a repeatable, documented, open-source harness suitable for adoption by the OCUDU community and RTECs for regression testing of future OCUDU releases.
This work package complements, and does not replace, the interoperability testing and the physical MVP demonstration required elsewhere in this topic. Emulated results establish the baseline and guide enhancement work. Over-the-air performance with physical radio units and user equipment at the RTEC or representative demonstration site remains the standard of evidence for final KPM achievement.
RF Network Planning and Site Engineering, a Second Mandatory Task
This requirement is unique to the manufacturing topic and it is one of the more substantive engineering asks in the release.
Industrial facilities are among the most difficult RF environments for any wireless system. Dense metal structures, racking, and machinery produce severe attenuation, multipath, and reflection conditions that directly affect handover performance, throughput, jitter, and coverage completeness.
Performers shall execute a representative facility-specific RF engineering task comprising three elements.
Predictive propagation modeling incorporating facility-specific features such as metal racking, machinery, mezzanines, tank farms, and loading areas.
An RF design that mitigates identified dead spots and multipath-driven impairments through cell placement, antenna selection and orientation, and mobility-parameter tuning.
And installation engineering practices that protect radio hardware, including antenna placement clearances from nearby reflective metal and verification of antenna-system return loss and voltage standing wave ratio at commissioning, with monitoring thereafter, to prevent reflected-power damage to radio unit front ends.
That third element is notably practical and it is the kind of detail that signals the requirement was written by someone who has damaged a radio front end. Return loss and VSWR verification at commissioning, with ongoing monitoring, is an installation and operations procedure, and an RF Design Report including representative coverage maps and return-loss and VSWR commissioning approaches is a named deliverable.
Security Requirements
Security shall be a first-class design requirement of the platform, not a demonstration afterthought.
Performers shall implement and document a security architecture covering the following.
3GPP security per TS 33.501, including mutual authentication and air-interface encryption and integrity protection.
Protection of the O-RAN open interfaces, meaning open fronthaul, E2, A1, and O1, per O-RAN WG11 specifications.
Zero-trust principles per NIST SP 800-207, including least-privilege access and separation of management and user traffic.
Monitoring of Common Vulnerabilities and Exposures affecting OCUDU and its dependencies, and timely upstream patching.
Security features and hardening developed for OCUDU shall be contributed upstream under the common benchmarking and enhancement work package.
The security architecture shall be documented at the Critical Design Review and validated in RTEC testing, and the MVP demonstration shall include at least one security capability shown live, for example rejection of an unauthorized device, encrypted fronthaul, or detection of a simulated intrusion.
Pick your live security demonstration early and design for it. Note also that the IIoT requirement above asks for secure IT and OT segmentation via network slicing or 5G-LAN group management, which is a second security-adjacent requirement specific to this topic and worth addressing alongside the architecture.
Milestones, Demonstration Site, and Deliverables
Milestones as stated
Month 1: Kickoff and Technical Interchange Meeting.
Monthly Status Reports throughout.
Month 12: Critical Design Review.
Month 16: Prototype demonstration.
Month 14: Final design review, demonstration, and assessment.
Month 18: Final Phase II Report.
The published list places the Month 16 prototype demonstration before the Month 14 final design review, which cannot be the intended sequence. The same inversion appears in the companion topic DV031, which points to a shared drafting error. Confirm through DSIP Topic Q&A and state your assumed sequence in your work plan.
Monthly Status Reports must be presented to the OCUDU Test and Evaluation Working Group as well, bringing the community up to speed on progress. That is a recurring external commitment and it should be staffed.
The demonstration site, which is specified more tightly here than in the venue topic
Prototype demonstrations will be performed at the proposer's site, ideally an operating or representative manufacturing facility such as a partner small or medium manufacturer plant, a manufacturing institute or applied-research factory floor, or a comparable industrial or laboratory environment.
The demonstration environment must be representative of the target deployment class in RF character, meaning metal-heavy, multipath-rich industrial construction, and in scale, meaning a footprint and cell count at minimum three cells, sufficient to exercise inter-cell handover at operational AGV and AMR speeds. Its fidelity to plant conditions must be documented in the MVP demonstration package.
Partial solutions may be considered successful if effective within a defined scope. A final technical report detailing the capabilities demonstrated will be required. Extended user evaluations or additional prototypes may be pursued based on utility.
The three-cell minimum is a hard, checkable number and it should drive your site selection and your hardware budget. The topic's own worked KPM example describes handing over between at least three small cells at speeds up to 10 miles per hour, so three cells and roughly 10 miles per hour is the demonstration you should plan.
Note that the site sentence in the published text reads "ideally an operating or representative manufacturing facility (such as a partner SMM plant, a manufacturing institute or applied-research factory floor, or a comparable industrial or laboratory environment) where live plant access is not feasible during Phase II," which parses oddly. The companion venue topic contains the parallel construction "or a full-scale representative test bed where live-venue access is not feasible during Phase II," which suggests the alternative clause was dropped here. The sensible reading is that an operating plant is preferred and a comparable industrial or laboratory environment is the fallback where live plant access is not feasible. Either way, the RF character and three-cell scale requirements govern.
OCUDU integration and scalability
The MVP demonstration, including physical radio units and user equipment, will need to occur at the factory-representative site, as close to a real environment as possible.
Performers should address scalability, including testing across multiple radio unit vendors and hardware-accelerator options, and should leverage RTEC-executed interoperability testing to address integration risks ahead of the demonstration wherever a validated reference configuration already exists.
Phase II deliverables
Kickoff and Technical Interchange Meeting slides.
Monthly Status Reports.
A Critical Design Document containing the full reference architecture across OCUDU, SD-Core, SD-RAN, and OSC.
Key Performance Metrics.
MVP Demonstration slides and documentation, including a description of the demonstration site's fidelity to factory conditions and the KPI results achieved against the referenced thresholds.
A Reference Configuration Package comprising executables, integration documentation, and RTEC test results for the validated RU, Core, RIC, and SMO combinations used.
Integration of the platform into an RTEC-affiliated test and evaluation network or a factory-representative demonstration site, demonstrating at least one of the two selected use cases.
An OCUDU Baseline Benchmark Report covering methodology, emulation environment description, configurations, and measured baseline results, expected by Month 3.
An Upstream Contribution Log, itemizing OCUDU code contributions such as patches and pull requests, their review status, and the KPM gap each addresses, updated in each Monthly Status Report with the final version in the Final Technical Report.
An open-source benchmark and regression harness, with documentation sufficient for independent execution by RTECs and the OCUDU community.
An RF Design Report, including representative coverage maps and return-loss and VSWR commissioning approaches.
A Final Design Document.
A Final Technical Report.
Note the relationship between addressing at least two use cases and "demonstrating at least one of the two selected use cases." You scope two in the Statement of Work and physically demonstrate at least one. That is a meaningful reduction in demonstration burden and it should shape your pairing: pick two where one is demonstrable at your site and the other is architecturally addressed.
Note also that the Critical Design Document here does not carry the venue topic's requirement to include a 6G and ISAC evolution path, consistent with this topic having no ISAC use case. It does, however, require the latency budget decomposition described earlier, and the Phase II scope calls for a documented technical bridge path toward FutureG capability.
Phase III Dual Use
The development of an open-source private 5G network platform for smart manufacturing offers significant dual-use potential, benefiting both commercial industry and Department operations.
For the commercial sector, this technology provides small and medium-sized manufacturers with a low-cost, secure, and vendor-neutral wireless solution. It directly addresses key manufacturing needs such as enhancing automated guided vehicle mobility, enabling real-time machine vision for quality control, improving connected-worker safety, and extending secure connectivity to outdoor logistics yards.
For the Department, this same technology can be applied to its own industrial and logistical environments. It offers a pathway to modernize DoW-affiliated depots, maintenance facilities, and logistics operations with resilient, high-mobility wireless connectivity. This is particularly relevant for contested logistics, where reliable, secure, and private communication networks are critical for maintaining operational tempo and supply chain integrity. The platform's open-source nature reduces dependency on proprietary systems and enhances security, aligning with key modernization goals.
The depot and maintenance facility case is the strongest defense hook and it is structurally identical to the commercial one. Depots are large, metal-heavy, multipath-rich industrial environments with mobile equipment, asset tracking needs, and outdoor yards, run by organizations that also lack in-house cellular engineering staff. If you can name a specific depot, maintenance center, or logistics activity, that is worth more than the general claim.
Funding, Cost Structure, and FutureG Mechanics
The award
Direct to Phase II proposals must not exceed a cost of $2,153,927 and a duration of 18 months.
Be realistic about scope. A full open-source stack integration, RTEC interoperability testing, OCUDU code enhancement with upstream contribution, a facility-specific RF engineering task with predictive propagation modeling, a security architecture with a live demonstration, an emulation benchmark harness, and a physical three-cell MVP at a factory-representative site, in 18 months for $2.15 million, is a full program. Existing OCUDU experience, an existing plant or applied-research factory floor relationship, and existing RTEC engagement are worth more than headcount.
Cost volume
A detailed Phase II Cost Volume must be submitted online in the proper format shown in the Cost Breakdown Guidance in the DoW 2026 SBIR BAA. Some items may not apply, and there is no need to provide information for every item. Provide enough information to allow evaluators to assess your plans to use the requested funds.
Justify items of equipment to be purchased, including Government Furnished Equipment. All requirements for government furnished equipment or other assets, and associated costs, must be determined and agreed to during Phase II contract negotiations. At least three radio units, user equipment across full-capability and reduced-capability classes, hardware accelerators, CBRS Spectrum Access System service, channel emulation and load generation for the Task A baseline, propagation modeling tools, and VSWR and return-loss test equipment all belong in the cost discussion.
Percentage of Work, with no exceptions
Review the updated Percentage of Work calculation details included in the DoW SBIR Program BAA. The FutureG Office will not accept any deviation to the POW requirements.
The natural team here includes a radio unit vendor, a systems integrator, a plant partner, possibly an RTEC, and possibly a manufacturing institute or university. Model your POW before you assemble it.
Technical and Business Assistance
Phase II awardees may request up to $50,000 per Phase II project. TABA funding is in addition to the Phase II cost ceiling and is not subject to profit or fee.
All requests for TABA must be completed using the SBIR/STTR TABA Request Form, and the completed form must be included in Volume 5 of the proposal submission in DSIP. OSW will not accept requests for TABA that do not utilize the form or that are not included as a submission document in Volume 5.
For this topic the strongest uses are commercial go-to-market development, since the topic asks explicitly for an as-a-service offer inside a stated price band, and spectrum and regulatory support for the CBRS deployment.
The 20-page structure
Volume 2 is 20 pages maximum: Part 1, Phase I Justification, 5 pages maximum, and Part 2, Phase II Technical Proposal, 15 pages maximum, with the Technology Transition and Commercialization Strategy at no more than 2 pages counting toward the 15.
So 5 pages of feasibility, 13 pages of technical proposal, 2 pages of commercialization. Against that you must fit: three research questions, two use cases, RedCap handling, the IIoT and TS 22.104 requirements, the required performance-class mapping, three common work package tasks, the RF network planning and site engineering task, the security architecture, the latency measurement definitions and budget approach, the milestone plan, key personnel, facilities, and consultants. This topic has more mandatory content than its venue companion and the same page allowance. Plan the allocation before drafting.
The FutureG instructions do not state that figures, tables, charts, and references count inside the page limit, and do not prohibit appendices. They defer to the DoW SBIR Program BAA formatting requirements, so read that rather than assuming another component's stricter rule applies.
What the technical proposal must contain
The Phase II Technical Objectives and Approach section must list specific technical objectives and provide a detailed technical approach, and must include these named subsections.
Phase II Work Plan, with an explicit, detailed description of the approach, indicating what is planned, how and where the work will be carried out, a schedule of major events, and the final product to be developed.
Related Work, describing significant activities directly related to the effort including those of the Principal Investigator, the firm, consultants, or others, and demonstrating awareness of the state of the art.
Relationship with Future Research or Research and Development, stating anticipated results and the significance of the Phase II effort as a foundation for Phase III.
Technology Transition and Commercialization Strategy, at no more than 2 pages counting toward the 15-page limit, addressing five specific questions: what is the first product this technology will go into; who will be your customers and what is your estimate of the market size; how much funding will you need to bring the technology to market and how will you raise those funds; does your company contain marketing expertise and if not how do you intend to bring it in; and who are your competitors and what is your price or quality advantage.
Key Personnel, including the Principal Investigator, with directly related education, experience, and relevant publications, and a concise resume of the PI.
Facilities and Equipment, describing available instrumentation and physical facilities, justifying equipment purchases including Government Furnished Equipment, and stating whether facilities meet federal, state, and local environmental laws across the named groupings.
Consultants, describing in detail any involvement of universities, academic institutions, or other consultants and identifying them in the Cost Volume.
Answer the five commercialization questions as five distinct answers, and note that the topic hands you the answer to the pricing part of question three: the $100,000 to $250,000 band.
The Company Commercialization Report is evaluated
Completion of the CCR as Volume 4 is required. The information contained in the CCR will be considered during proposal evaluations.
FutureG states this consistently in both its Phase I and Direct to Phase II sections. It is separate from the commercialization strategy in Volume 2: the CCR covers what you have done with past Phase II awards, the strategy covers how you propose to commercialize this research.
Evaluation and selection
All proposals will be evaluated in accordance with the evaluation criteria listed in the DoW solicitation.
Proposing firms will be notified of selection or non-selection status within 90 days of the closing date of the topic via DSIP. The FutureG text says "for a Phase I award," which appears to be residual language given that this topic issues no Phase I award. The notification will be sent to the individual listed as the Corporate Official on the proposal cover sheet, so make sure that is someone who will act on it.
Ninety days from October 21, 2026 is approximately January 19, 2027.
Refer to the DoW solicitation for procedures to protest the announcement. Protests after award should be submitted, as prescribed in FAR 33.106(b) and FAR 52.233-3, to osd.ncr.ousd-r-e.mbx.SBIR-STTR-Protest@mail.mil.
Questions
Specific questions pertaining to the administration of the FutureG SBIR Program and these proposal preparation instructions should be directed to the OUSW(R&E) FutureG Office at OSDRE-FutureG@groups.mail.mil.
The FutureG instructions do not state that DSIP Topic Q&A is unavailable, so the standard DoW process applies and Topic Q&A closes two weeks before the topic closes, on October 7, 2026.
The Reference
One, and it is a link to a vendor explainer: smart manufacturing, at ibm.com.
As with the companion venue topic, the formal reference list is not where the substance is. The real citations are embedded in the topic text and they are the reading list that matters: 3GPP TS 22.104 on service requirements for cyber-physical control applications, which you must map your use cases to; 3GPP TS 28.554 on key performance indicator definitions, named as an acceptable latency measurement methodology; 3GPP Release 16 and 17 NR positioning methods; 3GPP Release 17 RedCap and Release 18 eRedCap; 3GPP TS 33.501 on security; O-RAN WG11 specifications; NIST SP 800-207 on zero trust; the O-RAN 7.2x split; IEEE 802.11k, 802.11r, and 802.11v for the Wi-Fi comparison the topic makes; and IEEE Time-Sensitive Networking concepts.
That is ten substantive references embedded in prose against one marketing link in the reference section. The Related Work section is required to demonstrate awareness of the state of the art, and you carry that burden entirely. Bring the OCUDU project documentation, the OCUDU Testing and Validation Plan the topic refers to, the SD-Core and SD-RAN and OSC project documentation, and published RTEC test results.
Timeline and What to Do When
The dates
Topic opens: September 23, 2026
DSIP Topic Q&A closes: October 7, 2026, two weeks before the topic closes, per the DoW SBIR Program BAA
Proposal deadline: October 21, 2026
Selection notification: within 90 days of the closing date, approximately January 19, 2027
Period of performance: 18 months from award
A working backward plan
Before September 23. Audit the funding provenance of every feasibility result you intend to cite, since work based upon or logically extending from prior or ongoing federally funded SBIR or STTR work is excluded and failing the feasibility bar means the proposal is not evaluated. Resolve intellectual property ownership or license rights. Secure your demonstration site, confirming it is metal-heavy and multipath-rich and can host at minimum three cells with room to exercise handover at AGV speeds. Build the cost model against the $100,000 to $250,000 as-a-service price band and confirm it closes. Engage RTECs and identify which validated reference configurations exist for your intended RU, Core, RIC, and SMO combination. Get familiar with the OCUDU contribution process and the OCUDU Test and Evaluation Working Group cadence. Choose your two use cases. Plan your CBRS spectrum approach. Read TS 22.104 and prepare your service class mapping, and read TS 28.554 for the latency methodology. Model your Percentage of Work before assembling a team including an RU vendor, an integrator, a plant partner, and possibly a manufacturing institute. Confirm SAM registration and your CMMC posture.
September 23 through October 5. Draft the 5-page Phase I justification using the four accepted evidence categories, leaning on private, academic, and non-SBIR federally funded work. Draft the 13-page technical proposal covering the three research questions, your two use cases, RedCap handling, the IIoT and TS 22.104 requirements including NPN support and TSC and TSN awareness and IT and OT segmentation, the required performance-class mapping, the three common work package tasks, the RF network planning and site engineering task, the security architecture with your chosen live demonstration, your latency measurement reference points and budget decomposition approach, and the milestone plan with your assumed Month 14 and Month 16 sequence. Propose your own KPM set with threshold and objective values calibrated to your use cases, demonstration environment, spectrum plan, and channel bandwidth, and justify each. Draft the 2-page commercialization strategy answering all five enumerated questions, using the $100,000 to $250,000 band and the seven named adoption barriers. Draft the 3,000 character cover sheet abstract and the 3,000 character anticipated benefits and commercial applications discussion.
October 6 through October 7. Submit questions through DSIP Topic Q&A before it closes. The essential ones are the missing KPM tables, Section 3.0, and General System and Architectural Requirements section, and the Month 14 versus Month 16 milestone ordering. Send administrative questions to OSDRE-FutureG@groups.mail.mil.
October 8 through October 14. Build the cost volume online following the Cost Breakdown Guidance in the DoW 2026 SBIR BAA, against the $2,153,927 and 18-month ceiling. Price at least three radio units across multiple vendors, user equipment including reduced-capability classes, hardware accelerators, CBRS Spectrum Access System service, channel emulation and load generation, propagation modeling tools, VSWR and return-loss test equipment, RTEC testing engagement, site access and installation, OCUDU development labor including upstream contribution effort, security architecture work, and the recurring OCUDU T&E Working Group reporting. Identify Government Furnished Equipment needs. Complete the SBIR/STTR TABA Request Form and place it in Volume 5.
October 15 through October 18. Complete Volume 4, the Company Commercialization Report, carefully, since FutureG states it is considered during evaluations. Assemble Volume 5 with the TABA form and any letters from plant partners, manufacturing institutes, or RTECs that substantiate specific claims. Complete Volume 6 training and the Volume 7 foreign affiliations webform, remembering it must be the webform and will not be accepted as a PDF in Volume 5, and that no previous versions should be uploaded there. Run compliance: 5 plus 15 pages with the 2-page commercialization strategy inside the 15, no proprietary or classified information on the cover sheet, 3,000 character limits per cover sheet section.
October 19 through October 20. Submit and certify in DSIP.
Frequently Asked Questions
What is OSW-FutureG SBIR topic OSW26BZ06-DV032?
OSW26BZ06-DV032 is a Direct to Phase II SBIR topic titled "Smart Manufacturing," released under the OSW FutureG Office FY26 SBIR Broad Agency Announcement, Release 6. The objective is to design, validate, and demonstrate a fully open-source private 5G network platform for smart manufacturing integrating OCUDU, SD-Core, SD-RAN, and OSC components into a secure, vendor-neutral architecture supporting autonomous robotics, machine vision, and connected-worker safety.
How much funding is available?
Direct to Phase II proposals must not exceed a cost of $2,153,927 and a duration of 18 months. Phase II awardees may also request up to $50,000 in Technical and Business Assistance, in addition to the cost ceiling and not subject to profit or fee, using the mandatory SBIR/STTR TABA Request Form in Volume 5.
When is the proposal deadline?
The topic opens September 23, 2026 and proposals are due October 21, 2026 through the Defense SBIR/STTR Innovation Portal at dodsbirsttr.mil.
Can I submit a Phase I proposal?
No. This topic is accepting Direct to Phase II proposals only, and a formal Phase I award will not be issued.
What software stack is required?
OCUDU for the Centralized Unit and Distributed Unit, SD-Core for the 5G core, SD-RAN for the Near-Real-Time RIC, and the OSC stack for the Non-Real-Time RIC and SMO, integrated into a single fully open-source reference architecture with no proprietary core, RIC, or SMO component anywhere in the stack.
What are the stated performance targets?
Sustained sub-30 millisecond threshold to sub-15 millisecond objective latency for machine-vision backhaul, at least 99.5 percent handover success at operational AGV and AMR speeds, and at least five-nines availability for safety-critical services, all in dense, metal-heavy RF environments. The topic also gives a worked example: a session success rate greater than 99.5 percent for AGV and AMR connections while handing over between at least 3 small cells at speeds up to 10 miles per hour.
Where are the KPM tables the topic refers to?
They do not appear in the published document, and there is no numbered Section 3.0 or General System and Architectural Requirements section. Raise it through DSIP Topic Q&A before it closes on October 7. The topic does state the governing principle: the KPM values in the tables are suggested reference values rather than pass or fail contract requirements, proposers shall propose specific justified KPM targets calibrated to their use cases, demonstration environment, spectrum plan, and channel bandwidth, deviations must be technically justified, threshold values represent the intended standard of demonstration success while objective values are stretch goals, and final targets are agreed with the Government at kickoff and confirmed at the Critical Design Review.
How is latency defined?
Round-trip application-layer latency measured between the user equipment application interface and the local edge application endpoint served behind the on-site or edge User Plane Function, meaning device to edge through the RAN and core user plane, excluding external WAN transport. Handover time means user-plane interruption time at the RAN per 3GPP definitions. For each latency KPM you must specify measurement reference points, traffic type and packet size, and methodology such as KPI definitions per 3GPP TS 28.554, and include a latency budget decomposition in the Critical Design Document across the air interface, DU and CU processing, fronthaul and F1 transport, core user plane, and application processing.
Do I have to demonstrate hard-real-time motion control?
No. Hard-real-time machine motion control, meaning isochronous traffic with cycle times of approximately 0.5 to 2 milliseconds per 3GPP TS 22.104, is explicitly outside the Phase II demonstration scope. The latency KPMs target AGV and AMR supervision and control-plane traffic, machine-vision backhaul, and safety alerting. You must, however, address in your FutureG evolution path the OCUDU enhancements required to approach the 1 millisecond latency class over time, including deterministic and priority scheduling, Time-Sensitive Communication support, and mini-slot and preemption features.
What is the target commercial price point?
A CBRS-based as-a-service offer at $100,000 to $250,000. This is the most actionable number in the topic and it bounds the entire design: radio unit count and class, integration labor, and recurring service margin.
What does the topic say about the market?
Roughly 50,000 U.S. manufacturing firms in the 20 to 99 employee band alone, with several thousand more in the 100 to 250 range, based on National Association of Manufacturers data. But the serviceable addressable market is not all manufacturers, it is the subset with real mobility, reliability, coverage, or security pain: plants using AGVs, AMRs, machine vision, connected workers, outdoor yards, large indoor spaces, or metal-heavy RF environments.
What are the stated barriers to adoption?
Seven, described as consistent and compounding: return-on-investment ambiguity, legacy equipment and retrofit costs, spectrum and regulatory fragmentation, uneven device ecosystems, IT and OT integration complexity, in-house skills shortages, and tight capital budgets. Addressing each explicitly in your commercialization strategy is cheap differentiation.
Should I argue that Wi-Fi cannot roam?
No, and the topic pre-empts it. It states that modern Wi-Fi roaming standards, IEEE 802.11k, 802.11r, and 802.11v, substantially mitigate fixed-access-point handoff behavior when properly deployed on capable client devices. The advantage sought is that a 3GPP system provides deterministic network-scheduled access on interference-managed spectrum, standardized mobility management under network control, and quality-of-service guarantees enforceable under load. It also endorses Wi-Fi coexistence rather than rip-and-replace.
How many use cases must I address?
At least two of the four, in your Phase II Statement of Work, and you must identify which your reference architecture and pilot deployment are designed to validate. The deliverables require demonstrating at least one of the two selected use cases, so you scope two and physically demonstrate at least one.
What are the four use cases?
AGV and AMR connectivity and mobility, which also requires on-floor localization. Machine vision backhaul. Connected-worker safety. And secure outdoor yard and logistics coverage.
Is localization required?
Yes, within Use Case 1. That use case additionally requires on-floor localization of AGVs, AMRs, and tagged mobile assets for fleet management, geofencing, and safety zoning. Network-native positioning using 3GPP NR positioning methods from Release 16 and 17 is preferred, and hybrid approaches fusing NR positioning with existing plant localization systems may be proposed with justification.
What Industrial IoT requirements apply?
For the manufacturing vertical specifically, proposers shall address IIoT service characteristics as framed by 3GPP TS 22.104, including mapping selected use cases to TS 22.104 communication service classes, support for private-network or Non-Public Network operation, awareness of Time-Sensitive Communication and IEEE Time-Sensitive Networking integration concepts in the platform architecture, and secure IT and OT segmentation for IIoT traffic such as via network slicing or 5G-LAN group management. This requirement has no counterpart in the companion venue topic.
What is the mandatory common work package?
Three tasks, required regardless of use cases selected. Task A, Baseline Benchmark, establishing a quantified performance baseline of the integrated stack, with emulated end-to-end configuration acceptable and encouraged, incorporating existing RTEC results where available, presented to the OCUDU Test and Evaluation Working Group, with the report expected by Month 3. Task B, Code and Feature Enhancement, closing gaps between baseline and threshold and objective values, with all OCUDU modifications contributed upstream. Task C, Benchmark and Regression Harness, delivering the emulation-based benchmark suite as a repeatable, documented, open-source harness for adoption by the OCUDU community and RTECs.
Is there an additional mandatory engineering task?
Yes, and it is unique to this topic. A representative facility-specific RF engineering task comprising predictive propagation modeling incorporating facility-specific features such as metal racking, machinery, mezzanines, tank farms, and loading areas; an RF design mitigating dead spots and multipath impairments through cell placement, antenna selection and orientation, and mobility-parameter tuning; and installation engineering practices protecting radio hardware, including antenna placement clearances from reflective metal and verification of antenna-system return loss and VSWR at commissioning with monitoring thereafter to prevent reflected-power damage to RU front ends. An RF Design Report with representative coverage maps and commissioning approaches is a deliverable.
Do I have to contribute my code upstream?
Yes. All modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process, and enhancements that cannot be upstreamed shall be documented with rationale. Progress and upstream status are reported in Monthly Status Reports to the OCUDU T&E Working Group, and an itemized Upstream Contribution Log is a deliverable. This means your commercial differentiation cannot be the OCUDU code itself.
What are the security requirements?
A documented security architecture covering 3GPP security per TS 33.501 including mutual authentication and air-interface encryption and integrity protection; protection of the O-RAN open interfaces, meaning open fronthaul, E2, A1, and O1, per O-RAN WG11 specifications; zero-trust principles per NIST SP 800-207 including least-privilege access and separation of management and user traffic; and CVE monitoring for OCUDU and its dependencies with timely upstream patching. The architecture is documented at CDR, validated in RTEC testing, and the MVP demonstration must include at least one security capability shown live.
What are the Phase II milestones?
Month 1 kickoff and Technical Interchange Meeting, Monthly Status Reports throughout, Month 12 Critical Design Review, Month 16 prototype demonstration, Month 14 final design review and demonstration and assessment, and Month 18 Final Phase II Report. The published list places Month 16 before Month 14, which cannot be the intended order and appears as the same inversion in the companion topic DV031. Confirm through DSIP Topic Q&A and state your assumption in your work plan.
What does the demonstration site have to be?
Ideally an operating or representative manufacturing facility such as a partner small or medium manufacturer plant, a manufacturing institute or applied-research factory floor, or a comparable industrial or laboratory environment. It must be representative of the target deployment class in RF character, meaning metal-heavy and multipath-rich industrial construction, and in scale, meaning at minimum three cells sufficient to exercise inter-cell handover at operational AGV and AMR speeds. Its fidelity to plant conditions must be documented in the MVP demonstration package.
Is emulation acceptable?
For the Task A baseline, yes, and it is encouraged, provided the methodology, tooling, configurations, and results are fully documented and reproducible. But over-the-air performance with physical radio units and user equipment at the RTEC or representative demonstration site remains the standard of evidence for final KPM achievement.
How do I handle RedCap devices?
Address how the platform serves reduced-capability device classes including 3GPP Release 17 RedCap and Release 18 eRedCap, and identify any OCUDU scheduler or feature enhancements required, which are strongly encouraged as upstream contributions. Where RedCap-certified devices are not commercially available for a given endpoint type at demonstration time, you may demonstrate with available device classes or emulated RedCap UE profiles, and shall document the RedCap migration path.
What CMMC level applies?
The projected requirement for this topic is CMMC Level 2. Note that this topic states Level 2 without the parenthetical self-assessment qualifier that appears on the other two topics in this release, so if the distinction affects your compliance planning it is worth confirming through DSIP Topic Q&A.
Is this topic ITAR restricted?
No topic-level ITAR or EAR restriction paragraph appears on OSW26BZ06-DV032, and none appears on any of the three topics in this FutureG release.
How long can my technical volume be?
Twenty pages maximum, divided into Part 1 Phase I Justification at 5 pages maximum and Part 2 Phase II Technical Proposal at 15 pages maximum, with the Technology Transition and Commercialization Strategy at no more than 2 pages counting toward the 15. The FutureG instructions do not state that figures, tables, charts, and references count inside the limit or prohibit appendices, deferring instead to the DoW SBIR Program BAA formatting requirements.
Is the Company Commercialization Report evaluated?
Yes. FutureG states in both its Phase I and Direct to Phase II sections that information contained in the CCR will be considered during proposal evaluations. It is separate from the commercialization strategy in Volume 2.
Are there Percentage of Work restrictions?
Yes. The FutureG Office will not accept any deviation to the Percentage of Work requirements described in the DoW SBIR Program BAA. Model your POW before assembling a team that includes a radio unit vendor, an integrator, a plant partner, and possibly a manufacturing institute or university.
When will I hear back, and who gets notified?
Within 90 days of the closing date of the topic, approximately January 19, 2027, via DSIP. The notification goes to the individual listed as the Corporate Official on the proposal cover sheet. Note that the FutureG text says notification "for a Phase I award," which appears to be residual language given that this topic issues no Phase I award.
What is the defense application?
Modernizing DoW-affiliated depots, maintenance facilities, and logistics operations with resilient, high-mobility wireless connectivity, described as particularly relevant for contested logistics where reliable, secure, private communication networks are critical for maintaining operational tempo and supply chain integrity. Depots are structurally the same problem as commercial plants: large, metal-heavy, multipath-rich, with mobile equipment and outdoor yards.
Who do I contact with questions?
Technical questions about the topic go through DSIP Topic Q&A, which closes October 7, 2026. Administrative questions about the FutureG SBIR Program and these proposal preparation instructions go to the OUSW(R&E) FutureG Office at OSDRE-FutureG@groups.mail.mil.
Positioning Advice for Companies Considering This Topic
Audit your feasibility provenance before anything else. Feasibility documentation cannot be based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work, and a proposal that fails the feasibility bar is not evaluated. Open-source 5G integration work in the United States has been heavily SBIR funded, so this is a real risk for the most qualified bidders. The topic's own fourth evidence category tells you where to look: private, academic, or non-SBIR federally funded work.
Build the cost model to $100,000 to $250,000 and show it closes. This is the only topic in the release that states a target price point, and it is the question the government asked. A platform that performs beautifully at $600,000 per plant does not answer it. Show the radio unit count, hardware class, integration labor, and recurring service margin that land inside the band, and be explicit about what you trade to get there.
Do not argue that Wi-Fi cannot roam. The topic concedes that 802.11k, 802.11r, and 802.11v substantially mitigate handoff behavior when properly deployed, and it names the real advantages: deterministic network-scheduled access on interference-managed spectrum, standardized network-controlled mobility, and enforceable quality of service under load. Make that case instead. And adopt the Wi-Fi coexistence posture the topic endorses rather than a rip-and-replace pitch.
Secure a metal-heavy three-cell site early. The demonstration environment must be representative in RF character and in scale, with at minimum three cells sufficient to exercise inter-cell handover at operational AGV speeds, and its fidelity must be documented. A partner plant, a manufacturing institute, or an applied-research factory floor is a dependency you cannot buy quickly. Name it on page one.
Ask about the missing KPM tables, then propose your own. The topic points at tables and a Section 3.0 that are not published, but it also tells you how the KPMs are meant to work: suggested reference values, not pass or fail, with proposers proposing justified targets calibrated to their environment and final targets agreed at kickoff and confirmed at CDR. Raise the gap in Topic Q&A and handle it professionally in the proposal.
Do the latency budget decomposition properly. Five named segments, air interface, DU and CU processing, fronthaul and F1 transport, core user plane, and application processing, in the Critical Design Document, with measurement reference points, traffic type, packet size, and methodology specified per latency KPM. It is a named requirement, it is genuinely useful engineering, and most proposals will state a latency number without decomposing it.
Respect the isochronous scope boundary. Hard-real-time motion control at 0.5 to 2 millisecond cycle times is out of scope for Phase II. Promising it reads as not having read the topic. Address the 1 millisecond class in your FutureG evolution path with deterministic and priority scheduling, TSC support, and mini-slot and preemption features, which is exactly what was asked.
Take the TS 22.104 mapping seriously. Mapping your selected use cases to TS 22.104 communication service classes is a concrete, checkable artifact, and NPN support, TSC and TSN awareness, and secure IT and OT segmentation are named requirements unique to this topic. IT and OT segmentation in particular is what a plant IT department will scrutinize, so network slicing or 5G-LAN group management deserves real treatment.
Pick Use Cases 1 and 2 unless you have a reason not to. They carry the topic's two stated performance targets, handover success and machine-vision latency, they exercise both dominant performance classes, they share the indoor RF design, and they align with the two named OCUDU enhancement areas of mobility and handover optimization and uplink capacity. Use Case 3 pairs cheaply with either and adds the RedCap and five-nines dimensions.
Answer the trust question as a document. What does a plant manager with no RF staff need to see, in what form, to sign for a network with no vendor warranty? Sketching that evidence package, even as a table of contents, differentiates you from proposals that answer with a test matrix.
Treat the RF engineering task as a differentiator, not a chore. Predictive propagation modeling in metal-heavy environments, dead-spot mitigation through cell placement and antenna orientation, and VSWR verification at commissioning to prevent reflected-power damage to RU front ends. That last item is a practitioner's requirement, and answering it with actual installation practice signals that you have deployed in a factory rather than modeled one.
Budget the common work package separately. Tasks A, B, and C are required regardless of use case, the baseline report is due by Month 3, and the harness is an open-source deliverable documented for independent execution. Folding it into general engineering underprices it.
Plan for upstream review you do not control. All OCUDU changes go upstream on the project's timeline, the log includes review status, and non-upstreamable enhancements need documented rationale. Say how you sequence contributions and what happens to a KPM claim if a patch is still in review at Month 18.
State how you make money when the code is public. Integration, RF engineering, the evidence package, the as-a-service model, and support are your differentiation. A commercialization strategy that avoids this looks naive to a reviewer who wrote the upstream requirement.
Address the seven adoption barriers one by one. ROI ambiguity, legacy equipment and retrofit costs, spectrum and regulatory fragmentation, uneven device ecosystems, IT and OT integration complexity, skills shortages, and tight capital budgets. The topic says a tier-one proprietary platform addresses almost none of them. Showing that you address each is the clearest possible articulation of why you should be funded.
Plan the page budget before drafting. This topic has more mandatory content than its venue companion, including the IIoT requirements and the RF engineering task, and the same 5 plus 13 plus 2 page allowance. Decide the allocation first.
