Architecture Description

Managing the performance management data fl ow in mobile network management solutions

Architecture Description 2

Performance management (PM) as part of an Operations Support System (OSS) solution for mobile communications network is a business critical area today, and its importance is rising as the networks themselves are evolving faster and faster. Although it may sound easy to implement an OSS performance management solution, it is a complex challenge. The traditional approaches to overcome it requires increasingly high investments and maintenance costs.

One way to simplify the solution and to drive down costs is to improve the effi ciency of the Key Performance Indicators (KPI) management in the OSS solution.

When the KPI calculation and the PM data reduction can be implemented already in the subnetwork element management layer, all other consumers of PM data in the OSS solution are able to access this information with much lower integration and maintenance costs.

However, the approach to move KPI calculation to the subnetwork management layer will only work successfully if two prerequisites are fulfi lled:• KPI harmonisation across vendors are achieved• KPI access interface harmonisation are established

On both topics, further development is visible. While interfaces are discussed in standardisation bodies like OSS/J or NGOSS, the two largest vendors for 3G radio access systems – Ericsson and Nokia – have as a proof of concept drafted a group of WCDMA KPIs to measure the performance of WCDMA access networks in a standardised, practical and comparable way.

Executive Summary

Architecture Description 3

Table of Contents

Executive Summary 2

Introduction 4

The need for performance data 4

The importance of KPIs 5

The challenge to build a PM solution in a cost-effi cient way 7

Recommendation of an OSS PM solution architecture 8KPI harmonisation 9KPI access interface harmonisation 9

Summary 9

Terms 10

References 10

Trademarks 10

About Ericsson 11About Nokia 11

Architecture Description 4

Controlresource

performance

RM&Osupport &readiness

Serviceconfiguration& activation

Resourcetrouble

management

Resource performancemonitoring & reporting rules,operations policies, training

Analyse & reportresource

performance

Monitorresource

performance

Resourceconstraintsreport,improvementproposals

Resourceperformanceindicators,violations

New resourcesresource configurationchange/update

Resource performancemanagement

Servicequality

management

Resource performanceimprovement requests

Service affectingresource performance data

Closedresourcetroublereport

Performancedegradation

indication

(Pre-processed)performance data &

data validity information

Resourcedata collection& processing

Resourceperformancereports,forecasts

(Resource controls likepolicing and shaping)

Improvement actions(processes, money, workforce,

resources, configurations,...)

The need for performance data

One cornerstone of each effi cient management system today is to determine the current status and the performance of the network resources that is is managing. The eTOM® model (TeleManagement Forum 2003) calls that process resource performance management. eTOM® as a framework provides a process view on OSS related processes. It defi nes the network performance management process as a part of the resource management & operations layer, and breaks it down into a range of OSS processes, defi ning the information fl ow between performance management and other parts of the OSS solution.

Figure 1. A level 3 breakdown of the eTOM® resource performance management.

Introduction The Operation Support Systems of this millennium are very complex. OSS systems have developed during the past 10–15 years, with the result that most service providers have multiple OSS applications and systems. These OSS systems are characterised by complexity and high operations and maintenance costs. This applies particularly to the performance management (PM) area. In this paper performance management is understood as the collection, processing and distribution of performance related information that is periodically collected from a mobile telecommunications network.

This paper will give a short overview of performance management, why it is done, how it is implemented today, and how this implementation might change in future, with a special focus on the calculation of key performance indicators (KPIs). Today’s implementation of performance management solutions with its layered approach – vendor specifi c subnetwork managers and multi-vendor network and service managers – will be analysed. It will show how performance management as part of the today’s complex OSS systems can be simplifi ed, giving more weight to a calculation of KPIs in the subnetwork management layer.

Architecture Description 5

From the eTOM® model, a variety of processes where network performance data is involved can be identifi ed:• Resource trouble management (i.e. monitoring of network performance)• Resource performance management (i.e. analysis of PM data)• Service problem management (i.e. monitoring of service level problems)• Service quality management (i.e. analysis of service level performance and quality)• Resource management and operations support and readiness (i.e. strategic planning

and implementation)• Service confi guration and activation (i.e. confi guration of services based on user

requests)

Through further dependencies, PM data may also target to customer facing processes as well as enterprise management processes.

To effi ciently operate the resource performance management process, different sources of information can be utilised.• Fault/Alarm related data – events/alarms are sent by a network element in case of a

failure or problem• Performance related data – data about the performance and other aspects of the

network is periodically produced by network elements. • Active measurements/synthetic probes – traffi c is injected into the network

(e.g. by sending an SMS or MMS). The network behaviour in relation to the injected data is measured.

