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

群内每日免费分享5份+最新资料

300T网盘资源+40万份行业报告

为您的创业、职场、商业、投资、亲子、网赚、艺术、健身、心理、个人成长 …… 全面赋能！

关注公众号获取更多资料

添加微信，备
注“入群”
立刻免费领取
200套知识地图+最新研报

致终身学习者社群

行业报告/思维导图/电子书/资讯情报

收钱文案、增长黑客、产品运营、品牌企划、营销战略、办公软件、会计财务、广告设计、摄影修图、视频剪辑、直播带货、电商运营、投资理财、汽车房产、餐饮烹饪、职场经验、演讲口才、风水命理、心理思维、恋爱情趣、美妆护肤、健身瘦身、格斗搏击、漫画手绘、声乐训练、自媒体打造、效率软件工具、游戏影音……

扫码先加好友，以备不时之需

Content

Introduction 3
Emergence of the AI native concept 4
AI native definition 6
Conclusion 15
References 16
Authors 17

Introduction

This white paper presents a number of views on the artificial intelligence (AI) native concept and discusses the background and context of AI native implementations. A maturity model is introduced for specialists to determine at which level of AI native maturity a certain artifact is at.

The topics of how AI can bring business value to service providers [1] 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.

Emergence of the AI native concept

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 AIbased solutions are increasingly being used to improve network performance and enable intelligent network automation [5].

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 [14].

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.

AI native definition

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.

Figure 1: Ways to add AI 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 [10]. 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 [11] , as well as RAN functions such as Augmented MIMO Sleep [9] and AI-powered downlink link adaptation [12].

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 [13] 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 [13].

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:

Figure 2: AI native in the telecom context

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 valueadded functions, such as the cognitive autonomous network vision, autonomous actions based on derived knowledge and reasoning, and the adoption of present and future AIcentric 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) zerotouch; 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.

Figure 3: Intelligence everywhere across the architecture

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 [6]. 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.

Figure 4: Generic AI native architecture

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-* (selfconfiguration, self-healing, self-optimization, self-protection) capabilities. This enables a cognitive network [2], that is, an AI native implementation of an autonomous network. A more elaborate description of creating autonomous networks is provided in [7].

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.

Architecture		Level 0	Level 1	Level 2	Level 3		Level 4	Level5
品	No AI architecture A basic reference AI architecture defined AI architecture 只 □				AI architecture supporting streaming and distributed computing	Fully fledged AI architecture	AI managed AI architecture
Jrnrrrnrlrrpseerenhelrerrrrirbieerirrlrreseeeer	Collaboration 0 6	AI functions that do not collaborate	Some standalone AI functions that collaborate by sharing data Automatic	Several AI-based functions that integrate with a core AI infrastructure Partially	Fully cooperative AI-based functions and core AI infrastructure, with AI capabilities throughout the architecture Fully	Level 3AI systems that collaborate	Federation capabilities to share insights/ models from distributed "crowds"of functions
	Data ingestion Manual and storage and offline processing					Fully adapted to data pipeline, data mesh and ingestion no copy data architecture sharing	AI-driven universal data mesh
and security	Model LCM model LCM	No dedicated	Manual model deployment	Automated model deployment	Dynamic model adaptation to local conditions and data Basic model	Automated model migration/ upgrade Advanced model	Complete automated model LCM and security
Self-* Proprietary, Self-aware,						security security Self-healing	Self-augmenting Self-designing,
	logging,FM, PM CM	non-standardizeds	monitoring	Self-diagnosis, and prediction	self-configuring，self-optimization remedies and	business preemptive behavior management	AI-driven AI

Figure 5: AI native maturity model

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.

Conclusion

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 [15], 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.

Glossary

FM Fault Management

PM Performance Management

CM Configuration Management

References

