Nokia AI Traffic Forecast Puts Upload Capacity Under Pressure by 2035

Nokia published a forecast on November 4 projecting that AI will drive 44% of global network traffic by 2035. The Nokia AI traffic forecast puts total monthly traffic near 3,789 exabytes, with an exabyte representing one billion gigabytes. Its central warning concerns networks designed primarily to deliver downloads: machines and automated software will demand more capacity in the opposite direction.

That creates a planning conflict between familiar consumer traffic patterns and applications that continuously send information for processing. Operators must decide where additional upload capacity deserves investment, while enterprise buyers need evidence that connectivity will support their intended workloads.

Cisco and Ericsson have also identified changing AI traffic requirements, although their forecasts measure different things. Together, these reports sharpen a practical question: which network assumptions need updating before AI deployment expands, and which investment claims still require proof?

What the Nokia AI Traffic Forecast Actually Measures

Nokia’s network traffic outlook projects that monthly traffic will nearly quadruple from its 2026 level by 2035. The company builds its estimate from application usage, connected devices, and automated workflows, alongside external research, expert review, and laboratory work.

The headline describes a modeled future, rather than a measurement of traffic already flowing through networks.

That distinction matters because a precise endpoint can sound more certain than the underlying adoption assumptions. Network investment decisions need a range of plausible demand patterns, particularly when the forecast extends across changing applications, devices, and business models.

The report’s scope also deserves attention. Nokia separates traffic directly associated with AI applications from additional consumer activity influenced by AI recommendations. Its total includes access traffic and cloud AI workflow exchanges, while excluding several other categories of network activity.

Access traffic means data exchanged between users or devices and their connecting network. Cloud workflow traffic covers exchanges among services involved in completing an AI request. Those categories describe related activity at different locations, so readers should examine their boundaries before comparing forecasts.

For example, the traffic definitions exclude activity that remains on devices or premises. They also exclude communications inside AI computing platforms and certain transfers associated with training, replication, and backups.

Consequently, the headline should not become a claim that Nokia has counted every byte moving through every computer network. It describes the company’s defined forecast universe. That is a useful planning framework, provided readers preserve the definition when repeating its findings.

The same care applies to AI’s projected share. Traffic associated with a cloud assistant, a recommendation-driven viewing decision, and an industrial machine can arise through different mechanisms. Combining them helps estimate overall demand, but it does not make their operational requirements interchangeable.

A consumer watching additional video needs a different service experience from a machine waiting for an instruction. Their traffic can contribute to a common total while creating different congestion patterns, failure consequences, and investment priorities.

For operators, the useful starting point is therefore the composition of demand. A larger aggregate establishes scale, but application behavior helps determine which network segment requires attention.

For enterprise buyers, the distinction prevents an equally common mistake: translating a global forecast directly into an individual connectivity requirement. A company’s needs depend on its applications, operating locations, data policies, and tolerance for interruption.

The announcement changes the planning conversation by putting those issues beside the capacity headline. Its usefulness rests on whether organizations can connect the broad forecast to observable conditions in their own networks.

Operators Face Upload Demand Alongside Household Broadband Growth

The immediate pressure falls on organizations responsible for access networks, where devices first connect to wider services. They must support existing customers while preparing for applications whose traffic patterns remain uncertain.

More demand does not identify the right upgrade until operators know where, when, and in which direction traffic appears.

Nokia’s AI traffic projections identify agentic AI, software that executes tasks through multiple steps, as a particularly fast-growing category. The company projects its traffic reaching 160 times its 2026 level by 2035.

Physical AI, systems that sense and act in the physical world, is projected to reach 105 times its starting level. Nokia expects more than 90% of that category’s traffic to originate in the uplink, meaning the connection carrying information away from devices.

These are forecasts from small starting bases. Their operational significance lies in the types of demand they represent, rather than the multipliers alone.

A network carrying sensor information toward remote processing faces a different capacity problem from one delivering entertainment toward a screen. Additional download capacity does not automatically resolve an upload constraint.

