Network capabilities

The telecommunications sector is progressing towards fully autonomous, self-managing networks, termed “Self-x”, that operate with minimal or no human intervention across all CSP’s processes, supporting strategic objectives such as Zero-Touch, Zero-Wait, and Zero-Trouble operations and rapid service and product introduction. TM Forum facilitates this transformation by offering standardized architecture, open APIs, and methodologies (Autonomous Networks Framework and Manifesto), backed by major Communication Service Providers (CSPs) and vendors, to address escalating network complexity, reduce operational expenses, and accelerate advanced service delivery.

Industry stakeholders are advancing towards higher levels of network autonomy, leveraging TM Forum’s Autonomous Network Levels (ANL 0–5). Presently, the sector averages an ANL of 1.9, indicating partial automation featuring basic closed-loop processes, but with ambitions to attaining Level 4. (ANL4 refers to a highly autonomous network which intelligently makes decisions, managing networks in complex scenarios, using predictive analytics while autonomously optimizes network performance and customer experience, adapting to various domains without manual help. See ref [1] for details).

This constitutes a pivotal shift for CSPs, demanding substantial enhancements across technology infrastructure, organizational structure, corporate culture, and data and AI capabilities. The adoption strategy focuses on targeted deployment of ANL4 within areas demonstrating the greatest return on investment, continuously optimizing high-value processes.

As automation evolves, operational priorities transition from manual planning and troubleshooting to automated, intent-driven charging and operational workflows, initially implemented in OSS/BSS and progressively expanding into core and RAN network functions. Realization of autonomous networks depends on the integration of several foundational technologies:

• Intent-Based Management: Interfaces enabling operators to articulate business intents at a high level rather than issuing specific commands.
• Artificial Intelligence (AI) and Machine Learning (ML): Core analytical engines that process real-time telemetry, support learning and reasoning, and facilitate decision-making without explicit programming.
• Agentic AI: Collaborative autonomous software agents responsible for predictive optimization, fault mitigation, and comprehensive service lifecycle management.
• Closed-Loop Automation: A continuous observe–analyze–decide–act cycle transitioning the network from reactive to proactive operations.
• Knowledge Management: Systematic approaches to producing, sharing, utilizing, and governing organizational knowledge and data assets.
• Data Management & Observability: Robust, accurate telemetry serving as the authoritative data source for the closed-loop observation phase.

TM Forum has articulated a clear vision and roadmap for autonomous networks, providing guidance on Autonomous Domains (ADs) and protocols within the Open Digital Architecture (ODA). The TM Forum view can be seen as a top-down view describing the overall transformation of the CSP operations towards autonomous networks. The bottom-up view must also be considered, including integrating with standards and blueprints from other telecommunication bodies more focused on the network functionality, such as 3GPP and the Open-RAN Alliance (ORAN). In this area network vendor innovation, both based on and outside of standardization in automating the network functionality and its handling is important.

Ericsson’s management and orchestration model separates functional management (services and function oversight) from realization management (software and infrastructure administration), optimizing cross-network management for cloud-native environments. This approach encompasses RAN, transport, core, E2E services, and experience management, all underpinned by unified enablers for data, AI, agent-based systems, and digital twins as depicted below in Figure 3.

Autonomous Domains are fundamental constructs within autonomous networks, defined both operationally and architecturally/ functionally. Operational ADs encompass all lifecycle management tasks aligned to specific operational goals, whereas functional domains aggregate network elements and requisite LCM activities within their clearly demarcated boundaries. These domains often overlap, may be hierarchical, and can contain subsets of each other. Domain delineation is context-dependent; for example, enterprise deployments and CSPs may adopt distinct domain definitions according to their operational requirements.

Critical components of the high-level architectural blueprint include:

• Operational ADs deliver both resource-facing (RFS) and customer-facing (CFS) services, encompassing comprehensive resource and service operations.
• Full alignment with TM Forum architectures and guiding principles.
• Incorporation of best practices and influences from multiple industry standards bodies.

