Network capabilities

As the service needs for MBB increase or new use cases are addressed and supported in a CSP’s network, automation is expected to be necessary. For CSPs still pursuing only MBB, efficiency will be the main reason for automation. Going beyond MBB requires a balance between efficiency and flexibility to be supported by automation. Ericsson’s architectural approach assumes going beyond MBB.
The progression of automation will move from managing the resources and details to managing services and objectives.

The journey towards achieving a fully autonomous intent-based network, requires its architecture to be prepared by raising the level of abstraction, though maintaining precision. A couple of aspects of this journey are discussed below.

Separation of concerns or centralization, i.e. whether to have a more centralized responsibility domain covering RAN, Core and E2E management or more decentralized responsibility domains. Figure 6 is a prime choice to make. (Note that if the decentralized approach is used, it can still be co-deployed with internal separation of concerns via permissions.)

The trade-off is that a centralized approach offers more optimization and a decentralized approach favors flexibility at the sacrifice of some level of optimization. The flexibility may range from e.g., new service introduction, or flexible offering of services to other domains (e.g., RAN sharing).
Intents can be used to increase the total industry revenue by enabling CSPs to potentially offer multiple SLA-based products and/or to address increasing operational costs simplification of planning, optimization and assurance.

Various industries have previously used the concept of “intents”, but with varying meaning and definition. Even some mobile systems, have used intents e.g., as part of Kubernetes in the LCM of software. In this document, if not explicitly stated otherwise, we follow the basic definition of intent, intent owner, and intent handler set by Telecom Management Forum (TMF) [6], with intent API following either TMF or specified as complements to existing interfaces.

For the Introduction of Intents, three steps are required, Figure 7:

1. Introducing intent technologies within the constraints of the existing interfaces in TMF
2. Introducing the intent modelling approach
3. Introducing the intent interfaces.

An intent owner uses an API to set an intent to the intent handler. Specific intents point to a set of measurable quantities (meaning measurable by the intent handler) plus targets for the measurable quantities. In most systems the intent handler receives more than one intent. In such systems the intent handler shall prioritize between the intents in situations where not all intents can be met.

The domain-level target network architecture for intent handling is depicted in Figure 8. The domains are functional domains following a typical CSP operational responsibility structure. The intents enter the architecture in the operations parts of the architecture while the run-time traffic and control interfaces do not use intents. In particular:

The interface between the Business support system and the domain for service- and QoE management is complemented with missing information to support intents e.g. intent-priorities associated with network services.

The interfaces between the domain for service- and QoE management and the network sub-domains “RAN”, “Transport”, Infrastructure” and “Core network” will be extended with intents and intent-priorities associated with sub-domain network services, e.g. a transport service or a RAN service. The interface between the domain management system and the network functions will be extended with intents, intent-priorities, and intent reporting (observability) associated with function behavior, gradually migrating away from traditional node configuration to intent-based function configuration. The target architecture also includes intents for management of software, infrastructure, and transport, where intents are to some extent already used.

The ground rule is that traditional configuration parameters have priority over intents meaning they will serve as constraints including SON (Self Organizing Network) functions. Traditional configurations can then form constraints and boundaries for dynamically optimizing a system with intents within these constraints.

This migration will gradually enable inclusion of intents in two parallel main tracks:

1. Intent handlers will take control over the setting of selected configuration parameters, replacing manual configuration and SON functions.
2. Intents will increasingly replace configuration parameters, communicating to sub-systems directly with intents.

These ground rules enable legacy systems to form stable and safe starting points. Intents can start off “small” where existing configuration parameters act as guard rails towards unwanted and unexpected system behavior.

Intents should complement and interwork with 3GPP QoS, Network Slicing, etc. ​

Finally, intents give an opportunity to improve various aspects of network performance through automation and optimization towards specified goals.

To fully leverage intents, a multivendor eco-system should be maintained supported by standardization in the areas of Autonomous Networks and Intent-driven management already ongoing (in e.g. TMF, 3GPP, ETSI O-RAN). An architecture with wide industry acceptance is desired to address the aspects of automation such as AI, intent-driven management, digital twins, data-driven management, MLOps, and others.

