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
...
Gliffy | ||||
---|---|---|---|---|
|
2.2.1 Initialization
In this state, perform initialization, and based on the type of notification, go to either Section 2.2.1.1 or 2.2.1.2 for next actions.
...
- Store details of the cell (which sent the neighbor list change notification) and its neighbors in DB.
- 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).
- Form a cluster with the cell, its neighbors and neighbors of each of the neighbors.
- Assign a cluster id.
- Determine collision/confusion by calling method determine_collision_confusion. Go to step 2.2.1.3.
2.2.1.2. FM notification received
- Store details of the FM in DB.
- Increment the number of collisions and/or confusions depending on the type of alarm received. Go to step 2.2.1.3.
2.2.1.3. Check if OOF can be triggered
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, check
if any ANR actions are ongoing by PM-child thread
...
Go to "Wait for PM-based ANR actions state" (Section 2.2.3)
else
Go to step 2.2.1.4 below.
fi
else
Go to "wait for notifications/alarms" state (Section
fi
2.2.1.4. Re-determine valid collisions/confusions
This step is to ensure that collisions and confusions are re-computed after PM-based ANR actions are completed. When transitioning from 2.2.1.1 or 2.2.1.2, this action need not be carried out. After re-computation of collisions/confusions, again a check on number of collisions/confusions should be done to determine if OOF has to be triggered or more notifications should be awaited (handle also timeout case).
If OOF has to be triggered
then
Go to Step 2.2.1.5 below
else
Go to "wait for notifications/alarms" state (Section
fi
2.2.1.5. Determine OOF trigger type
A simple logic, for e.g., based on number of times PCI optimization has been triggered during a given time window could be used to determine whether PCI optimization or joint PCI-ANR optimization should be triggered.
If PCI optimization should be triggered
then
- 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.
else
- Send a Joint_PCI_ANR_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.
Transition to Trigger OOF state.
...
2.2.3. Wait for notifications
2.2.3. Wait for notifications
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.
...
Note: When transitioning to this state from Handle buffered notifications state, more than 1 notification may have to be handled.
2.2.5. Trigger OOF
...
.
2.2.6. Send PCI recommendations to Policy
...
Note: This is to allow changes to be implemented in that cluster by SDN-R, and RAN to send any new notifications upon neighbor list change (i.e., to minimize running the optimization algorithm unnecessarily).
2.3. PM-child thread
This child thread perform all PM-related computations, and initiate autonomous ANR updates based on HO metrics.
Gliffy | ||||
---|---|---|---|---|
|