AI is not confined to a single mobile-generation nor to specific parts of the mobile network but is already present in 4G and 5G functions and widely seen as a key enabler for 6G, contributing to the architecture of future networks. Ericsson regards AI primarily as an implementation technology rather than a separate functional layer, advising caution against over-specification that may lock the industry into immature choices. The pragmatic recommendation is to reuse the 5G Core as a baseline for 6G and incrementally add agent capabilities and expose application-specific agent support in enablement and exposure layers rather than embedding it deep in Core or RAN functions. Standardizing essential open interfaces for multi-vendor interoperability is critical to avoid vendor lock-in while preserving room for continued innovation. Figure 5 illustrates how AI agents are added to a system.

Standardization activity is already underway across multiple SDOs (Standard Development Organizations) and forums with discussions centered on AI/ML workflow handling, enabling/supporting functionality, APIs, and interoperability.

Agentic AI standardization has started but remains fragmented. TM Forum is leading with architectures and APIs for autonomous networks, including assets around Agentic AI protocols; 3GPP is exploring AI agents in its 6G studies; and O RAN is preparing for agentic concepts within the SMO. Alignment, especially toward 3GPP, is seen as essential to achieve coherent cross-domain standards.

Agentic AI refers to autonomous systems authorized to act, decide, and self-initiate tasks on behalf of an entity. Agents perceive environments via sensors, protocols, and data streams, then apply rules, logic, or learned models to generate outputs, take actions, call tools, or execute code. They operate at runtime, maintain and update internal memory, and can collaborate via agent-to-agent communication. Behavior ranges from deterministic rule sets to Turing-complete reasoning, with machine learning used to adapt internal knowledge and improve decision-making over time.

The evolution from single-agent architectures to multi-agent systems (MAS) coordinated by an Agent Fabric is central to the telecom vision. An Agent Fabric provides discovery, communication, orchestration, and governance for many cooperating agents. Early, high-value use cases include intent management functions that close control loops autonomously and interact with other agents to fulfill intents, AI/ML-driven rApps in the SMO that automate complex RAN tasks, end-to-end service orchestration, troubleshooting and assurance workflows, and business operations. Integration with digital twins and predictive analytics can further reduce manual intervention and accelerate innovation towards Autonomous Networks, see also Autonomous Networks.

Operationally, AgentOps is emerging as the complement to MLOps/LLMOps. While MLOps focuses on model lifecycle like training, deployment, monitoring, and governance. AgentOps addresses runtime governance, agent deployment and scaling, tool usage, chaining of agent behaviors, and multi-agent coordination. For telecoms, AgentOps will be critical to deploy agentic systems safely and at scale.

Agentic AI is poised to accelerate autonomy across network operations and service orchestration, reduce human intervention, and improve decision quality across planning, assurance, and optimization. Realizing this vision requires modular placement of agent capabilities, standard open interfaces for interoperability, cautious standardization to avoid premature constraints, and an agentic framework tuned to telco requirements so the ecosystem can grow in a safe, scalable way.

To support end-user AI Agent service, different example scenarios can be considered in mobile networks all requiring a balance between innovation and architectural feasibility:

• Maintaining the status quo with existing UE controls and APIs relying on use of Differentiated connectivity with enhancements such as enhanced uplink and definition of performance levels
• Adding Model Context Protocol (MCP) exposing CAMARA and OpenGW APIs for improved end-user AI Agent interaction
• Introducing new capacities or services such as network exposed information on ego-position, relevant sensing information or spatial data access
• Creating a general agent support framework for discovery and authentication for end-user AI Agents connecting to other AI Agents or to network resources such as exposed data
• Deep integration between End-user and Network-based AI agents.

The first option offers  network evolution to handle AI-based traffic towards OTT termination, and the last may demand radical redesign of networks. The three scenarios adding MCP, new network capacities or even a general agent support framework could be the choice if CSPs are to take a stronger position in their ability to enable End-user agentic applications without disrupting 5GC network architecture.

Ericsson advocates pushing end-user AI agent support to the developer platform and exposure layers rather than embedding it deeply in the Core or RAN in order to minimize risk, accelerate market readiness, and support functionalities like QoS, collaborative services, and advanced analytics, ensuring networks remain adaptable to the growing demand for agent-driven applications.

A dependable network provides connectivity services with binding conditions, for both parties (i.e., the service provider and the service user). These conditions may be defined using service-level objectives (SLOs), which may be used as the basis for a service-level agreement (SLA) between provider and user. An SLO may refer to QoS, availability (e.g., Communication Service Availability – CSA), or reliability (e.g., Communication Service Reliability – CSR) as examples.