• Non-intrusive probes – data on a specifi c type of calls is collected for instance from roaming subscribers typically by equipment other than the network elements themselves such as link analysers.

• Terminal based data – a relatively new approach, where the mobile phone itself collects data about the network or the services and sends this data to the OSS.

Each of these information sources can provide some understanding of the current network status to the network management. They may provide answers to certain questions about the network behaviour, while lacking in some aspects. For example, performance management data produced in the network elements provides a good view over a network element’s performance. But this information is usually not mobile phone or end-user specifi c, and it applies to all mobiles that are using that network element. Therefore traditional performance management data cannot be used to report on user-specifi c service level agreement.

Although eTOM® defi nes an abstract process framework, it is accurate enough to be mapped to most operators’ OSS organisations. However, regardless of the actual organisational structure, the conclusion is that performance management data is utilised, processed, visualised for and analysed by a multitude of departments or units within the operators’ organisations. And, by the different nature of their missions, each of these units or consumers of PM data has different needs and requirements related to the data, which will be further analysed in the next chapter.

The importance of KPIs

The amount of PM data that can be produced by a mobile network is immense. Each of the network elements in an operator’s mobile network can produce between about 40 up to 4000 different raw counters (typically grouped into “measurement types” of 10 to 200 counters) that describe its behaviour – depending on the importance, internal complexity and maturity level of that network element. A total amount of 104 different counters in a mobile network is a good estimation.

Architecture Description 6

Figure 2. Amount of PM data needed per eTOM® process.

Resourceperformancemanagement

Resourcetrouble

management

Serviceproblem

management

Servicequality

management

RM & O

Serviceconfiguration& activation

Enterprisemanagement

High Low

Needed granularity of PM data (”bandwidth”)

The total stream of PM data is calculated by taking into account• The amount of actually activated counters or measurement types (which counters

are sent)• The time granularity of a counter (how often it is sent, e.g. once per 15 minutes or

per hour)• The amount of objects in the network that produce this counter

Large networks can scale up to several hundreds of megabytes per hour – defi nitely a challenge for any OSS PM solution. When an operator defi nes its OSS architecture, the aspect of the reduction and refi nement of the PM data stream is of highest importance.

For each functional process (e.g. taken from eTOM®), the granularity of the PM information can be defi ned as proposed in Figure 2. There is a clear tendency in the OSS that the amount of data is reduced the closer the PM data consuming process is to the customer related processes. People in resource trouble management, for example, want to have access to a high amount of counters coming in with a high granularity, e.g. once per hour. This supports their tasks of effi ciently fi nding root causes of technical problems in the network. On the other hand, people in the enterprise management would like to condense the network behaviour into a handful of fi gures each month. They are not really interested in the thousands of details that the network is able to deliver (Best 2002).

Basically, there are three principles for the required reduction/refi nement: • Filter the number of counters• Plain aggregations • KPIs.

Reducing the amount of counters simply means that not all of the incoming raw counters are forwarded to all data consumers. Plain aggregation compresses raw counters along its “dimensions” as there might be time or network hierarchy. A counter that is hourly sent to the OSS by 2000 cells produces 1.440.000 values per month, while a process like service confi guration might require only one value for the whole network per month.

KPIs respond to the fact that many of the network element counters provide useful details about the network element, but do not provide as such a complete view on either complex technical processes (like a handover) or a customer experience (like a dropped call). So different counters are mathematically combined (using a “formula”) into so called “performance indicators”. From a set of available performance indicators, an operator chooses a small subset of those that from his viewpoint best represent the network behaviour as “key performance indicators” (KPIs) or even “key quality indicators” (KQIs) (TeleManagement Forum 2004).

Architecture Description 7

The challenge to build a PM solution in a cost-effi cient way

Although the concept of performance management is simple and straightforward, rapid network and service evolution makes it complex. But why is it so diffi cult to build a cost-effi cient PM solution? It sounds like a simple and straightforward approach to defi ne a few KPIs, and to make those accessible to the PM data consumers.

Unfortunately, this approach is not very easy to implement because:• Each network technology like radio access, switched or packet core requires its own

raw counters for troubleshooting and deep analysis of the element• For each technology, different vendors are offering their products, which have been

implemented using different architectures, which are differentiating on different aspects or are simply on a different maturity level. This implies that the raw counters in these network elements cannot always be calculated in the same way even for similar performance aspects (see the box below).

• Even though KPIs should be common across network equipment vendors and network operators, the actual calculation formula that is based on an element’s raw data is not. They differ between vendors, and change over time as the elements or the technology evolve.

• As network technologies development accelerates, the speed of change in the network architecture increases. New types of network elements are introduced, or existing implementations are changed rapidly, causing frequent changes to the KPI defi nitions.

