Defining AI native: A key enabler for advanced intelligent telecom networks

The topics of how AI can bring business value to service providers¹ and the BSS evolution towards becoming AI native^{3 4} have already been discussed. This whitepaper is a deep dive into the newly emerged and discussed AI native concept which still does not have a clear definition.

The reader will get an understanding of how AI native is defined and a tool will be presented, the AI native Maturity Level Matrix, to judge where a product is on the AI native maturity scale. The AI native Maturity Level Matrix further helps specialists to plan out their AI native journey.

Over the past decade, there has been an explosion in the development and use of AI and machine learning (ML) techniques with a particular focus on the ML aspects of the AI field, where ML is generally seen as a sub-field of AI. This is also how these terms will be used in this paper. The term AI will be used with the understanding that a large part of AI discussions revolves around the subfield of ML, but AI is not exclusively ML, and there is still a substantial amount of work in the other aspects of AI such as machine reasoning for instance.

At the present time, AI technologies have matured and are now considered stable with state-of-the-art techniques being used to solve many types of hard problems. AI techniques excel in situations where there is inherent randomness and non-determinism, and where the complexity of capturing patterns and correlations in available data, sometimes based on very complex inputs, takes an inordinate amount of effort to be tamed by human expertise. In these situations, AI techniques can be trained on available data and then learn to represent and predict the inherent behavior in the data.

In the telecom domain, the increasing relevance of AI in several use cases has been observed for some years now. There are multiple drivers for the adoption of AI-based solutions in the telecom industry and this relevance is captured also, but not only, by standardization, for example, the 3GPP specifications of 5G and 5G Advanced where AI- based solutions are increasingly being used to improve network performance and enable intelligent network automation⁵.

These facts taken together are turning AI into pervasive technologies in the telecom industry and have also given rise to the term AI native, which has started to emerge both in academic and industry discussions¹⁴.

As the role of AI grows, it will have a more predominant impact on the design and handling of telecommunication systems. On the other hand, so far, it has not been clear what the multi-faceted aspects of AI native will mean to telecom operators or communications service providers (CSPs), and how they should plan the evolution of their networks. There is also a lack of a clear definition helping to anchor the AI native concept and create a common understanding of what is meant by AI native and why it is important for the whole industry.

To address the lack of a clear definition of the term AI native, it is first necessary to clarify how the term is used. AI native is often used as a prefix to an entity like a system, function, or implementation, for example, a more specific entity like a specific function or an interface. Regardless of which entity the prefix is used for, it can be argued that the high-level concept of AI native remains the same, and it includes the pervasive use of AI and a required accompanying data infrastructure in all sub-components of an entity rather than adding on an AI-based component to an existing non-AI-based entity.

The term AI native implementation is used to disambiguate the language when discussing the concept in its broadest sense. It would be confusing to talk about a system, a function (which can be a function in the generic sense, or it could be a network function), or an application since all of these can be AI native. Instead, the generic term implementation will be used and that term will encompass all of the above and any other conceivable entity that can be considered AI native.

From an implementation perspective, there are different approaches to adding AI capabilities to a system.

The figure above visualizes a few different approaches.

The first approach is replacing, implementing, or augmenting an existing functionality using AI techniques¹⁰. This is something that has already been taking place in Ericsson products for quite some time, for example in the mobility management entity (SGSN-MME) product for the ML Assisted Paging¹¹, as well as RAN functions such as Augmented MIMO Sleep⁹ and AI-powered downlink link adaptation¹².

A second approach is adding a completely new AI-based component that does not have any corresponding legacy implementation. Some existing examples include AI-powered energy optimizers¹³ and 5G-aware traffic management^{8 11}.

Both the first and second approach require backward compatibility with the existing system implementation, that is, compatibility with the legacy interfaces in the first approach and with the newly introduced (or pre-existing) interfaces in the second.

A third approach is adding an AI-based component that acts as a control for legacy component(s). AI-based control provides automation, optimization, and/or extra features on top of the legacy functionalities, as in AI-powered advanced cell supervision¹³.

Simply using AI to replace existing or add new functionalities in one, multiple, or all components, does not make an implementation AI native. An AI native implementation is managed by AI-aware control components that may themselves be implemented using AI techniques, including functionality for managing the lifecycle of AI-based components. Building on this, a definition of the AI native concept can now be introduced.

AI native definition

The AI native concept can be defined as follows:
"AI native is the concept of having intrinsic trustworthy AI capabilities, where AI is a natural part of the functionality, in terms of design, deployment, operation, and maintenance. An AI native implementation leverages a data-driven and knowledge-based ecosystem, where data/knowledge is consumed and produced to realize new AI-based functionality or augment and replace static, rule-based mechanisms with learning and adaptive AI when needed.”

AI native in a telecom context

For AI native to be meaningful, additional support and conditions need to be in place. To put AI native into perspective, the context of AI native is visualized according to the following picture:

Purpose