The awareness of our dependency to networks is growing amongst enterprises, governments, and private citizens alike. The geopolitical tensions including national crises have created attention of the need of higher levels of NRAR. Today’s networks are still susceptible to disturbance by e.g. natural disasters forcing CSPs to special measures of which many could be addressed by improvements to the network itself.

This presents an opportunity for CSPs to further monetize their networks (current and future) by differentiated connectivity, see chapters E2E Service Exposure and Differentiated , addressing a larger market of new customers with requirements beyond best effort connectivity.

5G standards already provide a good basis for realizing dependable networks, especially in the domain of time critical communications.

Another related area regards deployment practices where cost efficiency must be considered, e.g. what deployment is required to support a certain level of dependability; what level of dependability is possible with a given deployment, etc.

The services and capabilities of the mobile network platform is evolving to become a natural, digitally integrated asset used globally across industries and domains. This enables new digital business and value-creation opportunities, delivering benefits to society, and provide services to end users.

To enable this vision, the standardization must harmonize with exposure and business frameworks, policies, APIs and services, including global reach providing ease of consumption by developers in different roles, development stages and across several industry verticals, addressing both wide area and private networks, and devices, see Figure 6.

Network API Exposure has been available since 4G and is expected to become a major enabler in 5G as well as in 6G.

Ericsson (with other industry players) supports a new and more agile and market focused initiative for C/L1, driven in the context of GSMA (e.g. Open Gateway ), Linux Foundation (Camara opensource project) and TMF all related to, but separated from 3GPP standardization.

The necessary revitalization of mobile connectivity includes differentiation, predictable performance and new business models to serve the “app economy” with new capabilities for the CSPs to be able to create new products with specific characteristics improving both existing applications and enabling new applications.

Figure 6 below is an overview of a layered exposure architecture, depicting an enterprise either consuming APIs exposed directly by a CSP or higher-level APIs exposed by a developer platform interacting with an API aggregator. Network capabilities can also interact via NNI exposed interfaces, e.g. for roaming scenarios. Interactions between networks can also be executed via federation mechanisms on the exposure layer.

Each layer implements the services provided by the interface (and exposed by the APIs) and any other support functions, i.e. the layer includes the functional and non-functional SW to realize this layer:

Network technical capabilities APIs (L0)
Implements and exposes technical capabilities of the network, from the different domains: from 3GPP Core/RAN and OSS/BSS, via proprietary or TMF standardized APIs. L0 capabilities are not prepared to be consumed externally.

Network External Exposure (L1)
Implements and exposes network services from CSP Public Network or Local Dedicated Network to external customers, to either Application Service Providers, Enterprises, Developer Platforms or Aggregators and is responsible for data privacy management/consent management, API security and identity translation.

API aggregators (L2)
Implements functionality for API aggregation across a large number of CSPs to expose network API services in an aggregated form in a wholesale model to external customers, typically developer platforms. APIs exposed are Layer 1 standardized APIs (preferred).

Developer Platforms (L3/L4)
Implements functionality as part of the developer platform providers to expose services and products utilizing and combining, if needed, aggregated network services to its customers. Examples are combinations of Services and APIs streamlined for e.g. Fleet Management, Smart Industries, etc.

The Exposure platform, Figure 7, shows the network services exposed from a CSP Public Network or Local Dedicated Network to external customers. It provides the exposure platform for Network APIs and is responsible for the Network APIs composition based on API transformation (as referred by GSMA Open Gateway). It exposes them through standardized (preferred) interfaces, like CAMARA and TMF.

One important area concerns data privacy management, a.k.a. Consent Management, which is a mandatory component of a service exposure platform at a CSP, allowing an operator to comply to legal requirements when processing and exposing privacy sensitive data of their subscribers respectively devices owned by their subscribers or other resources.

Of course Consent Management must be possible in a “roaming-capable API” scenario where enterprise devices (employee or IoT devices) roaming.

The Ericsson vision for Differentiated Connectivity (DiffConn) aims to turn 5G SA networks into an innovation platform with new monetization models, and incentives for further network investment going beyond best-effort mobile broadband meeting needs of both new applications and new functionality in existing applications and enabling future use-cases. DiffConn is starting to happen in 5G SA, and it is important to secure smooth evolution towards 6G.

