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

Compare with Current View Page History

« Previous Version 4 Next »

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.

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

  • 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.
  • New techniques for 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
  • New techniques for 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.

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

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.

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
  • Define policy evaluation to identify best possible slice / slice segment and service optimization action(s)
  • Create recipes for addressing slice performance degradation
  • Design data collection and analytics for various network optimization functions
  • Define policies / anomalies that indicate sub-optimal network performance
  • Define policy evaluation to identify the best possible optimization action(s)
  • Define SON coordination policies for the prevention, detection and resolution of conflicts or negative interactions of individual SON functions
  • Create recipes for executing network optimization steps (e.g. new configurations for RAN elements)

ONAP execution framework should support the following activities:

  • Start data collection in various DCAE instances and accessing historical data when needed
  • Perform needed SON analytics and generate an event when network impairments or service level violations are detected (e.g. when network optimization action is needed)
  • Trigger policy evaluation to identify the best solution to optimize network performance
  • Coordinate SON functions via policy evaluation to ensure that independently executing SON functions do not conflict or negatively interact with each other
  • Initiate radio access network change using SO and / or controllers
  • No labels