Challenges in Self Organizing Networks for Wireless Telecommunications

KN, Premnath#, Srinivasan Rajavelu*

#

Nokia Siemens Networks Pvt. Ltd., Bangalore, India

premnath.kn@nsn.com

Nokia Siemens Networks MEA FZ-LLC Dubai, UAE

srinivasan.rajavelu@nsn.com

Abstract Telecommunication network systems continue to emerge to meet the demand in Broadband Wireless Access (BWA) especially for data access through internet. The success of communication service providers (CSPs) rely on effective operational strategies to manage the network that includes planning, optimizing and maintenance of networks to meet the desired Quality of Service(QoS), Quality of Experience(QoE) and business goals. The operational effort and system resources involved in managing the network effectively are increasing the CAPEX and OPEX for CSP. Network Management Systems (NMS) plays a crucial role in commissioning, optimizing, healing and maintaining the telecommunication networks for increasing the operational efficiency. BWA technologies have emerged with Evolved Packet System (EPS) [1] that includes Long Term Evolution (LTE), System Architecture Evolution (SAE) and continue to emerge with Advanced LTE system as part of 3GPP standards. CSPs are slowly adapting BWA business model with the help of LTE, HSPA+ and WiMax systems. The existing wireless systems like GSM, UMTS and CDMA [1] systems continue to co-exist with BWA systems. The challenges faced by CSPs in managing the networks continue to increase for the heterogeneous telecommunication network systems which include access network elements, core network elements and service delivery platforms. As part of 3GPP LTE standardization Self Organizing Networks (SON) emerged as a preliminary standard and continue to mature for addressing the network operational efficiency. In this paper, for effective network operations the key challenges and other Non functional challenges for realizing the SON use cases(as per 3GPP Release 9 and Release 10) are highlighted, though challenges and nonfunctional challenges are not exclusively mentioned as part of standardization document. Keywords SON; LTE; Self Configuration; Self Organizing Networks; Self Optimization; Self Healing; Mobility Robustness; Cell Outage Compensation; Energy Saving; Automatic Neighbour Relation; Coverage and Capacity optimization; Load Balancing; Energy saving; SON Coordination

planning, configuration and optimisation processes via the use of SON functionalities can help the network operator to reduce OPEX by reducing manual involvement in such tasks. A. Self-Configuration brings a network element into service with minimal human operator intervention or none at all. Self-Configuration functionality minimizes Planning, basic configuration and Deployment tasks. [4] B. Self-Optimization brings effective usage of available network resources, frequencies in an optimized way. The function is to maximize network performance by optimizing the network configuration, taking into account characteristics of radio propagation, network traffic and UE mobility in the service area is effective. SelfOptimization functionality minimizes OPEX and improves end user experience. [5] C. Self-healing is to solve or mitigate the faults which could be solved automatically by triggering appropriate recovery actions. The trigger of Self-healing can be an alarm. The Self-healing functionality monitors the alarms, and when it finds alarm/s which could be solved automatically, it gathers more necessary information (e.g. measurements, testing result, etc) and does deep analysis, and then according to the analysis result, if necessary, it triggers appropriate recovery actions to solve the fault automatically. Self-healing functionality improves user experience. [6] II. REQUIREMENTS OF SON A. Operator use cases are currently done manually using network planning and optimization tools. Format of manually performing SON functions are referred as operator controlled or open loop solutions. The automatic way of performing operator use cases are referred as closed loop or autonomous solutions. SON solutions shall provide an easy transition from open loop (operator controlled) to closed loop (autonomous) operation that helps the operator to trust the reliability of SON functionalities. [3] B. The operator controlled or open loop SON functionality shall take effect only when the response is provided by the operator to proceed with proposed network configuration. [3]

I. INTRODUCTION Self Organizing Networks looks promising for managing telecommunication networks in an automated way. Framework, approaches and SON use-cases are evolved as part of 3GPP standardization process. Self Configuration [4], Self Optimization [5] and Self Healing [6] are the key functionalities of SON. Automation of some network

C. In case of closed loop or autonomous solutions, SON functionalities shall take effect without the response provided by the operator for the proposed network configuration. [3] D. New business cases like Radio Access Network (RAN) operator is emerging in the telecom industry. Also, telecom operators are open to partner their network with other operators. Hence the SON functionality implementation and SON architecture should support network sharing among operators. [3] E. A SON function can be enabled or disabled on Network Element (NE) or NMS. NE or NMS should be able to operate independent of enabling or disabling of SON functions. [3] III. USE CASES IN SON Following are the identified operator use cases that could benefit from SON functions. A. Automated Neighbour Relation (ANR): Network operator manually manages the Neighbour Relations (NRs). The key motivation behind ANR [2] use case is to automate manual process of managing NRs by the operator. The conceptual Neighbour Relation Table (NRT) resides in the eNB and managed by ANR function. ANR functions also have Neighbour Detection Function and Neighbour Removal Function which finds new neighbours and removes outdated NRs respectively. B. Neighbour List Optimization: On the basis of UE measurement reports neighbour list could be automatically reconfigured. So, the neighbour list will contain minimum set of cells necessary for handover. Newly reported cells are normally added into neighbour list. And cells with no handover attempts or few handover attempts or frequent handover failures are removed from the list. [7] C. Cell Outage Compensation (COC): Based on the equipment alarm COC function can be triggered. COC function should be triggered only if cell outage cannot be compensated by resetting to last known best configuration (cell software version update) or any known automatic cell recovery mechanisms. Until outage cell is manually recovered, by adjusting the coverage and handover parameters for the nearby neighbouring cells cell outage can be compensated. [7] D. Coverage and Capacity Optimization: The system capacity can be maximized by ensuring there is appropriate overlapping area between adjacent cells. This can be achieved by parameter settings related to Antenna tilt and power pilot among the related cells. Other key scenarios are related to compensating coverage holes by using inter Radio Access Technologies (RAT). Example: Like GSM or WCDMA coverage for compensating LTE coverage holes. Also compensating LTE coverage holes with other RAT technologies like CDMA, WiMax. [7] E. Interference Control: Uplink and downlink inter cell interference coordination are key scenarios in interference control. Effective coordination techniques like inter cell interference coordination are essential to compensate for

