NLP Powered Intent Based Network Management for Private 5G Networks

Intent driven networking holds the promise of simplifying network operations by allowing operators to use declarative, instead of imperative, interfaces. Adoption of this technology for 5G and beyond networks is however still in its infancy, where the required architectures, platforms, interfaces and algorithms are still being discussed. In this work, we present the design and implementation of a novel intent based platform for private 5G networks powered by a Natural Language Processing (NLP) interface. We demonstrate how our platform simplifies network operations in three relevant private network use cases, including: i) an intent based slice provisioning use case, ii) an intent based positioning use case, and iii) an intent based service deployment use case. Finally, all use cases are benchmarked in terms of intent provisioning time.


I. INTRODUCTION
After almost ten years of research and standardization, the design of 5G networks as a distributed software and cloud/edge based infrastructure managed by per-domain orchestrators is well established. Softwarization has enabled virtualization of network functions that brought along flexibility for network services and deployments. For example, through the adoption of network slicing, services are created and tailored to vertical users. Thanks to all these key technical enablers, more heterogeneous, dynamic, expanded and distributed services have emerged in 5G network scenarios, increasing the complexity of network operations and hindering the management of such networks.
The associate editor coordinating the review of this manuscript and approving it for publication was Bo Pu .
The virtualization of network functions also allows for the deployment of private networks where the Virtual Network Functions (VNFs) can be exclusively used by a private entity such as an enterprise. Private networks, named as Non-Public Networks (NPNs) by 3rd Generation Partnership Project (3GPP), are categorized based on their deployment type as (i) Stand-alone NPNs (SNPNs), which do not rely on network functions provided by a public land mobile network (PLMN); and (ii) public network integrated NPNs (PNI-NPNs), where the private network deployment is supported by a PLMN [1]. In both deployment types, NPNs can be managed and controlled by a private network operator or entity owner. Private 5G networks are being increasingly demanded by several vertical domains, but their adoption is hindered by the lack of a labor force skilled in 5G within the private entities deploying these networks.
In this vein, simplifying operational complexity is the main goal of intent based networking, which originated around 2014 with the advent of the first Software-Defined Networking (SDN) open platforms [2]. Intent based networks are emerging as a key enabler to facilitate the management of private 5G networks where, through the use of intents, endusers with no technical network insights are able to issue network configurations and to operationally manage the private network. In this way, intent based networks offer a significant added value to the network owners and/or customers that have no expert knowledge on communication networks.
The main concept behind intent based networking is adopting declarative interfaces where network operators specify what they want to achieve, instead of specifying how to achieve it. In this regard, Machine Learning (ML) is seen as a key enabler to autonomously fill the missing context required to translate high level intents into low level network configurations [3]. A relevant example of the configuration complexity incurred in private 5G networks is provided in [4], where the authors introduce 5G-CLARITY, which is a novel architecture for 5G private networks integrating 5GNR, Wi-Fi and Li-Fi access networks. The 5G-CLARITY architecture is composed of three strata, namely an infrastructure stratum, a virtualised network and application function stratum and a management and orchestration stratum, and provides support for multi-connectivity, positioning and slice provisioning. Thus, deploying end-to-end network services in 5G-CLARITY requires the provisioning and configuration of both virtual and physical network functions (V/PNFs), imposing a steep learning curve for private network operators that are not familiar with 5G technologies.
The main contribution of this paper is twofold. First, we extend the original 5G-CLARITY architecture proposed in [4] by adding a new intelligence stratum that enables the intent driven operation of the private 5G network by means of ML models and a novel natural language processing (NLP) intent driven interface. Second, we describe a prototype implementation of our intent driven platform and demonstrate its generality applying it to three relevant private 5G network use cases, including: i) an intent based slice provisioning use case, ii) an intent based positioning use case, and iii) an intent based service deployment use case.
The rest of the paper is structured as follows. Section II provides an overview of the existing standards and related works, highlighting the novelties of this work compared to the revised ones. Section III describes our proposed intelligence stratum to provide NLP based intents, including an Intent Engine and Artificial Intelligence (AI) Engine. Section IV describes the application of our designed intent based interface to three relevant private 5G network use cases. Finally, Section V summarizes and concludes the paper.

II. STATE OF THE ART
Over the last several years, intent-based networks (IBNs) have attracted the attention of academia researchers, industry, and standardization bodies due to their capabilities of mitigating the complexity of the management tasks in emerging networks. This section overviews previous works related to IBNs mainly focusing on the existing standards and the academic research works.