Location complicates the decision further. Demand concentrated around industrial sites can require a different response from demand spread across residential areas. Operators need to distinguish widespread growth from pressure concentrated around specific customers or service areas.

Fixed wireless access, or FWA, adds another planning variable by delivering broadband to a fixed location through cellular infrastructure. Nokia expects it to generate more than one-third of consumer cellular traffic by 2035.

That forecast should not be read as an AI adoption estimate. Household broadband growth can increase cellular demand independently of autonomous agents or connected machines. The overlap matters because multiple services can depend on shared infrastructure.

Ericsson’s FWA outlook provides a separate comparison. Its June 2026 forecast puts FWA at 36% of global mobile network data traffic by 2031.

The dates and categories differ from Nokia’s figures, so the estimates should not be treated as matching measurements. They nevertheless show why household broadband belongs in the same investment discussion as emerging AI workloads.

An operator assessing capacity must account for its actual service mix. Residential demand, business connectivity, and machine traffic can create different requirements even when they share network equipment.

The commercial question follows directly. Operators need customers willing to pay for the service characteristics they request, while buyers need clear commitments about performance. A broad promise of AI readiness leaves too much unspecified.

Enterprise procurement should therefore distinguish available capacity from dependable application performance. A connection can appear adequate in an isolated demonstration while leaving unanswered questions about congestion, interruption, and recovery.

The Nokia AI traffic forecast gives operators a reason to revisit those assumptions. It does not establish that every network needs the same architecture or that every proposed upgrade has an immediate business case.

The practical pressure is to make investment decisions more specific. Operators must connect expected demand to actual bottlenecks, and customers must explain which application outcomes justify stronger connectivity commitments.

Agents Change the Relationship Between Tasks and Traffic

The mechanism behind growing agent demand is straightforward: a user’s instruction can trigger exchanges the user never sees. The visible answer provides an incomplete picture of the network activity required to produce it.

For automated workflows, the relevant unit of demand is the completed task and its supporting exchanges.

Consider an illustrative research assistant comparing documents and preparing a briefing. It might retrieve source material, request model analysis, inspect another source, and revise its answer. The final briefing can be short even when the supporting process involves substantial information exchange.

This example describes a possible workflow, rather than a measured deployment. Its significance is the separation between the amount displayed to a user and the activity behind that result.

Inference, the process of running a trained model to produce an output, becomes part of that chain. Where inference runs determines which connections carry requests, supporting information, and responses.

Cisco’s AI network research offers evidence for the mechanism. Its testing found that agents could generate up to 450% more total traffic per task than human-driven execution.

That result supports attention to automated workflows, but “up to” limits what readers can conclude. It is not a universal multiplier for every assistant, application, or organization. Task design and implementation remain central.

The comparison also shows why token usage alone cannot settle network planning. Tokens are units of text or other content processed by a model. They describe model activity, while a workflow can also retrieve files, exchange tool results, or transfer supporting media.

An application team therefore needs visibility into the complete path. Otherwise, it risks attributing delays to the model when another service or connection deserves investigation.

Context, the information supplied to guide a model’s response, creates another design choice. More supporting material can help a task, but unnecessary transfer can add work without improving the result.

For knowledge workers, this connects infrastructure planning to information organization. A well-maintained AI knowledge base can support clearer decisions about what an assistant should retrieve.

That connection does not establish that any particular knowledge tool reduces network traffic. It highlights an application-level question: which information needs to move, and which material is irrelevant to the task?

Developers face the same issue when evaluating retries and repeated requests. A workflow that repeatedly asks for similar information deserves investigation before its traffic is treated as unavoidable demand.

The physical side presents a related but distinct problem. A machine can generate information because its surroundings keep changing, rather than because a person submits another request.

Here, useful application design must determine what requires remote analysis and what can be handled locally. Sending less information is beneficial only when the application still meets its operational requirements.