This is the objective that the given AI native implementation is tasked to achieve. It is normally a problem that, even with deep domain knowledge, would require very complex solutions using non-AI implementations but where data is available representing the system behavior that can be used to train an AI-based solution. For example, to make use of AI to enable the zero-touch operation vision, various kinds of functional enhancements and optimizations in the RAN, Core, or Management domain, or other kinds of non-functional optimizations such as power efficiency, latency, and throughput optimizations, and so on.

Environment

The environment represents the surroundings of the AI native system. An AI native implementation needs to be aware of what the environmental conditions are, and to be able to leverage them for its own purposes, to be able to detect and adapt to any variation, which might have an impact on its own ability to execute on the purpose. This can be the detection of which types of databases and protocols it interacts with, which type of hardware platform it is executing on, or which type of radio environment it is situated in.

Intelligence

Intelligence represents the ability to actively integrate its own base knowledge with new observations, by adapting to changed circumstances (for example, in the environment) and extending its knowledge base with newly acquired understanding, and finally, evolving strategies and measures to achieve objectives through learning new knowledge over time.

System

The system handles all the lifecycle management of the AI-based functionality and it represents the ability of the AI native implementation to interact with its neighbors and generate and expose data and knowledge in an AI/analytics-friendly way. The system ensures trustworthiness, fairness, and explainability in all operations and implements AI safety and AI control mechanisms. The system as a whole enables collaborative intelligence across the network.

Outcome

Finally, the outcome of an AI native implementation represents the enablement of value- added functions, such as the cognitive autonomous network vision, autonomous actions based on derived knowledge and reasoning, and the adoption of present and future AI- centric architectures.

AI native architecture

An important goal in the context of AI native is an AI-centric architecture. But what is an AI native architecture? Given the definition of the AI native concept above, it can be concluded that it is an architecture where AI is pervasive throughout the entire architecture. This can be achieved in new products by planning for an AI native architecture from the start. For legacy products, it can be considered possible to evolve an existing system, where this makes business sense, into an AI native system, given that certain aspects are properly addressed.

But how will AI native show in architecture? This is difficult to answer since it depends on the type of architecture. For example, AI nativeness would show differently in a functional architecture, which captures what functions to support, and how these functions interact, compared to a deployment architecture, which captures where to execute functions and run AI models, and what interactions there are between the physical locations where such AI models and corresponding functions are placed.

To answer the question, in this article, the following aspects are covered related to an AI native architecture: 1) intelligence everywhere; 2) a distributed data infrastructure; 3) zero- touch; 4) AIaaS.

The aspect of intelligence everywhere covers the requirement that it shall be possible to execute AI workloads wherever it makes sense based on a cost-benefit analysis. That means, in every network domain, on every layer of a stack, on every physical site from central to edge sites, and possibly even on mobile devices. This also implies that AI execution environments need to be available everywhere, and AI training environments might be co-located if needed.

The figure below illustrates this idea. Today there are several AI models already in production. It is expected that the number of AI models will grow. Eventually, the number will be so large that model lifecycle management cannot be done only with partial automation support anymore. Instead, it needs to be fully automated with business logic that decides what model version to use for execution and where and when to perform model (re-)training. Models with similar input features may be combined. Models may require data spanning several layers and even several domains, which may imply that layer and domain borders blur. In other words, the purpose of a model lifecycle management is to enable the AI native architecture with coordinated and trusted intelligence, constantly improving and following data changes, to achieve system-wide end-to-end gains.

The aspect of intelligence everywhere is interconnected with the aspect of a distributed data infrastructure. Executing and (when needed) training AI models everywhere is only possible if data and necessary compute resources (for example, GPUs) are available everywhere. And if data is available everywhere, it will also enable models spanning across today’s layers and domain boundaries. In other words, AI native will have strong requirements for the data infrastructure.

Data may have a best-before date or legal constraints. The sheer volume of data may set constraints. This would restrict when and where data can be consumed. A data stream may need to be processed, or several data streams may need to be combined. Data observability needs to be flexible to adapt to the requirements of the data consumer and the available resources of the data producer and the transport infrastructure. All this implies that the data infrastructure and the model orchestrators need to interact; sometimes data can be transported to the intelligence, and sometimes it is more efficient to bring the intelligence closer to the data, for instance when there are hard requirements on the timing of the data, where the data is useless after a certain time. A more elaborate description is available in Data Ingestion Architecture⁶. We expect this architecture to evolve further with time.

The two aspects mentioned above imply that many functions need to be in place. Examples are data observability, data pre-processing, feature engineering, model training, model repository, model serving, model drift detection, execution monitoring, and so on. All these functions would be available within the AI native network architecture allowing lifecycle management of AI artifacts, that is, models, pipelines, features, datasets, and so on. This aspect is often referred to as AIOps or MLOps.

From the above, it becomes clear that intelligence everywhere implies that AI techniques can be used in a cross-cutting fashion across the whole architecture, and it is not limited to one layer of the architecture. The same goes for the data infrastructure; data and knowledge need to be shared across layers and AI techniques can be applied in each layer and even across layers.