A. STANDARDIZATION
Several Standards Development Organizations (SDOs) (e.g., 3GPP, European Telecommunications Standards Institute (ETSI), TM Forum) are concentrating efforts on the standardization processes related to IBNs, although they are still under development. The standardization efforts of 3GPP are led by the SA5 group. In [5] the concepts of intent and intent driven management are introduced, where an intent driven management service allows their consumers to express intents to manage the 5G network and its services. The document also provides several intent driven management scenarios. In [6], 3GPP describes potential use cases (e.g., intent containing expectations for deploying a radio network in a specified area), their requirements, and the procedures to support intent driven network and service management. Another SDO contributing to this field is ETSI. In [7], the Zero-touch network and Service Management (ZSM) group starts describing the automation of network management. They concentrate on policy-driven automation, intent-based automation, and intent-based service orchestration. The 5G-CLARITY management stratum is an example implementation of an ETSI ZSM network [8], [9]. In [10], the Experiential Networked Intelligence (ENI) working group differentiates between declarative and imperative policies, and intent policies. Imperative policies specify how the network has to achieve a given task. In [10], these policies are stated as a triplet of event-condition-action, in which the condition determines the action to be taken to accomplish a desired state depending on the current state. On the other side, declarative policies just specify the desired state and let the system compute the action. ETSI defines an intent-based policy as a simplified declarative policy which declares what is wanted, but not how to do it. This intent definition approach is the one aligned with our proposal in this work.
TM Forum is another SDO working on facilitating business, services and network operations in 5G networks. The TM Forum Autonomous Networks Project defines a fully automated zero wait, zero touch, zero trouble innovative network for users and consumers of vertical industries. In several documents [11], [12], [13], [14], [15], [16] intent proposal, recommendations, interfaces and models specifications required to implement intents in autonomous networks can be found. Reference [11] describes a reference architecture for autonomous networks, including the three layers of business operations, service operations and resource operations, in order to provide guidance on the development of solution architectures for intelligent automation and autonomy within communications service provider (CSP) operations. IG1253 [12] is the main overview document of a set of documents describing the proposal for implementing VOLUME 11, 2023 36643 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.
intents in autonomous networks and intent-driven operation. It defines an intent as a formal specification of all expectations including requirements, goals, and constraints given to a technical system. Our proposal of intent concept in this work also aligns with this definition since the intents allow the autonomous system to know the goals together with the requirements and constraints that issue an action to accomplish the mentioned goal. Additionally, it introduces the intent management function as an architectural building block for the intent-based operation, which will receive an intent fulfillment, control the execution of these actions, and report the progress. The document also discusses the role of natural and domain specific language in intent-driven autonomous networks, proposing an interpreter, which acts as a mediator between the natural or domain specific and the formal intent framework. Our intent approach aligns with two components detailed in the document. The intent engine, which we introduce in section III, with minor changes to the functionality template and context information may perform the role of both an intent management function or interpreter. The rest of documents [13], [14], [15], [16] are complementary documents deepening on other key aspects. For example, [13] introduces the models that determine how an intent must be expressed by defining the modelling concepts to be used when formulating and interpreting an intent. Reference [14] proposes extensions to the common model for expressing intents that might be relevant in specific domains or contexts. Reference [15] defines the details of the intent management function and the interface through which the intent objects are exchanged, negotiated, and managed as part of the life cycle management process. Reference [16] defines mechanisms of registration and discovery of capabilities and the scope of the responsibility associated with an intent manager.

