# Learning Roadmap - Common Part (Basic)

This is a study notes for understanding the basic knowledge of Near-RT RIC's background.

[toc]

# Part 1: Background Knowledge of 5G
:::success
- Goal :
- [x] To know the characteristic of 5G
- [x] To know the overall architecture of 5G
- [x] To know the difference between 4G and 5g
:::

:::info
- Outcome (Study Note) :
- Learn about background of 5G
- Learn about 5G characteristic
- Learn about how 5G works + its architecture
- Learn about the difference between 4G and 5G
:::

***

## I. Background
5G, as its name, is the fifth generation of celullar networks. Cellular networks has been rapidly evolving since its first launch many years ago. 5G delivers a **high speeds, low latency, more reliability**, and **improved flexibility** for wireless services better than previous cellular networks.


Based on the image, we can conclude that researchers moving forwards with using 5G because there is a **gradual increase** in the number of mobile user, advanced mobile cloud gaming, high-definitions vidoes, and even the usage of IoT devices, such as smart meters and energy monitoring systems.

## II. Key Enabling Technologies / Characteristics of 5G
**Massive MIMO**: refers to employing a very large number of antennas, further magnifying the benefits of MIMO.
> Multiple-Input Multiple-Output (MIMO) technology uses multiple antennas at both the transmitter and receiver ends to improve signal quality and boost data rates.

**Milimetre Wave (mmWave)**:5G has shorter wavelengths compared to traditional cellular frequencies, resulting in ==higher data capacity== but also susceptibility to signal attenuation from obstacles and weather.
> mmWave range between 30-300GHz

**Small Cells**: These are smaller, low-power cellular base stations strategically deployed in dense areas ==to enhance network coverage and capacity==, particularly for ==mmWave frequencies== which have limited range.

**Li-Fi**: Li-Fi, short for Light Fidelity, is a technology that uses visible and ultraviolet light for high-speed data communication. While not directly related to cellular networks, it offers a complementary high-bandwidth option for specific applications requiring short-range, secure connectivity.

**Edge Computing**: This involves processing data closer to the source, on smart devices or the network edge, rather than relying solely on centralized cloud servers. This ==reduces latency and improves responsiveness== for applications like IoT and real-time communication.

**Beamforming**: This technique ==focuses radio waves into narrow beams== in the direction of devices, improving signal strength and reducing interference, especially beneficial for mmWave communications due to their directional nature.

**Network Slicing**: 5G introduces the concept of network slicing, which allows network operators to ==create multiple virtual networks== within a single physical infrastructure. Each network slice can be customized to meet the specific requirements of different applications, industries, or user groups.

## III. Architecture
The architecture of the 5G network is based on three main components: the User Equipment (UE), the Radio Access Network (RAN), and the Core Network (CN).

**User Equipment**: The User Equipment (UE) is the device that connects to the 5G network. It can be a smartphone, tablet, laptop, or any other device that supports 5G connectivity. The UE communicates with the network through the Radio Access Network (RAN) and accesses the internet and other services provided by the Core Network (CN).

**Radio Access Network(RAN)**: The Radio Access Network (RAN) is responsible for providing wireless connectivity between the User Equipment (UE) and the Core Network (CN). The RAN includes the base stations, antennas, and other equipment that provide wireless coverage in a particular area. The 5G RAN is designed to operate in three frequency bands: low, mid, and high (mmWave).

**Core Network(CN)**: The Core Network (CN) is responsible for managing and directing the traffic between the User Equipment (UE) and the internet. It includes the servers, routers, switches, and other equipment that provide the necessary infrastructure for the 5G network. The 5G Core Network is designed to support multiple use cases, including enhanced mobile broadband, massive machine-type communications, and ultra-reliable low-latency communications.
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:50%;" src="https://hackmd.io/_uploads/r1AGsDpPT.png" />

## IV. Difference

---

# Part 2: Background Knowledge of O-RAN
:::success
- Goal :
- [x] To know the characteristic of O-RAN
- [x] To know the overall architecture of O-RAN
- [x] To know the difference between O-RAN and 5G
:::

:::info
- Outcome (Study Note) :
- Learn about background of RAN and O-RAN
- Learn about O-RAN characteristic
- Learn about how O-RAN works + its architecture
- Learn about the difference between 5G and O-RAN
:::

