Skip to main content

xApp Lifecycle

The xApp lifecycle follows a 5-step approach as illustrated in Figure 1.

alt text

In a nutshell, we initialize the xApp connecting it to the RIC and then we receive the indication messages coming from the RAN function in the E2 Node. Messages are processed to extract the desired metrics. As a third step, we design the xApp logic based on our use case. A typical example is forecasting the network's Quality of Service (QoS) and using this insights to later apply control actions on the RAN, such as slicing or handover. Finally, we gracefully terminate the xApp when all jobs are finished. Let's break this down further.

Figure 2 presents in detail the sequence diagram with all the message exchanges between the E2 Node, FlexRIC and xApp during the complete 5-step lifecycle of the xApp.

alt text

Before starting the xApp, the FlexRIC and E2 Nodes are already initialized and running, ready to accept an xApp. Now, let's dive into each step of the xApp development.

Init​

The first step in every xApp is to initialize it. This includes the initialization of the arguments parsed from folder or file and subsequently the setup of the E42 interface towards the FlexRIC. After that, the xApp requests and reads the current E2 state. This is an array with the available E2 Nodes and RAN functions of each one. Having that we can choose which elements we want to utilize based on the target use case.

Indication​

In this step, we design the way we want to handle indication messages coming from the chosen elements. First we need to write a custom indication callback function that will do exactly this. It will handle incoming indication messages parsing the desired metrics and do some actions, such as storing them or calculating new metrics e.g. latency. To receive the indication messages, it is important to subscribe to the desired E2 Node and RAN function by employing the appropriate service model (SM). To do this, we subscribe providing:

  1. the ID of one or multiple E2 Nodes
  2. the ID of the service model
  3. the chosen time interval between the received indication messages (e.g. 5 ms)
  4. the custom indication callback function for handling indication messages

Logic​

This is the step of creativity. Here we design the core logic of the xApp to tackle a specific use case. At this point, we have already gathered and handled the indication messages. Thus, it is the ideal time to analyze them, extracting meaning, insights and making forecasting for future values. Here is a list with possible xApp data analysis techniques:

  • Exploratory Data Analysis (EDA)
  • Pre-processing & Feature Extraction
  • Forecasting with Supervised/Unsupervised Learning methods
  • Reinforcement Learning
  • Data set creation & augmentation
  • Model training & Online/Continuous Learning
  • Model Evaluation & Tuning

This is also the place to define use case goals such as QoS Guarantees. Based on these goals and on the data analysis and network observability, we can take certain decision on what control actions we should apply to the RAN in order to ensure the use case guarantees bringing the network closer to the desired state. Here is a list with possible xApp use cases:

  • Quality of Service (QoS) Guarantees
    • e.g. Flow Bit Rate, Priority Level and Packet Delay Budget
  • Quality of Experience (QoE) Guarantees
    • Mean Opinion Score (MOS), Initial Buffering, Stalling Events, etc
  • UE level Guarantees
    • Per UE: UL/DL Throughput, Packet Delay, Packet Loss Rate, etc
  • Slice SLA Assurance
    • Per Slice: Number of UEs, PDU sessions, DL/UL throughput, Packet Delay, Packet Loss Rate, Jitter, Priority
  • Load Balancing Guarantees
    • Current/Mean/Peak PRB utilization per Cell/Slice

Control​

Here we apply the control actions based on the decisions taken on the previous step. To do this, we utilize the subscribed service models and send one or more control actions to the RAN function based on our use case. A list of possible control actions is this:

  • Slicing reconfiguration
  • Handover
  • Migration
  • Radio Resource Management (RRM)
  • Power Control
  • Beamforming

Exit​

Finally, after finishing its job, the xApp should gracefully terminate by unsubscribing from all the service models and closing the E42 interface.