# Daily Note 04/08/2020
###### tags: `Daily Notes` , `O-RAN` , `Acumos`
## Name : Christofel Rio Goenawan
## University : Bandung Institute of Technology (ITB)
---
## Schedule:
1. Study Detailed Works of Near RT- RIC Platforms.
2. Create Slide Presentation for Tomorrow's Meeting.
3. Continue to try installing Acumos AI in NTUST Server.
## Outcome :
1. Explained detiled works of KPM.
2. Create Slide Presentation for Tomorrow's Meeting with Akmal.
3. Couldn't find server name that asked by command when try to set up needed services in NTUST server.
## Further Plan :
- Continue to deploy Acumos AIO in NTUST server
- Study more detailed about AIO Installation in Kubernets
---
## Daily Log
### 1.Study Detailed Works of Near- RT RIC Platforms. <mark>(9.00)</mark>
- Study more detail explanation in [Documentation](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=3604819 ) and other sources.
### 2.Create Slide Presentation for Tomorrow's Meeting. <mark>(14.00)</mark>
- Slide Presentation can be seen [here](https://docs.google.com/presentation/d/1L2bpcbmDt7wbZuDUOJFIZ-DOy-2Jy4TeRIIDNWPqw8E/edit?usp=sharing).
### 2.Continue to try deploying Acumos AIO in NTUST server. <mark>(16.00)</mark>
- Continue to try to deploy Acumos AIO in NTUST server using Prep- Deploy Process based one previous [study notes](https://hackmd.io/@christofel04/TEEP_Daily_Notes_10_7_2020).
---
## Report
### 1. Near- RT RIC Platforms
>In this note Writer use [Documentation](https://www.o-ran.org/s/ORAN-WG3E2SM-v0100.docx) and [Ferlinda's Notes](https://hackmd.io/hQj_2NYQS5mjhEZkxkkP0Q?both) as study sources.
This study use Near - RT RIC Cluster Bronze version as refernces.
#### Architectures
From references, simple architectures of Near- RT RIC Cluster Bronze version can be shown as below.

#### Functionality
From Ferlinda's notes, the functionality of Near- RT RIC Cluster can be seen as below.
* **E2 Termination:**
* Establishes **E2 SCTP connections (as requested by the E2 manager) and routes messages** received/sent over E2 to/from RMR.
* Can act as **RAN Function**, where the E2AP is done over SCTP Connection.
* Is **independent** and **binding messages to xApps**, according RMR routing.
* Repo: ric-plt/e2
* **E2 Manager:**
* Controls **E2 connection establishment** and provides **REST APIs to manage these connections**.
* Detailed information regarding Architecture, Design, and REST API Swagger can be found [here](https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=17269226).
* Repo: ric-plt/e2mgr
* **Routing Manager:**
* Responsible for **generating and distributing routing policies** to xApps.
* Routing Manager can communicate with **xApp, Sub Manager, and E2 Termination**. The relationship between them can be seen on [here](#2-Routing-Manager-and-Subscription-Manager).
* More regarding Routing Manager can be found [here](https://wiki.o-ran-sc.org/display/RICP/Routing+manager). I might update a separate note regarding this later on.
* Repo: ric-plt/rtmgr
* **Sub Manager:**
* Manage subscription, it has the ability to **subscription details, store subscriber address, retreive subscription response, detect duplication, and another subscription related task**.
* Communicate with xApp and Routing Manager. The relationship between them can be seen on section below.
* Repo: ric-plt/submgr
* **xApp Manager:**
* This is used to provide a **flexible and secure way to deploy and manage various xApp applications** in Kubernetes environment.
* Repo: ric-plt/appmgr
* **A1 Mediation:**
* A1 Mediation **listens for policy type and policy instance requests sent via HTTP by northbound interface (SMO Clusters) and publishes those requests to running xApps via RMR messages (northbound interface)**.
* A1 uses the ***RIC SDL library*** to persist all policy state information: this includes the **policy types, policy instances, and policy statuses**. SDL uses Redis as a backend.
* Repo:
* ric-plt/a1
* ric-plt/sdl
* ric-plt/sdl/config
* ric-plt/sdlgo
* ric-plt/sdlpy
* ric-plt/lib/rmr
* **O1 Mediation:**
* Took care of **communication via O1 interface between SMO and O-DU/RU/Infrastructure Management Framework**. According to the documentation all ManagedElements (near-real-time-RIC, O-CU-CP, O-CU-UP, O-DU and O-RU) implement the O1-interface.
* According to source code, this component's agent is related to xApp and xApp Manager. It's manager consisted of a python file for process-state with HTTP communication, **saving several information related to pid into table**.
* VES collectors will **receive the VES messages of the O1 interface**. For real-time event streaming the SMP project provide HV-VES. Relation can be found on notes below.
* Repo: ric-plt/o1
:::info
Writer couldn't find exact description about this component in both Amber and Bronze release. Then Writer study from documentation.
:::
* **DbaaS (Redis):**
* Provides **Database-as-a-Service, source codes are used for Redis database adaptation as cluster of Redis instances to provide high-availibility and single-instance Redis database**.
* Repo:
* ric-plt/dbaas
* ric-plt/dbaas/hiredis-vip
* **VESPA:**
* Uses the VES Agent to adapt near-RT RIC internal statistics collection using **Prometheus** (xApps and platform containers) to **ONAP's VES** (VNF event streaming)
* Repo: ric-plt/vespamgr
* **Jagger AIO:**
* Jaeger is an open source, end-to-end distributed tracing. More about this in [Masroor Hasan's article](https://medium.com/@masroor.hasan/tracing-infrastructure-with-jaeger-on-kubernetes-6800132a677). Jaeger Architecture in [Additional Notes -5](https://hackmd.io/hQj_2NYQS5mjhEZkxkkP0Q?both#5-Jaeger-Architecture).
* Jaeger Adapter 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**.
* This is used for **OpenTracing from near-RT RIC xApps and near-RT RIC platform components**.
* Repo:
* ric-plt/jaegeradapter
* ric-plt/tracelibgo
* ric-plt/tracelibcpp
* **xApp Onboarded:**
* Consisted of **artifacts for the (near realtime) RIC xapp framework**.
* Provides **interface that simplify the usage of the RIC services, such as RMR, SDL (database) access, logging, and on**.
* RIC provides frameworks for **C++, Python, and Go**.
* Repo:
* ric-plt/xapp-frame
* ric-plt/xapp-frame-cpp
* ric-plt/xapp-frame-py
* **Prometheus:**
* **Containers** for xApps and platform.
* According to Techplayon Promotheus can be defined as below.
`Prometheus is an open source software application used for event monitoring and alerting. It records real-time metrics in a time series database (allowing for high dimensionality) built using a HTTP pull model, with flexible queries and real-time alerting.`
* Related to VESPA.
* **Prometheus AM:**
* **Alert Manager for Prometheus**, used RICalarm management, can be setup to send alarms as VES events.
* Repo:
* ric-plt/alarm-go
* ric-plt/alarm-cpp
:::info
**Next Writer will study more about RIC Global Procedures Elements**
:::
---
### 2. Continue to try deploying Acumos AIO in NTUST server
>This deployment is continuation from [yesterday's notes]( https://hackmd.io/@christofel04/TEEP_Daily_Notes_30_7_2020 ).
In this note Writer use [Previous Notes](https://hackmd.io/@christofel04/TEEP_Daily_Notes_10_7_2020) as study sources.
Then Writer try to install needed services in server for Acumos AIO.
Writer use the next command as below.
```
bash system-integration/AIO/setup_prereqs.sh k8s ee705-7-ip113 $USER openshift 2>&1 | tee aio_prep.log
```

But when Writer use the command , the command ask for server's name that Writer don't know.
:::warning
After I discussed with Kevin, I try to find the server's name by command below.
``` oc login ```
But the command also ask for server's name
:::
:::info
**Next Writer Will Continue to Find the Server's Name For the Command**
:::
---
## Reference
1. https://www.o-ran.org/s/ORAN-WG3E2GAP-v0100.docx
2. https://www.o-ran.org/s/ORAN-WG3E2SM-KPM-v0100.docx
3. https://docs.o-ran-sc.org/en/latest/architecture/architecture.html
4. https://docs.acumos.org/en/clio/submodules/system-integration/docs/oneclick-deploy/user-guide.html