Summary

  • In a survey of 100 fixed-broadband decision-makers and specialists, 78% reported partial or full deployment of software-defined networking and/or network-functions virtualization. That does not mean 78% of customer services run autonomously.
  • The harder test is whether a system can make an authorised change across the relevant networks and suppliers, check the customer's result, and hand over safely when it cannot finish the job.

Imagine being told that a fault has been fixed while your connection still does not work. The operator's software may have done exactly what it was asked to do. It is the definition of “fixed” that needs attention.

This is an illustration, not a reported customer incident. It captures the awkward gap between a network that accepts software commands and a service that looks after itself. A controller can change a setting. It cannot, simply by existing, settle which team may act, which supplier must cooperate or who checks that the person paying for broadband can actually use it.

A Broadband Forum report notice, dated 7 October 2026, puts that gap in context. The Forum commissioned the work with STL Partners, drawing on 100 decision-makers and specialists at fixed-broadband providers worldwide. Radisys and Incognito Software Systems sponsored it.

The public STL extract says 78% of respondents had partly or fully deployed software-defined networking, or SDN, and/or network-functions virtualization, or NFV. Software control has plainly moved beyond a laboratory ambition for many in this sample. The percentage says nothing, however, about how many customer orders or faults they can handle from beginning to end without manual intervention.

Nor is it a census of the industry. The public pages do not provide enough sampling detail to test representativeness independently. The report itself sits behind access arrangements; this article relies on the public material. Sponsorship is a reason to be clear about attribution, not to dismiss the findings.

A command can finish before the job does

Consider a broadband order. An access device may accept its configuration while address assignment, transport capacity, customer equipment, identity, billing and service assurance still follow different workflows. An orchestrator can pass instructions between those systems. That is not proof that they understand the same service, that each instruction is authorised, or that the finished connection meets what the customer bought.

A fault poses the same problem in reverse. Spotting a likely cause is useful; deciding whether the diagnosis is reliable enough to act on is another task. Somebody must know who may change what, how to undo a bad change and how to verify recovery. Fast execution without that context could spread a mistake instead of ending an outage.

STL reports that some providers changed their infrastructure substantially without achieving the flexibility or resource efficiency they expected. One unnamed European Tier 1 operator described its transformation as roughly 30% technology, 30% skills and 40% investment justification and operating-model change. That is one operator's account, not a recipe for everyone. It does explain why buying a new controller leaves questions about shared resources, release approvals and supplier responsibility unanswered.

Measure a service, not a badge

ETSI GR F5G 019 V1.1.1 breaks the work into intent translation, awareness, analysis, decision and execution. Repeating a configured task is different from sensing conditions, deciding what a service needs and completing the change. Its Level 4 description concerns more complex cross-domain closed loops driven by service and customer experience; Level 5 extends across multiple services, domains and the lifecycle.

Crucially, the assessment pairs a network or service type with a workflow. Residential broadband fulfilment over a PON access network is one example. It keeps the overall result alongside the results for individual tasks, distinguishing work done by people, systems or both. That is more informative than attaching one impressive autonomy number to an entire operator.

TM Forum's framework likewise centres progress on scenarios. Its 8 October announcement introduced 20 Technical Solution Packages, including broadband complaint handling, transport fault management and IP change management. TM Forum says they link deployment experience to outcomes, architecture, interfaces, data and automation, using its framework and Open Digital Architecture. Forty packages by DTW Ignite 2027 is the target, not the current total.

A reusable package can save an operator from starting with a blank sheet. It cannot establish that another operator's inventory, permissions, equipment and escalation arrangements are compatible. Local testing still has to connect the pattern to a working service.

Who stays responsible?

Ask what scenario is covered, which tasks still need people, what the system is allowed to decide, and how the result is checked. Those four questions do more work than the word “autonomous”. They distinguish a useful capability in one part of a network from a service a customer can rely on.

Lu Heng's Note 65 on Running-Code Primacy provides a narrow editorial lens here: separate a claim on paper from an implementation demonstrated in use. It is the author's argument about Internet coordination, not evidence about the surveyed companies. Applied to broadband, it asks for a deployed workflow and an observable result, without discarding the value of standards or design.

The potential reward is quicker activation and repair, more responsive capacity decisions and a clearer view of where a problem crosses supplier boundaries. It is not an outcome this survey percentage proves. The final test remains the person trying to get online: has their service recovered, and if it has not, who can explain the failure, limit the damage and put it right?