...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
References
Use case overview and impacted components are described in the 5G OOF PCI optimization main wiki page.
1. Architecture
The architecture below depicts the SON-Handler MS as a part of DCAE. Only the relevant interactions and components are shown.
...
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.1.1. Initialization
In this state, the following actions are performed:
- Fetch config policy from Policy module (REST call) and configure the MS (thresholds, timers, etc.)Initialize Database, buffers, etcConfig Policy from CBS.
- Load any local configuration.
- Load data persisted in DB.
- Trigger DMaaP thread for registration of DMaaP topics (SDN-R, VES-Collector and Policy interfaces)
...
- .
2.1.2. Eternal Wait State
The main thread always comes back to this state (except when terminated). In this state, the inputs and associated actions are summarized below:
2.1.2.1. DMaaP message from VES-Collector received (PM/FM data)
- FM data received: Determine if alarm to be processed, if yes, trigger appropriate PCI-ANR child thread, else, buffer the FM data.
- PM data received: Trigger PM child thread
2.1.2.2.
...
SDN-R Notification handling
Upon receipt of a websocket notification from Policy module, fetch updated config policy via REST call (get_config)
2.1.3. SDN-R Notification Handling
Check if notification has to be processed or buffered as followsneighbor-list-change notification message (DMaaP) from SDN-R, do the following:
- Fetch the PCI_optimization requests (from DB) for which OOF has been triggered, and corresponding ‘cluster’ details
- For each ‘cluster’ for which OOF has been triggered, check if the Nodeid of the Cell Ci or at least one cell in its NbrList matches with any cell in the ‘cluster’
- If there is a match, then the request has to be buffered, along with the cluster indication (cluster id), else the notification has to be processed. If ‘notification the notification has to be processed’, transition to Child Thread triggering state, else transition to Buffer notification state.
2.1.4. Child Thread triggering
Fetch the available clusters (corresponding to the active child threads) from DB.For each cluster:if the Cell Ci and/or its neighbors Nbr_1i to Nbr_Ki are present in the clusterthen
Map the notification to the child thread handling the cluster (i.e., consider this cell also to be part of the cluster)child_thread_mapped = trueExit the loop of scanning each cluster
fi
3. If child_thread_mapped = false, then instantiate a new cluster (i.e., this cell is part of a new cluster).
2.1.5. Buffer notification
Buffer the notification (along with the cluster id) in the DB. Discard any older notifications (remove from the DB) from the same cell (which is buffered).
...
- processed, then instantiate the PCI-ANR child thread (if not already active), and forward the notification.
2.1.2.3. OOF Response Handling
Upon invocation of API by OOF for PCI result pass it to the relevant child thread(s) (by request id <-> thread mapping). Store the OOF results in database along with the timestamp.
2.1.
...
Upon trigger from Child thread that OOF results have been sent to Policy (as a DMaaP message), check if there are any buffered notifications to be handled for the cluster handled by the Child thread.
...
2.4. Policy response handling
- Forward the response from Policy to the appropriate child thread - it could be a PCI-ANR child thread (in case of PCI-ANR optimization), or PM child thread (in case of autonomous ANR update by PM child thread).
2.1.2.
...
5. Child Thread Status update handling
Clean up the resources associated with the cluster handled by the Child child thread (including cluster details), and kill the child thread.
2.1.
...
3. Terminating
Upon receiving a terminate request clean up all resources.
2.2. PCI-ANR Child Thread(s)
These child threads are spawned for handling PCI optimization primarily, though they may also trigger PCI-ANR joint optimization in some cases. The various states and associated actions are described below.
| Gliffy | ||||
|---|---|---|---|---|
|
2.2.1 Initialization
In this state, perform initialization, and transition to Cluster formation state.
| Gliffy | ||||
|---|---|---|---|---|
|
...
based on the type of notification, go to either Section 2.2.1.1 or 2.2.1.2 for next actions.
2.2.1.1. Neighbor list change notification received
- 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
if any ANR actions are ongoing by PM-child thread
Go to "Wait for PM-based ANR actions" state (Section 2.2.
...
If OOF has to be triggered Then
Transition to Trigger OOF state.
Else
Wait for more notifications
...
2)
else
Go to step 2.2.1.4 below.
fi
else
Go to "Wait for notifications/alarms" state (Section 2.2.3)
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
Go to "Trigger OOF, wait for PCI optimization results" state (Section 2.2.4)
else
Go to "Trigger OOF, wait for PCI-ANR optimization results" state (Section 2.2.5)
fi
2.2.2. Wait for PM-based ANR actions
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.
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
Transition to Trigger OOF state.
Else
Wait for more notifications (timer must have been started during cluster formation)
...
- 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 (neighbor list change)
- Store details of request in DB.
- Wait for OOF optimization result.
...
- .
...
Upon trigger from main thread with OOF PCI optimization result, prepare and send
...
DMaaP
...
messages to Policy: for the cells whose PCI value has changed, as well as to all the neighbors of the cells whose PCI value has changed. 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).
- Start Policy_rsp timer and wait for Policy response by going to "Wait for Policy Response" state (Section 2.2.6).
2.2.5. Trigger OOF, wait for PCI-ANR optimization results
- Fetch the list of cell pairs whose HO success is less than thresold_poor, but >= threshold_bad (this would have been prepared already by PM child thread and stored in DB).
- Send a Joint_PCI_ANR_opt request to OOF with cells triggering the request along with the trigger type, and list of 'removable neighbors'
- Store details of request in DB.
- Wait for OOF optimization result.
Upon trigger from main thread with OOF ANR-PCI optimization result
if response contains PCI updates
then
Prepare DMaaP messages to Policy for the cells whose PCI value has changed, as well as to all the neighbors of the cells whose PCI value has changed. 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)
fi
if response contains NRT updates (corresponding to ANR)
Update/prepare DMaaP messages to Policy for the cells whose neighbors have undergone updates (with indication "HO prohibited"). 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)
...
fi
Send prepared message(s) to Policy.
- Start Policy_rsp timer and wait for Policy response by going to "Wait for Policy Response" state (Section 2.2.6).
2.2.
...
6. Wait for Policy Response
Wait in this state until response is received from Policy or Policy_rsp timer expires. If any notification/alarm is received in this state, simply buffer/store them. Upon reception of Policy response or upon Policy_rsp timer expiry, log the details, start buf_timer (
...
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 unnecessarilyto wait for updates from RAN) and transition to "Wait for RAN updates" state (Section 2.27).
2.2.7. Wait for RAN updates
Wait in this state until buf_timer expires. If any notification/alarm is received in this state, simply buffer/store them. Upon expiry of buf_timer, check if there are any buffered notifications.
if there are buffered notifications/alarms
then
- Alarms: Based on OOF results and/or PM-based ANR updates check if any new alarms are automatically inapplicable, and remove them.
- Notifications: Based on OOF results and/or PM-based ANR updates check if any new neighbor list change notifications are automatically inapplicable (partially), and update them.
- Determine collisions/confusions, perform correlation of pending alarms and notifications to remove duplicate entries. Go to Step 2.2.1.3.
else
- Inform main thread of action completion
fi
2.3. PM-child thread
This child thread perform all PM-related computations, and initiate autonomous ANR updates based on HO metrics.
| Gliffy | ||||
|---|---|---|---|---|
|
2.3.1. Initialization
In this state, all data structures are initialized. This includes any processing-pending PM data, processed PM data and populating details from DB.
2.3.2. Wait for PM inputs
In this state PM inputs are awaited. Upon reception of PM inputs, do the following:
2.3.2.1 Handle PM inputs
- Compute HO success metrics for every source-destination cell pair, and store in DB.
- Store the details separately of the cell pair(s) whose HO success is consistently:
- < threshold_bad
- < threshold_poor, but >= threshold_bad
- Perform DB book-keeping actions (delete old PM entries).
- if any pair has a consistently HO success < threshold_bad
then
2.3.2.2. Check readiness for ANR actions and carry out next steps
if ANR actions can be carried out (i.e., any PCI-ANR actions are ongoing by a PCI-ANR child thread)
then
if Policy_rsp is not pending
then
2.3.2.2.1. Prepare and send message(s) to Policy
Prepare and send DMaaP messages to Policy for all the cells whose neighbors have to be updated with "HO prohibited".
Start policy_rsp timer
Go to "Wait for Policy response" state (Section 2.3.4)
else
Go to "Wait for Policy response" state (Section 2.3.4)
fi
else
Go to "Wait for PCI-ANR child thread(s) action completion" state (Section 2.3.3 )
fi
else
Remain in "Wait for PM inputs" state (Section 2.3.2).
fi
2.3.3. Wait for PCI-ANR child thread(s) action completion
When an indication that PCI-ANR child thread(s)' actions are completed is received, go to Step 2.3.2.2.1. If any PM inputs are received, go to Step 2.3.2.
2.3.4. Wait for Policy response
Upon reception of Policy response or Policy_rsp timeout, check if any pending ANR updates are to be sent to Policy. If any present, then go to Step 2.3.2.2, else update PM-based ANR actions are completed, and go to "Wait for PM inputs" state (Section 2.3.2).