---

## RAN
### I. Background
A radio access network (RAN) is a major component of a wireless telecommunications system that connects individual devices to other parts of a network through **a radio link**. The RAN links user equipment, such as a cellphone, computer or any remotely controlled machine, over a fiber or wireless Backhaul connection. That link goes to the core network, which manages subscriber information, location and more.

The RAN, which is sometimes also called the access network, is **the radio element** of the cellular network. A cellular network is made up of land areas called cells. A cell is served by at least one radio transceiver, although the standard is typically three for cell sites.

### II. Architecture of RAN
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:75%;" src="https://hackmd.io/_uploads/HJ00zDRDp.png" />

RAN is essentially a network of base stations (think cell towers) that connect our device to the core network. These base stations house various components, each playing a crucial role:

**Antennas**: These are the ears and mouths of the RAN, transmitting and receiving radio signals.
**Remote Radio Heads (RRHs)**: Located at the cell tower, RRHs handle the signal processing and amplification.
**Baseband Units (BBUs)**: The brains of the operation, BBUs process the data and manage communication with the core network. They can be centralized or distributed, depending on the RAN type.

### III. Types of RAN
1. **Tradtional RAN**
**Concept**: ==Closed==, vendor-specific ecosystem with tightly coupled BBUs and RRHs from the same manufacturer.
**Benefits**: Mature and reliable technology with proven track record.
**Challenges**: Limited flexibility, higher costs due to vendor lock-in, and slower innovation.

2. **C-RAN (Cloud RAN)**
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:75%;" src="https://hackmd.io/_uploads/SyWQNw0D6.png" />
**Concept**: ==Centralized RAN architecture==, where baseband processing units (BBUs) are located far from remote radio heads (RRHs) at cell towers.
**Benefits**: ==Simplified network management==, reduced energy consumption, and potential for improved network performance.
**Challenges**: Requires high-bandwidth and low-latency fiber or microwave backhaul connections between BBUs and RRHs.

3. **O-RAN (Open RAN)**
**Concept**: An open ecosystem for cellular networks, using white box hardware and software from multiple vendors. ==Think Legos for base stations!==
**Benefits**: Increased flexibility, lower costs, and faster innovation due to vendor competition.
**Challenges**: Ensuring interoperability between components from different vendors and creating mature open-source software solutions.

| Feature | Traditional RAN | Cloud RAN | Open RAN |
| -------- | -------- | -------- | --- |
| Hardware | Vendor-specific | Specialized RRHs, COTS BBUs | White box, multi-vendor |
| Software | Vendor-specific | Proprietary | Open-source or commercial |
| Flexibility | Low | Moderate | High |
| Cost | High | Moderate | Potentially Lower |
| Innovation | Slower | Moderate | Faster |

---

## O-RAN
### I. Background
O-RAN, or Open Radio Access Network, is a network architecture that aims to provide a **more open** and **flexible** approach to building radio access networks for 4G and 5G cellular networks. O-RAN is designed to enable multi-vendor interoperability and reduce the cost of building and operating cellular networks.

### II. Characteristic
**Open Interfaces**: Standardized interfaces between RAN components from different vendors, fostering competition and innovation.
**White Box Hardware**: Replacing traditional vendor-specific hardware with commercially available, off-the-shelf (COTS) equipment, reducing costs and increasing flexibility.
**Cloud-Native Software**: Utilizing software designed for cloud environments, enabling flexible scalability and easier network management.
**Centralized Intelligence**: Shifting processing power from base stations to centralized units, simplifying network management and optimizing performance.
**Programmable RAN**: Allowing operators to tailor network functionality and adapt to specific needs through software changes.

### III. Architecture
**Service Management and Orchestration (SMO)**: The brain of the operation, controlling and managing the RAN and its components.

**Radio Unit (O-RU)**: Located at the cell tower, it handles radio signal transmission and reception. A logical node hosting Low-PHY layer and RF processing based on a lower layer functional split. This is similar to 3GPP’s “TRP” or “RRH” but more specific in including the Low-PHY layer (FFT/iFFT, PRACH extraction).

