# Understand Odin (Observation Distribution Intelligent Network) structure
###### tags: `odin`
> :exclamation: Waiting for confirmation from O-RAN standards
> ## Key notes
> * Network abstraction
> * Raven registry and SM discorvery for all RAN functions
> * Conflict resolution/mitigation
> * Access control
> * rApp on-boarding and interface
> * Dashboard
> * Built-in CRD implementing available policies
> ## Raven functions
> * Translation from odin policy to the flexric > control/insert/policy
> * Implement A1 and E42 interface
> * A set of supported CRDs
> Questions:
> Newest release talks about A1 between xApp ? and Near-RT RIC. How are we using A1 here which is an interface between Non and Near ?
> Is the dynamic xApp here is the part of A1 interface ?
> If the gRPC only conneted to the Near-RT RIC, Are we able to send HTTP request from Non to xApp then xApp to gRPC
> But in the A1 interface: AP documents, They used consumer and provider in both Non and Near => Can't not send HTTP to xApp and gRPC. One way to make this a seperate way.
> Why xApp have to use both E2 and A1 interface connect to Near-RT RIC
## Why do we need Odin and not follow O-RAN standard
* O-RAN limits on defining the time, policy.
* Cannot implement complited handles
* Dificult in create X-app O-RAN:
* Decouple -> complicated logic implementation case
* => better to couple with the RAN function layer and layers
* Cost: expensive
=> The standard is not mature enough for us to go beyond. => remove A1 ?
## What is SDK
SDK is the a set of tools for third-party developers to use in producing applications using a particular framework or platform
* How do you know which part is SDK aiming for ?
Procgress bar on creating a RAVENs
This Ravens is for RAVENs but for special case it could work with dynamic Xapp
## End-to-End system of Odin in the whole ecosystem
Above need to fix
* ODIN act as an orchestrator in distribute dynamic xAPP (RAVEN) where it can be DELETE, UPDATE or CREATE new RAVEN with different policy type.
* From top to bottom, rApp with sending request to ODIN in requesting non-RT information using r1 interface with specific policy properties => RAVEN will be created in response to the use cases from above by enforcing the requested policy => RAN from the bottom will support RAVEN with information based on the given data structure that they were implemeted in RAVEN.
In more detail
* RAVEN's holding the polici properties and the logical function in updating the RAN state
* Each RAVEN can be connected to mutiple RAN ? => Holding mutiple RAN STATE.
* **Policy state is RAN STATE** which is used as a target for RAVEN if global == Policy state
### Questions:
* Can RAVEN conneceted to mutiple RANVEN and vice-versa.
* What is the goal of RAN STATE => What happen if the RAN STATE is success
* Check if my understanding about End to End is correct
* What is OLM role ?
## Non-RT RIC vs ODIN (Observation Distribution Intelligent Network)
### Non-RT RIC
* This is based on [O-RAN.WG2.Non-RT-RIC-ARCH-TS-v02.01](https://orandownloadsweb.azurewebsites.net/specifications)
#### 1. Definition
* Non-RT RIC is the **functional internal** to the SMO (Service Management and Orchestration). Basically Non-RT RIC is SMO framrwork functionalities which
* Support RAN and optimize
* Alternate A1 interface API and services to the Near-RT RICs
* Access other SMO framwork functionalities => carried across the O1 and o2 interface.
#### 2. Non-RT RIC architecture
* The above architecture comprised of:
* Non-RT RIC framework
* Logically terminates of A1 interface to the Near_RT RIC
* Exposes set of R1 services
* Non-RT RIC Applications (rApps) - **LEVERAGE** funttionalities in the Non-RT RIC framework/ SMO framework IN providing value added services related to RAN operation and optimization.
> ! Decomposition of logical function is not mandatory => it is up to vendor's implementation.
In this document , we only focus on Non-RT RIC framework and the interaction between R1 and A1 to Non-RT RIC.
#### 3. R1 (Brief description)
##### 3.1 Services
- Capabilities related to each other
- Service producer to service consumer(s) for consumption.
- Produce through serice endpoints (APIs )
- Being a service producer and/or a service consumer is a role of an rApp and SMO/Non-RT RIC framework.
=> We only care about **1 R1 service** which is specificlly on A1-related services, which provide access to functionality related to A1.
##### 3.2 A1 related services
This A1 related services were **provided by
SMO/Non-RT RIC framework** which
* Discovery of supported A1 policy types
* Creating, Updating, querying and deleting A1 policies
* Querying enforcement status of A1 policies
* Subscription to event notifications related to A1 policies.
#### 4. Non-RT RIC function definitions
##### 4.1 General descripton
The above R1 services were provieded **by a collection of logical functions**
> ! We are focusing on R1 termination, A1-related functions and A1 termination
> * A1-related functions: These functions produce A1 related services.
> * A1 termination: It enables the Non-RT RIC framework and the Near-RT RIC to exchange messages
over the A1 interface
> * R1 termination: It enables the Non-RT RIC framework and rApps to exchange messages to access the
R1 services via the R1 interface.
### ODIN (Open distributed Inteligent Network)
* The above figures show how a **dynamic xApp** created
* 1. User submitted a request via CR
* 2. ODIN(Non-RT RIC) received the request and created the new Athena Element CR
* 3. Send the Athena element controler to Athena element controller for her to deployment
* 4. Life cycle and status will be updated from bottom to the start.
- Athena controls the pods and Configurations life cycle
- Odin controls the elements life cycle
=> Pods life cycle inside Element life cycles
> ! What is element: Athena's element is configuring function to run the container.
> Read the repository Athena for more info
* What is the dynamic xApp:
* "An xApp with limited lifecycle that is created at a certain time to perform a task for a certain period of time exits as soon as it finishes its task."
* What's the CR looks like ?
```
name: test-xapp
deadline: 1m -> Conditionals deadlines
model: mosaic5g-models |
deployment-mode: dynamic-test | => similar to network
annotations, labels, etc. | (Which network we're mentioning)
```
>! Network here is to define the networks resources and pods in Kubernettes based on user preferences. Read the repository Athena for more info
* What is Raven : a dynamic XApp + Policy
* The above figures shows how a RAVEN is created
* 1. Requested CR send
* 2. Odin recieved the requested and tell OLM to create the CR and the pods
* 3. Eventhough that Athena have a power to create pods, there will be conflict to OLM pods That is why ODIN creates new Athena element CR but different from the CR in OLM to avoid conflict
* 5. Send the CR to Athena to watch the CR and pods. If changes happed, Athena send signal to ODIN to do all the changes
> ! Athena elemenet controller watches and use ODIN as the messenger to control OLM CRD.
> In the above figures, where is A1 interface indicate? A1 inteface is below Deployment box
> Some changes from the Athena
> - Implement mutiple backends for Athena Element CRDs
> - Implement mutiple managment levels at Athena
* How Raven being discovered
* Query list of CRDs => if match get the matched CRDs
* R1 CRDs. ODIN handles R1 to A1 because based on the figure where Kubernettes is the Non-RT RIC framework ?
## Different structure with O-RAN and BubleRAN
Basic side-by-side comparision O-RAN SMO and Operator Plane
### Questions:
1. Differences between Athena(Terminal Operator) vs Athena(Base Network Operator)
2. Advantage of using the right-hand side infrastructure
### What is this
* Left-hand-side: O-RAN SMO includes Non-RT RIC and OAM (Athena) - Basic athena including Athena + control plane + Athena manager.
* Right-hand side: Concept of Operator Plane developed for Trirematics **independants** of the **O-RAN specification** with
* 3 levels:
* lv0: K8s, 3GPP, Open RAN, etc. objects and concepts into declarative objects that are exposed via the K8s CRDs to the higher levels => Do fundamental operators => expose operations as a object => Do something with the objects (Athena decides) => No gRPC because it cannot talks in objects
* lv1: one transforms and transcends the **basic objects** to logical entities such as a Network Slice, a Network Terminal, etc. by consuming the Lv0 CRs => This is network abstraction creating packages flow => merge and abtract those logic
* lv2: take **perhaps** E2E actions by using the lower level primitives such as Network, Element, Terminal, Slice, etc. (Scheduling and implementing usecase) => close human logic like how it connect to the networks.
## Operator framework
## How to connect to Slice SLA
## 0. What is Operator framwork
Open source toolkit to manage Kubernetes native applications => Operators => In a automated and scalable way.
> NOTE: This based on the following tutorial
> [link](https://sdk.operatorframework.io/docs/building-operators/golang/tutorial/#create-a-new-project)
## 1. Create a new project sample
```=bash
# Create a folder
# Init create a project
operator-sdk init --domain example.com --repo gitlab.eurecom.fr/trirematics/odin
```
* ```--domain```: Prefix of the API group of your CRD => group portions of Kubernetes API groups.
* What can it do ? Generates a go.mod file to be used with GO modules
- ```repo=<path>``` required to create a project outside of $GOPATH/src.
## 2. Manager
Main program for the operator is ```main.go```
```=go
mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
Scheme: scheme,
MetricsBindAddress: metricsAddr,
Port: 9443,
HealthProbeBindAddress: probeAddr,
LeaderElection: enableLeaderElection,
LeaderElectionID: "27ec5fdb.trirematics.io",
Namespace: "odin",
})
```
Using this will run and initialize ```Manager```. More [detail](https://book.kubebuilder.io/cronjob-tutorial/empty-main.html) on what is manager.
## 3. Create API and controller for your API and CDR
```=bash
operator-sdk create api --group odin --version v1 --kind SliceSLAPolicy --resource --controller
```
This will create new APIs in ```api/v1/memcached_types.go``` and the controller at ```controllers/memcached_controller.go```
### 3.1 More in-dept about Kubernetes APIs
* Group-version-kind-resources
Each group-VERSION have one or more APIs types
Kind is a GROUP with differents version.
Resources is simply A USE OF KIND in the API.
> Important stuff to take into account
> ```
> # The name space for odin is odin-system
> # This get the information of the controller
> kubectl get -n odin-system odin-controller-manager-557b677d95-hqgjd -o yaml
> # To see the crd of odin
> # kubectl get crds | grep odin
> # Get more info
> # kubectl get crds sliceslapolicies.odin.trirematics.io -o yaml
> ```
3.2 What is pods in kubernettes
- A smallest deployable units of computing that you can create and manage in Kubernetes.
3.3 How to get APIs from the kubernetes\
1. Open local network
```
kubectl proxy
```
2. Get the crd
```
kubectl get crd
```
3. Get the resources we want to get
```
curl http://localhost:8001/apis/odin.trirematics.io/v1/sliceslapolicies
```
## 4. T9s machine
Create docker to mimic ayo machine
```=bash
docker network create --driver bridge --gateway 10.96.0.1 --subnet 10.96.0.0/16 t9s
```
Create a new cofiguration file
```
ls ~/.kube/config
# have server in https://10.96.0.1:6443
ls ~/.kube/kind.config
# have local server in localhost
```
## 5. Use cases of Non-RT RIC and A1 interface. (Manual script)
### 5.1 Traffic steering – Policy
* Purpose:
* Drive traffic management in RAN in accordance with defined intents, policies and configuration
* Pre-requisites:
* SMO has establised the data collection and sharing
* Component includes:
* Non-RT RIC
* Near-RT ROC
* E2 Nodes: control planes and user plane functions
* SMO/collection and controls: termination point for O1 interface.
* Procedure
* Thoughts and questions:
* This was
## Discussion on what we have last week
* We define what is local and global vs inbound and outbound
Questions:
1. Again the definitions on inbound and outbound.
2. Example and who have implements Prometheuou
3. We are talking about database tools => Do we want to replace O1 with prometheuso
4. Can Kubernettes observe RAN => Do we need to look at onos for more info (onos-config) or Alireza have look through it.
* Better performance from prometheus.
* Khoa create an xApp to monitor, subcribe to all of them ("Push base") => format the data in the languages of prometheus to understand => Push it into a single database.
* Single data source that have the information
* Control loop of RAN for 20 seconds
About the benefit using single dataset:
* Label dataset - non strutured-data = Bunch of numbers
* Example: 5 = number of UE which have a lot of labels attached to it
* Time, Ran
* Based on those label, we can query very fast ? How can we get this info
* Example: Calculate the moving target. ( Prometheus ?)
* A lot of machine learning tools, We can use machine learning tools like prometheus??
* If the device is Non-RT RIC => Prometheus we not going to lost any features => Go much faster
* Some tools can guest the patern of the dataset
* Now we go to A1-P first. 2 statements problems => if we put this in go => reject the 2 statments because its a invalid json.
```
<!-- We can exaplain this in xml -->
<statement>
<Hello/>
</statement>
<statement>
<World/>
</statement>
<!-- Completely fine with xml -->
```
* Back to policy: a configuration for xApp
* For example: Trafic steering => xapp on trafic steering => need to have input
* A1 gives your xApp input to follows and send the control command
* => if we give xApp read the input from file (doesn't matter if the changes come from configure file or the A1.
* Back to the developement of XApp => Use SDK to create xApp in go or pythong etc ..
* Add more functions => Use linux file system to detects changes => Read one configuration file => Listen the changes of that configuration file (iNotify or fNotify)
* This xApp can get the notify without having the non-RT RIC.
* Another example we could create a xApp on GPU (CUDA library to the xApp as well). This plugin could be languages specific. => Develop the an xApp with specific languages with supported plugins for that languages => Good for building templates => auto add new plugins
* This will help us avoid Odin that coud support us certain policies.
* This could notify changes if we change that xApp
* Flex-ric self sufficient with out trying connect to non-RT RIC
* example: Changing the ML jobs => Give the configure files
* What Non-RT RIC add to the pictures (To global views ) so flexRIc itself should handle alot of cases. Its the xApp logic that determind how much its need not the flexRIC - trying to get fast ASAP. so the Non-RT RIC is associate to xApp not to RICs. => Time is irrelivant , is ilogic
* Let's look at EI (Enrichement information), There are some information that are not from the RAN. => Near-RT RIC will ask Odin to provide me more information.
* Example: IMSI - international mobile subscriber identity is not avalible in the RAN. We have to get it from the CN. => What Odin will do is to not allon Near-RT RIC to have this information directly but we give this to Odin.
* We have similar framework of FlexRIC call FlexCN => Merge to the Non-RT RIC => rApp changes to another thing.
* Why is important ? => Need to explain this more
* Odin will be notify and change the UPF.
* Since we have single database => share data from that database to xApp instead using Enrichment information => Its define an access policy => Define which xApp is defined to which policy. => We give a subset information to xApp not Odin => to protect the rest information or enough information to access from other UE.
* For us, everyone will use that single datasource => single bottleneck.
* xApp wants to do real-time data => They should get the dataset them-self => directly from E2. (This also depends on the plugin of the database) There are 2 different use cases:
* You dont need fresh data => access to histogram data ?
* Each xApp can define its own dataset.
=> Looking at the use cases, what are the missing pieces we can find => we can trick A1-P using prometheus as a tools as an API.
* RANVEN - a special cases => They use CRD not configuration files. (What is the configuration files we are looking for) => We are going xApp SDK for golang (new plugins - for RANVENS) to develop xAPP in go.
* In odin, xApp managment => xApp repository functions in flexRIC => we could implements xApp repository functions or in general, RAN app. In that case, It doesn't care about policy or not policy => we could define meta data for each xApp that show which plugins it support then Odin could query those and give the user this 10 xApp which are doing this.
* Because this will make odin independent from Xapp => This will give us the control of xApp. if we not going to develop A1. => Role will be change and lots of thing will be handle by xApp
* There are 2 cases:
* Odin have installed the xApp => you have described to Odin what xApp you have. or todo what => Create a container and the task its done.
* How are we going to detect ? label the xApp. Exampl: we have a market place to do the xApp (5 xApp that do different things) => choose and Odin take care of setting up. => That's a global view of xApp. Based on all of this meta data => high end user to choose the xApp they want to execute and how we going to deploy. If the policy could turn to the configuration for the xApp => if we instead of define the policy - a standard way of develop xApp with those plugins with parameters mapping.
* We will have a manager to put the parametors to the configure file => this will be done by template with place holder => The manager will feed and put in placeholder => In this way, we could met xApp with random configuration as long as they template the configuration. (We have a lots of translation tools)
=> Minor priority
=> The task: define the xApp => define the parametors that we could change(With some xApp => come up with the standard) and how we could reverse => we could discover which xApp with meta data.
Recap:
* For me, Try to come up something equivilant to these in our platform. If I want to do data collection with prometheus =>
=> Read and rewrite based on our platform. To understand like if they have the data collection (How are we going to implementing this in our platform like using Prometheus)
* Do the coressponding xApp
* This will reflect whether we need new study or not
## The new design of xApp -> Ravens could just call an xApp in Odin (No dynamic or static ?)
* About the above new design
* Differents from the previous
* Data processing in pipeline from database from differences framwork ( protocal ? )
* Configuration - Plugins for supporting differnt frameworks in different languages
*
## New stucture of xApp
### E42 connection
```
> /flexric/src/ric/iApp
> /flexric/src/xApp
> IxApp
> IxAppConnection
```
* Check `Read_e42_iapp.h` and `msg_handle`
Sign in with Wallet
Connect another wallet