Exploring the cloudified bss

Exploring the cloudified BSS
TextStart

Cloud computing stepped decisively into the spotlight in 2011 with the emergence of clouds in various areas including computing, storage, security, and testing. This has encouraged operators such as Vodafone, China Mobile, and China Telecom to rapidly enter the cloud arena. What is the essence of cloud computing and how will it impact the Business Support System (BSS)?

By changing the business model from buying to leasing, cloud computing will inevitably change the division of work of all parties in the entire BSS ecosystem, including managed service providers, integrated service providers, and software and hardware vendors. In cloud computing era, operators will outsource their BSS to cloud service provider and become end user of BSS cloud, allowing them to focus on SLAs and customer experience. BSS cloud service providers can also share resources on a larger scale through virtualized hardware and multi-tenant architecture software, providing more operators with cheaper services, superior experiences, and improved efficiency.

BSS vendors must prioritize mergers and acquisitions as long-term strategies through which to vertically consolidate the value chain and secure dominance in terms of market share and technologies. Only in this way can they survive and thrive by providing better BSS cloud service.

BSS can be deployed in private or public cloud. Given the current technologies, the Internet-based public cloud applications are more tolerant to delays, downtime, and data leakage. However, telecom operators have higher requirements on the service availability of a BSS. BSS failures can lead to decreased customer satisfaction and revenue loss. In addition, BSS customer data is a critical information asset and operators cannot control the data leakage in a public cloud. Therefore, most operators will lease or construct private clouds for BSS over the next five years. BSS must be cloudified to build a BSS could, and we will further discuss the features and principles of a cloudified BSS.

Features of a cloudified BSS

What are the features and benefits of a cloudified BSS? According to The NIST Definition of Cloud Computing, a cloudified BSS should have the following six key features:

1) Enterprise-wide sharing: A cloudified BSS should maximize the IT resource sharing rather than using separate IT systems for each region or subsidiary. The BSS can then encapsulate applications as services, and flexibly support business processes and coordination within or among enterprises by orchestrating these services. Additionally, multi-tenant mode enables a cloudified BSS to support autonomous and differentiated operations within different regions or subsidiaries.

2) SLA-driven dynamic deployment and scheduling, dynamic scaling-on-demand, and self-healing mechanisms: The dynamic deployment and scheduling mechanism dynamically deploys or schedules applications based on SLAs to ensure that hardware can be fully shared and optimally utilized; dynamic scaling-on-demand evaluates service or data volumes to optimally pool resources and provide services that guarantee SLAs; self-healing automates the troubleshooting of failures based on SLAs without affecting service quality or user experience.

3) Convenient access anywhere, anytime: Customers can smoothly access services from any access point via compact or virtual terminal devices.

4) Fully virtualized architecture: The storage, computer, and network infrastructure are all virtualized, while physical locations are transparent. Application software is independent of hardware. Multiple applications can run on the same physical computer; or multiple physical computers can be a logical computer to run a large-scale application transparently.

5) Dynamic data distribution, real-time synchronization, and lifecycle management: Dynamic data distribution in a data-centric context enables the BSS to support linear scalability and leverage hardware resources; real-time synchronization ensures high system availability; data lifecycle management serves as the basis for both dynamic data distribution and real-time synchronization.

6) Automated intelligent management: This covers the end-to-end monitoring and control of the entire computing environment including applications, middleware and hardware. Little manual intervention is needed as the system automates SLA-based deployment and scheduling, dynamic scaling-on-demand, and self-healing.

Realization of these six features position the cloudified BSS as an evolved system that can realize the goals beyond traditional BSSs: lowering construction and O&M costs; ensuring better service quality and QoE; adapting to rapidly changing business models and requirements. However, the SLA-based self-healing mechanism accelerates troubleshooting and improves QoE, full resource sharing reduces expenditure on hardware, and automated system management lowers O&M costs.

The cloudified BSS differs from a virtualized BSS in several ways. Virtualization generally refers to the logical representation of physical resources; for example, host virtualization divides one physical host into multiple logical hosts, storage virtualization divides a physical storage pool into multiple logical storage devices, and desktop virtualization centralizes scattered physical desktop clients into one logical desktop client.

