More reliable robotics and autonomous systems with network APIs

For autonomous systems, the network needs to do more than carry data. Service exposure lets applications ask for what they need and get a real answer.

Picture this: it’s lunchtime and a delivery robot enters a busy city square. It has a route, a payload and a job to finish. But the square is packed and every pedestrian is carrying a phone on the same network the robot depends on. As the crowd thickens, its remote-assist video stream starts to stutter. It can’t tell that a denser crowd is forming around the corner. It can’t pinpoint its own position among the people in motion. And it has no way to ask the network for more bandwidth or to be warned that available bandwidth is about to run out.

So, it does the only safe thing: it stops. In the middle of the square. Waiting.

The robot didn’t fail because its motors broke or its cameras went dark, or because of coverage or speed. It failed because the network was congested and the robot had no way to solve that congestion by itself: a clear gap exists between network capabilities and the robot’s functionality. Closing that gap is what service exposure is about.

From a pipe to a platform

Each mobile generation has added value – voice, text, the mobile internet, the app economy, the digitalization of industries, and so on, as shown in Figure 1. Beyond greatly enhanced speed and coverage, 5G also includes powerful functionality in areas such as slicing, precise location and quality on demand. 6G takes this further by bringing connectivity, sensing and compute into the same real-time loop – turning the network into an active participant in cyber-physical systems.   by bringing connectivity, sensing and compute into the same real-time loop – turning the network into an active participant in cyber-physical systems.

Figure 1. Each mobile generation added a new layer of value – 6G brings connectivity, sensing and compute into the same real-time loop.

The shift now underway is from “megabits per second” to outcomes: not how fast the link is but what is required to succeed, right now, in this place. A delivery robot doesn’t want megabits. It wants an outcome – safe passage across the square, with the video and bandwidth to support it.

That shift is what turns a network into a platform. When capabilities are exposed as APIs, developers can build applications that weren’t possible before. Every new use case proves demand, demand justifies investment and investment opens up more capabilities – a cycle that gets easier with each turn.

The direction networks are heading in is toward cyber-physical interaction: systems that sense the physical world, reason about it in real time and act on it through actuators – all in one continuous loop, with little tolerance for network uncertainty. That means the network itself has to change from a reactive pipe into an active part of the loop. But for applications to benefit from the network’s capabilities, those capabilities need to be made accessible in a secure and programmable way. This is the role of service exposure. The next question is: which capabilities matter most for autonomous systems?

What a robot can ask for

Connectivity is the starting point, not the whole story. A network can also share what it knows and lend what it can compute. Three kinds of services matter most.

1) Dependable, differentiated connectivity: “Can you hold my video stream for the next 30 seconds?”

Today’s network can’t really answer this question. It can carry the stream or drop it but it can’t promise anything in between. For our robot, surrounded by a crowd on the same cell, that silence is the problem.

Quality on demand changes this. Instead of taking whatever the network happens to deliver, an application can request a specific quality profile – bandwidth, latency and packet loss – that the network commits to for a defined flow and duration. Instead of a best-effort average, the network provides a guarantee backed by real SLAs and active monitoring.

And critically, the network can say no. If it can’t meet the request, it says so upfront so the robot can decide what to do before it’s too late, not after.

2) Spatial services: “Where am I and what’s around me?”

The robot stopped partly because it couldn’t see what was coming – but the network could. Network-based positioning tells it where it is among moving people. Device density shows how crowded a space is before it gets there. Integrated Sensing and Communication (ISAC), an emerging capability that uses the same radio signals that carry data to also sense the physical environment, could eventually flag a crowd forming around the corner before the robot arrives. Beyond the network’s own sensing, a shared maps service can extend that awareness by letting the robot draw on what other machines have already seen, not just what its own sensors can reach.

The real shift is that these are no longer hard robotics problems to solve from scratch – they’re services a robot can simply ask for, the way any application calls an API – for example, precise location or population density.

3) Compute and AI: “Can you run this workload for me?”

Autonomy is compute-hungry and not all of it belongs onboard. The network can also provide access to compute resources at the radio edge, close to where data is generated. That can allow applications to offload workloads such as perception or planning to infrastructure close enough to meet their needs.

The robot doesn’t need to carry every model itself, whether that’s a lightweight detector or a full foundation model. It can draw on AI as a service, the same way it draws on connectivity: on demand, at the scale it needs, without owning any of the infrastructure underneath.

What the network exposes

Turning these three services into something a developer can actually call on takes more than raw capability.

The network isn’t just a pipe – it sees things an application can’t: location, identity, movement and congestion. Much of that is sensitive. So, the real question isn’t just how to expose it securely, but how to give an application exactly what it needs - without handing it a window into everything else.