• The lack of harmonised KPI defi nitions for different network technologies forces data consuming systems within an OSS solution to frequently “reinvent the wheel”. Structured approaches to defi ne the KPIs on paper for an organisation might help to harmonise the knowledge, but will not improve the implementation efforts for each consumer.

• Consistent interfaces to access the KPIs are currently missing in OSS solutions.

In a traditional PM solution, the different types of network elements are typically managed by specifi c subnetwork managers. They play a central role for a PM solution as they are responsible for the basic communication with the network elements, and receive all raw PM data that is needed by any party within the solution. A subnetwork manager is typically a system that is provided by the network technology vendor. The collection and interpretation of vendor specifi c raw counters is vendor specifi c and might vary over time.

A good example how equipment implementation can infl uence counter generation between network equipment vendors is the calculation of cell availability. Either you can sample the cell availability regularly, divide it by the amount of samples after the end of the time interval, or you calculate the times of cell unavailability due to planned and unplanned downtimes, and divide that by the measurement period at the end of the time interval.

Besides an effi cient data reduction, KPIs play also another role: by nature, their meaning is independent from a specifi c equipment vendor. By using KPIs, it is easier to achieve truly multi-vendor performance management without becoming locked into vendor-specifi c details.

All mechanisms to reduce and harmonise the PM data stream within a PM solution are heavily used in today’s OSS systems, typically as a combination of all three possible solutions. Hence KPIs are a broadly accepted concept, and the proper creation and management of KPIs is business critical for many operators today. However, its actual implementation has its challenges and depends on many factors, which will be further discussed in the next chapter.

Architecture Description 8

Recommendation of an OSS PM solution architecture

Summarising the fi ndings of the previous chapters, we can state that traditional PM solutions:• will face more and more raw data to process from an increasingly complex network.• will have more challenges to understand and implement different vendors’ KPIs from

a multitude of technologies and network elements.• will create more and more integration and maintenance costs to the OSS solution

How can this trend be stopped or reverted? There is no silver bullet available at the moment, but there is a development underway that has the potential to actually address this trend.

The essence is that the KPI calculation and the PM data reduction can be implemented already in the subnetwork management layer.

What actually makes this approach attractive?• It hides the complexity of the PM data to service, customer and business management

systems. When the amount of data which is moved through the OSS solution is reduced, it is easier to implement PM data consumers.

• It reduces the complexity of the whole OSS PM solution, allowing faster and more cost-effi cient technical integration.

• KPIs can be effi ciently developed and applied in the subnetwork manager in parallel to the network element releases, as both are typically provided by the same vendor.

• It offers fl exibility to provide raw data effi ciently to support troubleshooting and low level analysis by network element experts if needed, as the raw data is available in the subnetwork managers

• The solution works with all network technologies, it is not dependent on a certain platform or implementation in the network elements. The 2G and 3G equipment that has been rolled out to the fi eld does not require extensive changes or updates.

In the end, all benefi ts can be translated into reduced costs for implementing, running and maintaining a business critical part of an operator’s management solution.

Traditional network management systems as such multivendor and multitechnology systems typically adapt to the diverse subnetwork managers – at high integration and maintenance costs. Service management and other (customer oriented) functions might be utilising interfaces from subnetwork managers or TMN – or both, depending on the actual availability of data and interfaces.

Therefore the current constraints of the traditional multivendor PM systems lead to a situation where• Service and business management applications have to be integrated at a high cost.

For every $ 3 spent in OSS, about $ 1 is spent for systems integration (Gartner 2003).• Maintenance costs for keeping the integrations – and the whole solution – working

and up-to-date are high. This includes technical interfaces as well as KPI defi nitions. And as the speed of change in the managed networks accelerate, the maintenance costs will increase further.

• The network, service and customer management systems are unnecessarily loaded by a high amount of data and redundant calculation of the same information.

However, there are trends visible in the OSS market that will help to challenge these problems in the future, which will be discussed in the next chapter.

Architecture Description 9

However, the approach to move KPI calculation to the subnetwork management layer will only work successfully if two prerequisites are fulfi lled:• KPI harmonisation across vendors are achieved• KPI access interface harmonisation are established

Let’s have a closer look at these two issues.

KPI harmonisationFrom the network or service management point of view, a successful encapsulation of KPIs in the subnetwork managers means that the KPIs which are emitted from the different subnetworks are complete, comparable in their scope, and similar in their implementation. Under this precondition, managing the performance data in a multi-vendor environment becomes an easy and straightforward task, as the whole network can be treated as one domain.

Actually, as a proof of concept, the two largest vendors for 3G radio access systems – Ericsson and Nokia – have drafted a group of WCDMA KPIs to measure the performance of WCDMA access networks in a standardised, practical and comparable way (see Table 1).

