Exploring the cloudified BSS TextStart Cloud computing stepped

advertisement
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
Download