B. RELATED WORK
Application of intent based networking for 5G networks has been an intensive area of academic research in the last years. In [17], the authors propose an architecture for an intent driven orchestrator that can manage an end-to-end 5G system. The intent driven platform includes an ML function orchestrator (MLFO) component to manage the life cycle of ML functions required to support intents, and a centralized Data Lake component to expose network telemetry. In this work, we leverage the ideas of the MLFO and Data Lake components to design a novel intent based platform for private 5G networks.
Other authors have focused on the demonstration of intent based platforms operating over 5G research infrastructures. For example, [18] and [19] introduce intent based platform prototypes aiming at simplifying the lifecycle management of 5G network slices. The authors in [18] use a 5G stack based on Open Source MANO (OSM) [20] and FlexRAN [21], while in [19] the authors use a stack based on M-CORD [22]. In both cases, intents are provided through a graphical user interface (GUI), where the user indicates a slice type and some complementary parameters that are translated by the intent engine into detailed configuration requests towards the Network Function Virtualization (NFV) and Radio Access Network (RAN) orchestrators. Unlike these previous works, our proposed intent based platform offers a natural language interface instead of a GUI.
The work in [23] surveys current intent based standardization and open-source related initiatives claiming that the field has not progressed much since 2015 in terms of new platforms or product adoption, mainly due to the lack of intent based interfaces that can effectively simplify network management operations. In this regard, the authors identify advances in NLP, thanks to AI/ML, as a potential catalyzer to adopt intent based interfaces. Regarding NLP interfaces for network management, the work in [24] presents a voice assisted network management platform, where the Alexa appliance is extended [25] to trigger establishment of end-toend paths in a simulated SDN enabled carrier network. The authors demonstrate that voice-activated high level intents such as set up a path from CityA to CityB can be automatically translated into the required low level configurations. Similarly, in [26], the authors propose an intent-based network design based on natural language specifications to trigger network tasks in a network of several Open vSwitch switches emulated in Mininet. The authors check the functionality of intents like create flow from 10.0.0.1 to 10.0.0.2 and block web traffic. In future work we expect to see more investigations into the use and chaining of large language models for intent fulfillment. The authors of [27] have identified that complex operations may require the chaining of several models, each specialised for specific domains and as a result have investigated the user experience when authoring these chains. This work in the academic space coupled with the increased interest of large language models such as CHATGPT in popular culture may lead to similar approaches being investigated in the network and telecommunications domain.
To the best of our knowledge, no previous works are available demonstrating application of NLP based intent interfaces to management of 5G networks. Our goal in this work is to cover this gap. To that end, we put our focus on private 5G networks and we design a novel intelligence stratum that enables the intent driven operation of private 5G network by means of a novel NLP intent driven interface. Our designed intelligence stratum builds on the 5G-CLARITY architecture presented in [4]. Fig. 1 depicts the 5G-CLARITY private network architecture introduced in [4] augmented with a detailed management and orchestration stratum and with a novel intelligence stratum that enables the intent driven operation of the private network infrastructure.

III. 5G-CLARITY INTELLIGENCE STRATUM DESIGN
As introduced in [4], the infrastructure stratum includes the physical network functions that compose the private 5G network infrastructure, i.e. wireless access points, radio heads, Ethernet switches, as well as compute clusters dedicated to host virtualized RAN and edge network functions. These virtualized RAN and edge network functions compose the network and application function stratum including, among others, core network, multi-connectivity, positioning, and O-RAN related network functions. Connectivity services over this infrastructure consist of radiating a private PLMN identifier (PLMNID)/Single -Network Slice Selection Assistance Information (S-NSSAI) pair with a dedicated user plane function (UPF) and an associated quality of service (QoS). Thus, provisioning connectivity services requires complex low level configurations on both the physical and virtual network functions.
The purpose of the Management and Orchestration stratum depicted in Fig. 1 is to enable an application programming interface (API) driven operation of the private network infrastructure. The management and orchestration stratum is composed of two main subsystems, the service and slice provisioning subsystem and the data processing subsystem.
The goal of the service and slice provisioning subsystem is to configure and provision the physical and virtual network functions required for a specific service. To this end, the service and slice provisioning subsystem includes three management functions, namely: i) an NFV Orchestrator (NFVO) 1 used to manage the lifecycle of network services required for a slice, ii) a RAN controller in charge of configuring the wireless physical and virtual network functions, and iii) a Slice Manager function, which encodes the end-toend business logic of a network slice, and offers a simplified north-bound interface to manage network slices. The interested reader is referred to [4] for a detailed description of the infrastructure slices supported by the 5G-CLARITY system.
The goal of the data processing subsystem is to collect and maintain network telemetry associated to the private 5G infrastructure, where telemetry is generated both by the physical and virtual functions in all segments of the network, i.e., RAN, transport, and core. Public cloud Data Lake services and data processing pipelines, such as the Semantic Data Aggregator available in [28], can be used to implement this stratum. The stored network telemetry will be queried by the intelligence stratum to generate low level configurations.
While enabling API driven control, the operational complexity exposed by the management and orchestration stratum is still significant. As a matter of example, let us take a closer look at the provisioning process of a network slice over the 5G-CLARITY infrastructure, which involves two main steps. First, the infrastructure stratum resources allocated to the slice (i.e., access points and compute resources) need to be selected. Listing 1 depicts the API endpoint used to select cells and configure low level radio parameters, and Listing 2 the endpoint used to select compute resources, where the required compute, memory and storage resources are specified. The second step is to instantiate the network services composing the slice. Listing 3 illustrates the API endpoint used to configure a radio service, which includes QoS, service and user related low level configurations. We can see how the provided endpoints are far from the simplicity envisioned by our intent based interface, where a user should be able to provision a network slice using natural language through a simple intent such as I want to provision a slice. Delivering this abstraction is the goal of the intelligence stratum depicted in Fig. 1.
The intelligence stratum is composed of two functional elements, the Intent Engine and the AI Engine (c.f. Fig. 1). The goal of the Intent Engine is to offer an NLP based interface to the end user, which is then translated into lowlevel configurations towards the functions of the appropriate stratum, e.g. the API calls of the Slice Manager, illustrated in Listings 1, 2 and 3. The goal of the AI Engine is to host and manage the lifecycle of ML models, which will support the Intent Engine into generating the required low level context. The Intent Engine and AI Engine work together to make informed complex changes in the network, which are dynamically communicated to the responsible components in both the Network and Application Function Stratum and the Management and Orchestration Stratum. Next, we describe the detailed design of the Intent Engine and AI Engine components, and the intent related workflows that describe the low level actions performed in our platform when high level intents are issued by an user.

