Network capabilities

The Service and network automation landscapes are undergoing significant changes, driven by the integration of new technologies, open-source practices, and intent-based management. This transformation enhances flexibility and efficiency, allowing CSPs to stay competitive and explore growth opportunities and innovation. The ultimate goal is a transition from automated to truly autonomous networks.

The shift towards a horizontal architecture, embracing cloud-native technologies, introduces new challenges for the CSPs. Complexity increases making assurance more difficult when trying to find a balancing between functional management and realization. Still however, traditional vertically integrated nodes remain important. The telecom industry is currently adapting to leverage IT and hyperscale cloud provider advancements. A unified management platform that supports both end-to-end and domain-specific applications is anticipated, facilitating flexible deployments and incorporating DevOps methodologies. Intent-based management will be a strategic tool for enhancing network operations and service delivery.

The IT industry's influence is increasingly evident, with e.g. open-source solutions and best practices being integrated into OSS frameworks. Although some initiatives, like ONAP, have encountered obstacles, e.g.  due to community size, open-source communities continue to drive innovation and resolving specific problems. Industry efforts in OSS are gaining traction, particularly as 6G discussions underscore the need for alignment and standardization. Consequently, the adoption of cloud-native software lifecycle management and GITops is becoming vital. A data-driven approach, with robust data collection and analysis, is now essential for gaining a competitive edge. The proliferation of data from network equipment is critical for assurance, optimization, and analytics.

New technologies must integrate with existing systems and processes, especially as 3GPP technologies see wider adoption across various sectors, such as enterprise- and mission critical networks. This trend necessitates management solutions tailored for smaller, IT-oriented networks, requiring a departure from traditional CSP processes to align with IT priorities.

Revenue pressure forces operators to choose between maximizing efficiency through network consolidation or growing/expanding their offerings with new services. Automation plays a crucial role in both strategies, ranging from programmed procedures to advanced, intent-based systems that autonomously achieve objectives. By leveraging network capabilities, OSS and BSS can expand and also create new service offerings, support complex value chains, and enable differentiated connectivity. Initiatives like the O-RAN Alliance are shaping expectations for integrating management logic across diverse stakeholders.

The increasing demand for MBB and emerging use cases makes automation even more critical. For CSPs focused on MBB, automation primarily drives efficiency. However, to diversify beyond MBB, a balance between efficiency and flexibility is essential. Ericsson’s architectural approach supports the broader perspective. Achieving a fully autonomous intent-based network involves raising the abstraction level in architecture while maintaining precision. A key decision in this process is whether to centralize responsibility domains, such as RAN, Core, and end-to-end management, or to adopt a decentralized approach. Centralization can optimize operations, whereas decentralization offers flexibility.

Intents present a significant opportunity for increasing industry revenue by allowing CSPs to offer multiple SLA-based products as well as streamlining operations in planning, optimization, and assurance. Ericsson intents will align with Telecom Management Forum (TMF) definitions, with APIs designed according to TMF standards or necessary complements.

Introducing intents involves three key steps described in Figure 6: incorporating intent technologies within existing TMF constraints, adopting an intent modelling approach, and establishing intent interfaces. An intent owner uses an internal API to set an intent for the intent handler, which prioritizes intents when conflicts arise. The domain-level target architecture for intent handling aligns with CSP operational structures. Intents are integrated into the operational layers of architecture, while runtime traffic and control interfaces remain unchanged. Interfaces between business support systems and service management domains incorporate intents and priorities, ensuring seamless integration.

In the evolving network landscape, traditional configuration parameters serve as constraints within a framework guided by intents, enabling dynamic optimization. This transition allows intents to evolve along two paths: replacing manual settings and SON functions and gradually positioning configuration parameters to communicate directly with subsystems. These foundational rules provide a stable starting point for legacy systems while allowing intents to integrate with technologies like 3GPP QoS and Network Slicing.

Intents have the potential to significantly enhance network performance through automation and goal-oriented optimization. To fully capitalize on this potential, maintaining a multivendor ecosystem supported by standardization in areas such as Autonomous Networks and intent-driven management is essential. An architecture with broad industry acceptance will be needed to address automation aspects like AI, digital twins, intent-driven management, etc. Digital Twins will also rely heavily on data availability and a distributed data infrastructure. See also the chapter Data Handling.

Assurance is vital for maintaining service levels and customer experience, requiring continuous monitoring, management, healing, and optimization of networks. An automated assurance processes, powered by data and AI, are required for managing complex networks. Definitions of SLA, SLO, and SLI guide these processes. (See chapter Dependable Networks).

When the implementation of the network functions moves towards full cloud native implementation, there is a need to adopt cloud-native observability technologies to be able to observe the layered realization domains and connect and aggregation the realization information to the logical functional and service views of what the network provides.