That’s what service exposure does. A capability sitting in raw infrastructure isn’t a product – it needs access controls, privacy guarantees and safety boundaries before anyone outside can use it. That’s the wrapping layer shown as L1 in Figure 2. But wrapped services only help developers at scale if they don’t need a separate integration for every operator. Aggregation across operators – integrate once, reach globally – is the role Aduna plays at L2. It’s also why the industry is converging on common API definitions through CAMARA and the GSMA Open Gateway. Platforms like Vonage (L3–L4) package those services into the APIs and SDKs developers build on, tailored for specific industries and enterprise needs.

Figure 2. From raw capability to developer-ready API: security and control (L1), cross-operator aggregation (L2), and developer platforms for specific industries (L3–L4)

Done well, this changes what a network sells: not just bandwidth, but services with defined behavior, guaranteed quality and pricing that reflects the value they unlock.

A network-powered solution for physical AI

No single service is the point. What matters is that these three areas – connectivity, spatial and compute – are common building blocks, as shown in Figure 3. Build them once, expose them well and any robot, drone or autonomous vehicle can combine them however it needs. The same services that help a delivery robot cross a crowded square can help a drone inspect infrastructure or a factory AGV navigate a production floor – the use cases differ but the platform doesn’t.

Figure 3. Reusable services from the mobile platform stack serve use cases across industries – from autonomous mobility to public safety to manufacturing.

This is where the value compounds. Getting our robot across the square safely isn’t one problem, it’s several happening at once: the stream has to hold, a perception model might need to run elsewhere and it helps to know a crowd is building before the robot turns the corner. None of that gets solved in isolation. It gets solved together, by a system in which the network can negotiate quality, provide situational information and support the workload simultaneously.

No connectivity upgrade or smarter antenna can solve these problems. The solution comes from creating a layer that turns network capability into machine capability and makes autonomy possible in places it wasn’t before. The robot needs less because the platform gives more.

What’s ahead?

Two developments can turn exposed services into capabilities that autonomous systems can actively orchestrate rather than simply call on.

The first is observability. Networks already have near-real-time insight into radio and traffic conditions and machine learning can turn that into decisions. That means a robot no longer has to discover a problem by failing. The question shifts from “is my link good right now?” to “will it still hold in ten seconds if this crowd keeps growing?” – giving it or its digital twin time to act before performance drops.

The second is agentic AI. Once services are discoverable and callable, a robot doesn’t need a human wiring them together. Using emerging standards like the Model Context Protocol (MCP) and agent-to-agent (A2A) communication, an agent can find the APIs it needs and negotiate directly with the network – requesting quality, pulling in situational data, arranging compute – then recompose all of it as conditions change. Exposure is what makes the network legible to an agent in the first place.

This points toward communication–compute–control co-design , illustrated in Figure 4. The robot’s behavior, where its compute runs and the connectivity it relies on all shape each other, so it can slow down or drop resolution before its control loop actually breaks. That’s what turns a set of exposed services into a system that behaves. Agentic AI is a glimpse of a robot eventually orchestrating that system on its own.

Figure 4. Communication–compute–control co-design: behavior, compute placement and connectivity are designed together so the robot can adapt before the loop breaks.

The opportunity

The business case doesn’t rest on any one robot. It scales precisely because the services are shared: build connectivity, spatial and compute capabilities once and every delivery robot, drone and autonomous vehicle can use them. That’s what turns a proof of concept into a market.

If you’re a communication service provider: the capabilities physical AI needs are already sitting in your network. The opportunity is to expose them as reusable services and, through aggregation across operators, make them available everywhere. Every capability you expose brings more developers, more usage and more reason to keep investing.

If you’re building the robots, drones or fleets: you know what they need to stay dependable. The opportunity is to bring those requirements into the design of both the application and the network from the outset rather than bolting them together afterward. That’s how “best-effort and hope” becomes performance you can actually count on.

If you’re a researcher: environments such as Digital Arena Sweden provide an opportunity to experiment with these end-to-end integrations – from application behavior to compute placement and network services – on real robots rather than only in simulation. Bring your hypotheses and find out what works and where the limits are!

Which brings us back to the robot in the square. With a network that exposes connectivity, spatial and compute as services it can call on – and agents that can negotiate them in real time – it doesn’t stall silently in the crowd. It asks for what it needs and the network answers.

Not a robot on a pipe. A robot in the loop.

Read more

• Collaboration with Telia and Scania
• Physical AI needs a nervous system
• 6G – connectivity and beyond for the 2030s
• A Framework for Communication–Compute–Control Co-Design in Cyber–Physical Systems
• From data to decisions: Make agentic AI-driven telecom operations a reality