Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

NOTE: This page is work in progress.


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.


The internal architecture of SON-Handler MS is shown below.


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.


1.2. Database

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

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.

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 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 neighbor-list-change notification message (DMaaP) from SDN-R, do the following:

  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 the notification has to be 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.2.4. Policy response handling

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

2.2.1 Initialization

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.

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.

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.


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, check if any ANR actions are ongoing by PM-child thread. If yes, transition to wait for PM-based ANR actions state.



Transition to Trigger OOF state.

   Else

                Wait for more notifications

           Fi

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

           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. 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 Modification state.
  • If new notifications are received when in this state, then 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.

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

  • No labels