...
- 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 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.
Comment (Vladimir Y.) Let me explain my point with more details. Suppose that we want to design a single Policy function (block), which interoperates with multiple Analytics functions, even with those that will be designed in the future. Is it possible at all? If there was a standardized interface between the Policy function and (any) Analytics function, then yes. I think, however, that such standardized interface is not possible because of wide variety of optimization algorithms. If there are arguments why such "standardization" may be possible, we can discuss them.
One solution could be to assume that every Analytics function is coupled with a specific complementary Policy function e.g. produced by same vendor.
- 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.
Comment (Vladimir Y.) It works for open source development, but not for solutions (algorithms) developed by vendors. Besides, such decomposition can lead to quite different policy parts
- 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).
...