Managing the intelligence and the data infrastructure mentioned above makes the task of human operators even more complex. There is a need to automate the management of AI and data. Instead of introducing new manual operations (where humans decide what to do and how) or automated operations (where humans design workflow executions), the aim should be for fully autonomous operations. Humans would still be in control by expressing requirements to the system and by supervising that those requirements are fulfilled, rather than instructing the system on what actions to take. We call this aspect zero-touch. Introducing zero-touch for the management of AI and data may even be an enabler for a fully autonomous network, where an autonomous network is a network with self-* (self- configuration, self-healing, self-optimization, self-protection) capabilities. This enables a cognitive network², that is, an AI native implementation of an autonomous network. A more elaborate description of creating autonomous networks is provided in⁷.

Finally, the AI native architecture aspects above require novel functions in the network related to AI and data handling. Some of these functions may be exposed as services to external parties. Examples include AI model lifecycle management features such as training or an execution environment, or data handling aspects such as data exposure. Exposing such services turns the network into a platform for innovation. The exposure of these AI services is usually called AI as a service (AIaaS); users of AIaaS may be the service provider or even customers of the service provider.

AI native maturity model

Having explored the context of AI native and its implications on architecture, how is an AI native system designed, or how is an existing implementation evolved into an AI native implementation where it makes sense? In other words, how can a reference framework be defined for the AI native journey in the telecom industry?

In this section, specialists are given a tool to assess where their products are on the AI native spectrum and to plan how an implementation could evolve toward being AI native. Specialists are also given an understanding of the context of developing products, which aim to become AI native.

The guiding principle is increasing the span and the autonomy of the AI native implementation, while, at the same time, decreasing the level of human intervention and control. Thus, while at initial levels the AI is simply replacing basic functions under strict human guidance and revision, thereafter AI becomes more and more the heart of the implementation, with humans focusing only on specifying goals and monitoring outputs.

To help guide specialists in their AI native journey, Ericsson has developed an AI native maturity model. This model, in contrast to many other AI maturity models, focuses on the AI native aspect and it leaves out many other aspects such as strategy and finance, people management, training and culture, governance, and other AI related aspects that are also relevant to developing AI systems. The model consists of a matrix of five levels, with an additional level of zero, signifying not being AI native, and for each level, there are several dimensions. The dimensions, such as architecture, collaboration, data ingestion, and so on, can be analyzed with respect to their level of AI nativeness.

The columns with the different levels are to be seen as a measurement tool rather than an absolute goal, as it does not necessarily make sense to reach level 5 for all AI native implementations as requirements differ per implementation.

The rows in the model are independent, so a given implementation can be on level 2 for one dimension and level 3 for another. The choice is left to each application to, for example, mandate level 3 on data management but settle for level 1 on the self -* dimension.

The AI native maturity model can initially be used to establish a baseline assessment of where a product is in regard to its AI native journey. It can then further be used to set a target of AI nativeness and milestones on how to get there.

When the appropriate target level for implementation is decided based on the business needs, the model can be used, starting from the baseline assessment, and map further steps along the different dimensions onto a timeline. An evolutionary story can then be outlined to reach the wanted level of AI nativeness over time.

For an implementation to have reached a minimal level of AI nativeness, it should reach level 1 on at least the architecture, data ingestion, storage and processing, model lifecycle management (LCM) and security, and self-* dimensions. That is to say, there must be a well-defined, (basic) architecture for AI facilities and mechanisms to deploy and manage AI models, and for models to ingest needed data from the surroundings. The ability to monitor the model’s behavior over time is also required.

The topics of ethics, trustworthiness, and safety are of utmost importance, they play a very central role in all AI implementations and vary across the world. Due to this, these aspects are not covered specifically in the maturity model, as it is not wished to impose a minimum or suitable level for a given implementation, which might be acceptable or not depending on where the system is deployed. It is instead chosen to state that ethical, trustworthy, and safe AI is mandatory for all levels and all dimensions, and it is assumed that all implementations follow all regulatory guidelines and rules that apply where the system is deployed.

In this white paper, different types of AI implementation approaches were defined and the concept of AI native was demystified, including the definition. The main aspects of an AI native implementation were then clarified and it was described how AI native will show in architecture, followed by a detailed explanation of AI native levels, which can be used as guidelines by the telecom industry on their AI maturity journey. These levels complement the existing maturity models on AI by different standardization forums¹⁵, hence a valuable step ahead could be to evaluate this framework in different forums to get an industry-wide consensus.

An AI native implementation ideally means that AI is implemented as the first thought in the system and not as an afterthought. In other words, the system is designed to leverage AI to achieve zero-touch networks that deliver on different needs. We are at the cusp of delivering a transformative portfolio using the latest cutting-edge technologies and evolving toward an AI native architecture in a stepwise approach. It is paramount for the industry to come together and leverage and evolve AI native technologies as needed for scaled adoption.

CSPs and telco suppliers can leverage the AI native maturity model and design their journey based on where they are and where they need to go. It is essential that as an industry, some terms are very clearly established with AI native being one of the most sought-after.