**Distributed Unit (O-DU)**: Performs baseband processing closer to the cell tower, reducing backhaul traffic. A logical node hosting RLC/MAC/High-PHY layers based on a lower layer functional split.

**O-CU-CP** (O-RAN Central Unit – Control Plane): a logical node hosting the RRC and the ==control plane== part of the PDCP protocol.

**O-CU-UP** (O-RAN Central Unit – User Plane): a logical node hosting the ==user plane== part of the PDCP protocol and the SDAP protocol.

**Non-Real-Time RIC** (RAN Intelligent Controller): Provides analytics and optimization for long-term network performance. A functionality within SMO that drives the content carried across the A1 interface.

**Near-Real-Time RIC**: An O-RAN Network Function (NF) that enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over E2 interface. It may include AI/ML (Artificial Intelligence / Machine Learning) workflow including model training, inference and updates.

**O-Cloud**: O-Cloud is a cloud computing platform comprising a collection of physical infrastructure nodes that meet O-RAN requirements to host the relevant O-RAN functions (such as Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU), the supporting software components (such as Operating System, Virtual Machine Monitor, Container Runtime, etc.) and the appropriate management and orchestration functions.

### IV. Difference
O-RAN is different from 5G in that ==5G is a wireless communication standard==, while ==O-RAN is an architecture== that can be used with 5G and other wireless communication standards. 5G defines the air interface and core network, while O-RAN defines the radio access network. **They are complementary players**, not competitors. O-RAN aims to make 5G networks more flexible, cost-effective, and innovative, enabling operators to better cater to diverse user needs and applications.

---

# Part 3: Background Knowledge of Near-RT RIC
:::success
- Goal :
- [x] To know the characteristic of Near-RT RIC
- [x] To know the overall architecture of Near-RT RIC
- [x] To know the definition of Near-RT RIC Platform and xApp
:::

:::info
- Outcome (Study Note) :
- Learn about background of Near-RT RIC and xApp
- Learn about Near-RT RIC characteristic
- Learn about Near-RT RIC architecture
- Learn about O-RAN.WG3.RICARCH-R003-v05.00
:::

---

## I. Definition
> RIC (or RAN Intelligent Controller) is the most important O-RAN Network Function.

**Near-RT RIC** is **a software** based near‐real‐time micro‐service‐based platform for hosting micro-service-based applications - the xApps - that run on the Near-RT RIC platform. **xApps are not part of the RIC platform** and developed in projects that are separate from the Near-RT RIC platform project. The Near-RT RIC platform is **providing xApps the infrastructure** for controlling a distributed collection of RAN base stations (eNB, gNB, CU, DU) in a region via the O-RAN alliance's E2 protocol ("southbound"). As part of this infrastructure it also provides "northbound" interfaces for operators: the A1 and O1 interfaces.

### Characteristic
Key characteristics of Near-RT RIC include:

1. **Real-time control**: Near-RT RIC can control RAN elements, including CUs and DUs, and perform network optimization actions within a timeframe of 10 milliseconds to one second.
2. **xApp and rApp support**: Near-RT RIC hosts xApps and rApps, which are applications that leverage the functionalities available in the RIC.
3. **AI/ML integration**: Near-RT RIC supports AI/ML workflows, including model training and updates, and policy-based guidance of applications/features.
4. **Network slicing and optimization**: Near-RT RIC plays a key role in network functions like network slicing, high-bandwidth, low-latency applications, and prioritized communications, helping mobile network operators improve network performance, increase business agility, and reduce costs.
5. **Flexible deployment**: Near-RT RIC can be deployed centrally or on the network edge, providing flexibility in its implementation.
6. **Platform functions**: Near-RT RIC provides a set of platform functions that are commonly used to support the specific functions hosted by xApps.
7. **APIs and interfaces**: Near-RT RIC offers APIs enabling xApps to directly use the information elements of programming languages (e.g., C, C++, Python, Go) and supports xApp subscription management based on operators' requirements.
8. **Collaboration with Non-RT RIC**: Near-RT RIC works in conjunction with Non-RT RIC, which manages events and resources with a response time of one second or more. Together, they provide a comprehensive solution for RAN management and optimization.

## II. Architecture