A. INTENT ENGINE
The Intent Engine is built upon Adaptive Policy EXecution (APEX), a state machine approach to policy execution that incorporates a context functionality into the decision making mechanism. APEX was initially published in [29] and was later adopted as a Policy Decision Point (PDP) in the Open Network Automation Platform. 2 Our previous work in [30] provides the core NLP-based interpretation mechanism for the Intent Engine. Fig. 2 shows the interpretation and matching process utilised in this work. The core components of the mechanism are the use of Context, Interpreter and Intent Matching. Context contains information of available interfaces and functionality, Interpreter manages the translation and building of API calls to fulfil the intent request, and Intent Matching provides an evaluation of the intent request when compared to available functions and strategies. 2 https://docs.onap.org/projects/onap-policy-parent/en/latest/apex/APEX-Introduction.html LISTING 1. Radio chunk.

LISTING 2. Compute chunk.
These components of the mechanism will be described in more detail in the following paragraphs. The mechanism was then adapted to expand the action and interface generation features to incorporate the AI Engine, ML models and orchestration type components. This allowed the Intent Engine to communicate with slice provisioning systems, active ML LISTING 3. Example radio service activation API endpoint. models running in the AI Engine and production-quality Network Service Orchestrators (NSO). This communication will be shown in Section IV.
Next, we describe the key design principles of our Intent Engine, namely: i) the Intent Design, describing how intents are built, ii) the Intent Matching Engine, describing how intents are matched to specific API endpoints, and iii) the South-bound provider integration, describing how different management functions can be integrated with the Intent Engine.

1) INTENT DESIGN
An Intent message has two fields: request and parameters. The request field contains an intent in the form of an English sentence. This is used in the matching process to compare the users request with operations available to the Intent Engine. The parameters field contains information the user would like to inject into the action building process. This is required information that is not provided through component defaults or through a supplementary ML model in the AI Engine.
The request and parameters fields can be seen in Listing 4 in the form of an example, namely a Slice Provisioning Intent. In the example, the request details the creation of a slice through an ML model in the AI Engine. As this is a complex process containing several sequenced executions the ML model populates many of the sequenced operations, however some parameters cannot be queried or generated. These parameters are detailed in the example such as user-list, location and technology. A detailed explanation of the intent based slice provisioning use case is provided in Section IV-A.

2) INTENT MATCHING ENGINE
The Intent Engine adopts an NLP-based matching process to correlate intents with executable operations available in the moment. This is achieved through a text distancing algorithm trained on Wikipedia data, which scores the intent request against a range of operation descriptions. The operation descriptions are stored in a model referred to as the Functionality Template (see Fig. 2). The user provides the Functionality Template to the Intent Engine through a registration process, informing the Intent Engine how and where to communicate with the component. This template follows OpenAPI Specification allowing it to be processed in the intent matching and action generation stage of the execution. Information from this model also informs the dynamic building of the interface to allow communication between the Intent Engine and the target component as a result of the processed intent. A detailed description and evaluation of our matching engine can be found in [30].

3) SOUTH-BOUND PROVIDER INTEGRATION
Informed through the Functionality Template, the Intent Engine dynamically builds the interfaces for the south-bound communications. Through the use cases described in Section IV we show the Intent Engine communicating several requests to three components operating in two independent strata. These interfaces are built at execution time to ensure the most up to date information is used during the action building and interface building stage of execution. As a result, changes or re-configurations of components do not require a hard restart of the Intent Engine. Instead, the reissuing of an updated Functionality Template would restore the communication.

