OSW-FutureG SBIR OSW26BZ06-DV031: Smart Venues and Stadiums, Open-Source Private 5G
Quick Answer
OSW26BZ06-DV031 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 stadiums and large venues built entirely from open-source software, with no proprietary core, RAN Intelligent Controller, or Service Management and Orchestration component anywhere in the stack, validated at a real venue under real event-day congestion, and architected to evolve toward 6G Integrated Sensing and Communication. 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 specific stack is named and it is not optional: 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. If your architecture includes a commercial core or a vendor RIC, it does not meet the topic.
The economic argument is unusually detailed for a solicitation. Distributed Antenna System deployments in large public venues have grown from a few million dollars in early builds to routinely tens of millions. Active multi-carrier DAS hardware and installation is commonly quoted at $5 to $10 per square foot, meaning even a mid-sized 300,000 square foot concourse and bowl footprint implies a multi-million-dollar build before integration, spectrum, and ongoing carrier-management costs. And mobile network operator appetite to fund new DAS builds outside Tier 1 venues, meaning 70,000-plus capacity or 200-plus events per year, is shrinking, leaving small and mid-sized venues with a widening connectivity gap.
There is one thing you should know before reading further. The topic repeatedly directs proposers to key performance metrics in "the table below" and to "Section 3.0" thresholds. No such tables and no numbered Section 3.0 appear in the published document. That gap is discussed in its own section below, and it is the most important question to ask the government before the topic closes.
Topic At a Glance
Topic number: OSW26BZ06-DV031
Title: Smart Venues and Stadiums
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, Sustainment and Logistics
Projected CMMC level requirement: Level 2 (Self)
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: extreme user density, ultra-secure operation, and integrated sensing
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
Upstream requirement: all modifications to OCUDU shall be contributed upstream through the project's standard contribution and review process
Demonstration site: the proposer's site, ideally an operating or representative venue or stadium environment, or a full-scale representative test bed where live-venue access is not feasible during Phase II
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 venues and stadiums, connected stadiums, 5G stadiums
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 following" and "do not need to have a perfect, finished product" are real allowances, and simulation models are explicitly acceptable.
The restriction that still applies, and it matters here
The FutureG Direct to Phase II guidelines impose a hard constraint that 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 acceptable evidence category says "prior private, academic, or non-SBIR federally funded work," which is consistent with the restriction and tells you exactly where to look. Non-SBIR federally funded work is explicitly fine. Private and academic work is fine. Prior SBIR and STTR work is the problem.
This is a live risk for exactly the companies most likely to bid, because open-source 5G integration work in the United States has been substantially SBIR funded. Audit the provenance of every result you intend to cite.
And the consequence is severe: 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
This section exists because the gap is material and you should not discover it while drafting.
The topic refers to key performance metric tables and to a numbered section repeatedly. It says other suggested KPMs for the various use cases and system requirements are given below for reference. In Use Case 2 it says the positioning and velocity accuracy, anomaly alert, and missed-detection and false-alarm KPMs "in the table below" apply to the Tier 1 demonstrated functions. Task A requires establishing a baseline against the KPMs relevant to the selected use cases "including the General System and Architectural Requirements." The deliverables list requires MVP demonstration 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."
No KPM tables appear in the published document. There is no numbered Section 3.0, and no section titled General System and Architectural Requirements.
What to do about it
Ask. DSIP Topic Q&A closes October 7, 2026, two weeks before the topic closes, and this is the single highest-value question available on this topic. Ask whether the KPM tables and the General System and Architectural Requirements section were omitted from the published instructions and, if so, request them or a pointer to them.
In the meantime, the topic gives you enough to proceed and in fact tells you to. It says proposers should address specific, relevant, measurable, and quantifiable KPMs including, for example, concurrent-device density, sensing detection accuracy, latency, jitter, and service availability. And it gives one worked example: "The platform must sustain a session success rate greater than 99.5% for fan-facing connections at a concurrent-device density of 3,000 devices per acre in the lower bowl."
The companion topic in this same release, DV032 Smart Manufacturing, states the governing principle explicitly and it is reasonable to read it as the program office's general intent: the KPM values in the tables are suggested reference values, not pass/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 suggested values must be technically justified; threshold values represent the intended standard of Phase II demonstration success while objective values are stretch goals; and final KPM targets will be agreed with the Government at kickoff and confirmed at the Critical Design Review.
So the practical approach is to propose your own KPM set with threshold and objective values, justify each against your architecture and spectrum plan, state plainly that you are doing so because the referenced tables do not appear in the published instructions, and note that final targets will be agreed at kickoff and confirmed at CDR. That is a defensible position and it demonstrates that you read the document carefully, which is itself worth something.
What the Government Is Actually Buying
The objective
The objective of this Phase II effort is to design, validate, and demonstrate a secure, high-density private 5G network platform for stadiums and large venues, integrating open-source OCUDU, SD-Core, SD-RAN, and OSC components, to deliver resilient, multi-service communication alongside a 6G-ready Integrated Sensing and Communication architecture.
This platform will be validated at a representative venue site to prove stable performance under extreme device congestion, enable native device localization for crowd analytics, and establish a cost-effective, vendor-neutral dual-use framework for both commercial entertainment venues and dense military installation environments.
The market, as the government describes it
The realistic near-to-mid-term serviceable addressable market for private 5G and 6G-ready platforms among U.S. venues and stadiums is a subset of venues with acute connectivity, safety, and operational pain: major-league and collegiate stadiums, multi-purpose arenas, outdoor amphitheaters, and convention and exhibition centers that host recurring high-density events, require public-safety-grade coverage throughout bowls, concourses, tunnels, and back-of-house areas, and are increasingly asked to support fan-facing digital experiences, cashierless concessions, camera and sensor networks, and first-responder communications simultaneously on event day.
The United States features an extensive footprint of sports and entertainment infrastructure, spanning an estimated 2,000 to 5,000 major stadiums and arenas when accounting for all professional, collegiate, and municipal facilities, which further scales to over 15,000 total venues if relatively large localized high school stadiums are included. Beyond stadiums and arenas, industry directories catalog well over 400 U.S. convention and exhibition centers, ranging from single-hall regional facilities to multi-million-square-foot complexes. Together, these figures put the large-venue addressable base at several hundred U.S. facilities, before counting mid-sized arenas, amphitheaters, and secondary convention space. Localized large gatherings such as fairs add up to several thousand more.
Note the careful narrowing. Fifteen thousand venues exist, but the serviceable addressable base is "several hundred U.S. facilities." Your commercialization strategy should use the government's own narrower figure rather than the headline number, because inflating it against the topic's own text is an easy weakness to spot.
The pain points
Venues already invest heavily in connectivity infrastructure, yet several published industry reports indicate persistent cost and coverage pain. Distributed Antenna System deployments in large public venues have grown from a few million dollars in early builds to routinely tens of millions of dollars. Independent of venue scale, active multi-carrier DAS hardware and installation is commonly quoted at $5 to $10 per square foot, meaning even a mid-sized 300,000 square foot concourse and bowl footprint implies a multi-million-dollar build before integration, spectrum, and ongoing carrier-management costs.
Despite this infrastructure spend, published reviews consistently cite coverage dead zones in lower bowls and concourses, congestion during peak moments such as kickoff, halftime, and entry and egress, and multi-year vendor lock-in as recurring pain points. Industry reporting suggests that mobile network operator appetite to fund new DAS builds outside Tier 1 venues, defined as 70,000-plus capacity or 200-plus events per year, is shrinking, leaving small and mid-sized venues with a widening connectivity gap.
How this segment buys
This segment buys on measurable fan and operational outcomes, specifically dropped-call rate at kickoff, point-of-sale uptime, camera uptime, and incident-response time, not on global platform standardization.
Its stated barriers to adopting anything other than the incumbent DAS and neutral-host model are consistent: high capital expenditure and multi-year contract terms, uncertainty about interoperability across multiple wireless carriers that must all be hosted on one system, integration complexity with legacy venue information technology and operational technology and public-safety radio systems, and a lack of in-house RF and cellular engineering staff.
Those four named metrics are the ones to build your value proposition around. Dropped-call rate at kickoff, POS uptime, camera uptime, incident-response time. They are also natural KPMs, and using the buyer's own language is more persuasive than throughput figures.
The open-source argument, and its honest cost
An all-open-source stack removes the structural cost and lock-in that makes proprietary DAS platforms a poor fit for this segment's economics. Because OCUDU communicates 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 and antenna form factor best fits a given venue's bowl geometry, concourse layout, and budget.
Together, OCUDU, SD-Core, SD-RAN, and OSC form one integrated, fully open-source 5G stack that a systems integrator can deploy, support, and price as a right-sized, as-a-service offer for a single venue, rather than a broad, vendor-locked, multi-carrier neutral-host platform.
The trade-off of an all-open-source stack is the same one seen in other verticals: the burden of proving interoperability, stability, and security shifts from a single vendor's warranty to the integrator and the open-source community.
Venue operators, who by their own account do not carry in-house cellular or RF engineering expertise, have essentially zero tolerance for connectivity failures discovered live, on a broadcast event, in front of tens of thousands of people.
That last sentence is the commercial crux of the topic and it deserves a direct answer in your proposal. The topic gives you the intended answer: this is exactly the gap the ongoing OCUDU Testing and Validation Plan, and its RTEC-centered extensions, are designed to close, through independently witnessed, multi-vendor testing of device diversity, RU diversity, high-density and high-mobility 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.
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 a mapping table in substance, and it is easy to omit while writing about the venue application. Do not omit it.
For this topic, the dominant performance classes are extreme user density, ultra-secure operation, and integrated sensing: tens of thousands of concurrent devices per venue with sharp event-day load peaks, public-safety-grade availability and access control across bowls, concourses, and back-of-house areas, and an architecture evolvable to 6G Integrated Sensing and Communication.
The Four Research Questions
Research and development for this effort should address, at minimum, the following four questions. Treat them as required sections.
All-open-source economics
What is the fully loaded cost, covering integration, support, spectrum, hardware, and RF design, of an OCUDU plus SD-Core plus SD-RAN plus OSC deployment at venue scale relative to a proprietary DAS and neutral-host platform, and how should that be packaged as a CBRS-based, as-a-service offer within the price point venue operators require?
Note "CBRS-based." Citizens Broadband Radio Service spectrum is the assumed band, which shapes your RF design, your device ecosystem, and your Spectrum Access System dependency. Note also "as-a-service," meaning the business model is recurring rather than capital sale. Unlike the companion manufacturing topic, this one does not state a target price point, so you must establish it from the DAS comparison the topic gave you.
Use-case-first deployment
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 under stadium-scale, high-density loading conditions?
6G and ISAC evolution path
What architectural changes across waveform, RU capability, RIC application, and SMO orchestration are required to evolve the platform from a 5G communications-only deployment to a 6G-ready platform capable of Integrated Sensing and Communication, and which ISAC-enabled use cases can be prototyped now using 5G-Advanced sensing features as a bridge to native 6G ISAC?
Trust in open source
How does RTEC-executed testing of the full open-source stack reduce the integration risk and skills-shortage barrier venue operators 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 fourth question is the most commercially important and the one most proposals will answer weakly. The deliverable it implies is an evidence package: what does a venue general manager with no RF staff need to see, in what form, to sign a contract for a network with no vendor warranty behind it? Answer it as a document design problem, not as a testing plan.
Solutions leveraging artificial intelligence and machine learning for crowd analytics, 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 venues and stadiums vertical. Dual-use opportunities are expected across commercial venue operators, DoW-affiliated event and installation venues, and public-safety agencies.
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 a practical accommodation worth using. RedCap device availability in CBRS bands is limited, and the topic explicitly permits emulated profiles with a documented migration path.
Use Case 1: High-density fan connectivity and broadcast and production backhaul
Tens of thousands of fans, concession point-of-sale terminals, ticketing scanners, and broadcast and production camera and audio feeds must all operate simultaneously within a single bowl and concourse footprint, with demand spiking sharply at kickoff, halftime, and egress. Legacy DAS and Wi-Fi are commonly saturated at these peak moments, producing dropped sessions and stalled transactions.
This use case requires the platform to sustain high concurrent-device density with consistent per-user throughput, plus dedicated low-latency, low-jitter uplink capacity for broadcast and production camera backhaul, across the full bowl and concourse footprint.
Note that this bundles two different problems: massive downlink-and-uplink density for consumer devices, and guaranteed low-jitter uplink for a small number of professional video feeds, on the same network at the same moment. The quality-of-service and slicing story is the answer, and it should be explicit.
Use Case 2: ISAC-enabled crowd analytics and situational awareness, 6G-ready
Venue operators and public-safety personnel need continuous, accurate awareness of crowd density, flow, and anomalies such as bottlenecks at egress, unattended objects, and unauthorized drone incursion into restricted airspace above the bowl, to prevent crushing incidents and stampedes and respond quickly to emerging threats. Deploying a separate dedicated sensor network of radar, lidar, or additional camera arrays to provide this awareness is costly and adds another system to integrate.
This use case requires the platform to support Integrated Sensing and Communication, which uses the same radio infrastructure and spectrum that carries communication traffic to also sense the physical environment, through bistatic or monostatic sensing from gNB and O-RU hardware correlated with RIC-hosted analytics applications, without requiring a separate sensing-only network build.
The topic cites 3GPP Release 19 Technical Report 22.837, which identifies more than 30 ISAC use cases spanning object and intruder detection, environmental monitoring, motion sensing, and public-safety scenarios directly applicable to stadiums, arenas, and convention centers. It also cites 3GPP TS 22.137, which establishes a standardized set of ISAC performance metrics including positioning accuracy, velocity accuracy, sensing resolution, sensing range, refresh rate, latency, and missed-detection and false-alarm probabilities.
Proposers should treat 5G-Advanced sensing features as the near-term bridge path toward native 6G ISAC.
The hybrid localization requirement
Proposers shall employ a hybrid architecture in which standardized network-native user equipment positioning, meaning 3GPP Release 16 and 17 NR positioning using uplink time difference of arrival, multi-round-trip-time, and angle of arrival and departure, over the connected device population provides the primary, near-term source of crowd density, flow, and bottleneck analytics, with appropriate aggregation and anonymization for fan-facing devices, and RF sensing, meaning ISAC, is applied to non-cooperative targets that carry no connected device.
Crowd-analytics KPMs may be satisfied via UE positioning in the Phase II demonstration.
That last sentence is a significant de-risking allowance. You can meet the crowd analytics metrics using standardized positioning of connected phones rather than true RF sensing. Read it together with the tiering below.
The tiered scope, which is the most important paragraph in this use case
Sensing functions under this use case are tiered by 12-month feasibility.
Tier 1, for the Phase II demonstration, comprises two things. First, crowd density and flow analytics derived from network-native UE positioning of connected devices, per the hybrid-localization requirement, aggregated and anonymized. Second, at least one non-cooperative RF-sensing bridge function achievable at 5G-Advanced maturity and deployed sensing bandwidths, for example detection of unauthorized drone incursion exploiting Doppler and motion signatures, demonstrated in a laboratory or limited field configuration.
Tier 2 is roadmap only: unattended-object detection and fine-grained tracking of individuals within dense, multi-directional crowds, which are limited by achievable sensing resolution of approximately c over 2B at deployable bandwidths. These shall be addressed in the documented 6G and ISAC evolution path with quantified bandwidth, waveform, aperture, and sensor-fusion requirements rather than demonstrated in Phase II.
Custom or modified waveforms are not required for Phase II.
The positioning and velocity accuracy, anomaly alert, and missed-detection and false-alarm KPMs referenced in the tables apply to the Tier 1 demonstrated functions.
This tiering is the government being realistic, and it is written by someone who understands the physics. The c over 2B range resolution limit means that at CBRS-scale bandwidths you cannot resolve individual people in a crowd, and the topic says so rather than asking you to pretend otherwise. Respect the tiering. A proposal that promises Tier 2 capability in Phase II is not more ambitious, it is less credible.
Note also that a laboratory or limited field configuration is acceptable for the Tier 1 non-cooperative sensing function. Drone detection by Doppler signature in a controlled setting satisfies it.
Use Case 3: Public safety and first responder priority communications
First responders, venue security, and event staff require reliable, prioritized push-to-talk and data communications throughout the bowl, concourses, tunnels, loading docks, and below-grade back-of-house areas that legacy DAS and Wi-Fi frequently fail to reach or fail to prioritize during network congestion.
This use case requires the platform to sustain low-latency, high-reliability, priority and preemption-capable connectivity for public-safety traffic across the full indoor venue footprint, including areas outside typical fan-facing coverage design.
Priority and preemption is a specific 3GPP capability set and it is the part of this use case that has to actually work under the Use Case 1 load. If you address both use cases, show the interaction: public-safety traffic preempting fan traffic at kickoff is the test.
Use Case 4: Venue operations, logistics, and outdoor perimeter coverage
Loading docks, outdoor plazas, parking structures, and perimeter areas surrounding a venue increasingly require connectivity for autonomous cleaning and security robots, connected cameras, RFID and asset tracking for concessions and merchandise logistics, and credentialed-access control, yet typically fall outside indoor DAS and Wi-Fi coverage entirely.
This use case requires the platform to extend secure, private coverage into outdoor plaza, parking, and perimeter areas immediately adjacent to the venue, using the same OCUDU-based infrastructure rather than a separate outdoor Wi-Fi or cellular repeater buildout.
Choosing your two
Some combinations are cheaper than others. Use Cases 1 and 3 share the indoor bowl and concourse RF design and differ mainly in quality-of-service treatment, which makes them the most economical pair and the most directly aligned with the buying metrics the topic named. Use Case 2 requires ISAC-capable radio units or software-defined sensing functions plus RIC-hosted analytics, which is additional hardware and additional integration, though the Tier 1 tiering and the UE-positioning allowance make it more tractable than it first appears. Use Case 4 requires outdoor cell planning and additional radio units.
State your choice explicitly and say what your reference architecture and pilot deployment are designed to validate, because the topic requires you to identify 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.
This is not optional and it is not scoped by your use case choice. Budget it 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 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.
Note that the baseline benchmark report is expected by Month 3. That is early, and it means your emulation environment has to be standing up in the first weeks of the award.
Task B: Code and Feature Enhancement
Identify the gaps between baseline performance and the 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.
The upstream contribution requirement has real business consequences. Your code improvements go into a public open-source project, reviewed by that project's maintainers on their timeline. That means your 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 your commercialization strategy rather than leaving a reviewer to wonder how you make money.
It also means schedule risk you do not control. Upstream review timelines belong to the project, and the deliverable is an itemized log including review status, which acknowledges that acceptance is not guaranteed. Plan for contributions in review at the end of the period of performance.
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.
That final sentence is the one to underline. Emulation gets you the baseline. Over-the-air with real hardware is what counts for final KPM achievement.
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.
Four named standards and one live demonstration requirement. The live security demonstration is easy to underplan, so pick which capability you will show and design the demonstration around it early. Note also that ultra-secure operation is one of the three dominant performance classes for this topic, alongside extreme user density and integrated sensing, so security is a scored dimension rather than a compliance section.
Milestones 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.
Note the ordering. 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 DV032 in this release, which suggests a shared drafting error rather than a deliberate structure. The sensible reading is a Month 14 prototype demonstration followed by a Month 16 final design review and assessment, or the reverse; either way, confirm through DSIP Topic Q&A before you build a schedule around it, and state your assumed sequence in your work plan.
Monthly Status Reports are to 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, not just an internal report, and it should be staffed.
The demonstration site
Prototype demonstrations will be performed at the proposer's site, ideally an operating or representative venue or stadium environment, or a full-scale representative test bed where live-venue access is not feasible during Phase II.
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 MVP demonstration, including physical radio units and user equipment, and for Use Case 2 ISAC-capable RU and sensing hardware or software-defined sensing functions, will need to occur at the venue-representative site.
Securing a venue relationship is the practical crux of this proposal. An operating stadium, arena, amphitheater, or convention center that will let you install radio units and run tests, or a full-scale representative test bed, is a dependency you do not control and cannot buy quickly. If you have a venue partner, name it on page one. If you have a test bed, describe its fidelity to venue conditions, because the deliverables require a description of the demonstration site's fidelity to venue and stadium conditions.
Scalability and RTEC leverage
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, including the 6G and ISAC evolution path.
Key Performance Metrics.
MVP Demonstration slides and documentation, including a description of the demonstration site's fidelity to venue and stadium 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 venue-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.
A Final Design Document.
A Final Technical Report.
Two notes on this list. The published deliverables include a duplicated integration bullet, one referring to a venue-representative demonstration site and one referring to a factory-representative demonstration site. The factory reference is plainly carried over from the companion Smart Manufacturing topic and does not apply here.
Also note the relationship between "address 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 demonstrate at least one physically. That is a meaningful reduction in demonstration burden and it should shape which two you select: pick a pair where one is demonstrable at your site and the other is architecturally addressed.
Phase III Dual Use
The advanced private 5G and FutureG networking platform presents significant dual-use opportunities by leveraging a single, open-source technology stack to serve both commercial venues and critical DoW operational needs.
For commercial interests, this technology offers a cost-effective and vendor-neutral alternative to proprietary systems in stadiums, arenas, and convention centers. It aims to enhance fan experiences with high-density connectivity, support broadcast backhauling, and improve venue operations through integrated sensing for crowd analytics and situational awareness.
For the Department, the same platform provides resilient, secure, and high-density wireless coverage essential for DoW-affiliated event venues, training facilities, and large-scale installation assembly spaces. The platform's capability for Integrated Sensing and Communication can be adapted for enhanced situational awareness, asset tracking, and security monitoring in dynamic military environments, ensuring that advancements in commercial wireless technology directly bolster defense capabilities.
The defense case is worth developing beyond the stated text. Large-scale installation assembly spaces, base-wide event venues, training facilities, and deployed camp environments all involve dense transient populations in fixed footprints, which is structurally the same problem as a stadium. The Contested Logistics Technologies Critical Technology Area designation also points at the logistics and asset-tracking angle in Use Case 4 more than at fan connectivity, so if you want the defense narrative to land, Use Case 4 and the public-safety priority communications of Use Case 3 are the stronger hooks.
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 venue-scale RF design, an ISAC or positioning capability if you select Use Case 2, an emulation benchmark harness, a security architecture with a live demonstration, and a physical MVP at a venue-representative site, in 18 months for $2.15 million, is a full program. Existing OCUDU experience, an existing venue or test bed relationship, and existing RTEC engagement are worth more here 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 in the cost volume template 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. Radio units, user equipment, CBRS Spectrum Access System service, channel emulators, and load generators 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.
This is a serious constraint on this topic. The natural team includes a radio unit vendor, a systems integrator, a venue partner, possibly an RTEC, and possibly a university. Model your POW before you assemble it, because a plan that pushes too much work outside your firm cannot be negotiated back into compliance.
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 is explicitly asking for an as-a-service offer at a price point, 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. Within the 15 pages, the Technology Transition and Commercialization Strategy is not to exceed 2 pages and counts toward the limit.
So 5 pages of feasibility, 13 pages of technical proposal, 2 pages of commercialization. Against that you must fit: the four research questions, two use cases, the RedCap discussion, the hybrid localization architecture if you select Use Case 2, the performance-class mapping, three common work package tasks, the security architecture, the RF design approach, the milestone plan, key personnel, facilities, and consultants. Plan the page allocation before drafting, because this is one of the tightest content-to-page ratios in the cycle.
Note that 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. Read that BAA 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. They are enumerated and a reviewer will look for each.
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 in both its Phase I and Direct to Phase II sections, consistently. Complete it fully. Note that 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. Note that 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. Use it, and use it on the missing KPM tables above all.
The Reference
One, and it is a link to an industry article: the rise of smart stadiums, at cellnex.com.
That is the entire cited reference list, which is remarkable for a topic of this technical density. The substantive citations are embedded in the topic text rather than in the reference section, and they are the ones that matter: 3GPP Release 19 TR 22.837 for ISAC use cases, 3GPP TS 22.137 for ISAC performance metrics, 3GPP Release 16 and 17 NR positioning methods, 3GPP Release 17 RedCap and Release 18 eRedCap, 3GPP TS 33.501 for security, O-RAN WG11 specifications for open interface protection, NIST SP 800-207 for zero trust, and the O-RAN 7.2x split.
Those eight are your real reading list. The Related Work section is required to demonstrate awareness of the state of the art, and with only a marketing article in the formal reference list 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 the published RTEC test results the topic tells you to leverage.
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, because 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 venue or full-scale test bed relationship in writing, since the MVP demonstration requires physical radio units and user equipment at a venue-representative site. Engage the RTEC community and identify which validated reference configurations already exist for your intended RU, Core, RIC, and SMO combination, since the baseline shall incorporate available RTEC results rather than duplicate them. Get familiar with the OCUDU contribution process and the OCUDU Test and Evaluation Working Group cadence, since Monthly Status Reports go to that group. Choose your two use cases and be able to say which your reference architecture and pilot deployment validate. Plan your CBRS spectrum approach. Read the eight embedded standards references. Model your Percentage of Work before assembling a team that includes an RU vendor, an integrator, a venue, and possibly a university. Confirm SAM registration and CMMC Level 2 self-assessment in SPRS.
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 four research questions, your two use cases, RedCap handling, the hybrid localization architecture and Tier 1 and Tier 2 scoping if you select Use Case 2, the required performance-class mapping, the three common work package tasks, the security architecture with your chosen live demonstration, the RF design approach, and the milestone plan with your assumed Month 14 and Month 16 sequence. Draft your own KPM set with threshold and objective values and justify each. Draft the 2-page commercialization strategy answering all five enumerated questions, using the government's own "several hundred U.S. facilities" figure and the four buying metrics. 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 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 radio units across multiple vendors, user equipment, hardware accelerators, CBRS Spectrum Access System service, channel emulation and load generation for the Task A baseline, RTEC testing engagement, venue site access and installation, ISAC or sensing hardware if applicable, 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 venue partners 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-DV031?
OSW26BZ06-DV031 is a Direct to Phase II SBIR topic titled "Smart Venues and Stadiums," released under the OSW FutureG Office FY26 SBIR Broad Agency Announcement, Release 6. The objective is to design, validate, and demonstrate a secure, high-density private 5G network platform for stadiums and large venues, integrating open-source OCUDU, SD-Core, SD-RAN, and OSC components, delivering resilient multi-service communication alongside a 6G-ready Integrated Sensing and Communication architecture, validated at a representative venue site.
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 feasibility evidence does the topic accept?
One or more of four categories: test data and metrics from previous lab environments or early field trials; technical reports and white papers explaining previous research, system designs, or software integration efforts; prototype designs and simulation models including diagrams, architectural blueprints, or simulation results; and previous project outcomes including success criteria, milestone reports, or commercialization results from prior private, academic, or non-SBIR federally funded work. The government states that proposers do not need to have a perfect, finished product.
Can my feasibility evidence come from a prior SBIR award?
No. The FutureG Direct to Phase II guidelines state that feasibility documentation cannot be based upon or logically extend from any prior or ongoing federally funded SBIR or STTR work, and that the work must have been substantially performed by the proposer or the Principal Investigator. The Volume 2 instruction uses the weaker phrasing "must not be solely based on"; plan against the stricter reading. Note that the topic's own fourth evidence category names private, academic, or non-SBIR federally funded work, which is consistent with the restriction.
Where are the KPM tables the topic refers to?
They do not appear in the published document. The topic refers to KPMs in "the table below," to "Section 3.0" thresholds, and to a "General System and Architectural Requirements" section, none of which are present. This is the most important thing to raise through DSIP Topic Q&A before it closes on October 7. In the meantime, propose your own justified KPM set with threshold and objective values, state why you are doing so, and note that final targets are agreed at kickoff and confirmed at the Critical Design Review.
What KPMs does the topic name in its text?
Concurrent-device density, sensing detection accuracy, latency, jitter, and service availability, given as examples. It also provides one worked example: the platform must sustain a session success rate greater than 99.5 percent for fan-facing connections at a concurrent-device density of 3,000 devices per acre in the lower bowl. The four buying metrics the segment uses are also natural KPMs: dropped-call rate at kickoff, point-of-sale uptime, camera uptime, and incident-response time.
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. Note that 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?
High-density fan connectivity and broadcast and production backhaul. ISAC-enabled crowd analytics and situational awareness, 6G-ready. Public safety and first responder priority communications. And venue operations, logistics, and outdoor perimeter coverage.
Do I have to build true RF sensing for the crowd analytics use case?
Not entirely. Proposers shall employ a hybrid architecture where standardized network-native UE positioning using 3GPP Release 16 and 17 NR positioning provides the primary near-term source of crowd density, flow, and bottleneck analytics, with RF sensing applied to non-cooperative targets carrying no connected device. The topic states that crowd-analytics KPMs may be satisfied via UE positioning in the Phase II demonstration.
What is the tiered sensing scope?
Tier 1, for the Phase II demonstration, is crowd density and flow analytics from network-native UE positioning, aggregated and anonymized, plus at least one non-cooperative RF-sensing bridge function achievable at 5G-Advanced maturity and deployed bandwidths, such as unauthorized drone incursion detection using Doppler and motion signatures, demonstrated in a laboratory or limited field configuration. Tier 2 is roadmap only: unattended-object detection and fine-grained tracking of individuals in dense crowds, limited by achievable sensing resolution of approximately c over 2B at deployable bandwidths, to be addressed in the documented 6G and ISAC evolution path rather than demonstrated. Custom or modified waveforms are not required for Phase II.
What is the mandatory common work package?
Three tasks, required in the Phase II Statement of Work 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. Task B, Code and Feature Enhancement, closing the 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.
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 contribution 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. Note that 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 DV032. Confirm the sequence through DSIP Topic Q&A and state your assumption in your work plan.
Where must the demonstration happen?
At the proposer's site, ideally an operating or representative venue or stadium environment, or a full-scale representative test bed where live-venue access is not feasible during Phase II. The MVP demonstration, including physical radio units and user equipment, must occur at the venue-representative site, and the deliverables require documenting the site's fidelity to venue and stadium conditions.
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.
What spectrum does the topic assume?
CBRS. The economics question asks how the deployment should be packaged as a CBRS-based, as-a-service offer within the price point venue operators require. Unlike the companion manufacturing topic, this one does not state a target price point, so you must establish it from the DAS cost comparison the topic provides.
What does the topic say about the market size?
An estimated 2,000 to 5,000 major stadiums and arenas across professional, collegiate, and municipal facilities, scaling to over 15,000 total venues including larger high school stadiums, plus well over 400 U.S. convention and exhibition centers. But the topic narrows the serviceable addressable base to several hundred U.S. facilities before counting mid-sized arenas, amphitheaters, and secondary convention space. Use the narrower figure in your commercialization strategy.
What is the required performance-class mapping?
The Technical Volume shall include a mapping of each selected use case, and its associated KPMs, to the generic network performance class or classes it exercises, and shall identify which anticipated OCUDU code or feature enhancements correspond to each class. For this topic the dominant performance classes are extreme user density, ultra-secure operation, and integrated sensing. This is a required element stated with "shall" and it is easy to omit.
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 with self-assessment.
Is this topic ITAR restricted?
No topic-level ITAR or EAR restriction paragraph appears on OSW26BZ06-DV031, 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.
What must the commercialization strategy address?
Five specific questions in no more than 2 pages. 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. Who are your competitors and what is your price or quality advantage.
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: the CCR covers what you have done with past Phase II awards, the strategy covers how you propose to commercialize this research.
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. This is a real constraint given that the natural team includes a radio unit vendor, an integrator, a venue partner, possibly an RTEC, and possibly a university. Model your POW before assembling it.
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.
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 at all. 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.
Ask about the missing KPM tables, then proceed anyway. The topic points at tables and a Section 3.0 that are not in the published document. Raise it in Topic Q&A before October 7, and in the proposal propose your own justified KPM set with threshold and objective values, saying plainly why. Noting the gap and handling it professionally is a strength, not a complaint.
Secure the venue relationship first. The MVP demonstration requires physical radio units and user equipment at a venue-representative site, and the deliverables require documenting that site's fidelity to venue conditions. A signed venue partner or a described full-scale test bed is the single most valuable thing on page one. Nothing technical compensates for not having somewhere to demonstrate.
Answer the trust question as a document, not a test plan. The fourth research question asks 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 is a deliverable a venue general manager reads and acts on. Designing it, and showing a mockup or a table of contents, differentiates you from proposals that answer with a testing matrix.
Use the buyer's four metrics. Dropped-call rate at kickoff, point-of-sale uptime, camera uptime, incident-response time. The topic says this segment buys on those, not on platform standardization. Building your KPMs and your value proposition on those four speaks the customer's language and the government's at the same time.
Pick your two use cases on cost, then justify on mission. Use Cases 1 and 3 share the indoor RF design and differ mainly in quality-of-service treatment, which makes them the most economical pair and the one closest to the named buying metrics. If you address both, show priority and preemption for public safety working under peak fan load, because that interaction is the real test.
Respect the Tier 1 and Tier 2 sensing boundary. The topic tells you that fine-grained tracking of individuals in dense crowds is limited by c over 2B at deployable bandwidths and puts it in the roadmap, not the demonstration. A proposal promising Tier 2 in Phase II reads as not having done the physics. Use the UE-positioning allowance for crowd analytics and pick one tractable non-cooperative sensing function, drone detection being the topic's own example, in a laboratory or limited field setting.
Do the performance-class mapping. It is a "shall" requirement on the Technical Volume: map each use case and its KPMs to the performance classes it exercises and identify the OCUDU code or feature enhancements corresponding to each class. It is also the element most likely to get squeezed out by venue-specific content. Reserve space for it.
Budget the common work package as a separate line. Tasks A, B, and C are required regardless of use case, the baseline benchmark report is due by Month 3, and the harness is an open-source deliverable with documentation sufficient for independent execution. Proposals that fold this into general engineering will underprice it.
Plan for upstream review you do not control. All OCUDU modifications go upstream through the project's process, the deliverable is a log including review status, and enhancements that cannot be upstreamed need documented rationale. That is schedule risk owned by someone else. 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. Your differentiation is integration, RF engineering, the evidence package, the as-a-service model, and support, not the OCUDU code. A commercialization strategy that does not confront this looks naive to a reviewer who wrote the upstream requirement.
Use the government's own market number. Several hundred U.S. facilities is the serviceable addressable base the topic states, after listing 15,000 venues. Quoting the big number when the topic already narrowed it is an easy weakness to spot. The credible move is to use the narrow number and show that the unit economics work at that scale.
Engage RTECs before you propose. The baseline shall incorporate available RTEC results rather than duplicate them, RTEC-executed interoperability testing is referenced throughout, and the security architecture is validated in RTEC testing. Knowing which validated reference configurations already exist for your RU, Core, RIC, and SMO combination saves you money and shows the reviewer you are inside the community.
Plan the page budget before drafting. Five, thirteen, and two pages against four research questions, two use cases, RedCap, hybrid localization, performance-class mapping, three work package tasks, a security architecture, an RF design, and a milestone plan. Decide the allocation first or the technical proposal will lose whichever section you write last.
Make the Corporate Official someone who watches email. FutureG sends the selection notification to the Corporate Official on the cover sheet and does not state that the Principal Investigator is copied.