Above is the picture of Near-RT RIC Internal Architecture. Here's a list of each component's function:
**Database and Shared Data Layer**: enables the ==reading and writing== of RAN/UE information. Stores UE-related data in the UE-NIB (UE-Network Information Base) database and radio access network-related information in the R-NIB (Radio-Network Information Base) database.

**Conflict Mitigation**: ==resolves== potentially ==overlapping or conflicting requests== from multiple xApps, ensuring smooth and coordinated operations.

**xApp Subscription Management**: ==merges subscriptions== from different xApps and provides unified data distribution to xApps.

**Security**: ==provides a robust security scheme for the xApps==, safeguarding the integrity and confidentiality of data and operations.

**Messaging Infrastructure**: ==enables message interaction== among Near-RT RIC internal functions, facilitating communication between different components.

**API Enablement**: provides support for registration, discovery and consumption of Near-RT RIC APIs within the Near-RT RIC scope.

**Interface Termination**: terminates interfaces such as E2, A1, Y1, and O1 from respective nodes and layers.
* E2 termination, which terminates the E2 interface from an E2 Node;
* A1 termination, which terminates the A1 interface from the non-RT RIC;
* O1 termination, which terminates the O1 interface from Service Management & Orchestration layer;
* Y1 termination, which terminates the Y1 interface from Y1 Consumers

**xApp Repository**: ==manages== candidate xApps for A1 Termination, facilitating the delivery of A1 policies based on ==policy types and operator policies==. It also maintains and aligns supported policy types with registered xApps and operator policies, while executing access control for requested A1-EI types according to operator policies.

**AI/ML Support**: enables the Near-RT RIC platform with data pipelining, model management, training and inference, which constitute ==complete AI/ML workflow support== for xApps to implement AI/ML algorithms

## III. API in Near-RT RIC
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:75%;" src="https://hackmd.io/_uploads/r1uyGF-_6.png" />
The Near-RT RIC APIs are a collection of well-defined interfaces providing Near-RT RIC platform and xApp services.

:::info
:bulb: **What Near-RT RIC APIs Provides for xApp**

