# [Intern] 27/06/2022 The main features of the FlexRIC SDK with a structure
###### tags: `BMW-Lab`, `Intern`

:::success
**Goal:** To understand the main features of the FlexRIC SDK with a structure.
:::

:::success
**References**
- [FlexRIC SDK](https://dl.acm.org/doi/abs/10.1145/3485983.3494870)
:::

## Background of FlexRIC.

FlexRIC is a SDK, consisting of a server library and an agent library with two optional extensions: controller-internal applications (iApps) and communication interfaces. The objective of the SDK is to facilitate the realization of specialized SD-RAN controllers to target specic use cases, while being simple to use. FlexRIC does not support extra features endogenously following the zero-overhead principle. In its simplest form, the SDK can be used to implement an SD-RAN controller using an E2-compatible protocol, as it is shown in Figure


The FlexRIC SDK consists of an agent and a server
library. The agent library provides integration of a base station to a controller, which is specialized to a particular use case using iApps. Server, library Virtualization, layer/iApps, Agent library, Specialized, Controller .

## Architecture of FlexRIC


The agent library provides the necessary support to connect to a controller, such as O-RAN RIC. It consists of a networking
interface, the E2AP abstraction, a message handler, and a generic RAN function API. The E2AP abstraction provides an intermediate
representation for the E2 protocol, relieving RAN functions from E2 protocol specicities . Further, the agent provides the generic RAN function API to implement RAN functions with custom SM-specic logic. This API denes callbacks for E2AP
messages, i.e., subscription requests (for new information subscription), subscription delete request (removal of subscriptions), and control messages (to trigger SM-specic actions), which need to be implemented by RAN functions. The SMs are tailored towards specic RAN sublayers (for statistics) or RAN control endpoints (for control) to easily integrate the agent library in disaggregated base stations, and expose a simplied API, facilitating the integration with various
base station implementations. The base station provides basic node information, such as the public land mobile network (PLMN), and registers RAN functions according to the underlying node’s capability: not all RAN layers are present in every node for disaggregated base stations, and FlexRIC natively supports such disaggregation through the selection of appropriate RAN functions. The base station uses the interface of pre-dened RAN functions to expose data and handle control messages, or it might dene additional RAN functions using the generic RAN function API. The agent library is not tied to any existing cellular user plane implementation or RAT and is therefore inherently vendor-neutral and RAT-neutral, making it a reusable component for multi-vendor and multi-RAT scenarios. Multi-Controller Support at the Agent Library. The agent library provides means to connect to multiple controllers. This becomes useful in a multi-service context, e.g., for “recursive” controllers that virtualize RAN control or base station hypervisors like Orion , which permits shared control and exposes information to multiple controllers while also providing isolation between them. The FlexRIC agent library assists the handling of multiple service
controllers through the management of additional controllers (setup, teardown, providing controller origin to RAN functions for
message handling), and a UE-to-controller association. The UE-to-controller association is used to indicate the UEs that are to be exposed to each controller. An active E2 subscription addresses all (or an indicated subset) of UEs. However, a given RAN
function does not know a priori which UEs are to be exposed to a particular controller. Therefore, when handling messages, the
agent is able to look up and reveal the UEs that belong to the corresponding controllers.
The agent library associates every UE to the controller, and provides no means for an automatic association of UEs to additional controllers, e.g., through 5G RRC slice identiers (S-NSSAI). Rather, this has to be triggered through a controller based on information through SMs, as the agent might not always be capable to determine an association. Consider the example of a split base station with CU and DU, and separate controllers that are concerned with the DU exposing a remote scheduling SM, as shown in figure When a new UE arrives and should be connected to the separate controller, its association depends on the selected PLMN of the UE, which is decoded in the CU. The agent of the DU therefore cannot infer such an association.