We're not gonna take it anymore!

It's no secret that network engineers base their equipment decisions on 'capability' rather than 'manageability.' They don't make purchase decisions based on the manufacturers that have the best OSS capabilities. But with all the whining about inflexible OSSs and uncommon data formats, it's a wonder service providers don't put their requirements in RFPs.

'Why can't it be the service providers that dictate the direction of management and structure of data‾' asks Nancee Ruzicka, senior research analyst with Stratecast.

The good news is that is exactly what some pioneering service providers are starting to do. Tier ones like BT, Telstra,Vodafone and Chunghwa Telecom are throwing their weight around to push network equipment vendors and OSS companies to 'listen' as opposed to 'dictate.' The bad news is that it will be a while before the rest of the industry has even a handful of standardized assurance mechanisms that make their lives easier.

Part of the problem is that it's scary to risk losing a vendor on top of whose equipment your services run. 'But, how likely is it equipment vendors would allow themselves to lose customers wanting a say in their future‾' ponders Ruzicka rhetorically.

In fact, it's already happening. 'We are pushing to get our vendors to provide us standardized interfaces, as we have to integrate fragmented data across applications and

CASE STUDY
Chunghwa Telecom: Calling the shots

 

network types,' says Victor Chiu, VP of Chunghwa Telecom's Telecom Laboratory.  'In the near future, we can no longer throw manpower at it.'

Sounds simple

It's already evident that customers often perceive better quality from one service provider over another, despite the fact both may offer the same commoditized product, with the same functions and performance results.

You cannot cast a wide enough net to please all of your customers all of the time. 'It's just not possible with the mushrooming number of changeable parts - northbound interfaces from the network; southbound info from the OSS/BSS about customers; data about user devices from the west; and data from third parties coming from the east. Then on top of that, you have the data from network, servers and databases,' says Ruzicka.

Rather, service providers should concentrate first on services that target their most profitable customers. That doesn't necessarily mean their biggest, but their most valuable. There is a difference. Rather than hoard mounds of data to later boil down to a customer service level, service providers have to look at the network through a customer-device view, as opposed to a switch view. The evolution of services and consequent customer expectations outpace the evolution of network management capabilities and operations support, which means the vice grip engineers have on the network has too loosen to even begin to think in the manner that a Chunghwa or BT does. To loosen that grip, there are several growing pains that must be experienced.

One of the first is gaining an understanding all the network equipment players. Where traditionally, service providers might have managed a thousands systems from a handful of network equipment players, nowadays that same thousand systems might come from dozens of different suppliers.

 

Throw on top of that multiple types of access and transmission networks, different data services, myriad functions and feature sets, and you've got a recipe for disaster. The inability to manage all the pieces inevitably leads to swivel-chair management.

To eliminate manual processes, tighter integration is needed among the network, OSSs and customer-facing systems.  Achieving that integration is a long road, but a road nonetheless.
Only then can they have the flexibility to seek out the data in the network that reveals which customers are profitable. That data is usable by different audiences - customer-oriented types who need certain metrics and KPIs, and engineering types who need different metrics and KPIs.
'You want to get to a point where all your people learn what to parse immediately and what to throw into a data store,' says Ruzicka.

If each internal audience has what it needs, it can respond more dynamically.  If a Google launches a mobile phone application that combines email, web services and mobile advertising applications, the marketers need to expeditiously identify potential customers for those types of applications and devise their own service offering - or partner where appropriate in the value chain.

Starts with data integrity

To develop KPIs for each audience, service providers have to start with initiatives for data integrity. It's not a new concept, but one that has become more critical with new services.
'Too many times, inventory projects fail because service providers roll out new systems and load them with data that is accurate at first, but then becomes less accurate over time,' says Derek Bell, VP of product management for Subex, whose TrueSource product is the core of its automated fulfillment offerings. 'Within six to nine months, things can fall apart because updates and modifications aren't fed back to the appropriate systems. Everything then blows up because it's out of date.'

The ability to prioritize customers when a card or fault affects service requires correlation among inventory, fault management and CRM views with the network.

The first step is low-level aggregation of data - something that is addressed by most network management systems and element management systems today. Additionally, open interfaces can be used to combining common elements and schemes for data integration.

Like Chunghwa, Subex believes web services interfaces and JMS interfaces, as well as MTOSI and SID, will be key factors. The organization has used those frameworks and interfaces in TM Forum Catalysts involving Aricent, Ceon, Infosys Technologies and Progress Software - all of which collaborated to create an integrated BSS framework combining product lifecycle management, CRM, order management, provisioning and billing.

As the process of aggregating data evolves, there can be greater 'enrichment' of alarms. That means common and intuitive language can be used to detect and resolve problems.

'Rather than using 'crypticode,' such as referring to a piece of equipment as 'element 603,' you would have intuitive identification through common-language identifiers that point to size, location and other common words,' says Yoav Sapir, director of product management for TTI-Telecom, whose Netrac solutions focus on automating analysis and expediting the use of corrective actions.

'If engineers can see that it's a Cisco router on the third floor of building B, life gets a lot easier to take care of alarms and to proactively reach out to customers.'

 

He notes that the use of common language also helps to filter out 'derivative' alarms. Once clearer identification is possible, it's possible to reduce repeated events and the redundancies they inspire.

'That's when you start moving toward real-time assurance and fault management,' says Stratecast's Ruzicka.

Big and small

As they do so, service providers learn not to throw the baby out with the bath water. 'As they correlate device failures to home in on a big problem, they don't want to completely miss data about an issue important to individual customers, or large groups of them - even if it's not on the NOC's troubleshooting radar,' says Ruzicka, noting systems often are geared toward large failures, and miss smaller ones.

To demonstrate that concept, TTI-Telecom will partner with BT, Amdocs, Progress Software, Harris Stratex, tail-f, Telchemy and Nortel during the Harmony Catalyst at TM Forum's Management World Orlando in November.

As service providers continue to separate root cause alarms from derivative alarms, they can begin to detect patterns and consequently build rules-based correlation engines that enable 'deterministic scenarios' by examining network elements and probes.

According to Sapir, that means predicting what effects certain errors and alarms will have on other elements of a network. 'A level of prediction helps engineers determine what types of 'derived' problems might stem from a certain type of root cause problem. Once the root is fixed, the derivatives also cease,' says Sapir.

As data integrity improves, Sapir believes advanced 'topology-based' correlations can be used so that engineers can apply statistical rules to the topology of the network in order to predict likely scenarios.

Regardless of the labels applied to systems that allow people to detect patterns and 'learn' so they can be more intelligent, there's no question data is the key. Like the maxim says, 'you are what you eat,' and if you feed management and assurance systems with good data, you can work to do what the 'cool' Web 2.0-type companies do in terms of targeting and servicing customers.

Like Apple, Google, Amazon or Virgin, service providers have to put the customer first, not the network. Then they can develop systems that grow around the customer. It's time that the network and OSSs become slaves to that customer, as opposed to the other way around.

Susana Schwartz is marketing manager for the TM Forum's Collaborative Program and a long-time writer in the field of OSS/BSS