Use case overview and impacted components are described in the 5G OOF PCI optimization main wiki page.
The architecture below depicts the SON-Handler MS as a part of DCAE. Only the relevant interactions and components are shown.
The internal architecture of SON-Handler MS is shown below.
This is composed of a Main Thread and one or more Child Threads. The Main Thread is responsible for spawning and terminating the Child Threads, this is described in the sections below.
This is a PostgreSQL DB, and is intended to persist information such as the following:
This is responsible for registering with the DMaaP client for the DMaaP notifications from SDN-R and VES-Collector, and to Policy.
Note: The pre-processing logic may not be 100% fool-proof as well as the most efficient one. An attempt has been made to balance the usefulness for a PoC versus the complexity of handling all possible scenarios.
The state transition diagram is illustrated below:
The main actions in the various states are listed below:
In this state, the following actions are performed:
The main thread always comes back to this state (except when terminated). In this state, the inputs and associated actions are summarized below:
Upon receipt of a neighbor-list-change notification message (DMaaP) from SDN-R, do the following:
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.
Clean up the resources associated with the child thread (including cluster details), and kill the child thread.
Upon receiving a terminate request clean up all resources.
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.
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.
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.2)
else
Go to step 2.2.1.4 below.
fi
else
Go to "Wait for notifications/alarms" state (Section 2.2.3)
fi
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
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
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.
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.
Note: When transitioning to this state from Handle buffered notifications state, more than 1 notification may have to be handled.
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).
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.
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
else
fi
This child thread perform all PM-related computations, and initiate autonomous ANR updates based on HO metrics.
In this state, all data structures are initialized. This includes any processing-pending PM data, processed PM data and populating details from DB.
In this state PM inputs are awaited. Upon reception of PM inputs, do the following:
then
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
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
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.