APPLICATION NOTE. Elastic Scalability. for HetNet Deployment, Management & Optimization

Transcription

1 APPLICATION NOTE Elastic Scalability for HetNet Deployment, Management & Optimization

2 Introduction Most industry reports indicate that the HetNet market is poised for explosive growth in the coming years. Densification of the cellular network will see carriers deploying large numbers of small cells and Wi-Fi access points, often in a separate layer from the macrocells, to deliver high capacity in a targeted way close to the users. In the HetNet, cells of many sizes, air interfaces and spectrum (including Wi-Fi) are combined to form a seamless pool of flexible capacity. A variety of service provider types will offer services in this landscape Mobile Network Operators (MNOs), Multi-System Operators (MSOs), Internet Service Providers (ISPs) etc. either rolling out their own networks or piggybacking on networks deployed by others. While carriers have been deploying networks for decades, small cells will present an entirely different challenge as far as scalability goes. The scale of the future HetNet will be an order of magnitude more expansive than that of today s network. The sheer numbers of small cells deployed by carriers will be on a scale unprecedented in the wireless industry. Add carrier managed Wi-Fi to this, and the numbers become staggering. Tomorrow s HetNet management solutions will not only need to enable accelerated, plug-n-play deployment, but also support in and/or out scaling in a dynamically growing environment where deployments will not always be planned. Residential or homespot access points, for example, can proliferate in a less planned fashion, leading to unpredictable spikes in the load on the network management system. Even in the case of planned deployments, carriers will deploy heterogeneous access points in numbers far larger than seen today in macrocell deployments. 8,000,000 Cellular only WiFi/cellular WiFi only 7,000,000 6,000,000 5,000,000 Sites 4,000,000 3,000,000 2,000,000 1,000, Figure 1: Activation of New Access Points Yearly XCellAir Scalability Application Note 1

3 Growth will be driven by: (a) geographical requirements the need to deploy access points in new areas; and (b) auto-scaling based on access points added and/or taken out of existing coverage areas. Managing these networks in a scalable fashion will present significant challenges, and will require solutions architected from the ground up for scalability. Closely linked to the requirement for scalability is reliability the ability to maintain the required level of network management performance under high load, even when individual system components fail. This implies the need for load balancing and failover schemes, facilitating seamless switchover and redistribution of load between physical servers when failures occur. XCellAir s cloud based system allows service providers accelerated HetNet deployment, management, optimization and monetization. Uniquely, it blends Self-Organizing Network (SON) and Radio Resource Management (RRM) with traditional network management functionality, enabling plug-n-play, adaptive, interference-aware control of the network. The solution also differentiates itself from the competition in the way it scales in a fine-grained manner. The XCellAir system addresses scalability at multiple levels: A highly efficient and optimized design that minimizes resource allocation requirements per access point deployed; A cloud-based design from the onset, where management functionality is virtualized across commodity servers in the cloud, enabling granular in/out scaling as the network configuration changes in real time; By providing cloud orchestration, provisioning and monitoring tools to facilitate fine-grained auto-scaling of network management capacity. The system s Business Logic components are designed for scalability, with cleanly decoupled functional layers. Front End entities provide stateless interfaces to access points, and are typically implemented within Web containers. Communication between functional entities is largely via a queue management system, keeping the layers sufficiently decoupled from one another. The Services block contains the smarts of the system, and includes the algorithms to discover, provision and manage the access points in an adaptive, self-organizing manner. The Backend block includes the database, visualization and orchestration interfaces. These entities are fully unified and agnostic to the type of access point (Wi-Fi, cellular) being managed. Radio Map Cluster Stack ( Business Logic ) DATABASE VM Configuration SERVICES VM FRONT END VM QUEUE MANAGEMENT VM Front End Load Balancer RRM Fault Mgmt Front End SON Load Balancer Figure 2: Functional Architecture XCellAir Scalability Application Note 2

4 DESIGNED TO SCALE A Product with Elasticity at its Core The XCellAir system s Business Logic components have been designed from the outset to run on a scalable cloud framework. The architecture provides the modularity, partitioning, self-containment and portability to scale reliably on various cloud frameworks, public or private. An Efficient Architecture and Implementation XCellAir s implementation minimizes system resource requirements (processing, memory, storage, network bandwidth) for the support of each access point being managed. Stated another way, the design maximizes the number of access points that can be supported by a given server configuration (processor, memory, storage etc.) and ensures highly optimal usage of available resources. The following design tenets enable this: A largely stateless implementation minimizes the amount of context (and therefore memory and storage resources) that needs to be maintained within the system. The use of in-memory caching to reduce storage requirements and increase data read and/or write throughput Lightweight REST-style interfaces for inter-component communication The use of non-relational (NoSQL) database technology to facilitate elastic horizontal database scaling based on capacity needs. Loosely Coupled Layers Enable Fine-grained Independent Scaling The system functionality is organized into cleanly decoupled layers, as depicted in Figure 2. Each layer of functionality (Front-End, Services, Database) is deployed within a virtual machine (VM) structure in the cloud, and scales independently based on its own loading. Seamless communication is effected between virtual machines as they migrate across physical servers. Self-contained Virtual Machine Design The system components are self-contained, in that virtual machine instances are decoupled from one another. The design obviates the need for communication or data sharing between virtual machine instances, as the system scales horizontally and new VMs are instantiated to meet capacity needs. XCellAir Scalability Application Note 3

