# 13 July 2020 - Daily Report

## Summary
----
### Expected Outcome :
* Understand another use case of Non-RT RIC
* be able to install docker
* Understand kubernetes architecture and working principles

___
### Outcome :
* Understand the use case of Non-RT RIC in V2X communication
* Successfully install docker in Ubuntu
* Know the kubernetes architecture/structure

### Further plan:
* Try to install Kubernetes and Acumos

___
### Timeline
1. Study Non-RT RIC use case 4 <mark> 09:00 </mark>
2. Install docker <mark> 10:55 </mark>
3. Study Kubernetes Structure/architecture <mark> 1:08 pm </mark>
---
## Study Notes

### What is V2X communication?
:::info
reference: https://www.zdnet.com/article/what-is-v2x-communication-creating-connectivity-for-the-autonomous-car-era/
:::
V2X which stands for 'vehicle to everything' is the term for the car's communication system where information from sensors and other sources travels via high-bandwidth, low-latency, high-reliability links, paving the way to fully autonomous driving.

There are competing standards in play for V2X:
1. IEEE 802.11p
2. Cellular V2X

**Comparison**:
image: qualcomm

In the future, V2X communication **will increase autonomous vehicle safety and reliability**. This picture below is the direct communication for active safety use cases.
image: qualcomm