MLOps is a set of processes and technology capabilities for building, deploying, and operationalizing ML systems, including how data is refined and transformed to serve the ML system, aiming to unify it with DevOps, targeting the introduction of software in a repeatable/reproducible and fault-tolerant workflow.

Thus, MLOps advocates automation and monitoring in all steps of ML system construction and deployment with a main goal to achieve shorter TTM with high confidence level of addressing challenges in the automated processes of development, verification, etc.

Additional challenges of adopting MLOps to highly reliable live telecom networks exist such as the need to handle lifecycle management and automatic re-training of the many instances of ML models.

Adoption of MLOps enables a more expedient handling of artifacts like models, pipelines, datasets, etc. in a uniform way across the different stages of the process.

Targeting products and services, will require MLOps to be able to be deployed for several scenarios, e.g., provided as-a-Service (aaS) or licensed SW/product on customer site, deployed on cloud infrastructure or deployed on dedicated HW, and likely in several more.

CSP realities vary depending on selection of cloud infrastructure where a CSP potentially selects to use a particular HCP or use private cloud which can be done for various reasons, like applications execution, licensed SW, data management and storage, etc.

Being able to apply MLOps across several large HCPs (e.g., AWS, Azure, GCP), with the limited compatibility between their APIs for AI services, requires a certain level of adaption for vendors’ products/services to adopt to each of these HCPs. Thus a multi-cloud approach will require certain efforts in a variety of areas depending on each HCP.A few abstraction layer initiatives exist that could help to provide an abstraction layer for different HCP services. None of these alternatives, however, yet provide a complete solution to the problem.

The telecommunications domain poses challenges not readily addressed by mainstream MLOps solutions. We see a few key requirements on MLOps compared to what third-party solutions offer:

MLOps needs to operate in multiple different environments: services, products, and embedded solutions, including deployments on CSP site. This means that multiple deployment scenarios for MLOps functionality for developing, deploying, and executing AI-models/applications needs to be supported in parallel, such as all local to a CSP site or all at vendor premise or combinations of these.

Products and services may need to be developed to be compatible with multiple HCPs. Each HCP offers different APIs, for deployment as well as for ML services, which are not aligned. To overcome this and enable multi-cloud deployment, there are three main alternatives: HCP specific implementations, Abstraction Layer (e.g., through relying on a 3P framework) or relying on CaaS layer. Since HCPs are currently not converging, the direction is to continue evolving selected tools for training and inference. We will rely on CaaS layer to support hybrid and multi-cloud deployment of ML workloads by norming the execution environment. This approach needs to be constantly re-evaluated if HCPs’ services are converging, or other solutions are emerging.

Data - Important data is generated at the network edge, and not all data is owned by the vendor. Solutions are needed to manage data on the CSP side, and solutions may not be able to retain all data. MLOps require iterating on pipelines and models using data, ideally from multiple customers. Data needs to be available where the MLOps environment is executing and needs to be able to be injected to all the different MLOps phases. This data is important for the vendor to develop new and enhance existing features, this is done in the vendors data driven development environment.

Simulators are essential for developing e.g., reinforcement learning use cases, or for estimating the effect of network actions taken based on ML predictions. Data from live networks is an attractive asset. To best support the wide variety of use-cases, there may be a need for domain/use case specific tools to fit the development flow.

The main components in MLOps can be deployed in several sites and combinations depending on product/service needed. In Figure 9 below the deployment architecture is outlined for one of the most complex product cases where development is initially performed in a vendor site, while it also supports deployment of Experimentation, Development, Staging and Execution environments in national or regional sites at the customer. This may be more limited for some products, e.g., only including Execution environment, but it is included to show one end of the scale of complexity. For some products, the Execution environment may also be pushed further out in the network.

Enterprises, governments, and private citizens alike rely on its availability, reliability and resilience around the clock. To be able to meet ever-rising expectations on the network, while simultaneously meeting the requirements of emerging use cases beyond MBB, increasingly higher levels of network robustness will be required.

5GS (5G System) has been designed to provide the robustness required to support the growth of conventional MBB services, while also offering network support to new business segments and use cases with more advanced requirements in terms of NRAR. 5GS delivers new capabilities that enable enterprises with business-critical use cases in segments such as manufacturing, ports, automotive, etc. to take a major step forward in their digitalization journeys by replacing older means of communication with the 5GS. These new capabilities can also be leveraged for mission-critical networks.

