Page History

...

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 in Casablanca timeframe versus the complexity of handling all possible scenarios.

2.1. Main Thread

The state transition diagram is illustrated below:

The main actions in the various states are listed below:

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, etc.
• Trigger DMaaP thread for registration of DMaaP topics (SDN-R and Policy interfaces)

2.1.2. Config Policy Update

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 follows:

1. Fetch the PCI_optimization requests (from DB) for which OOF has been triggered, and corresponding ‘cluster’ details
2. 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’
3. 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 has to be processed’

then

1. Fetch the available clusters (corresponding to the active child threads) from DB.

2. For each cluster:

   if the Cell Ci and/or its neighbors Nbr_1i to Nbr_Ki are present in the cluster

   then

• • 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 = true
  • Exit 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).

else

Buffer the notification

fi

1. 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. Upon trigger from child thread that OOF result has been sent to Policy

(a)    Check for any buffered notifications for that cluster (using cluster id)

If yes

Then

Forward it to the child thread

Else

Kill the child thread

Fi

1. Upon receiving a terminate request clean up all resources.

If ‘process’

Then