Neither category supports a simple claim that automation always wastes bandwidth. Additional exchanges can accompany valuable work. The planning question is whether the resulting traffic is necessary, well understood, and supported by suitable connectivity.

That is why the projected growth deserves attention beyond telecom departments. Product decisions determine workflow behavior, and workflow behavior determines the demand that networks ultimately need to carry.

Processing Closer to Users Has a Conditional Business Case

Nokia expects some AI processing to become more distributed. Edge computing means processing closer to users or devices, while metropolitan network facilities provide another possible location between access connections and distant cloud services.

The company projects that edge and metropolitan infrastructure will serve 36% of AI-native traffic by 2035. It also expects most AI traffic to remain within the central cloud.

The investment decision concerns where each workload belongs, with performance, operating complexity, and data requirements shaping the answer.

This is an architectural choice rather than a universal migration schedule. Moving a workload closer changes where computing resources must be installed, maintained, secured, and updated.

For an enterprise, proximity can sound attractive before the application requirement is clear. A local facility offers little value if the relevant delay arises elsewhere in the workflow.

Cisco provides a useful skeptical comparison. Its research says model processing currently dominates end-to-end inference delay in the workloads it examines. It argues that network delay alone does not yet justify broad architectural shifts toward edge inference.

That finding does not invalidate Nokia’s longer-term projection. The companies are addressing different time horizons and questions. Cisco’s observation concerns current performance, while Nokia models how future applications and deployment choices develop.

The comparison does challenge a shortcut in infrastructure marketing. An application involving AI does not automatically require nearby computing, and nearby computing does not automatically improve the outcome users care about.

A buyer needs to identify the actual requirement. Is the application waiting on information transfer, remote processing, another business system, or human approval? Each answer points toward a different intervention.

Data sovereignty, requirements governing where data is stored or processed, can also shape placement. Such requirements deserve separate treatment from performance because a compliance constraint can apply even when a distant service performs adequately.

Operational resilience adds another consideration. A distributed application requires explicit decisions about what happens when a site loses access to supporting services. Geographic proximity by itself does not answer that question.

For developers, a sensible architecture begins with the application’s dependencies. Moving inference closer while leaving essential tools elsewhere can preserve much of the original dependency on remote connections.

Enterprise buyers should also examine who operates each component. Responsibility for updates, monitoring, access control, and incident response must remain clear when an application spans multiple locations.

These considerations make the forecast more useful when treated as a distribution problem. Different workloads can justify different placements, and the same organization can operate several approaches.

Central cloud services remain relevant where shared resources and centralized operations fit the application. Nearby processing deserves consideration where a demonstrated requirement supports it.

The strongest business case connects placement to a measurable outcome. A deployment should show why the chosen location improves performance, meets a data requirement, or supports dependable operation.

Without that connection, an organization risks buying an architectural label. The longer-term shift Nokia anticipates will depend on practical deployment decisions whose value can be demonstrated at the application level.

The Forecast’s Assumptions Matter More Than Its Precision

Long-range forecasts help organizations prepare, but their apparent numerical precision can obscure uncertainty. Adoption, application design, local processing, and service economics all affect the path between an emerging category and a global total.

The strongest reading of Nokia’s forecast preserves its assumptions and avoids turning projected demand into guaranteed equipment spending.

Start with the growth multipliers. A small category can grow quickly while its eventual contribution remains dependent on adoption. The multiplier alone does not show which users arrive, what they do, or where their traffic travels.

Deployment choices matter as well. A workflow running primarily on a device has different network implications from a comparable service relying on remote exchanges. A forecast must make assumptions about how those choices evolve.

Efficiency introduces another uncertainty. Developers can change how much information an application sends for a given task. They can also expand what the application attempts, creating additional demand despite improvements in individual operations.

The resulting balance is an empirical question. It cannot be resolved by assuming that efficiency eliminates growth or that every improvement necessarily produces more traffic.

