References

Use case overview and impacted components are described in the 5G OOF PCI optimization main wiki page.

1. Architecture

This architecture depicts a standalone PCI micro-service. When this is moved to DCAE, it may undergo some adaptations, for e.g., the interfaces have to be adapted appropriately.

...

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

1.3. DMaaP Client

This is responsible for registering with the DMaaP client for the DMaaP notifications from SDN-R, and to Policy.

2. Core Logic components and Pre-processing algorithm

...

The state transition diagram is illustrated below:Image Removed

The main actions in the various states are listed below:

...

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.
4. If ‘notification has to be processed’

...

1. , transition to Child Thread triggering state, else transition to Buffer notification state.

2.1.4. Child Thread triggering

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

...

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).

fi

2.1.

...

6. 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.

...

7. Child thread status update handling (PCI recommendations sent to Policy)

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.

If there are any such buffered notifications, forward them to the Child thread , otherwise kill the Child thread (transition to Buffered notification handling state, otherwise transition to Resource cleanup state.

2.1.8. Resource cleanup

Kill the Child thread for which the OOF PCI results were received, and clean up resources associated with the cluster handled by the Child thread.

2.1.

...

9. Terminating

Upon receiving a terminate request clean up all resources.

2.2. Child Thread(s)

...

Gliffy
name child_thread pagePin 2

2.2.1 Initialization

In this state, perform initialization, and transition to Cluster formation state.

...

2.2.3. Wait for notifications

• Start notif_timer if not started already, and wait for more notifications
• If a new notification is received, transition to Cluster expansion statemodification 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).
• Extend 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).

...

          Else

                 Start timer    Wait for more notifications (timer must have been started during cluster formation)

           Fi

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 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).

After sending the message to Policy, a status update is provided to the Main Thread for further actions.

2.2.7.

...

Buffered notification handling

• If the main thread triggers a buffered notification to be handled, start buf_timer (if not started already) to buffer the notification (pre-configured value), if not already started (Note), and store the notification contents.
• Upon expiry of buf_timer, process the received (and stored) notifications by transitioning to Cluster ExpansionModification state.
• If new notifications are received when in this state, then simply store the notifications check on whether a notification was received and buffered for the same cell earlier, and if yes, discard the earlier notification (i.e., retain only the latest unprocessed notification for a cell). Simply store the notification and remain in this state.

...