B. AI ENGINE
The AI Engine is built upon the open-source Function-as-a-Service (FaaS) platform OpenFaaS. The OpenFaas platform provides a flexible and lightweight toolkit which can be deployed through Docker, built using a range of languages and scales appropriate to usage.
The conceptual diagram shown in Fig. 3 gives a highlevel overview of OpenFaaS concepts, with endpoints for the user, monitoring, Kubernetes as the FaaS provider and two example functions. OpenFaaS exposes REST endpoints to the user accessible through CLI client, GUI or REST request. The central FaaS provider running on Kubernetes provides the infrastructure for deployed functions. In the AI Engine these functions represent the ML models accessible through the Intent Engine. Examples of these models will be provided in Section IV.
OpenFaaS provides a command line interface tool referred to as faas-cli. This tool allows straightforward control of key OpenFaaS operations for the creation and deployment of ML models onto the AI Engine. OpenFaaS was customised for the 5G-CLARITY project through an embedding of the Prometheus monitoring and Grafana visualisation tools. These tool sets are incorporated into the model creation process through the creation of templates for 5G-CLARITY AI Engine models. Models created with this template embed the previous tool functionalities. This template uses a python3 language and is adapted with a Prometheus monitoring library to expose internal model metrics to the telemetry subsystem of the 5G-CLARITY system (c.f. Fig. 1). This tool also initiates the building of models, pushing of models to the Docker registry and deployment of models onto the running AI Engine. Execution of these models is triggered through the Intent Engine, as will be seen through the use cases described in Section IV. The AI Engine supports models for the coordination and sequencing of complex network management and configuration tasks. In the event of a flag or identified conflict, log information is provided to the user detailing the events leading up to the issue. Starting with case (a), we depict a situation where the Intent Engine is able to directly match a user issued intent to a concrete API endpoint exposed by the service and slice provisioning subsystem. We note that while possible this will not be common in practice, because user intents will often translate into complex interactions with the service and slice provisioning subsystem that cannot be directly inferred by the intent matching engine. The alternative to handle complex user interactions is depicted in case (b), where the Intent Engine will match a high level intent to a specific ML model that will be instantiated in the AI engine to satisfy the intent. The ML model will encode the low level interactions required to implement the requested intent.
Cases (c) and (d) depict how instantitated ML models interact with the network, which is also by means of issuing intents. The intents issued by the ML models will however contain more information than user issued intents, in the form of additional parameters, such that the Intent Engine can properly match them to the corresponding southbound providers. ML models are expected to generate two types of intents. First, as depicted in case (c), data related intents are issued towards the data processing subsystem to subscribe to relevant telemetry including access network and user telemetry. Second, as depicted in case (d), an action related intent is issued towards the service and slice provisioning subsystem to enforce an action on the private 5G network. In Section IV, the generic workflows of Fig. 4 are applied to three different use cases.
Finally, it is worth highlighting that the entity triggering the intent in the cases depicted in Fig. 4 could be located within the private venue, or could be an external entity offering managed services, e.g. a mobile network operator (MNO) or system integrator.

IV. DEMONSTRATION ON SELECTED USE CASES
We present in this section three uses cases enabled by our intent driven platform that are relevant for private 5G network operators. The first use case, described in Section IV-A, demonstrates the provisioning of network slices using intents. The second use case, described in Section IV-B, illustrates the deployment of an ML model that supports high precision positioning services in indoor environments. The third use case, described in Section IV-C, illustrates the intent based deployment of an application function connected to the private 5G infrastructure.
All use cases are evaluated in terms of their required execution time, which we define as the time required from the moment the user inserts the intent into the intelligence stratum until the corresponding actions are enforced in the network.

A. INTENT BASED SLICE PROVISIONING 1) MOTIVATION
As discussed in [4], network slicing over private 5G networks can be used to support multiple services over a common infrastructure. For example, in a factory environment, different production lines can be connected to dedicated network slices to ensure isolation and provide a dedicated QoS. The 5G-CLARITY system supports infrastructure based network slices that are composed of the following elements: i. A compute chunk, defining the compute infrastructure that will host the VNFs allocated to that slice. The compute chunk specifies the compute, memory and storage resources allocated to that slice. VOLUME 11, 2023 ii. A radio chunk, specifying the 5GNR cells and WiFi and LiFi access points from which devices can access the provisioned slice. iii. A core network service, deploying the 5G Core VNFs, and configuring them with the appropriate PLMNID/ S-NSSAI identifiers associated to the slice, with the initial set of User Equipments (UEs) that are allowed to connect to the slice, as well as the QoS parameters allocated to that slice. iv. A radio service adding the PLMNID/S-NSSAI identifier and service set identifier (SSID) to the cells and APs selected in radio chunk. The radio service also specifies the radio resources (physical resource blocks (PRBs) or airtime) that are allocated to the slice.
A detailed description of the 5G-CLARITY approach to infrastructure slicing can be found in [4].

