NOTE: This page is work in progress.

...

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

...

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, etcConfig 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)

Gliffy
name PM child thread pagePin 6

• .

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 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 followsneighbor-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 ‘notification the notification has to be processed’, 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

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

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

...

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

...

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.

...

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 cluster handled by the Child 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 transition to Cluster formation state. Gliffynamechild_threadpagePin13

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

...

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

Gliffy
name PM child thread pagePin 6