Classification creates a separate challenge. Nokia’s definition includes incremental consumer traffic influenced by AI recommendations. Estimating that increment requires a counterfactual judgment about activity that would otherwise have occurred.

Readers should therefore distinguish categories that can be observed directly from categories that require behavioral modeling. Both can inform planning, but they offer different kinds of evidence.

Comparisons across vendors require similar discipline. Cisco projects AI inference at one-quarter of network traffic by 2035. That figure should not be presented as a direct contradiction of Nokia’s broader AI-driven share.

Inference traffic and AI-driven traffic describe different scopes. A meaningful comparison would align included applications, network boundaries, and counting methods before interpreting the difference.

Commercial incentives also deserve acknowledgment. Nokia, Cisco, and Ericsson sell infrastructure that benefits from network investment. Their research can contain valuable evidence while serving business objectives.

That does not justify dismissing their findings. It supports asking for transparent methods, field measurements, and customer outcomes alongside vendor projections.

The available evidence also does not establish a general collapse in network readiness. Pressure can be uneven, with constraints emerging in particular locations or applications rather than everywhere simultaneously.

A global total cannot identify those locations by itself. Operators need local evidence before translating a worldwide trajectory into individual construction or procurement decisions.

For enterprise buyers, the practical risk runs in both directions. Underestimating connectivity can leave an application unable to meet expectations. Overestimating its requirements can commit resources before demand or operational value is clear.

The Nokia AI traffic forecast is most useful as a structured planning scenario. It identifies assumptions that deserve testing while leaving room for application behavior and deployment choices to change.

That approach keeps the news in proportion. The report strengthens the case for measuring AI workloads, while the timing and scale of particular investments remain decisions requiring closer evidence.

Three Signals to Watch Through Early 2027

The next few months will not validate a forecast ending in 2035. They can provide evidence about whether its underlying mechanisms are appearing in commercial networks and enterprise deployments.

Near-term observation should focus on measured traffic behavior, customer adoption, and deployment economics, in that order.

The first signal is operator disclosure about upload demand in identifiable AI deployments. Useful evidence would connect traffic patterns to specific applications and distinguish them from ordinary broadband growth.

Measurements showing persistent upload constraints would strengthen the case that existing planning assumptions need adjustment. Reports of adequate headroom would support a more selective investment response.

Context matters as much as the result. Readers should look for the deployment setting, measurement period, application behavior, and network conditions. An isolated performance figure offers limited guidance without those details.

The second signal is sustained commercial use of agents and connected machines. Trials can reveal technical requirements, but recurring operation provides stronger evidence about whether those requirements translate into lasting demand.

The most informative disclosures would describe active use, completed tasks, operating locations, and customer expansion. Announcements that merely add AI terminology offer less help in evaluating traffic forecasts.

Continued deployment would support Nokia’s demand thesis. Slow adoption, abandoned workflows, or applications performing more work locally would weaken assumptions that depend on expanding remote exchanges.

The third signal is evidence supporting the location of processing. Customers and vendors should explain why a particular workload belongs in a central cloud, metropolitan facility, nearby site, or device.

Comparative results showing an application benefit would strengthen the case for distributed processing. Results dominated by model execution or other remote dependencies would support a more cautious architectural response.

Operating economics belong beside performance in those comparisons. A technically successful deployment still needs a sustainable arrangement for maintaining equipment, software, security, and service support.

Investors should avoid treating general AI demand as proof of a particular supplier’s future results. Operators should connect expansion plans to actual network conditions. Enterprise buyers should require commitments tied to application outcomes.

Over the coming months, read the Nokia AI traffic forecast alongside evidence from the networks and applications you depend on. Ask vendors to explain where data travels, which connection limits performance, and what changes under sustained use. Keep those assumptions with your deployment records, then compare them with observed behavior as adoption grows. For knowledge teams, that means documenting retrieval and processing choices alongside model quality. For operators, it means separating household broadband growth from emerging machine workloads. Before expanding an AI deployment, can your team identify the traffic it creates and the service requirement that traffic must satisfy?