- [A1 related APIs](https://): APIs to access A1 related services;
- [E2 related APIs](https://): APIs to access E2 related services;
- [Management APIs](https://): APIs to access management related services;
- [SDL APIs](https://): APIs to access Shared Data Layer related services;
- [Enablement APIs](https://): APIs to access enablement services.
:::

### Near-RT RIC API Approach
The Near-RT RIC API Approach defines signaling and data transport protocols for Near-RT RIC APIs. The APIs enable xApps to directly use the information elements of programming languages and support xApp subscription management based on operators' requirements. There is 2 approaches that can be implemented: Network API and SDK approach.

### Network API approach
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:50%;" src="https://hackmd.io/_uploads/ryAdoVB_T.png" />
**Concept**: Exposing Near-RT RIC functionalities through a well-defined set of network-accessible APIs, enabling remote interaction from xApps and other entities.

**Key Advantages**:
* Promotes flexibility and remote access
* Facilitates multi-vendor integration
* Supports cloud-native deployments
* Enables easier updates and maintenance

**Potential Consideration**:
* Overhead of network communication
* Security implications
* Complexity of API management

### SDK approach
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:50%;" src="https://hackmd.io/_uploads/r1VdjVrda.png" />
**Concept**: roviding a software development kit (SDK) that includes libraries and tools for xApps to directly interact with Near-RT RIC functions within a local environment.

**Key Advantages**:
* Potential for higher performance and lower latency
* Finer-grained control over RIC resources
* Tighter integration with the platform

**Potential Consideration**:
* Requires xApps to be deployed within the same environment as the Near-RT RIC
* May limit flexibility and vendor portability

### Another Approach
Network API and SDK approach are not mutually exclusive, therefore there are two other options that can be used to Near-RT RIC.

An xApp designed to support the Network API approach may be implemented using **either** an internal SDK library that provides the Network API interface or a **direct implementation** the Network API interface.
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:50%;" src="https://hackmd.io/_uploads/rkGtgrHu6.png" />

A Near-RT RIC Platform may be designed to **support both** the Network API approach and the SDK approach and so xApps implemented using either approach may access platform services.
<img style="display:block;margin:20px auto;padding:1px;border:1px #eee;width:50%;" src="https://hackmd.io/_uploads/ryaqxHr_T.png" />

---

# Part 4: Understand the Near-RT RIC OSC
:::success
- Goal :
- [ ] Install the Near-RT RIC Platform
- [ ] Install xApp using DMS tool
- [x] Mapping Near-RT RIC between specification and OSC
- [x] Give Each Components a Introduction
- [x] Be familiar with the platform operation
- Useful Links :
- [Gerrit](https://gerrit.o-ran-sc.org/r/admin/repos)
:::

:::info
- Outcome (Study Note) :
- Successfully installed the Near-RT RIC Platform
- Successfully installed xApp using DMS Tool
- Successfully mapping specification and OSC of Near-RT RIC
- Learn about each components in Near-RT RIC
:::

---

## I. Near-RT RIC Platform
The Near-RT RIC Platform operates as a software-based, near-real-time microservice platform, offering xApps the necessary infrastructure for managing a distributed array of RAN base stations (eNB, gNB, CU, DU) through the E2 protocol (southbound interface). Additionally, it serves as a mediator for the ==E2 interface== between xApps and RAN elements, as well as for the ==A1 and O1 interfaces== between xApps and the operator (northbound).

## II. Components
**A1 Mediator**: The A1 Mediator facilitates communication and interaction between xApps and the operator through the A1 interface. It ensures a smooth flow of policy-related information and updates.

**Demo1**: Demo1 is a demonstration xApp maintained by the RICP project. It serves as an illustrative example showcasing the capabilities and functionalities of xApps within the RIC environment.

**E2 Manager (E2M)**: The E2 Manager oversees and manages the E2 interface, facilitating communication between xApps and RAN elements (eNB, gNB, CU, DU). It plays a crucial role in maintaining connectivity and data exchange.

**E2 Terminator (E2T)**: The E2 Terminator manages the termination of the E2 interface from an E2 Node. It ensures proper communication cessation between the Near-RT RIC and external E2 elements.

**Influx-DB Wrapper**: The Influx-DB Wrapper acts as an intermediary layer facilitating communication between the Near-RT RIC platform and InfluxDB. It enables the storage and retrieval of time-series data, providing a streamlined interface for managing data within the platform.

**Logging (not tracing)**: Logging is responsible for capturing, recording, and storing system events, messages, or actions. It provides a valuable resource for monitoring, debugging, and evaluating the system's performance.

**O1 Mediator**: The O1 Mediator serves as a mediator for the O1 interface, facilitating communication and coordination between xApps and the Service Management & Orchestration layer. It plays a crucial role in ensuring effective data exchange and interoperability.

**RIC Alarm System**: The RIC Alarm System is designed to detect and notify relevant parties about system alarms or irregularities. It plays a critical role in maintaining system health and reliability.

**RIC Message Router (RMR)**: RIC Message Router acts as a core component for routing messages within the RIC ecosystem. It ensures efficient and reliable communication between different components.

**RNIB (Radio-Network Information Base)**: RNIB serves as a database for storing and managing radio access network-related information. It holds data crucial for the effective operation of the RIC platform.

**Routing Manager**: The Routing Manager is responsible for managing the routing of messages and data within the RIC environment. It ensures that information is directed to the appropriate destinations.

**Subscription Manager**: The Subscription Manager is responsible for managing and coordinating subscriptions from different xApps. It ensures that data subscriptions are merged efficiently, and unified data distribution is provided to xApps, promoting synchronized communication and information flow.

**xApp Framework for CXX (xapp-frame-cpp)**: xApp Frameworks provide the foundational structure and tools for rapid development of RIC applications using C or C++.

**xApp Framework for Go (xapp-frame)**: xApp Frameworks provide the foundational structure and tools for rapid development of RIC applications using Golang.

**xApp Framework for Python (xapp-frame-py)**: xApp Frameworks provide the foundational structure and tools for rapid development of RIC applications using Python.

**xApp Framework for Rust (xapp-frame-rust)**: xApp Frameworks provide the foundational structure and tools for rapid development of RIC applications using Rust.

## III. Platform Repositories
The RICP (near-RT RIC platform) includes the following component repositories. The development of these components is managed via the RICP project.

Repository|Desciption|
|---|---|
|com/log|A thread-safe logging C API library with Mapped Diagnostics Context (MDC) support.|
|com/golog|Golang implementation of the common logging library |
|com/pylog|Python implementation of the common logging library|
|ric-plt/a1|Terminating the northbound A1 interface. It is translating information received over A1 it into conrete actions that xApps must take to adpat their behavior accordingly and it sends back feedback on the implementation status of such actions.|
|ric-plt/appmgr|Provides a flexible and secure way for deploying and managing various RIC xApp applications in a Kubernetes environment.|
|ric-plt/dbaas|Adaptation of the single-instance Redis database|
|ric-plt/e2|The E2 termination component that actually establishes E2 SCTP connections (as requested by the E2 manager) and routes messages received/sent over E2 to/from RMR.|
|ric-plt/e2mgr|The E2 manager implementation. The E2 manager controls E2 connection establishment and provides REST APIs to manage these connections.|
|ric-plt/lib/rmr|RIC message routing - A library originally based on NNG (nano-messaging nxt generation) for low latency message routing. Starting from Bronze (Feb-2020) we replaced NNG with plain usage of TCP in that library (see RIC-49).|
|ric-plt/nodeb-rnib|R-NIB APIs/libraries to store and retrieve RAN configuration data, like a list of cells per gNB.|
|ric-plt/rtmgr|Routing Manager (ric-plt/rtmgr) is a basic RIC platform service, responsible for generating and distributing routing policies to xApps.|
|ric-plt/sdl|SDL (Shared data layer) data access libraris for Redis including Redis server-side modules allowing multi-key atomic operations and publish channels.|
|ric-plt/sdlgo|same as ric-plt/sdl, but for the Go language|
|ric-plt/sdlpy|same as ric-plt/sdl, but for python|
|ric-plt/submgr|Near-realtime RIC Platform Subscription Manager|
|ric-plt/jaegeradapter|This repository includes files needed for starting the Jaeger Agent in a side-car container, and also files needed for starting Jaeger all-in-one of full collector containers.|
|ric-plt/vespamgr|The VESPA manager uses the VES Agent (https://github.com/nokia/ONAP-VESPA) to adapt near-RT RIC internal statistics collection using Prometheus (xApps and platform containers) to ONAP's VES (VNF event streaming).|
|ric-plt/xapp-frame|Artifacts for the (near realtime) RIC xapp framework, including common libraries, etc|
|ric-plt/asn1-documents|ASN.1 definitions and related documents that are needed by other components|
|ric-plt/ric-test|This repo includes test cases that span the full RIC platform, i.e., that cannot run against a single RIC component.|
|ric-plt/ric-dep|Code and configuration files that are needed for deploying a near-RT RIC platform instance|
|ric-plt/o1|o1 mediator|
|ric-plt/xapp-frame-py|The near-RT RIC python xapp framework|
|ric-plt/xapp-frame-cpp|The near-RT RIC C++ xapp framework|
|ric-plt/alarm-go|The near-RT RIC alarm adapter and Go library|
|ric-plt/alarm-cpp|The near-RT RIC alarm library for C++|
|ric-plt/libe2app|The near-RT RIC E2AP library|
|ric-plt/ricctl|The CLI (Command line interface) for the near-RT RIC platform|
|ric-plt/ricdms|The DMS (Deployment management services) implementation for RIC xApps|
|ric-plt/stslgo|The STSL (shared metrics layer) libraries provide access to the time series databases. The interface is optimized for time-series database interfaces. Initially it supports InfluxDB. This repo is for the go version of it.|
|ric-plt/xapp-frame-rust|The near-RT RIC Rust xapp framework|

## IV. Installation Result
### Near-RT RIC Platform
:::success
Successfully installed!
:::
[User Guide to Install](https://hackmd.io/@2xIzdkQiS9K3Pfrv6tVEtA/G-release_Near-RT-RIC_Install)
| | **version** | **command** |
| -------- | -------- | -------- |
| Helm | 3.5.4 | helm version |
| Kubernetes | 1.16.0 | kubectl version |
| Docker | 24.0.5 | docker version |

### xApp