As private citizens, we have become increasingly dependent on the availability of MBB networks and rarely leave home without our cellphone. In our daily life we conveniently rely on being able to use the network for services like banking, ticketing, early warning systems, etc.

With MBB networks availability is taken for granted, it may be challenging to monetize NRAR. Some proactiveness is advised to avoid being caught out by the expected regulations emerging due to society’s dependency to the network. A more reliable and robust network should be seen as a premium service and it can also attract new subscribers and prevent churn.

Mission-critical networks are already deployed using mobile technology. 5G will provide possibilities to extend into new areas and new use cases such as Public Safety, Utilities or Digital Airspace. It will further enable XR use cases for, e.g. first responders or in other suitable cases across different segments and verticals.

The characteristics of wide area coverage makes mission-critical networks a very compatible case, as a symbiotic extension to the existing mobile network of the CSP, who can present a robust and reliable network.

For business-critical or Enterprise verticals, low latency in 5G may appear to be a killer case. Although valuable, industries express the need for a reliable and predictable network to relate to their processes, machinery, etc.

Delivering new capabilities to enable enterprises with business-critical use cases as well as the modernization and digitalization of public safety, requires that the e2e perspective for a service/application is considered. This will require a trustworthy network while at the same time provide extensive coverage and high reliability.

This is a shift in the view of robustness from the more traditional use of Node Level In Service Performance (ISP) towards Network Robustness to support the top level e2e application requirements.

While both 4G and 5G can provide the high level of robustness required to deliver MBB services of today, the new and emerging use cases will require addition of new features and mechanisms in a network robustness toolbox. Beyond that and as depicted by the examples shown in the blue and red fields in Figure 10 below, it is equally important to consider Planning and Deployment of the Functional and Traffical parts to be able to secure a NRAR capable Network. Network-level design must include consideration of both sunny day scenarios and different disaster/failure cases in all parts of the network.

The green line between the application client and the server, highlights the significance of the E2E perspective.The 5GS robustness toolbox consists of both standardized and vendor-specific network features and mechanisms.

Highly flexible, it gives CSPs the power to activate the most appropriate mechanisms depending on the use cases and the deployment variants. Even if many areas to build robust networks may appear to be using the same or similar principles; network planning, redundant power, solid operations, comprehensive procedures for LCM, etc. they may differ in how they are applied for the above cases.

NRAR-levels is a methodology introduced by Ericsson as a guidance to network operators and their customers (see Figure 11). The key characteristic for each NRAR-level is the Supported/ Maximum Service Interruption Time.

The ASIT (Allowed Service Interruption Time) requirement of an application is used to identify the NRAR-level needed i.e., based on the use cases supported by the network operator. Each NRAR-level defines the NRAR tools and network planning/deployment guidelines needed. Once these tools are activated, and the guidelines followed, the intention is to meet the SIT for the selected NRAR levels at different (single failure) situations.

The number of NRAR levels is based on the combination of existing ASIT requirements and identified NRAR tools, and to some level of future proofness in both these aspects. The 6 NRAR levels are the current best thinking and may change going forward.

A network can support multiple NRAR levels simultaneously for different UEs and applications. This means that different NRAR tools can also be activated to different UEs, especially in the RAN. The finest granular level is a QoS Flow for a specific UE.

Any breaches to the ASIT will impact the Communication Service Availability (CSA) of the concerned application(s) negatively. For applications with high CSA requirements, it is recommended to apply an NRAR-level with a SIT which is lower than the ASIT of the application, to ensure that (single) network restarts/failures will not cause communication failures for this application.

Figure 11 NRAR-level framework

There are two main ways for CSPs to monetize QoS in 5G networks. The first alternative is via subscription(s), where the end-user (consumer or enterprise user) pays the operator a premium for differentiated services, optimized for video conferencing, XR, gaming or some other service. This model is also referred to as B2C/B2B model and is currently supported by the category-URSP (UE Route Selection Policy) and enterprise-URSP solutions.

The second alternative is via Network APIs, where an Application Service Provider (ASP) pays the CSPs a fee for granting a specific user a differentiated service for a limited period. This model is also referred as B2B2X model and is supported by the CAMARA NI-QoS (Network Initiated QoS).

