NOTE: This page is work in progress.
...
This is a PostgreSQL DB, and is intended to persist information such as the following:
- PCI-Handler MS Config information (e.g., thresholds, timer values, OOF algorithm name, etc.)
- Pre-processing results and other related information (e.g., neighbor list)
- Buffered notifications (i.e., notifications not yet processed at all)
- State information
- Association between pnf-name and CellId
- PM/FM data
1.3. DMaaP Client
This is responsible for registering with the DMaaP client for the DMaaP notifications from SDN-R and VES-Collector, and to Policy.
2. Core Logic components and Pre-processing algorithm
...
Wait until PM-based ANR actions are completed by PM child thread. In this state, if any new notifications/alarms are received, then the child thread simply buffers them. Upon knowing that the PM-based ANR actions are completed, go to Step 2.2.1.4.
2.2.3. Wait for notifications/alarms
Wait for more notifications/alarms, and start notification_timer if not started already. Upon reception of a new notification/alarm, go to Step 2.2.3.1 below. Upon notification_timer expiry, go to Step 2.2.1.5.
2.2.3.1. Process notification/alarm
- If a cell that already exists in the cluster has sent a notification (for neighbor-list change), update the cell's neighbors appropriately in the existing cluster. Otherwise, 'attach' the cell appropriately in the existing cluster, and update the cell's neighbors.
- For each of the neighbors, fetch the neighbor list (via REST API) from SDN-R Config DB (i.e., fetch neighbor of neighbors of the cell that sent the neighbor list change notification).
- Modify/extend the cluster appropriately.
- Determine collision/confusion by calling method determine_collision_confusion.
- Correlate alarms and neighbor list change notifications (to avoid duplicate counts),
- Go to Step 2.2.1.3.
Note: When transitioning to this state from Handle buffered notifications state, more than 1 notification may have to be handled.
2.2.4. Trigger OOF, wait for PCI optimization results
- Send a PCI_opt request to OOF with cells triggering the request along with the trigger type
- Store details of request in DB.
- Wait for OOF optimization result.
Upon trigger from main thread with OOF PCI optimization result, prepare and send a DMaaP message to Policy (message layout available in Policy sub-page. The message payload layout shall be the same as the yang model contents for the configuration update to be sent by SDN-R towards the RAN. The pnf-name corresponding to the cell-ids can be fetched from Config DB of SDN-R (using REST API). (Note: The layout of the message from SDN-R to RAN is available in the SDN-R sub-page).
Upon reception of response from OOF, prepareAfter sending the message to Policy, a status update is provided to the Main Thread for further actions.
2.2.5. Trigger OOF, wait for PCI-ANR optimization results
...
Start notif_timer if not started already, and wait for more notificationsIf a new notification is received, transition to Cluster modification state. If notif_timer expires, transition to Trigger OOF state.
2.2.4. Cluster modification
If a cell that already exists in the cluster has sent a notification (for neighbor-list change), update the cell's neighbors appropriately in the existing cluster. Otherwise, 'attach' the cell appropriately in the existing cluster, and update the cell's neighbors.For each of the neighbors, fetch the neighbor list (via REST API) from SDN-R Config DB (i.e., fetch neighbor of neighbors of the cell that sent the neighbor list change notification).Modify/extend the cluster appropriately.Determine collision/confusion by calling method determine_collision_confusion.Based on number of collisions/confusions and config policy, determine if OOF has to be triggered or more notifications should be awaited (handle also timeout case).
If OOF has to be triggered Then
...
Trigger OOF
...
Else
Wait for more notifications (timer must have been started during cluster formation)
Fi
...
state
...
.
2.2.6. Send PCI recommendations to Policy
...