2) INTELLIGENCE STRATUM DESIGN
Despite the complexity involved in the slice provisioning process described in the previous subsection, our intent based platform enables private network operators to provision slices through a natural language interface. The key to our design is a set of ML models deployed in the AI Engine of the intelligence stratum (c.f. Section III), illustrated in Fig. 5. These models allow to translate a high level intent to the required low level configuration, including: i. The Slice Creation Workflow (SCW) model that encodes the multiple low level interactions with the Slice Manager function required to provision a network slice (c.f. Listings 1, 2 and 3). The SCW model offers a single endpoint that can be identified by the intent matching component of the Intent Engine (see Fig. 5), and is in charge of orchestrating the inputs provided by the other models. ii. The Radio Node Selection (RNS) model that is in charge of selecting the 5GNR cells or WiFi and LiFi access points from which the slice needs to be served. An ML-based radio node selection may consider current and predicted load demands around the area where the slice needs to be served. iii. The Compute Requirements (CR) model that is in charge of defining the computational requirements (CPU, memory and storage) allocated to the slice. An ML-based compute node selection may consider predictions on CPU utilization or energy saving constraints. iv. The Slice QoS (SQS) model that is in charge of defining the QoS Class identifier (QCI) and uplink (UL)/downlink (DL) Aggregate Maximum Bit Rate (AMBR) parameters to be applied to the devices connecting to the slice. An ML-based QoS selection may consider a Service Level Agreement (SLA) definition at slice level, e.g. as the authors proposed in [31].
Note that we focus on the architectural definition of the ML models needed to support an intent based slice provisioning, and leave a concrete implementation of these models for future work. Fig. 6 describes the detailed interactions between the Intent Engine, the SCW, RNS, CR and SQS modules in the AI Engine, and the Slice Manager function to enable intent based slice provisioning. The generated intents are shown in red in Fig. 6, and we note that intents are generated both by the human operator and by the ML models (case (c) in Fig. 4). Table 1 describes four types of slice related intents supported by our system. The different intent types differ in the type of provided parameters, which result in the involvement of different ML models in the slice provisioning process.

3) INTENT DEFINITION
Starting from the default intent type at the top of Table 1, we can see that no parameters other than the desired user list are provided. In this case, the user is not providing any useful context information that can be used by the RNS, CR and SQS models to optimize the slice provisioning process. Thus, these models provide default slice parameters. In the second intent type radio information is provided as context in the form of a desired geographical area where the slice needs to be provisioned, or the desired access technologies that should advertise the slice (e.g. 5G NR, Wi-Fi or Li-Fi). In this case, the RNS model uses the provided parameters to select the target cells and APs. Fig. 6 depicts the interactions generated by the RNS model. In the third type of intent in Table 1 compute related information is provided as a list of target network service identifiers (NSIds) that will make use of the deployed slice. 3 The CR module uses the list of NSIds to dimension the CPUs, memory and storage requirements of the slice, through the interactions depicted in Fig. 6. Finally, the fourth type of intent in Table 1 includes a parameter providing a high level quality indicator. The SQS model makes use of this parameter to derive the 5G Core QoS parameters to be used in the slice. The interactions triggered by the SQS model are depicted in Fig. 6.

B. INTENT BASED NLoS IDENTIFICATION 1) MOTIVATION
Accurate positioning is a key service to be delivered by private 5G networks, especially in indoor environments such as factories where there is no Global Navigation Satellite System (GNSS) coverage. To this end, 3GPP has specified (in Release 16) positioning extensions that include new Positioning Reference Signals (PRS) in the physical layer, as well as a Location Management Function (LMF) in the 5G Core. 3 NSIds refer to the identifiers of the network services onboarded on the NFV orchestrator of the service and slice provisioning subsystem. In use case 3 we discuss how these NSIds could be derived from high level user information.  that runs a localization algorithm to estimate the position of the UE [32]. In the case of time measurements, it is crucial for the LMF algorithms to discern if the measurement between the UE and a gNB has been performed under Line of Sight (LoS) conditions or not, as this heavily impacts the accuracy of the positioning measurement. Thus, in this section we describe a use case where the LMF can generate an intent towards the 5G-CLARITY intelligence stratum to verify if the communication link between a given UE and gNB pair is LoS or Non-LoS (NLoS).