The network element equipment vendors will – by the nature of this topic – take a signifi cant role in this kind of specifi cation work. Standardisation bodies should naturally serve as a driving force as well as a discussion forum on these topics.

KPI access interface harmonisationThe defi nition of the actual KPIs and their calculation is one side of the coin, the other side is the easy and harmonised access to the information in the subnetwork managers. By creating interfaces, or by utilising the efforts currently invested in standards or initiatives like OSS/J or NGOSS, the integration reference points (IRPs) for the KPI access can be harmonised across subnetwork management vendors. This will further simplify the total PM solution and drive down the costs for maintenance and implementation.

Table 1. Ericsson and Nokia drafted to the grouping of WCDMA KPIs.

Accessability: RRC Setup Success Rate Service Setup Success RateRetainability: Service Normal ReleaseUsage: Cell Availability CS Allocated Traffi c PS RAB throughputHandover: HHO success SHO successIntegrity: UL BLER

Summary It can be stated that in a market where KPIs and their access have been harmonised across equipment vendors, moving the KPI calculation to the subnetwork managers clearly has the potential to reduce the total costs of OSS systems.

The further plan is to invite vendors as well as operators to give feedback on this technical description and the KPI structuring and defi nitions, to fi nalise the current draft, and to submit the result as a contribution to the standardisation and industry fora like 3GPP, TMF and OSS/J.

Architecture Description 10

Terms 3GPP The 3rd Generation Partnership ProjectCS Circuit switchedIRPs Integration Reference PointsKPI Key Performance IndicatorNGOSS New Generation Operations Software and Systems (NGOSS) programOSS Operations Support SystemOSS/J OSS Through Java™ InitiativeTMF TeleManagement ForumTMN Telecommunication Management Network

References TeleManagement Forum. 2003. The Enhanced Telecom Operations Map®. Addendum D – GB921D.TeleManagement Forum. 2004. Wireless Service Measurements Handbook. GB923.Nokia. 2004. A new R&D Paradigm: Building OSS systems with standardized middleware. Best, I. 2002. Implementing Service Level Management. Comnitel Technologies.

Trademarks Java is a trademark of Sun Microsystems, Inc.eTOM® and NGOSS are trademarks of TeleManagement Forum

Architecture Description 11

About EricssonEricsson is the market leader in telecommunications. Providing innovative solutions in more than 140 countries, Ericsson is helping to create the most powerful communication companies in the world. Based on Ericsson’s deep understanding of consumer needs and with future evolution in mind, Ericsson is breaking new ground and driving the industry.

Copyright © Ericsson AB 2004. All products are subject to continued development and research. We reserve the right to alter any technical specifi cations without prior notice. All product names are trademarks of their respective owners.

About NokiaNokia is an active member of Telemanagement Forum Board and the OSS through Java Initiative, which brings a new level of openness and interoperability to network and service management environments. This work refl ects Nokia’s commitment to encouraging standardization and industry collaboration in order to gain new effi ciencies through plug and play OSS solutions.

Nokia is the world leader in mobile communications, driving the growth and sustainability of the broader mobility industry. Nokia is dedicated to enhancing people’s lives and productivity by providing easy-to-use and secure products like mobile phones, and solutions for imaging, games, media, mobile network operators and businesses. Nokia is a broadly held company with listings on fi ve major exchanges.

The contents of this document are copyright © 2004 Nokia. All rights reserved. A license is hereby granted to download and print a copy of this document for personal use only. No other license to any other intellectual property rights is granted herein. Unless expressly permitted herein, reproduction, transfer, distribution or storage of part or all of the contents in any form without the prior written permission of Nokia is prohibited.

The content of this document is provided “as is”, without warranties of any kind with regards its accuracy or reliability, and specifi cally excluding all implied warranties, for example of merchantability, fi tness for purpose, title and non-infringement. In no event shall Nokia be liable for any special, indirect or consequential damages, or any damages whatsoever resulting form loss of use, data or profi ts, arising out of or in connection with the use of the document. Nokia reserves the right to revise the document or withdraw it at any time without prior notice.

Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Nokia product names are either trademarks or registered trademarks of Nokia. Other product and company names mentioned herein may be trademarks or trade names of their respective owners.

Telefonaktiebolaget LM EricssonSE-164 83 Stockholm

SwedenPhone: +46 8 719 0000

www.ericsson.com

NOKIA CORPORATIONNetworks

P.O. Box 300FIN-00045 NOKIA GROUP, Finland

Phone: +358 (0) 7180 08000www.nokia.com

05/2

004

Indi

visu

al/D

igic

olor