These two monetization options are not in competition with each other. Instead, they can work well together, and we believe that a combination of B2B/B2C and B2B2X models is the best approach to maximize the overall TAM that CSPs can address.

Traffic classification is about mapping of different applications and application flows from a specific UE to different network resources (e.g., network slices, PDU sessions and Radio Bearers) in both uplink (UL) and downlink (DL). These network resources may have different QoS levels associated to them (Figure 12). NI-QoS, URSP and L4S (Low Latency Low Loss Scalable Throughput) are examples of traffic classification mechanisms with different control points that can be used for QoS support in mobile networks. Traffic classification is seen as a dynamic way of handling a single UE connected to multiple network resources. UE classification would be a more static way of controlling that different UEs are connected to different network resources.

Additional network functionality beyond traffic classification will be needed to support QoS. Examples of such functionality include SLA, SLA assurance support with relevant network KPIs and e2e dimensioning and configuration of the different performance levels, incl. RAN, transport and core, based on the traffic mix expected in an area. In addition, a key requirement for any traffic classification solution is that most applications use multiple application flows with different requirements.

Existing 3GPP standards and products designed based on these standards are not fully prepared to support QoS for data applications beyond VoLTE/IMS. As an example, there is only 5 radio bearers available beyond existing applications (default internet, IMS, SMS/MMS/SUPL). This means that any new traffic classification based on URSP and/or NI-QoS will be solved with up to 5 radio bearers (in the smartphone case).

NI-QoS is standardized in 3GPP since long time and is used in commercial operation mainly for VoLTE/IMS. NI-QoS is an excellent basis for Network API as it provides dynamic and fine-granular application-flow-level traffic differentiation. NI-QoS is orthogonal to network slicing but can be used in combination with it. The main hurdle with wider adoption of NI-QoS to any applications have been the complicated integration between CSPs and ASPs, and all initiatives to encrypt traffic at Over-The-Top (OTT) level over the mobile networks e.g. due to end-user privacy needs.

URSP is standardized by 3GPP, since Rel-15, for a UE connected to multiple network slices. The 3GPP standards define multiple URSP Traffic Descriptors (TD) that would allow both application and application flow level mapping to network resources. Device OS vendors have however taken their own initiatives on interpreting the URSP rules. They have also defined separate URSP solutions for consumers/B2C and enterprises/B2B.

The B2C URSP solution is called category-URSP and is based on the concept of Traffic Category (TC) at UE OS-level. The applications specify the TC(s) when setting up the communication, for example “Low Latency” and “High Bandwidth”. Device OS vendors have their own Traffic Categories. A generalized concept is still needed to support all OSes, tethering, FWA etc. The CSP defines, controls and monetizes on subscription levels and QoS matching the TCs.

The B2B URSP solution is called as enterprise-URSP and is based on the Enterprise IT Admin defining how different enterprise applications are mapped to the connectivity services defined, controlled and monetized by the CSP. This solution likely needs to evolve to the granularity of enterprise application flows.

The more fine-granular URSP TDs defined by 3GPP would be a good basis for Network APIs but are currently being blocked by smartphone OS vendors claiming end-user privacy, NN/OI and technical limitations. We are looking at alternatives to let API-based services (via e.g. CAMARA) control when and how the traffic category solution is to be used. This would allow for activation only when certain applications are needing the service and could be seen as a network slicing compatible alternative to NI-QoS.

L4S is an IETF-defined solution promoted by Ericsson for time critical communications to ensure that latency-critical high-rate apps can detect the available bitrate while keeping a bounded latency. Ericsson drive for L4S is based on enabling fast RAN based end-to-end rate adaptation indication for applications to minimize latency. Traffic classification in L4S is based on NI-QoS. L4S can either be included as a generic network optimization feature available for all applications, and UEs, or support for it can be limited to specific subscriptions and/or traffic characteristics.

Future direction will require a Traffic Classification Toolbox addressing a wide set of needs to be able to handle the ongoing alignment, settlement and potential standardization initiatives existing in the market. Ericsson understands the need for supporting multiple solutions for traffic classification and handling, incl. NI-QoS, L4S and category-URSP and enterprise-URSP for the different needs and use cases, and the related network APIs. We see both the category-URSP and enterprise-URSP solutions as good initial solutions with support on the smartphone ecosystem side. For other use cases, device types and device OSes, we see possibilities in going to both application and application flow level granularity based on network APIs for NI-QoS and more fine-granular URSP TDs, and even combinations of the different solutions.