2) INTELLIGENCE STRATUM DESIGN
A single ML model referred to as NLoS model instantiated in the AI Engine is sufficient to implement this use case.  Fig. 7 depicts the implementation scheme of our intent-based NLoS identification. The process starts when the LMF generates an intent towards the Intent Engine to validate if a certain gNB is in the LoS of a UE (step 1). The Intent Engine matches the received intent to an endpoint offered by the NLoS model (step 2), which has been previously registered as a south-bound provider of the Intent Engine. Subsequently, the NLoS model generates a new intent towards the Intent Engine asking for the Channel Impulse Response (CIR) data corresponding to the requested UE and gNB pair (step 3). The Intent Engine matches the received intent to an end-point offered by the data lake, which has also been registered as a south-bound provider of the Intent Engine, resulting in the delivery of the CIR data to the NLoS model (steps 4 and 5). Finally, the link condition is computed by the NLoS model, returned to the Intent Engine, which then forwards it to the LMF (steps 6 and 7). Table 2 describes the intent related to the NLoS identification. The intent body is any high level sentence containing any of the phrases link condition, NLoS, and LoS. The parameters are the UE and gNB identifiers for which the link condition needs to be returned. Finally, the description explains the steps of intent processing. In particular, the CIRs are firstly retrieved from the data lake. Next, they are fed into the DNN pretrained on the data from the environment. The DNN consists of 2 hidden layers with N neurons in each layer where N denotes the length of the discrete CIR. Such a DNN has been previously proposed in [33] and successfully employed in [34]. Lastly, the results are returned to the operator by denoting the link condition, i.e., LoS or NLoS, and their corresponding probabilities. For example, a response such as {Link condition: ''NLoS,'' Probability: 0.76} means that the link condition is NLoS with the probability of 0.76. The LMF will then use this information when computing the position estimate for the UE, e.g., by dropping the measurement corresponding to that specific link.

C. INTENT BASED NETWORK SERVICE PROVISIONING 1) MOTIVATION
Private 5G operators need to connect their enterprise services to the deployed 5G network slices automatically without a complex configuration workflow. To this end, enterprise services, which are virtualized and represented through a network service descriptor (NSD) that is onboarded to the NFVO, can be instantiated over the appropriate compute resources under requests. However, direct operation of the NFVO is still too cumbersome for a private network operator that is not skilled in 5G. Therefore, there is a need to enable intent based deployment of enterprise services over the compute resources available in the private 5G network, e.g. the edge cluster in Fig. 1.
In this section we describe an intent based NFV service deployment use case based on the 5G-CLARITY architecture, where OSM is used as NFVO [35].

2) INTELLIGENCE STRATUM DESIGN
Like in the design of the intent based slice provisioning use case, several ML models need to be instantiated in the AI engine to support this use case, namely: • The NFVi workflow (NFVi-w) model, which offers a single endpoint that can be matched by the Intent Engine upon receiving an intent including the words network service. In addition, this model receives in the intent parameters the context information required to resolve the exact NSD identifier that needs to be provisioned.
• The NS selection model is in charge of resolving the required NSD identifier from the context information provided in the intent. ML models may assist in the operation of the NS selection model by autonomously choosing application parameters, e.g. resolution in the case of video, as a function of the current state of the network.
• The VIM selection model that is in charge of selecting the exact compute resources, i.e. Virtualization Infrastructure Manager (VIM) registered to the NFVO where the network service needs to be instantiated.  Fig. 8 depicts the architecture of the intelligence stratum required to enable this use case, with the NFVi-w, the NS selection and the VIM selection models in the AI engine. Fig. 9 illustrates the sequence of interactions between the Intent Engine, the models in the AI Engine and OSM described above. These interactions are further detailed in next paragraph.

3) INTENT DEFINITION
In Table 3 we describe two types of Intents that can be supported by our platform, which differ in the context information provided in the parameters of the intent.
In the default type of intent, the provided parameters contain context information that is used by the NS selection model to select the appropriate NS identifier from all the NSDs that have been pre-onboarded in the NFVO. Fig. 9 depicts the detailed interactions triggered by the NS selection model. The second type of intent incorporates placement context, also passed as a parameter to the intent body. The VIM selection model processes the provided context, along with telemetry information available in the data processing subsystem, to select the VIM account where the selected network service should be provisioned. Fig. 9 also depicts the detailed interactions triggered by the VIM selection model.