Virtualization may enable hardware resource-sharing, but it cannot make a cloudified BSS. Storage virtualization, for example, is unable to dynamically distribute application data; equally, host virtualization cannot converge small-granularity hardware. While an important supplement for cloud computing, virtualization does not underpin the conversion process to a cloudified BSS.

Migrating to a cloudified BSS

Realizing the six major characteristics of a cloudified BSS to deliver its expected benefits presents considerable challenges in terms of operation management, processes, architecture, technology, and O&M management.

Integrated operations

The cloudified BSS is designed to enhance operating efficiency and lower costs, especially IT costs. Operators generally adopt separate operation management, for example, setting up different business units for fixed, mobile and broadband services while establishing branches based on regional divisions. Without operating synergy, this leads to poor efficiency and degraded service experience, meaning that inter-departmental service flows need to be streamlined to synergize.

The transformation of operation modes and service flows requires management restructuring, which would take a considerable amount of time. Operating synergy not only enhances competiveness and efficiency, but also optimizes the sharing of IT resources such as hardware and software. Another difficulty involves the support mechanism for differentiated operations. To do so, operators need to convert business capabilities into services and then flexibly manage these services and their related processes.

Platform to meet SLAs

In terms of applications, a cloudified BSS requires full isolation between the functional and non-functional features. The functional features include business logic; the non-functional features cover system deployment, performance, reliability, scalability, and maintenance.

The cloudified BSS can realize SLA-based deployment and scheduling, dynamic scaling-on-demand and self-healing without complicating operations. This assures SLAs through the service platform alone, allowing presentation logic, functional logic, data storage, and access logic to exist outside of the SLA. The service platform can deploy applications across the optimal hardware – such as a highly reliable cluster – based on a given SLA. As SLAs may specify times for response, processing and interruptions, the system can monitor SLA requirements and implement dynamic scaling to meet these requirements.

If a service platform detects an increased traffic load but the system responds slowly, the platform can reroute the traffic and allocate a new server to share the load while still meeting the SLA. After lowering the system load, the platform can then reroute traffic again to reduce the number of servers required.

Data access can also decrease speeds to an extent that breaches SLA requirements if the data in a data table increases. In this case, the system can dynamically divide and then distribute a data table among multiple databases. It can also change the data route and assign the access request to multiple databases to ensure that the SLA is met. If a fault occurs in a database, host, or storage device, the system self-heals based on SLA specifications.

A legacy BSS must be maximally configured (at two to three times the average configuration) to meet peak hour traffic. Moreover, operators opt for static hardware configuration, which fails to reduce traffic pressures as applications have different peak hours. In this context, hardware utilization can be lowered to 30 to 40%. Applications must be deployed dynamically to maximize the hardware utilization rate and lower the IT costs. For example, a settlement system can free idle capacity to the CRM and billing systems during the day.

Isolated service and technology layers

The service functions in the system architecture of the service platform must be isolated from the infrastructure, including hardware, middleware, and databases. As a result, service functionality does not rely on a specific technology and the service platform would employ a distributed application and data structure. Isolating the service platform from the infrastructure also ensures that the optimal technology is adopted in terms of cost and efficiency. For example, a traditional BSS adapts well to centralized architecture in minicomputer mode, yet it cannot use lower cost blade servers.

The rapid growth in users and services may compromise the system reliability and performance offered by centralized architecture; for example, a minor fault can affect QoE for a large user base. Migrating a legacy BSS to distributed database architecture involves a massive workload and is impractical. To ensure optimal cost and efficiency, the service functions and infrastructure should be removed from the BSS architecture.

Smart and automatic O&M

A cloudified BSS demands smart, automated O&M. Manual maintenance frequently interrupts services and is prone to human error – even a simple upgrade can degrade service quality for a considerable time. In contrast, operators can enhance QoE by presetting rules to automatically upgrade and troubleshoot faults.

Huawei continues to explore the cloudified BSS and is active in fields such as automated management, distributed application architecture, and distributed data access. Huawei is making a decisive contribution to the next-generation cloudified BSS and is ready to assist operators to deliver added value.

TextEnd