工作日誌
===

[toc]

## 2023/10

### 10/16-10/22
* **Goal:**
* make SMO-Altiplano NETCONF session meet O1 specification
* Altiplano Virtualizer (AV) integration (device-level FCAPS)

* **Motivation:**
* Altiplano Virtualizer acts as a "device proxy"
* Altiplano take the advantage of "YANG Schema Mount(RFC 8530)"
> YANG Schema Mount introduce a new mechaism that allows for mounting one data model consisting of any number of YANG modules at a specified location of another (parent) schema.
* Altiplano mount YANG schemas of a group of devices under its management domain onto its own YANG schema.
* Once Altiplano receives \<edit-config> NETCONF operation which makes attempts to modify the leaf node info. from YANG Schema mounted, *As a proxy, Altiplano would transform the request message from the MnS consumer and send the transformed \<edit-config> to the corresponding device*
* Device mount point (device specific data):

            anv:device-manager
                anv-device-holders:device-holder
                    anv-device-holders:device
                          anv-device-holders:device-specific-data

* Alitiplano Device Alarm (O1 notification)
* Virtualizer would subscribe all the kind of notifications from devices it managed
* Once virtualzer receive notification, Virtulizer would directly forward the notification to NBI client if the notification type is subscribed by NBI client
> Using NBI, you can disable or enable the forwarding of a notification per notification type. When a notification type is added to the list of disabled notifications, Network Virtualizer does not forward the corresponding notifications to the NBI. By default, Network Virtualizer disables the forwarding of certain type of notifications that are deemed to be no interest for a NBI client.
* Issue may encountered:
:::danger
Virtualizer doesn't support "xpath filter capability"
:::
* [xpath](https://www.rfc-editor.org/rfc/rfc5277.html#section-5.2) is used for specifying the filters while creating subscriptions for notifications.
* O1 Spec: <br> Both MnS Provider and Consumer SHALL support the following NETCONF capabilities.
* writable-running
* rollback-on-error
* validate
* **xpath**

* **Methodology:**
* write rApp
* write sdnc plugin

* **What to study**:
* rappcatalogue
* ONAP ccsdk
* dmaap message router service
* sdnr/sdnc development
* https://wiki.onap.org/display/DW/SDN-R+Developer+Guide
* https://wiki.onap.org/pages/viewpage.action?pageId=81396544
* https://wiki.onap.org/display/DW/SDN+Controller+Development+Guide

* **What has been done:**
* ONAP-based SMO could establish NETCONF session with Nokia AV and AC
* Nokia Altiplano NBI guide digest
* ORAN Alliance Specification
* O1 interface specification: v04, v10
* R1 interface specification: R1GAP, R1UCR, R1AP, R1TP
* read RFCs
* 7950, 8530, 7895, 8528, 6241, 7893, 8526, 5277
* Get the existing configuration data from AV web UI
* device: ntust, ntust.IHUB, ntust.LT1

* **What plans to do (Short-term):**
* Find the way to get YANG files
* YANG modules are essentials to ONAP ccsdk
* test NETCONF \<get-schema> operation ([RFC6022 YANG Module for NETCONF Monitoring](https://www.rfc-editor.org/rfc/rfc6022.html))
* Find mappings from O1 MnS to Altiplano API exposed by NETCONF

* Setup ONAP ccsdk devlepment environment

* Find rApp sample code

* Keep making attempts to solve the environment setup issue descripted as follows

* **Problems encountered**:
1. Environment Setting:
* SMO components could not successfully re-deploy on my k8s cluster on my local PC since the AAF license issue
* sdnc pods are in running state but ODLUX is not accessible/available
* What attempts have been made:
* rebuild VM/K8S environment (failed)
* [The solution provided by Louis](https://wiki.onap.org/display/DW/Create+AAF+CA+certificates?refresh=1694070998132&focusedCommentId=188514501&fbclid=IwAR0F0gdXgg5qcubgYSMf7MRsd_Uexr6ogxuqkuZPovYCNT-63sMDG5DZlqs#comment-188514501) (failed)
* [The charts provided by Louis](https://drive.google.com/file/d/1a8RqPpmD41qm1mDxkFedKHd8LSlHjix2/view?usp=sharing) (failed: sdnc pods keep killed and restarting(CrashLoopBackError))
* By the next week: deploy charts which have successfully deployed on k8s cluster from the others' PC

            helm repo add local https://harbor.winfra.cs.nycu.edu.tw/chartrepo/winlab-oran

2. retrieve YANG modules of devices managed
>YANG files will be useful reference for creating your customized NETCONF requests and executing them through the NBI interface.
>
>If you have access to the Network Virtualizer WebUI, you can download all the YANG modules of Network Virtualizer **from the NC Client Application. If not, contact your Access Controller administrator for the YANG modules.**
>
>When you download the YANG modules from the NC Client WebUI application, you will also get the device YANG modules corresponding to each device extension installed on your Network Virtualizer

There is no instruction specifying how to do.
There is no NC Client Application on AV WebUI but AC WebUI.



3. OSC ONAP SMO f-release O1 version
H-release: O1 v08
The latest: O1 v10

Yet, I could not find any clues about which O1 version f-release takes.

### 10/23-10/29
### 10/30-11/05

## 2023/11

### 11/06-11/12
#### **Problems Solved:**
1. SMO environment setting:
+ successfully deploy SMO components on VM server situated at NYCU MIRC B09
+ establish netconf connection b/w SMO and AC/AV.
+ The cause of failure may be defects in the hardware of my personal laptop.


2. retreive YANG files of AV/AC and the device mounted on AV
+ Uploaded to [Google Drive](https://drive.google.com/drive/folders/1QNbGUEWgTEM7_fcMzK3uPchjFTdmOjDX?usp=sharing)

#### **Ploblems encountered /not solved:**

1. the O1 interface version which f-release takes
2. the access method of the following PON network devices:
+ ntust
+ LS-FX-FANT-H-FX4 23.3
+ ntust.IHUB
+ LS-FX-IHUB-H-FX4 23.3
+ ntust.LT1
+ LS-FX-FWLT-C 23.3

#### **What plans to do next**
+ O1/VES
1. subscribe alarms on AV
2. notification type

3. ***conversion from 'notification' to 'VES'***
+ We can follow the architecture given below to design ODL app:
+ [2022-06-DD - ONAP: An O-RAN SMO Use Case with Netconf Notifications](https://wiki.lfnetworking.org/display/LN/2022-06-DD+-+ONAP%3A+An+O-RAN+SMO+Use+Case+with+Netconf+Notifications)

4. Push VES to VES collector by dmaap message router
5. Visualize the VES event via Grafana

### 11/13-11/19

#### * Goal *
* ODL may not afford the load from Performance Metric
* Design an agent between SMO and Altiplano AC, which consists of
* VES Agent (FAPS)
* transform FCAPS event from Altiplano into VES format
* submit to VES collector via TLS/HTTPS
* netconf agent (demux) (CM)
* Altiplano Virtualizer (as a Device Proxy)
* mount schemas of underlay device onto its own schema
* which aggregates device CM settings into one
* Demux
* SMO in a view of separate devices not aggregated into one
* transform
* SMO -> Altiplano
* add mount point info
* Altiplano -> SMO
* (put a graph/ppt for further illustration)

#### * Progress *

1. CommonEventFormat_30.1.1_ONAP
* https://docs.onap.org/projects/onap-vnfrqts-requirements/en/latest/_downloads/f4ec93622b0b8d95cb5b6b8952b9418e/CommonEventFormat_30.1.1_ONAP.json
* VES event type
* Fault
* heartbeat
* measurement
* mobileFlow
* notification
* other
* perf3gpp
* pnfRegistration
* sipSignaling
* stateChange
* syslog
* thresholdCrossingAlert
* voiceQuality
2. construct json builder follow the format spec
3. VES listener
* https://docs.onap.org/projects/onap-vnfrqts-requirements/en/latest/Chapter8/ves_5_4_1/VESEventListener.html
4. make attempts to subscribe FM events but <rpc-error>

### 11/20-11/26
### 11/27-12/04