D. DEMONSTRATION
We describe in this section a demonstration of our implemented use cases, and a benchmark that measures for each use case the intent execution time, defined as the time required from the moment the user inserts the intent into the intelligence stratum until the corresponding actions are enforced in the network. Fig. 10 contains three snapshots of the public demonstrations of each use case available in Youtube.    Table 4 reports the intent execution times for each use case. Next, we discuss each use case in detail.
An implementation and demonstration of our intent based slice provisioning is available in [37], where we can see the full slice provisioning process including the intent engine, the slice manager and the RAN controller. Fig. 10(a) depicts a snapshot of our demonstration where we can see how the slice provisioning intent is issued through a POSTMAN interface. To benchmark the intent execution time we repeat 10 slice provisioning experiments and compute an average time of approximately 3 minutes, which is a reasonable time considering the fact that provisioning a slice requires re-configuring 5G cells and APs as well as spanning new core network related VNFs. Regarding the NLoS identification use case, an implementation and demonstration is available in [38]. Fig. 10(b) provides a snapshot of the demonstrator where we can see an obstacle blocking the communication path between the UE and gNB. We can see in the demonstrator how upon triggering a request by the operator (through POSTMAN interface), the ''LoS'' decision on the link condition and its corresponding probability is returned. Next, when the direct link is blocked by a metal object, the returned decision switches to ''NLoS.'' Table 4 reports the average time from intent provisioning to NLoS detection to be of one second, which is reasonable given the fact that the model is trained offline and only needs to feed the CIR and return the decision on the link condition. Furthermore, the accuracy of the NLoS identifier model has been reported in [34] and [39] and is around 95%.
The NFV use case as demonstrated in an Intent based end-to-end NFVI-as-a-service deployment is captured in the snapshot shown in Fig. 10(c). This is associated to a smart tourism service, in which surveillance video from a 360 • camera mounted on a mobile robot is requested remotely using intents generated by a public safety officer's monitoring device. To implement this service a virtual media forwarding unit is provisioned at the edge in the museum, which forwards the robot camera feed to the appropriate user device. As shown in Table 4, the average time to instantiate a video service from when the intent is initiated to NS creation is 234 seconds (≈4 minutes). The layers of interactions between and within OSM, intent engine and the image size account for this duration. A video demonstration of this use case is available in [36].

V. CONCLUSION
There is a strong interest in designing systems that can simplify the interactions between humans and complex digital systems through the use of natural language based interfaces. Intent based networking has been devised as the architectural framework to achieve this simplification in the management of mobile networks, where advances in this regard are especially needed in the area of private 5G networks owned by verticals that often lack skilled 5G personnel.
In this paper, we have introduced the 5G-CLARITY intelligence stratum that offers an NLP interface to private 5G network operators. Our proposed intelligent stratum features an Intent Engine that receives as input intents in the form of English level sentences, and an AI engine that hosts ML models, which encode complex API workflows and provide the low-level context missing in the original intent definition.
We describe a prototype implementation of our intelligence stratum and demonstrate it with three private 5G network use cases, namely a slice provisioning use case, an indoor positioning use case, and a network service deployment use case. All use cases are benchmarked in terms of intent provisioning time.
As part of our future work, we plan to continue investigating how recent advances in NLP, e.g. based on the use of Large Language Models (LLMs) [27], can be leveraged to further simplify the operation of private 5G networks. For example, an LLM could learn to map a user intent directly to a complex sequence of API endpoints, thus simplifying the need for the manually handcrafted workflow models that are needed in our current system to support different use cases.
LORENA CHINCHILLA-ROMERO received the B.Sc. and M.Sc. degrees from the University of Granada (UGR), Granada, Spain, in 2018 and 2020, respectively. She is currently pursuing the Ph.D. degree with the WiMuNet Laboratory Research Group, Department of Signal Theory, Telematics and Communications, UGR. Her research interests include private 5G networks, radio resource management, and machine learning. ADRIANA FERNÁNDEZ-FERNÁNDEZ received the degree in telecommunications and electronic engineering and the Ph.D. degree in telematics engineering from Universitat Politècnica de Catalunya (UPC). She is a Senior Researcher with i2CAT Foundation, Spain. Before joining i2CAT, she was a Postdoctoral Researcher with the BAMPLA Research Group, UPC. She is the author/coauthor of over 20 papers in peer-reviewed international journals and conference proceedings. She has been awarded several scholarships from the Spanish Government through the Research Training Program (FPI). Her current research interests include management, orchestration, and network slicing in 5G networks, as well as on NFV and cloud-native technologies. Her research interests include communication network modeling and optimization, energy-aware routing, SDN, and traffic engineering. Researcher, investigating on the spectra-efficient long-haul optical transmission systems and low-cost short-range transmission systems. In July 2013, he joined the University of Bristol. His research focuses on machinelearning applications in dynamic optical networks and 5G beyond networks, programmable optical networks, and data center networks.