In the evolving landscape of 6G networks, AI is an increasingly crucial component, with applications spanning various domains.

While AI is often mentioned generically in 6G discussions, the current focus is mainly on Radio Access Network (RAN) use cases, network management, and orchestration automation. For RAN, AI applications are primarily considered for layers 1, 2, and 3, as well as in rApps. Some of these use cases will require real-time inference and data from multiple sources, while others, particularly in network optimization, can operate with less stringent time constraints.

In the Core network, the role of AI is mainly on network analytics but also in optimizations, especially in intent-based management. Both OSS and the Network Data Analytics Function (NWDAF) are positioned as key elements in this domain.

There is a growing demand for AI applications driven by advancements in Generative AI (GenAI) including on-device multi-modal generative AI capabilities. As AI use cases progress from basic text-based interactions to complex multimodal experiences and autonomous AI agents. Networks need to be enhanced to support the new and complex requirements of these applications.

Ericsson’s products are AI-ready, equipped with capabilities that meet current demands and continuously evolving to address future AI-driven requirements.  As part of the evolution, Ericsson’s products will be equipped with key capabilities to enable AI-driven innovations and ensure seamless, differentiated and efficient service delivery.

Investments in Machine Learning Operations (MLOps) are increasing due to the identification of the role of MLOps as an enabler for scaling of AI/ML in the industry.

AI as a Service (AIaaS) is being explored in different variants. Currently its primary purpose appears to be enabling third-party users or applications to build AI-based use cases leveraging mobile network-specific data. A broader interpretation includes future network support for execution of more complex AI models on behalf of end-user devices.

Standardization efforts for AI in telecommunications are ongoing in organizations like 3GPP, O-RAN, TMF, and ITU-T primarily focusing on managing AI/ML workflows in various 5G network functions. 

Below Figure 7 summarizes some typical areas for AI in the network architecture as examples to consider in addition to the text in the chapter.

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 is increasing. The geopolitical tensions including national crises have created attention of the need of higher levels of Network Availability, Reliability and Resilience (NRAR). Today’s networks are still susceptible to disturbance by e.g. natural disasters forcing CSPs to extraordinary 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 Exposure and Differentiated Services, by 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 area relates to deployment practices which raises some questions to be answered to take cost efficiency into account, such as, what deployment is required to support a certain level of dependability; what level of dependability is possible with a given deployment, etc. 

Today’s consumers and enterprises buy applications and connectivity separately.

Connectivity is largely offered on a best-effort basis often with virtually unlimited data volume subscriptions giving CSPs limited ability to differentiate their offerings towards existing and new customer segments.

Network API Exposure has been available since in 4G and is expected to become a major enabler  in 5G/5G SA and set the baseline for 6G as well.

New revenues will be made available via Network APIs and pay per use business, leveraging the cellular network as a platform for innovation with its various assets/capabilities for creation of new services with additional value. (See also chapter Networking trends.)

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 sell new products with specific characteristics improving both existing applications and enabling new applications.

Local net neutrality legislations may impact which business models that are available on some markets.

Above capabilities will be made available to both enterprise and mobile broadband segments thus including both Public- and Local Dedicated Networks.

Figure 8 below is an overview of a layered exposure architecture, depicting an enterprise either directly consuming APIs exposed by a CSP or higher-level APIs exposed by a developer platform interacting with an API aggregator.

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 (microservices) to realize this layer:

Network technical capabilities APIs (L0)

Implements and exposes technical capabilities of the network, providing network capabilities 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 Dedicated Network to external customers, to either Application Service Providers, Enterprises, Developer Platforms or Aggregators. 

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, typically developers and enterprises. Examples are combinations of Services and APIs streamlined for e.g. Fleet Management, Smart Industries, etc.

The Exposure platform (see Figure 9) shows the network services exposed from a CSP Public Network or Dedicated Network to external customers, either directly to Application Service Providers, Enterprises or via Aggregators. 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 or TMF.

It is further responsible for data privacy management/consent management, API security and privacy, identity translation and also responsible of the monetization (access control, onboarding, ordering, and accounting), management and control mechanisms of Network APIs.

One important area regards 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. 

An example of Consent Management use is in a “roaming-capable API” scenario.  Global enterprises will require to operate and run their applications not only when their devices (employee or IoT devices) are connected to the local home network but also when they are roaming in a visited network. At this point, consent needs to be checked with the home network for collection of various data like positioning of the device, etc.

The leading use case for Differentiated Services is currently Differentiated Connectivity. Differentiated connectivity will bring value to both consumers and enterprises, in different user segments with different device types. We have defined three device/user segments, to explain how differentiated connectivity can be implemented.