Ericsson – AI in networks
Ericsson – Cognitive networks
Ericsson – Road to AI native BSS
Ericsson – BSS and AI, time to go AI native
Ericsson - 5G Advanced: Evolution toward 6G
Ericsson - Data ingestion architecture for telecom applications
Ericsson - Creating autonomous networks with intent-based closed loops
Ericsson - 5G-aware traffic management
Ericsson - Augmented MIMO sleep
Ericsson - Accelerating the adoption of AI in programmable 5G networks
External - Mobility Prediction for 5G Core Networks
Ericsson - Ran Automation and AI-powered downlink link adaptation
Ericsson - AI-powered energy optimizer
External - Report ITU-R M.2516-0 (11/2022) Future technology trends of terrestrial IMT systems towards 2030 and beyond
TMFORUM - AI Maturity Model Toolkit

Authors

Massimo Iovene is a technology leader in Core Network engineering, with more than 25 years of experience working with telecommunications architecture, product implementation and customer engagement. In the past years working on product strategy and evolutionary aspects around Cloud technologies, Automation, O&M, Total Cost of Ownership aspects, Cloud Native journey, analyzing market trends, status of the industry and the research. More recently his work has focused on the domain of AI and related methods, with the primary ambition of applying them to telecommunications, for nodes and service automatization.

Dr. Leif Jonsson received his MSc degree in Computer Science (1998) from Uppsala University; in the same year he started working at Ericssons research division. In 2018 he finished his PhD in Computer Science with a focus on Machine Learning and AI at Linköping University in cooperation with Ericsson. His research interests include applying machine learning techniques to large-scale software development processes to automate traditionally hard to automate tasks. In his current position as Expert in AI & Machine Learning, he focuses on AI strategy, teaching and mentoring in the area of ML and research into applied ML at Ericsson.

Dinand Roeland is a principal researcher at Ericsson Research who joined the company in 2000. His current research interests involve introducing artificial intelligence technologies into end-to-end network architecture with the goal of achieving an autonomous cognitive network. He has worked in a variety of technical leadership roles including product development, concept development, prototyping, standardization, system management and project management. He holds an M.Sc. cum laude in computer architectures and intelligent systems from the University of Groningen in the Netherlands.

Mirko D’Angelo is an Experienced Researcher in network management and automation at Ericsson Research where he currently investigates the use of AI to realize cognitive networks. He holds a Ph.D. degree in Computer Science from Linnaeus University, Sweden, and a M.Sc. cum laude from University of Rome “Tor Vergata”, Italy. His research interests lie in the area of autonomous and self-adaptive systems with a distinct focus on AI applied to distributed systems.

Göran Hall is an Expert in Network Architecture Evolution at the CTO office. He joined Ericsson in 1991 to work on development and standardization, primarily within the area of Packet Core network architecture, which has so far includes GPRS, WCDMA, PDC, EPC and 5G Core. He has been chief network architect for the Packet Core domain in his previous assignment, including responsibility for the functional requirements and architecture for the 5G Core network. Hall holds an M.Sc. in Electrical Engineering from Chalmers University of Technology in Gothenburg, Sweden.

Dr. Melike Erol-Kantarci is Chief Cloud RAN AI\ML Data Scientist at Ericsson. She is also Canada Research Chair in AI-enabled Next-Generation Wireless Networks and Associate Professor at the University of Ottawa. She has over 200 peer-reviewed publications which have been cited over 7000 times and she has an h-index of 42. She has received numerous awards and recognitions. In 2019, Dr. Erol-Kantarci was named to the list of N2Women Stars in Computer Networking and Communications (formerly known as “people you should know in networking and communications”). She has delivered 70+ keynotes, tutorials and panels around the globe. She is also an IEEE ComSoc Distinguished Lecturer, IEEE Senior member and ACM Senior Member.

Jitendra Manocha is a Senior Portfolio Manager in the Business area of Cloud Software & Services. In his 20+ years of experience, he has held various leading positions in product management, R&D, and services. In recent years he has worked in the AI/ML strategy, Edge computing, and Network as a Platform. He previously worked in 5G Analytics and 5G network exposure in 5G Core networks. He has experience in creating products from concepts to industrialization and scaling them to tangible businesses. He holds two M.Sc degrees from KTH Royal Institute of Technology in Stockholm, Sweden, in the areas of Information technology and Industrial Management and an engineering degree in Electronics & Communication.