Network capabilities

Intent can be defined as a “formal specification of all expectations including requirements, goals and constraints given to a technical system”. It states which goals to achieve rather than how to achieve them.  Intent enables the creation of autonomous sub-systems rather than creating tightly coupled management workflows.

Cognition is a psychology term referring to an “action or process of acquiring knowledge, by reasoning or by intuition or through the senses“ [Oxford]. Using cognitive technologies makes it possible to implement a technical system with cognitive capabilities using e.g. AI techniques including Machine Learning (ML) and Machine Reasoning (MR).

Standardization in the areas of Autonomous Networks and Intent-driven management is ongoing in several Standardization Organizations (e.g. TMF, 3GPP, ETSI) and cover separate aspects of automation which include use of cognitive technologies such as AI, intent-driven management, digital twins, data-driven management, MLOps, and others.

As a step towards a fully autonomous network and achieving an intent-based management of a network, its architecture must be prepared by raising the level of abstraction in management with e.g., strong separation of concerns.

Each instance of an Intent Management Function, IMF then has a clear and non-overlapping scope of responsibility for a functional domain in the autonomous network architecture as shown in Figure 1.

IMFs receive intents from customers and other functions, and exchange intent with each other, managing the life cycle of an intent, and coordinate, within its domain of responsibility, the needed actions with other management functions.

The internal control loop of an IMF has a cognitive loop of five logical phases: Measurements, Assurance, Proposal, Evaluation and Actuation.

Collaboration with, for example, service assurance and service orchestration are also required to ensure fulfilment.

MLOps is a set of processes and technology capabilities for building, deploying, and operationalizing Machine Learning (ML) systems, including how data is refined and transformed to serve the ML system, aiming to unify ML system development and ML system operation 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.

Certain additional challenges of adopting MLOps to highly reliable live telecom networks exist such as the need to handle lifecycle management or 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, both internal and external, 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, but likely in several more.

CSPs’ realities vary depending on selection of cloud infrastructure with a clear divider of whether the CSP selects to use a particular HCP or use private cloud which can be done for various reasons, like applications execution, licensed SW or data storage, etc.

Spreading MLOps over several large HCPs (e.g., AWS, Azure, GCP), with the limited compatibility between their APIs for AI services requires a certain level of adoption for vendors’ products/services to adopt to each of these HCPs.  Although there may be benefits of using HCP tools/services, it will require certain efforts – efforts for transferring data, efforts for data refinement, efforts for consumption, etc.

A few abstraction layer initiatives exist that may help to provide an abstraction layer for different HCP services. None of these alternatives, however, provide a complete solution to the problem and AI/ML is not at the top of their priority list.

Mobile broadband has become a society-critical service in recent years, with enterprises, governments and private citizens alike relying on its availability, reliability and resilience around the clock. Living up to continuously rising expectations while simultaneously evolving networks to meet the requirements of emerging use cases beyond MBB will require the ability to deliver increasingly higher levels of network robustness.

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 and automotive to take a major step forward in their digitalization journeys by replacing older means of communication with the 5GS. These new capabilities are also beneficial for mission-critical networks like national security and public safety deployments being modernized.

It is important to consider all parts of the network in the definition of robustness (as illustrated by the green part in Figure 3), as the weakest link in the E2E chain sets the limits for the network service characteristics. In addition, network-level design must include consideration of both sunny day scenarios and different disaster/failure cases in all parts of the network. The large orange section represents both new critical use cases and society-critical use cases with new and tougher requirements. The orange line between the application client and the server, highlights the significance of the E2E perspective.

While both 4G and 5G can provide the high level of robustness required to deliver such services today, new and emerging use cases require the addition of new features and mechanisms in the network robustness toolbox. 5GS has been designed to meet even the most challenging network robustness requirements. Beyond that, the creation of robust networks also requires careful network planning and deployment.

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. The toolbox also enables CSPs to activate different mechanisms for different user equipment within a single network.

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) and is based on mechanisms such as:

• NI-QoS (Network Initiated-Quality of Service) is standardized in 3GPP and based on establishment of radio bearers and QoS Flows (shortly bearers)
• L4S (Low Latency Low Loss Scalable Throughput) is an IETF-defined solution for time critical communications to ensure that latency-critical high-rate apps using built on L4S information in the IP-header
• URSP (UE Route Selection Policy) is standardized by 3GPP for a UE using multiple slices and/or PDU Sessions

These network resources may have different QoS levels associated to them (see Figure 4). NI-QoS and URSP are examples of traffic classification mechanisms with different control points that can be used for QoS support in mobile networks.

Additional functionality is needed to support a network with deployed QoS support. One such example is SLA and SLA assurance support. 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 and particular care needs to be taken in the RAN parts where there are limitations in the number of radio bearers.

Another area of concern is how to handle Net Neutrality and Open Internet (NN/OI) which impact how a CSP can monetize QoS. One way of working with this could be to offer several subscriptions on a single device.

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.

See also chapter on the Global Network Platform.

As CSPs seek to expand outside 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 while leveraging their existing connectivity offerings and combine them with cloud and edge offerings from different players.

Exposure can be applied in different places, both in the network and in the device as illustrated in Figure 5 below which is based on the High Level Network Architecture further below in Figure 5.

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.

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.

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 from Modem vendors.

Although the Z and C layers are expressed as thin lines (Figure 5), 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 consistence experience towards different consumers of the APIs (developers, integrators, enterprises etc.) enabling scale and eliminates the need for an to have to use a proxy through the Management, Orchestration and Monetization layer.