• Platform devices: Typically, consumer smartphones where applications are distributed via an app store. An outdoor mobile AR gaming application would greatly benefit from differentiated connectivity to ensure the stable low latency and high bandwidth required for the real-time integration of high-resolution digital elements in the physical environment, assuring game developers that their users will have a great experience without delays or bad resolution.
• User-managed devices: Typically, smartphones, or, for example, a 5G router where applications are downloaded and managed through a company’s application store and IT department. Today’s business communications applications already generate multiple data streams with different needs and with current hybrid working environments, stable and guaranteed connections are critical for productivity and employee satisfaction.
• Full-stack systems: Typically, devices with built-in connectivity where the application is controlled and installed by the manufacturer/integrator of the device or system. This could be, for example, a car or a TV-camera for broadcasting, requiring a trusted uplink capacity to ensure that they can reach their viewers with live coverage.

Differentiated connectivity can be sold either directly from CSPs to consumer or enterprise customers, or indirectly through integration with an application. In the indirect model, revenue would be realized either as in-app purchases, or as part of a monthly app subscription fee.

For platform devices, the most common model will be integration with the application layer enabling the required scale.

Toward enterprises with user-managed devices, both models are likely where enterprises buy their IT applications integrated with differentiated connectivity (likely for off-the-shelf applications), or in a direct CSP sales model (likely for in-house applications). Full-stack integrators will use both direct and indirect models and will likely be the user/device group with the highest share of direct CSP sales.

The indirect sales model selling connectivity through the application allows for the cost of connectivity to be included in the service fee to their customers. As an example, this could be included in a subscription fee, an in-app multi-player pass for the AR game, or as part of the monthly volume licensing fee that a business pays for the communications application.

Developers designing applications for best-effort MBB are familiar with 4G and 5G networks capabilities. Every user who has tried to use modern applications when ending up with 3G-only coverage knows the struggle of coping with performance below a certain level. Similarly, introducing differentiated connectivity beyond best effort, the application service provider community needs guidelines on what can be expected from different ‘levels’ of differentiated connectivity and how their application behaviors fit with those.

Early exploration will likely create a scenario where industry players introduce a range of different connectivity services, unique for each CSP and without market coherence, making application design difficult for application service providers. Therefore, we propose that industry aligns on a select few guidelines and levels, simplifying the approach for CSPs, enabling them to focus their service offering creation and network investments to attract maximum interest from a broad application developer community with global reach and scale. Industry-aligned guidelines and levels simplify the approach for aggregators and developer platforms to create what global application service providers need most, namely coherent global network API offerings based on reasonably similar connectivity offerings across multiple CSPs globally.

A performance level is an industry-aligned specification of a network connection. It specifies the characteristics of a bi-directional network connection and is defined by KPIs (e.g. latency, data rate) experienced by a traffic application when using a network connection. Higher levels with lower latency and a higher data rate will be specified over time with increasingly capable networks.

When a CSP wants to offer a performance level-based 5G connectivity service to its users for use with certain application flows, that CSP needs to design a corresponding connectivity service offering and dimension the network for such traffic.

We envisage that the industry will explore different performance level-based offerings, eventually aligning on a few widely known that are available across markets, enabling design of demanding applications by ASPs that scale beyond a single CSP. As a complement, there will be offerings based on CSP-unique performance levels, particularly to serve the full stack IoT device/user segment where customization can be more essential than global application scale.

Most of the key technical concepts needed to realize differentiated connectivity either exist in today’s networks and devices or are soon being released in standards and products.

Figure 10 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. Traffic classification functionality that maps different applications and application flows for a specific UE to different network resources (network slices, PDU sessions, QoS flows and Radio Bearers) in both uplink (UL) and downlink (DL) is key, especially in RAN. 

Traffic classification based on Network-Initiated Quality of Service (NI-QoS) has been standardized in 3GPP since release 7 and is used in commercial operations mainly for VoLTE/VoNR and IMS. It can be an excellent basis for network APIs, especially for full-stack systems as it is designed based on traffic classification that is dynamic and granular. 

Wider adoption for platform devices and user-managed devices is challenged primarily by initiatives to encrypt traffic end-to-end over mobile networks. For such devices, URSP offers a standardized approach to enable CSP control of the mapping of application traffic to network resources. Such policies provide the device QoS functionality with traffic steering rules, in other words, which PDU session a certain traffic type is to use. As separate PDU sessions may have different QoS treatment, these rules can then control the QoS treatment as well. 

Another differentiated service available is positioning and location. The 5G enablers will make both indoor and outdoor positioning available in both local dedicated and public networks.

Historically (enterprise) networks have been built to keep out an attacker with different perimeter security control. Today this is not enough as we already have the adversary in these networks directly or indirectly which means perimeter protection is insufficient. Today’s networks shall rather be seen as untrusted and correct security measures must be deployed to protect the users (subjects) and resources that reside on these networks. NIST published a document in 2020 [6]) that defines and discusses principles for protecting subjects and resources in untrusted networks. The focus of the NIST document is enterprise networks, but most of what NIST states is equally applicable for any network including 3GPP networks.