5 Cloud Framework Independence The system s Business Logic components have zero dependence on the cloud framework they run on. Where third-party components are used, they are industry-standard utilities with abstractions and/or wrappers for easy portability. The software is fully portable across cloud frameworks. Headline Here? Fghg Ghghgggh Gh Chunk 1 Chunk 2 Chunk 3 Load Balancing on the Front End The Front-End components receive requests from access points and operator consoles, and funnel them into the Service Layer XCellAir s system. The Front-End (FE) blocks are designed to handle heavy message loads in a scalable, resilient, fail-safe fashion. They are instantiated on virtual machines, and are independently scalable based on load. FE virtualization also ensures automatic redistribution of message load across available FEs in case of a specific FE instance failing. Load balancing functions reside downstream from the Front-End functions, and route incoming messages to the appropriate FE instances based on the existing load distribution. If a particular FE instance fails, load is automatically distributed amongst the other healthy FE copies. Database Scalability The databases at the backend of the system have the capacity to store large amounts of information, pertaining to access point provisioning, alarms and faults, radio resource allocation specifics and user (operator) profiles. As the network grows, high throughput from access points can challenge the capacity of a single database server. High query rates can exhaust the CPU capacity of a single server. Large data sets can similarly stretch the storage capacity of a single server. Radio Map DATABASE VM SHARED APPLICATIONS VM Configuration RRM Fault Mgmt SON Figure 3: Database Horizontal Scaling XCellAir s system uses horizontal scaling, or sharding, to ensure the databases scale to meet capacity needs. Sharding essentially divides the data set for a Cluster of access points and distributes it over multiple servers or shards, instantiated on the cloud as virtual machines. This reduces the number of operations each server needs to handle, as well as the amount of data each server needs to store. Replicas of shards are created and maintained, providing redundancy and high availability for the data in each shard. As the data set grows, the system automatically splits, resizes and reallocates data chunks across shards to maintain a balanced distribution of data across servers. XCellAir Scalability Application Note 4

6 Replete with Orchestration & Provisioning Tools to Enable Plug-n-Play Deployment and Automatic Scaling XCellAir s solution comes with the orchestration, provisioning and monitoring tools needed to make deployment and scaling fully automated and seamless. The system visualizes the HetNet as a collection of Clusters, each Cluster encompassing a potentially large number of access points. The service provider can dimension a Cluster to be as large as required. For example, the entire city of Montreal could be a Cluster. New Cluster Deployment The system is deployed in the service provider s cloud framework as a Cluster Stack. The Cluster Stack shown in Figure 4 below represents the functionality (i.e. the Business Logic) to manage and optimize a Cluster of access points. XCellAir s system includes orchestration and provisioning tools that enable one-touch, plug-nplay deployment of the Cluster Stack. Once the Stack is deployed and provisioned in the cloud, physical access points can be deployed, and the system will discover, provision and manage the access points. The Infrastructure Admin Server (IAS) shown in Figure 4 coordinates the orchestration and provisioning procedures required to launch, configure and inter-connect the various components in the Cluster Stack. The process is triggered by a single click on the management terminal. The IAS communicates with the cloud framework (public or private) to create and launch the base set of virtual machines (VMs) that are required for the Stack to be operational. The cloud framework allocates physical resources (processors, memory, storage etc.) needed for each VM, and ensures that each VM is up and running. Inter-VM connectivity is established, as per provisioning recipes that are loaded into each VM as part of its startup. Single-Touch, Plug-n-Play Process The Cluster Stack startup process is fully automated, driven by a single click from the user terminal. Horizontal Auto-Scaling Based on Capacity Needs The same set of orchestration, provisioning and monitoring tools enable the system to scale automatically with network and management traffic growth. A monitoring client within a VM monitors key performance parameters to determine whether resources need to be added or removed. When target parameters cross defined thresholds, indications are sent to the IAS, which works with the cloud framework to add or remove VMs. Cloud Framework Independent Process The use of open source tools and XCellAir-developed components makes the orchestration process minimally dependent on the cloud framework being used. With minimal adaptation, the IAS can work with various cloud frameworks. Various Integration Models Supported Multiple approaches are possible for integration of XCellAir s Server functionality into the service provider s framework. Both public and private cloud approaches are supported. The service provider can use the IAS to orchestrate, provision and monitor the system. In case the service provider wishes to use their own orchestration tools, the design of the system enables simplified integration with alternative tool sets. XCellAir Scalability Application Note 5

7 Cluster Stack ( Business Logic ) Cloud Provisioning Plane DATABASE VM CLOUD FRAMEWORK (public or private) VM Image Catalog SERVICES VM Orchestration Engine Orchestration API Radio Map RRM SON Configuration Fault Mgmt FRONT END VM Orchestration Client Provisioning Server QUEUE MANAGEMENT VM Monitoring Server Repository Provisioning Service (Java App) FRONT END VM Front End Front End MANAGEMENT TERMINAL Provisioning Service (Java App) Load Balancer Load Balancer Figure 4: Cluster Stack & Orchestration Plane XCellAir Scalability Application Note 6

8 Conclusion The demand for data services and always-on connectivity is growing with no end in sight. If wireless carriers are going to effectively service and tap into the revenue potential of this demand they need to bring the radio access network closer to the user and take advantage of all types of spectrum. To date the deployment of HetNets has been limited due to operational expense, interference and scalability concerns. XCellAir s cloud-based system modernizes the operations of carrier HetNets getting the most from their largely untapped potential. In addition, the system delivers these capabilities in a highly scalable fashion, allowing XCellAir to enable true RAN densification. For more information on XCellAir s solution, please contact [email protected] or visit our website Phone: [email protected] 6540 Lusk Blvd, San Diego, CA 92121, Suite 210 Copyright 2015 XCellAir. All Rights Reserved. AN_001_201502