Our vision is a network with a high degree of abstraction where consumption of services by an application should not require knowledge of the details of how telco networks work but instead it should be possible to interact using a set of simple yet powerful APIs for business management as well as network capability access.

Currently CSPs are expanding the use of telecom to explore the exposure of network capabilities, e.g. to address enterprises. The network resources exposed must be made easy to consume and shaped to fit the needs and desired use cases of enterprises and their partners.

To be successful, CSPs need to expand their service portfolio and turn their network into a programmable platform with the capability to onboard new applications and aggregators while leveraging their existing connectivity offerings and combine them with cloud and edge offerings.

Exposure can be applied in different places, both in the network and in the device as illustrated in Figure 13 below (based on The Ericsson Global Architecture). Only the most important interfaces are described here.

Z interface layer represents higher level and domain specific abstractions, interfaces, and services, within environments that Developer’s trust, encapsulating/wrapping the C layer as needed. Aggregators typically expose APIs on the Z interface.
C interface layer contains a collection of northbound exposed capabilities and services of the network, reachable via Service Exposure Frameworks and its APIs/Protocols/SDKs, covering domains such as BSS, OSS, Packet Core and Communication Services.
Y interface layer is a collection of exposed abstractions of capabilities and services in Z and C from the device side. Exposed capabilities are similar but may also differ.
X interface layer is a collection of network services exposed via the modem / UNI interface, typically AT commands. Many standardized, but a large set of proprietary

Although the Z and C interfaces are expressed as thin lines (see Figure 13), these can contain a set of functions that are common to all exposed services, e.g., discovery, access control, identity management, throttling, etc. This drives a consistent experience towards different consumers of the APIs (developers, integrators, enterprises etc.) enabling scale and eliminates the need to use a proxy through the Management, Orchestration and Monetization layer.

An efficient and scalable service exposure architecture requires a service exposure platform that provides gateway functionality as well as a set of centralized supporting functions responsible for authentication and authorization of API invokers, API management and some functions for developers (such as API catalogues).

An Aggregation Platform, Figure 14 has the purpose of realizing and accelerating the development and availability of network services and APIs, the onboarding of CSPs and exposing APIs to application developers and ASPs (Application Service Providers) as well as to enterprises. Together with service exposure platform, it results in a scalable cloud platform with APIs and communication services including a channel to the developer- and enterprise eco systems.

The Figure 14 below shows the relation between the Aggregation Platform the CSP exposure and exposure towards the Developer ecosystem.

New commercial services for enterprises, will be exposed through the Aggregation platform, utilizing underlying network services exposed by the CSPs, like QoS, location etc.

It will integrate the APIs and services exposed by CSPs, using Ericsson or other vendors’ products then aggregated and exposed in a consistent way so that developers, enterprises, and other platforms can consume the APIs in a uniform way on a global scale.

Ericsson always strive for an open ecosystem of different players consuming services from the CSPs. All players, including HCPs and other CPaaS players, will benefit from standardized / industry aligned APIs exposure from the CSPs, through instances like the CAMARA¹ initiative. This has been proven by e.g. the early global standardization of voice and SMS leveraged successfully by e.g. Vonage and other CPaaS players.

Additional value will be continuously added by utilizing the exposed network APIs, evolving into more advanced solutions with increased 5G network deployments.

[1] CAMARA - Telco Global API Alliance, is an open-source project within Linux Foundation

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 [2]) 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 with as many meanings as there are speakers and writers. The term Zero Trust (ZT) is used 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 [2] .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 by NIST[2], 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.

3GPP has concluded a study on how the NIST zero trust security principles/tenants are fulfilled in 5G core during 2023 and identified set of gaps. A second study is ongoing to look at these gaps and see what new security controls 3GPP can standardize to fulfil a ZTA. Examples of areas of investigation are monitoring on network functions and possible new interfaces needed.

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 15.

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[3] 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 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 and Infrastructure Security Agency) [4] 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.