The term Zero Trust (ZT) is frequently used in several definitions in talks, discussions, papers, etc. with as many meanings as there are speakers/writers. ZT as a term has no agreed definition, but NIST has defined ZTA [6] .The ZTA principles are not new, and many have been used for years, but NIST now collected them in one document to describe the principles for security interaction over any network.

Principles of a Zero Trust Architecture (ZTA)

Zero trust is a concept in which digital systems cannot earn trust the way humans do. No network user, packet, interface, or device can be assumed to be trusted.

The implementation of ZT affects all assets, including digital systems, people, and processes. Zero trust has evolved from a concept to a ZTA, defined, with the principle that “there is no implicit trust granted to an asset based upon its ownership, physical location, or network location”.  This is a paradigm-shift for securing mobile critical infrastructure, particularly 3GPP networks, which traditionally have been within CSP premises and secured with perimeter security under the assumption that the internal network is trusted based upon ownership and location.

An important aspect of ZTA is to, even if new security controls are implemented, follow the ZTA tenets. The perimeter protection shall not be removed. The defense in-depth paradigm still applies and perimeter protection and ZTA security controls should coexist to protect against the threats.

Guidance of ZTA in 5G networks

The migration of 5G critical infrastructure to private, hybrid, and public cloud deployments introduces new actors and stakeholders to a shared-responsibility ecosystem. The new security paradigm for 5G infrastructure, including both RAN and core network, is based on a ZTA to protect against external and internal threats.

Security architecture in the evolution of 5G

Current 5G security architecture implements parts of the ZTA tenets in different places of the architecture. For some parts like UE access, most of the ZTA tenets are implemented either based on 3GPP standards or based on vendor implementations, but in other areas improvements are needed to become a ZTA. An important part of ZTA is that in a 5G network ZTA must be addressed on different levels, see Figure 11.

Starting from the top level, the user (of a device) is accessing an application (consumer or enterprise) and security here is mostly handled OTT provided by the application provider. Security controls like authentication and access control plus secure communication (confidentiality and integrity protection) is based on what the application provider has implemented. 3GPP has standards that can be utilized by the application provider like GBA (Generic Bootstrapping Architecture) and AKMA (Authentication and Key Management for Applications).

The middle level is where 3GPP comes into play even if some of the ZTA tenets today are outside the scope of 3GPP and rely on vendor implementations. As the scope of 3GPP is about functionality of UE and network functions and interfaces, implementation aspects of how NFs are implemented and deployed are not part of the scope (except in a few work items like Network Equipment Security Assurance Scheme (NESAS)/Security Assurance Specification (SCAS). 3GPP networks have some compliance to ZTA security controls, but it depends on the part/domain of the 3GPP network. In case of 5G Core and SBA, many aspects of ZTA are implemented in relation to the 3GPP scope, but other domains/parts of the network have fewer principles in place. ATIS (Alliance for Telecommunications Industry Solutions) has prepared a report [7] with gaps and proposed mitigations to make 5G a zero-trust architecture. Ericsson was co-chairing this work group. 

To consider security aspects, it’s important to start this work early in the ongoing 6G architecture discussions rather than becoming an afterthought. The 6G security architecture should be an evolution of 5G and the ZTA aspects are considered already now in the standardization work. 

Telco network functions are more and more using cloud native principles for improved scaling, management and deployment options and there we have the bottom level when it comes to ZTA. In cloud native, network functions are built up based on micro-services that from a security perspective introduce new attack surfaces that must be secured. Governments and regulators have new requirements on operators and for example CISA (Cybersecurity & Infrastructure Security Agency) [8]] has provided four guideline documents regarding how to secure 5G networks in a cloud infrastructure which are very much in line with Ericsson’s security requirements, architecture principles and guidelines used for product development.

Telecom networks rely on cryptography for protection of data transmitted through the network. In the case of UE (SIM) authentication and encryption towards the network, symmetric cryptography is used which is not vulnerable to quantum computing, but other parts of the network use IPSec and (D)TLS to protect the interfaces and these are more vulnerable to quantum computing.

Standardization of the first quantum safe crypto algorithms are ready from NIST, and work has started in IETF to adopt these for coming IPSec and TLS versions. Still by using up-to-date IPSec and TLS the crypto algorithms are seen as a secure for still a while, but it is now time to adopt the quantum safe so the older algorithms can be phased out in the future. NIST and some regulators over the world are providing guidance when PQC crypto shall be introduced and non-PQC shall be phased out. 

3GPP will adopt PQC into the standards based on the updated IETF security protocols.