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.
With reference to the above architecture:
1.1. Core Logic
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:
- 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
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.
...
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.5.
...
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 and clean up resources associated with the cluster handled by the Child thread.
...
Upon receiving a terminate request clean up all resources.
2.
...
2. Child Thread(s)
2.2.1 Initialization
In this state, perform initialization, and transition to Cluster formation state.
2.2.2. Cluster formation
- 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.
- 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
Fi
2.2.3. Wait for notifications
- Start notif_timer and wait for more notifications
- If a new notification is received, transition to Cluster expansion state. If notif_timer expires, transition to Trigger OOF state.
2.2.4. Cluster expansion
- Attach the cell and its neighbors appropriately to the existing cluster.
- 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 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
Start timer for more notifications
Fi
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
- 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.
2.2.6. Send PCI recommendations to Policy
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. Handle buffered notification
- 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 Expansion state.
- If new notifications are received when in this state, then simply store the notifications and remain in this state.
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).