...
- Data is collected from the network using appropriate interfaces and is published to DMaaP. Such data can be performance (PM) counters, KPIs, alarms, etc.
Question (Karpura S.) Is there another requirement for which type of data needs to be published to DMaaP ? Or, does this assume that any type of data can be published to DMaaP by the network and it really depends on the type of NBIs already defined in other standards bodies (3gpp, xRAN)
Comment (Sarat) – At this point, let us keep it as general as possible – any data that can be collected and published on DMaaP - Network data is consumed by SON algorithmic-logic micro-services that may be either part of DCAE, thereby managed by the DCAE controller, or part of other analytics frameworks that have access to DMaaP.
- SON analytical logic analyses the network data. Such logic may be implemented within a single micro-services, or may leverage communication between multiple micro-services. The result of the SON logic is published to DMaaP for consumption by other ONAP components – primarily the ONAP Policy platform.
Comment (Vladimir Y.)The part of publishing assumes that there is certain "standardized" set of possible results. However from experience in SON algorithms development, there is a wide variety of possible outcomes. I don't think any standard can be established here to cover all or most of reasonable outcomes.
Comment (Sarat) Typically the consumer of the results such microservice analyses is Policy, in this context – which makes decisions using these results. Therefore, so long as the policy engine can understand the results, we are good here.
- The Policy platform will obtain and assess the SON algorithmic output, in order to make a decision on what actions will need to be performed to network elements towards achieving the optimization goal. Such actions may be decided exclusively by Policy, or may be recommended by the SON algorithm as part of its output.
Comment (Vladimir Y.)Hardly possible, because of the reason outlined in the previous comment. Besides, this bullet includes the decision on certain action to be executed. This decision requires detailed knowledge of the algorithm of the SON analytical part. For example, the analytical part may decide that the cell A is overloaded, based on a (proprietary) formula that includes 5 PM measurements. Then the Policy platform needs to decide what to do, without any knowledge of the formula. Then the change in the network may lead to increased load as computed with the formula, rather than to load reduction.
Comment (Sarat): Valid point. So, the analytics in DCAE and the Policy should be well-coordinated. In other words, we need to start with an algorithm first and decompose that into analytics (microservices) and Policy.
- The Policy platform will convey its decision to the radio SDN controller, which will further apply the action(s) to the appropriate network element(s).
Comment (Oskar M.) There is no radio SDN controller in the ONAP architecture. Could re-use execution framework requirement stated below: initiate radio access network change using SO and / or controllers.
Comment (Sarat) – Yes. And this is a gap we need to address. One potential option is to use SDN-C and adapt the southbound interface to interface with the RAN. The northbound interface of SDN-C is DMaaP and we should be good there.
- Upon applying the action, the SON logic will analyze post-action network data to determine (in conjunction with Policy) whether subsequent actions need to be applied in order to achieve the optimization objective.
Comment (Vladimir Y.) Please see two previous comments. Also not clear what "in conjunction with Policy" means.
...
- Design per slice segment Data Collection, Analytics, SLA / SLO calculations
- Design E2E Slice & Services Analytics and SLA / SLO calculation
- Define policies / anomalies that indicate sub-optimal slice segment / E2E slice, and service performance
Comment (Vladimir Y.) Typically there are multiple KPIs for slice segments and KQIs for services. To date, there is no agreed (e.g. standardized) integrative metrics for slice and service performance.
Comment (Sarat): Can we start with what we have today or services (e.g. accessibility, retainability, throughput etc) and create some KPIs for slices? If so we could address most of the comments below, I think.
- Define policy evaluation to identify best possible slice / slice segment and service optimization action(s)
Comment (Vladimir Y.) Hardly possible because of uncertainty with definition of metrics for slice and service performance - Create recipes for addressing slice performance degradation
Comment (Vladimir Y.) Same problem - Design data collection and analytics for various network optimization functions
- Define policies / anomalies that indicate sub-optimal network performance
Comment (Vladimir Y.) Hardly possible because of uncertainty with definition of metrics for slice and service performance - Define policy evaluation to identify the best possible optimization action(s)
Comment (Vladimir Y.) Duplicate - Define SON coordination policies for the prevention, detection and resolution of conflicts or negative interactions of individual SON functions
Comment (Vladimir Y.) See above comment on coordination - Create recipes for executing network optimization steps (e.g. new configurations for RAN elements)
Comment (Karpura S.) I propose adding re-mapping of PNFs to VNFs also as an example of optimization.
...