The goal is to create a healthier ecosystem where connectivity is monetized based on the value it delivers. Ericsson’s vision is to create an open ecosystem where Application Service Providers (ASPs) can innovate on top of new network capabilities and CSPs monetize these capabilities.

Existing CSP networks need to evolve to support DiffConn with predictable, well-defined Performance Levels (PLs) which are defined using metrics like uplink/downlink bandwidth and latency, coverage area, and availability, and can be part of SLAs with observability of SLA fulfillment.

The well-defined PLs enable CSPs to differentiate connectivity services and introduce new business models. DiffConn will work for all CSP customer types and even non CSP deployments and support current business models: CSPs selling PLs directly (B2C, B2B) or via applications (B2B2X), while staying open to future models.

The e2e ecosystem for DiffConn includes multiple players that all need to contribute to and see the value of DiffConn. Examples of these are ASPs, CSPs, device/UE OS vendors, device/UE modem/chipset vendors, end users, enterprise IT administrators, aggregators, developer platforms, network vendors and regulators.

The DiffConn vision is realized by a combination of Subscribed QoS and Application-activated QoS activation models, creating an optimal balance between the two. In Subscribed QoS the DiffConn support is included e.g. in a monthly subscription between the subscriber and the CSP. Already today it is possible to leverage Subscribed QoS, thus preparing for the shift to Application-activated QoS, and ensure new slicing-based subscription models to support the long-term target.

In the Application-activated QoS model, DiffConn is activated from the application to the CSP via Network APIs. To really enable ASP innovation the ASPs must be involved in selecting and activating PLs, via network APIs for dynamic access, based on the needs of their applications. Applications also decide on mapping of their applications and application flows to the right PLs. Enabling exclusive usage of a PL for an application maximizes the potential value of the PLs for the ASPs and their users. This means that a PL is only used for a specific application and its application flows in a device in the CSP network.

Several granularity options will be available in the above activation models:  whole device, application category, traffic category, application and  application flow.

Figure 8 illustrates the high-level functional architecture of ecosystem entities involved in creating, setting up and managing differentiated connectivity service offerings. The main parts are the application client and server, the CSP’s mobile network, and the aggregator / developer platform offering network APIs and the UE.

Security has historically implied that (enterprise) networks have been built to employ security control on its perimeters to prevent attacks. Today’s networks should be regarded as untrusted and correct security measures must be deployed to protect the users (subjects) and resources that reside on these networks. In essence adopting Zero Trust Architecture (ZTA) principles.

The 6G security architecture will be an evolution of the 5G security architecture, with new security controls to fulfil the new 6G use cases. 5G has a solid security architecture where security in most parts is built-into the network but in some areas, they have been add-ons. It’s assumed that the 6G architecture will use new protocols which should leverage the built-in security.

ZTA follows the principles, published by NIST in 2020 [2], which dictates that no network user, packet, interface, or device can be assumed to be trusted. Thus, implementation of ZTA affects all assets, including digital systems, people, and processes.

Even if 6G would be ZTA out of the box, perimeter protection like “gateways” between the domains will be needed to mitigate against security risks like lateral movement. ZTA is not replacing perimeter protection but is a complement to it.

The emerging area of exposure services has opened up new attack surfaces with increased security risks. Best practices exist today for protection of APIs and web applications, but the topic needs to be addressed further as well as in 6G.

Another topic of concern is Post Quantum Cryptography(PQC) whereby quantum computing is used to attempt to exploit vulnerabilities in the cryptography of Telecom networks. With the standardization of the first quantum safe crypto algorithms already available from NIST, and work started in IETF to adopt these for coming IPSec and TLS versions these, older algorithms can soon be phased out. NIST and some regulators over the world are providing guidance when PQC crypto shall be introduced and non-PQC shall be phased out.

5G integrates Location Services (LCS) for commercial and regulatory use leveraging how 3GPP defines nodes with various roles: Gateway Mobile Location Centre/Location Retrieval Function (GMLC/LRF), Unified Data Management (UDM) for subscription, Access and Mobility Management Function (AMF) for request processing, Location Management Function (LMF) for positioning calculations, Network Exposure Function/Common API Framework (NEF/CAPIF) for service exposure, and both User Equipment/Radio Access Network (UE/RAN) for measurements.

