Radio Access Network Optimization

A Service Provider (SP) must, in real-time, optimize the performance of the 5G Radio Access Network (RAN). This optimization may be effected via dynamic configuration of relevant 5G radio and backhaul network parameters. Such optimization is part of the so-called “Self-Organized Networking” or SON. ONAP will enable the design and implementation of an open SON ecosystem for 5G RAN optimization by providing a common open framework that (a) enables multiple SON vendors to implement their SON solutions on the same network and (b) provides facilities for managing and coordinating the concurrent application of multiple independently developed and deployed SON algorithms, avoiding or resolving conflicts that might arise.

Comment (Vladimir Y.) I doubt the part (a) describes a real scenario. What would be the reason for the operator  to run simultaneously several potentially conflicting SON solutions? For the part (b), there is a question whether it's possible at all to coordinate actions of several independently designed black boxes. 

In this respect, example SON use cases that could be designed and implemented on ONAP include the following:

• Optimization of E2E service level QoE (KQIs), with slicing awareness where relevant

• 5G White space/unlicensed spectrum management, where SON allocates bandwidth resources to users based on their traffic and mobility profiles, as well the availability of licensed bands in a given geographical location.
• 5G energy optimization: where a SON algorithm dynamically adapts the transmission power and/or tilt of 5G cells based on traffic conditions, in order to maximize the power efficiency of the network. This is especially important in dense networks
  Comment (Vladimir Y.)This technique is widely used in 3G and 4G SON solutions, so not really new 
• Load balancing: where the allocation of user traffic to 4G and 5G cells in the region is based on a wide set of inputs including user load, traffic requirements/conditions, and environmental factors.
  Comment (Vladimir Y.)Same comment: this technique is widely used in 3G and 4G SON solutions, so not really new
  

For such use cases, RAN optimization end-to-end solutions will need to be realized via ONAP control loops. A potential high-level runtime workflow could be the following:

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

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

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.

Based on the above high-level work flow, the application of ONAP-based SON solutions will need to be managed and coordinated appropriately. SON coordination is necessary in order to ensure that independently executing SON functions do not conflict, or otherwise negatively interact with one another. The SON coordination should be policy-driven, allowing operators to easily tailor the logic governing SON function interactions to their own unique network scenarios and business objectives. Finally, such coordination should also take into account 5G-specific mechanisms such as network slicing and be able to interoperate with legacy proprietary SON platforms to the extent possible.

Comment (Vladimir Y.) The notion of “independently executed SON functions” needs clarification. Why would the network operator start several SON functions in parallel? Are they optimizing same KPIs / KQIs? What kinds of conflicts are foreseen?.

In order to support the optimization capabilities described (both the Slicing and RAN optimizations), ONAP must support design and execution capabilities described below.

The ONAP Design Studio (SDC) must support the following Capabilities:

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

Comment (Vladimir Y.) Re-applied the changes proposed by Cisco for v5 .

ONAP execution framework should provide all needed support to the optimization (SON) applications:

• Access to the network performance data via certain DCAE instances
• Access to historical data when needed
• Access to the analytics needed for SON operations e.g. for computation of the KPIs and KQIs that are targeted in the optimization and/or involved in optimization conditions (restrictions). The micro services (MSs) implementing such analytics can be directly called or set to generate an event if/when certain condition is met.
• Access to the configuration management (controllers) in the network domains where the SON actions are executed.
• Access to the policies, defined by the operator, that influence (e.g. restrict) execution of SON actions

Users and Benefits

This ONAP use case enables automated management of large scale disaggregated 5G radio access networks and E2E network slices.  It also enables the deployment and life cycle management of hybrid 5G networks (a combination of PNFs and VNFs)

Comment (Oskar M.) I think this description is related to the other sub cases (A and B)?

Comment (Vladimir Y.)  Deleted "lifecycle"