system performance loss and increase cell edge users bit rate. [7] F. Load Balancing: Scenarios related to overlapping coverage, hierarchical coverage and neighbouring coverage shall be included on load balancing. Especially for intra-frequency (same frequency), inter-frequency (across frequency) and inter RAT (across RAN technologies). [7] G. Mobility Robustness and Load Balancing: Hand over (HO) parameter optimization SON functionality shall aim at reducing the number of HO failures, increasing the HO success rate as well as reducing inefficient use of network resources (like Bearer Setup) due to unnecessary handovers. The cell reselection and handover thresholds of the UEs in the edge of the congested cell are adjusted to handover to the less congested adjacent cells. The HO parameter optimization should aim at detecting and mitigating too early HOs, too late HOs and HOs to a wrong cell leading to HO failures. [7] H. Power or Energy Saving: Certain cells are busy only during peak hours or certain time of the day. Latest power consumption reports indicate that base station towers consume more energy and causes ecological damage related to high consumption of fossil fuel for power generation in developing countries. The capacity of the cells that remain unutilized could be detected based on usage measurements and put to standby mode periodically and activating nearby cells using other SON use cases like cell outage compensation. The main energy saving potential results from variations in load over time. [7] IV. BASIC FRAMEWORK IN SON There are four different architectures that are possible for implementing various SON use cases. The architecture is selected depending on the needs of the SON use cases. [3] A. Centralized: SON functionalities where SON algorithms are executed in the Operator and Maintenance (OAM) system. Centralised SON has two variants: 1) NM-Centralised SON: SON solution where SON algorithms are executed at the Network Management level (NM level). [3] 2) EM-Centralised SON: SON solution where SON algorithms are executed at the Element Management level (EM level). [3] B. Distributed: SON solution where SON algorithms are executed at the Network element level (NE level) Example: eNodeB itself. [3] C. Hybrid: SON solution where SON algorithms are executed at two or more of the following levels: NE or EM or NM. [3] SON use cases are realized as part of SON functionalities. SON functionalities can be implemented in all the four SON architecture. Every SON architecture type has its advantages and drawbacks. The key differentiator of SON architecture lies in performance of the use-case and the cost factors that influence the right architecture. SON architecture classification such as Centralized, Hybrid and Distributed

SON gives an operator a flexibility to activate the SON functionality at NMS, EM or at NE level.

Fig. 1 A sample Network Cluster with SON functionalities residing at NMS, EM and NEs.

The SON use case that involves Network level analysis involving different Network Element types across the network then preferably the use case is implemented as part of SON functionalities residing at NM-Centralized SON. If the use case involves element level analysis across multiple elements of same type (Ex: Across multiple eNBs) then preferably the use case is implemented as part of SON functionalities residing at EM-Centralized SON. The SON use case that can be handled at the network element level is preferably implemented as part of SON functionalities residing at Distributed SON. SON functionalities preferably residing at Network Element referred as Distributed SON is the mostly preferred solution by operators. Distributed SON functionalities make use of User Equipment (UE) measurements for successful SON functionalities (Ex: ANR). Since UE is supplied by many vendors and not all vendors guarantee to support SON specific needs Distributed SON cannot be fully realized. Hence there is a need to activate the same use-case as part of Centralized SON. Based on the effectiveness of the system, operator could decide to activate appropriate SON functions. Some of the SON use cases require network level information as well as immediate reaction based on network element condition. Such use cases are preferably implemented as part of SON functionalities residing on the NMS as well on the Network Element. Such SON functionality is referred as Hybrid SON. V. CHALLENGES A. Challenges for realizing a SON use case by operators are as follows: 1) Vendor Agnostic: Different vendors adopt different strategies in realizing SON use cases.