UE-RAN positioning can also use Open Mobile Alliance Secure User Plane Location (OMA SUPL) with a SUPL Location Platform (SLP). RAN/UE traces via Trace Collection Entity (TCE) can also be processed by radio applications (rApps) to estimate device positions and correlate them with network events for Operations, Administration and Maintenance (OAM) and Key Performance Indicator (KPI) analysis. 

There exist three key APIs for exposure: OMA Mobile Location Protocol (MLP), CAMARA and 3GPP Ngmlc.

Current solutions available in commercial networks include:

1. 3GPP passive data for network-based positioning, based on data available from non-positioning mechanisms such as mobility management.
2. 3GPP device agnostic signaling and RAN measurements for network-based positioning, based on activated signaling in RAN to enable positioning.
3. 3GPP RAT-dependent positioning, based on Rel 16 signals, measurements and procedures.
4. 3GPP RAT-independent positioning, encompassing device-based GNSS positioning with optional device reporting.

From a device capability support, two categories stand out:

1. Device agnostic category, only supporting fundamental mobility measurements and procedures – supportive of positioning mechanisms 1 and 2.
2. Device dependent category, supporting positioning mechanisms 3 and 4.

For Local Dedicated Networks, the dominating positioning mechanisms would be 2, supported by device type A). For public networks, positioning mechanisms 2 and 4 will be important.

The 5G positioning architecture is very fitting in many aspects, but some improvements can be considered, such as optimized support for periodic measurements and due to increased data transport needs.

Positioning will continue to be important in 6G not only for commercial but more so for regulatory requirements. AI-based positioning enhancements can be expected as can further additions of time referencing and the ability by the network to support adequate location exposure APIs and API transformations.

Wireless sensing is a technology where a mobile system can acquire information about characteristics of an environment and/or objects within it. A key advantage is observing the environment without requiring objects to participate, without requiring objects to participate, i.e., objects observed do not have to be or include a user equipment (UE).

When sensing is integrated into a communication system such as a mobile system, it is called integrated sensing and communication (ISAC). Sensing in a mobile system uses radio frequency (RF) to detect objects and determine characteristics such as distance (range), angle, velocity and shape. 3GPP is studying how to include initial sensing capabilities for limited use cases in 5G Advanced, while 6G plans envision sensing for further use cases. Examples of possible market opportunities include ensuring public safety (for example, detecting and tracking drones), monitoring automated guided vehicles and preventing collisions, improving communication (for example, tracking signal‑blocking objects), etc.

To address these needs, Ericsson has developed an end-to-end (E2E) architecture for 6G sensing.

In our E2E sensing architecture, shown in Figure 10, the 6G RAN is responsible for carrying out the sensing measurements required to fulfil the requirements on the sensing service, as requested by the sensing client. The workflow for the sensing service, i.e., the steps and actions to take to deliver the expected results to the sensing client, as well as applicable parts of sensing processing are handled by the core functionalities for sensing or simply sensing core functionalities. The sensing core functionalities must handle policies related to the external sensing request (allowed areas, privacy policies and so on) when initiating a sensing measurement throughout workflow handling.

Sensing use cases show potential to deliver benefits for consumers, enterprises and governments (especially public safety organizations).

Standardized mechanisms will however be needed for the network and the application to set up the sensing process and use an API to provide the results to the application (Exposure). Sensing may also be combined with other services such as  positioning, SIM (subscriber identity module) density and other types of information for the benefit of applications that require comprehensive situational awareness.

Figure 11 illustrates the main types of capabilities under discussion for sensing, including the ability to detect objects and sense properties such as weather phenomena. The most obvious capability is detecting moving objects (A) through radio-based sensing mechanisms such as Doppler analysis or similar techniques. This can be valuable, e.g., in the protection of no-fly zones such as airports or stadiums.

To ensure optimal radio resource utilization, sensing measurements should be both executed and handled in RAN. An additional benefit of this approach is that it ensures the availability of RAN internal processing resources to handle the sensing measurements.

While 5G Advanced will introduce the first standardized sensing features, it is in 6G that integrated sensing and communication is likely to reach its full potential.