### Use Case 4: Context-based dynamic handover management for V2X
:::info
main reference :
* [O-RAN Non-RT RIC & A1 Interface : Use Cases and Requirements 2.0 - April 2020](https://www.o-ran.org/s/O-RANWG2Use-Case-Requirements-v0200.pdf)
:::
Part of the V2X architecture is the V2X UE (SIM + device attached to vehicle) which communicates with the V2X application server. The exchanged information comprises Cooperative Awareness Messages (CAMs), radio cell IDs, Connection IDs, and basic radio measurements.

As vehicle traverse along a highway, due to their high speed and the heterogenous naturan environment V2X UE-s are handed over frequently which may cause handover (HO) anomalies: e.g., short stay, ping-pong and remote cell. This anomalies could disturb the functionality of V2X applications.

This use case aims **to present a method to avoid and/or resolve problematic HO scenarios by using past navigation and radio statistics in order to customize HO sequences on a UE level**.

#### Entities/resources involved in the use case
1. **Non-RT RIC**
* **Retreive necessary performance, configuration and other data for constructing/training relevant AI/ML models** that will be deployed in Near-RT RIC to assist in the V2X HO management function.
* Support **deployment and update of AI/ML models** into Near-RT RIC xApp
* Support communication of intents and policies (system-level and UE-level) from Non-RT RIC to Near-RT RIC
* Support communication of Non-RAN data to enrich control function in Near-RT RIC (enrichment data)
2. **Near-RT RIC**
* Support **update of AI/ML models** retreived from Non-RT RIC
* Support interpretation and execution of intents and policies from Non-RT RIC
* Support necessary performance, configuration and other data for defining and updating intents and policies for tuning relevant AI/ML models
* Support communication of configuration parameters to RAN
3. **RAN**
* Support **data collection** with required granularity to SMO over O1 interface
* Support Near-real-time configuration-based optimization of HO parameters over E2 interface
* **Report** necessary **performance, configuration** and **other data** for performing real-time V2X HO optimization in the near-RT RIC over E2 interface
4. **V2X Application Server**
* Support **data collection** with required granularity from V2X UE over V1 interface
* Support **communication of real-time traffic** related data about V2X UE to Non-RT RIC as enrichment data.


#### Required data
The measurement counters and KPIs (as defined by 3GPP) should be appropriately by cell, QoS type, slice, etc.
1. Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells.
2. UE connection and mobility/handover statistics with indication of successful and failed handovers and error codes etc.
3. V2X related data: position, velocity, direction, navigation data, CAMs.

### Docker Installation
::: info
References:
* [Fandi Azam's notes](https://hackmd.io/@EHEAmKPKSYmpHcyPeiO8jQ/rkGSGt5HI#What-is-Docker)
* [Docker documentation](https://docs.docker.com/engine/install/ubuntu/)
:::

**Steps**:
1. Set up the repository
* Update the ```apt``` package index and install packages to allow ```apt``` to use a repository over HTTPS:

$ sudo apt-get update

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common


* Add Docker's official GPG key:

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Then verify that you now have the key with the fingerprint ```9DC8 5822 9FC7 DD38 854A``` ```E2D8 8D81 803C 0EBF CD88``` by searching for the last 8 characters of the fingerprint

$ sudo apt-key fingerprint 0EBFCD88

pub   rsa4096 2017-02-22 [SCEA]
      9DC8 5822 9FC7 DD38 854A  E2D8 8D81 803C 0EBF CD88
uid           [ unknown] Docker Release (CE deb) <[e-mail]>
sub   rsa4096 2017-02-22 [S]


* Use the following command to set up the **stable** repository. To add the **nightly** or **test** repository, add the word ```nightly``` or ```test``` (or both) after the word ```stable``` in the commands below

$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"


2. Install docker engine

* Update the ```apt``` package index, and install the latest version of Docker Engine and containerd, or go to the nnext step to install a specific version:

 $ sudo apt-get update
 $ sudo apt-get install docker-ce docker-ce-cli containerd.io


* To install a specific version of Docker Engine, list the available versions in the repo, then select and install:
* List the versions available in your repo

    $ apt-cache madison docker-ce

  docker-ce | 5:18.09.1~3-0~ubuntu-xenial | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 5:18.09.0~3-0~ubuntu-xenial | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 18.06.1~ce~3-0~ubuntu       | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  docker-ce | 18.06.0~ce~3-0~ubuntu       | https://download.docker.com/linux/ubuntu  xenial/stable amd64 Packages
  ...


* Install a specific version using the version string from the second column, for example, ```5:19.03.12~3-0~ubuntu-focal```

    $ sudo apt-get install docker-ce=<VERSION_STRING> docker-ce-cli=<VERSION_STRING> containerd.io


* Verify that Docker Engine is installed correctly by running the ```hello-world``` image.

$ sudo docker run hello-world


**Docker has been successfully installed in my ubuntu VirtualMachine**

### Kubernetes
:::info
Reference:
* [Johnny's presentation](https://drive.google.com/file/d/16u1ePiD053ddtsdWN5bRT7Pg3gpi8HAj/view) about kubernetes
* [Kubernetes Documentation](https://kubernetes.io/docs/concepts/overview/components/#:~:text=A%20Kubernetes%20cluster%20consists%20of,.%20%2C%20that%20run%20containerized%20applications.)
:::
#### Kubernetes Cluster Structure
1. **Kube-API-Server**
The API server is a key component and serves the kubernetes API using JSON over HTTP, which provides both the internal and external interface to Kubernetes.
2. **Scheduler and Controller Manager**
**Scheduler** is a component that watches for newly created Pods with no assigned Node, and selects a node for them to runn on. Factors taken into account for scheduling decision include : individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines
**Controller manager** is a component that runs controller processes. These controllers include:
* Node controller: responsible for noticing and responding when nodes go down.
* Replication controller: responsible for maintaining the correct number of pods for every replication controller object in the system
* Endpoints controller: Populates the endpoints object (that is, joins Services & Pods)
* Service Account & Token controllers: Create defaunts and API access tokens for new namespce

4. **Etcd**
Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data

5. **Kubelet**
An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod

6. **Kube-Proxy**
Kube-proxy is a network proxy that runs on each node in cluster, implementing part of the Kubernetes Service concept. Kube-proxy maintains network rules on nodes. These network rules allow network communication to pods from network sessions inside of outside the cluster.

7. **Pod**
Pods is a small unit in kubernetes. One pod operates in one node. It includes one or more container.

**Kubernetes Deployment**
A deployment provides declarative updates for Pods and ReplicaSets. Deployments has some use case such as:
* **create a deployment too rollout a replicaset**. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
* **Declare the new state of the Pods** by updating the PodTemplateSpec of the Deployment
* **Rollback** to an earlier deployment revision if the current state of the deployment is not stable.
* **Scale Up** the deployment to facilitate more load
* **Pause** the deployment to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout
* Use the status of the deployment as and indicator that a rollout has stuck
* Clean up older ReplicaSets that we don't need anymore


___

###### tags: `Daily Report`