2) Interworking: Interworking of SON use cases across different vendor equipments and their management systems. 3) SON Use case Transition: SON Use case transition from operator assisted open loop to closed loop SON functions. This requires a SON process flow framework that learns the operator work flow and automatically creates a transition for closed loop SON functions. 4) Approaches: Different approaches based on Framework can be used for realizing SON use cases. Approaches currently available in the standard include Centralized or Distributed or Hybrid approach. Based on operator business need and reaction time for SON functions, SON use cases could be implemented in any approach. Every SON use case implementation requires use case specific realization, complying with some of the non-functional requirement which is not related to the use cases directly. For example, SON functionality residing on the Network Elements (NEs) should comply with the interfaces that are required to deploy the SON functionalities on a NE environment. Shortly, there is a special deployment need to configure the SON functionalities on Distributed, Hybrid and Centralized SON. This could potentially influence the functional level implementation of SON use case itself. One approach to address the above challenge is with help of a controller function referred as SON Coordinator [8]. SON Coordinator co-ordinates the use cases, activities between the SON functions.

Fig. 2 SON Coordinator coordinates the SON functionalities residing across network.

SON Coordinator coordinates the SON functionalities and the SON use cases residing across the operator network. Interworking challenge of SON use case between NEs of same type but with different Vendor can be mitigated using SON Coordinator. SON Coordinator could potentially coordinate the information exchange between NEs using standard web-service based interfaces. The heterogeneous properties like vendor specific interfaces, data model can be

abstracted at SON coordinator level, so the information could be successfully exchanged. B. Non functional challenges in implementing SON use cases are as follows: 1) Soft Computing Algorithms: Availability or usage of efficient Heuristic algorithms in Centralized SON. Neural network approaches for self learning of network through which automatic decisions are made based on past experience that would facilitate the Self Organizing aspects of the network. Since the network size of the operator could be huge, such self learning methods and problem solving genetic algorithm techniques could facilitate new horizons in SON. Availability and applying of such proven algorithms for SON aspects is a challenge. 2) Control and Sequencing: Control and sequencing of mutually exclusive SON use cases and its impact on network. Some of the SON use cases are contradictory and requires clear sequencing. Example: Cell outage compensation could get triggered for a cell which is put on stand-by mode by power optimization SON algorithms. This demands a SON controller or coordinator [8] to effectively handle SON use cases. All the SON use cases cannot be run in parallel. The probable reason could be the SON framework or the nature of the use case itself. 3) Classification methodologies and Prediction Techniques: Clear classification, association methodologies and prediction techniques should be available to predict what would be the success of proposed network configuration changes based on SON algorithms and classifying the network based on predicted success. 4) Recovery mechanisms: Recovery mechanisms that include Reset to factory defaults, Reverting the network configuration to a pre determined state or earlier state. 5) Avoiding Network Overload and scalable use case: Network overload or degrade in network performance due to additional load on network equipments for real time decisions. Also, the SON functionalities should be scalable according to the size of the network. For example a green field network would not have many network deployed. Over the time when the capacity increases the network moves to further stage like evolving and mature network. The use cases implemented as part of SON functionalities should be scalable across green field, evolving and mature network.

VI. CONCLUSIONS In this paper the widely adopted SON functionalities, use cases, framework and its challenges are discussed. Since the transition of operator use cases are going to be from open loop to closed loop SON functions, network management eco system demands mindset change for the way the features are designed, implemented and used. The results proposed by SON functionalities should be predictable results on the network. The non functional requirements published in this paper are some of the initial indications for further research. The need of this study is to identify the challenges in SON for telecommunication networks. Based on the challenges listed in this paper further research possibilities has been opened for adapting mathematical modeling and advanced computing techniques for effective SON solutions in telecommunication networks. ACKNOWLEDGMENT The authors would like to acknowledge 3GPP, NGMN for the standardization specification related to SON and the SON need realized by operators as part of NGMN. The authors would like to thank their employer Nokia Siemens Networks for providing the necessary support to perform research and development in SON. The authors would like to appreciate and thank ICRTIT 2011 for providing an opportunity to offer the plenary talk on SON subject so the potential of research in advance computing can be explored, researched and later applied in realizing effective SON use cases. REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] 3GPP TS 21.905, Vocabulary for 3GPP Specifications (Rel. 10), Mar. 2010. 3GPP TS 36.300, Evolved Universal Terrestrial Radio Access (EUTRA) and Evolved Universal Terrestrial Radio Access Network (EUTRAN); Overall description; Stage 2 (Rel. 10), Dec. 2010. 3GPP TS 32.500, Telecommunication management; Self-Organizing Networks (SON); Concepts and requirements (Rel. 10), Sep. 2010. 3GPP TS 32.501, Telecommunication management; Selfconfiguration of network elements; Concepts and requirements (Rel. 9), Mar. 2010. 3GPP TS 32.521, Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP); Requirements (Rel. 9), Mar. 2010. 3GPP TS 32.541, Telecommunication management; Self-Organizing Networks (SON); Self-healing concepts and requirements (Rel. 10), Jul. 2010. NEC Corporation, White Paper - Self Organizing Network, NEC's proposals for next-generation radio network management, Feb. 2009. Socrates Research Project, FP7 SOCRATES Final Workshop on SelfOrganization in Mobile Networks, Feb. 2011. [Online] Available: http://www.fp7socrates.org/files/Presentations/SOCRATES_2010_NGMN%20OPE% 20workshop%20presentation.pdf