SERVICE PROVIDERS OSS/BSS: Talk Components Talk

That Indian telecom industry is growing at a phenomenal rate is a clichéd
statement. It surprises only the ignorant.

Managing subscriber growth has turned from simple to complex, and still
telcos are always hungry for more. These are exciting times for telcos. These
are challenging times too, for their OSS/BSS departments. Billing, the star
component of BSS, has not ceased to be a nightmare for the CIO. More than one
telco continues to grapple with billing-related problems. QoS, a critical OSS
component, remains a cause of constant worry to the CTO.

Issues and challenges

Consolidation of various billing-related systems-legacy, acquired, and new-remains
a concern area. With big private operators like Bharti and Hutchison, it's
important in the wake of acquisitions. With state-owned operators, particularly
BSNL, a CDR-based billing project keep the interest alive.

A common problem facing operators is that the CRM system often seems to be
not talking to other systems like billing. This despite the fact that
integration of various components like billing, CRM, fraud management, etc. is
considered critical to both revenue maximization and customer satisfaction.

What are the integration challenges of new access networks/WLAN hotspots from
an OSS/BSS perspective? What are the arguments for using best-of-breed OSS
solutions for these specialized networks?

As far as QoS is concerned, the challenge before telcos is to be able to
attend to the related issues in existing networks even while expanding to newer
areas. Inter-carrier billing is another gray area. Fraud management is also a
growing concern, with inter-operator fraud adding a new dimension to the whole
aspect. One is also not oblivious of the developments on the global OSS/BSS
landscape. One such development is the TeleManagement Forum's NGOSS
initiative. Yet another important development in the OSS space has been the OSS
through Java (OSS/J) initiative.

Indian telcos will like to understand what such global initiatives mean to
them. What tangible benefits can one look at by adopting the guidelines offered
by such initiatives?

Offerings and Trends

The real service enabling platforms in the BSS/OSS mix are, billing and
ordering, usage mediation, and service activation.

Therefore, it is imperative that these components are either pre-integrated
or integrated first. Subsequent to service enablement and integration of the
above components, it makes sense to invest in and integrate other systems such
as fraud management, point-of-sale systems, and CRM

systems.

Some operators seem to currently use CRM solutions as the focal point for a
single point of contact. This has resulted in duplication of systems, databases,
staff and created myriad problems in providing good service to the customers
because of the lack of integration between these systems.

What is required is a common framework that allows plugging in of various
components from single or multiple vendors. The priority should be to provide a
good customer experience first which points to modules like billing, customer
assurance (CRM, loyalty, retention and call center), service assurance, and
revenue assurance.

OSS for hotspots: Operators have been deploying new access networks,
particularly WLAN hotspots, in metros. An argument here is for using
best-of-breed OSS solutions for these specialized networks.

A counter argument is that best-of-breed solutions can only be an interim
solution. Integrating best-of-breed itself is a problem and a permanent solution
is to integrate the functionality through the use of standards across vendors.

In this regard, the key integration points would be:

• Instant or on-demand activation of accounts in a WLAN service
• Real-time collection, mediation of usage data
• Real-time authorization and balance management
• Self-care systems integrated to ordering and billing system

The key lies in integrating disparate systems that support
different technologies, architectures, and interface protocols, and doing all of
this before launching the service.

Billing-where lies the problem?:

• It's debated quite often whether billing is a
  technology- or product-related issue or a process/implementation-related
  issue. It has been seen that most cases, this is not a technology or
  product-related issue, though this could be true in some isolated cases.
  More often than not, the real reason could be one or more of the following:

• Systems have been implemented in fairly tight timeframes,
  which doesn't allow for the operator's
  
  technical team to learn and adopt the system

• Technology per se is not the issue, but knowledge
  transfer of that technology is. Knowledge transfer should be an integral
  part of any implementation project

• Operational processes within the service provider
  organization have not been ramped up or tuned towards the applications
  deployed. In certain cases, there is lack of operational maturity

• Integration between various systems results in different
  components being deployed at different points in time, resulting in
  workaround and semi-manual procedures. The impact of this is often felt in
  the billing system

• Having said that, some technology/product-related issues
  could arise in the following areas:

• Outdated or switch-specific mediation systems which are
  low in functionality, e.g. cannot check duplicate CDRs, or cannot correlate
  records in real-time

• Lack of ordering functionality in billing system. The
  easiest way to ensure this is that the ordering functionality is a part of
  the billing system rather than trying to integrate ordering and billing
  systems that follow different data models

Interconnect billing:

• Again, the issues here are more around process and
  operations. Service Providers need to ensure that they have a timely process
  for translating changes in interconnect tariff schemes and policies into
  configuration in the interconnect billing system. Interconnect billing
  system vendors need to ensure that their applications support:

• Re-rating in addition to re-pricing

• More on-screen automated reconciliation functions, rather
  than just voluminous reports

• Alerts and notifications in case of exceptional results

Adopting standards, as is done for roaming, should help in
rendering the reconciliation process easier to manage. Today, too much time is
spent in the process of reconciliation. This needs to be reduced to make the
process effective.

Often, whenever there is an interconnect dispute between
operators, most of the time reconciliation is done on the same set of billing
records that generated the interconnect invoice. This approach is not going to
help. What is predominantly followed by the US and European operators is that
SS7 signaling-based call records are used to do an interconnect billing
reconciliation, as SS7 based call records are technically considered more
accurate. If there is a interconnect call, signaling and SS7-based systems can
collect these signaling messages to create call records.

Fraud management: This is an area that demands more attention
than it has received so far. It is an important tool to curb loss and maximize
revenues.

The different categories of fraud (subscription fraud, usage
fraud, etc.) may need to be addressed through specialized components of a single
system or multiple systems.

Fraud on any network, wireless or wireline, cannot be
adequately prevented without a holistic approach involving people, process and
dedicated systems. A proven method to fight fraud is to have a focused fraud
management department which uses a fraud management system designed to identify
fraud as it happens. The key here is to follow a process that reacts swiftly to
prevent future instances of the same fraud by addressing network and operational
vulnerabilities, frequently with the help of other departments within the
organization. Further, all customers should be constantly monitored across the
three stages of their lifecycle:

Entry-to prevent subscription fraud or fraudster
gaining access to the network through false identity

Usage-to prevent unauthorized usage or service usage with no intention to
pay

Payment-to prevent instances of bad debt

QoS issues: QOS can only be taken seriously when the
service provider uses it as a pricing /rating parameter for the service. Until
this happens QOS will be remain a buzzword restricted to network engineering
groups.

International standards: TeleManagement Forum's
NGOSS is an evolving framework that could serve as a guideline in specific
areas. Adopting the framework does not automatically result in tangible
solutions since the devil is always in the details. By its very nature, an
industry-agreed framework provides generic guidelines and leaves the details to
specific implementations. As such, it is important for Indian operators to
assess:

• Where their OSS/BSS systems are today

• Assess if any changes in business processes are required

• How the BSS/OSS systems will meet future growth plans

• Identify any potential gaps

• Investigate if the NGOSS framework has any viable
  business processes that could be adopted

India has a definite advantage, being a late starter in
telecom, and therefore has an opportunity to learn from the mistakes of others.
In this respect, Indian operators should adopt standards-based solutions, which
fit the eTOM architecture. With majority of vendors aligning their solutions to
be compatible with NGOSS, operators have a good opportunity to plan their
operations well and in a phased manner and thereby extract maximum return on
their capital investments.

OSS through Java: Another talked-about topic is the OSS
through Java (OSS/J) initiative. OSS-J is really one of the technological
implementations of the NGOSS framework. It leverages the increasing popularity
of Java and APIs built in Java.

Its benefit lies in the fact that it is a tangible solution,
rather than just a guideline. Service providers today are torn between two
conflicting enterprise portal development standards, Java/J2EE and .Net. OSS/J
is more applicable in environments where development standards are largely
Java-oriented and the various BSS/OSS applications support Java APIs.

For taking advantage of OSS/J, the product architecture
should be such that it leverages the advantages of J2EE and JCA principles by
providing a rich, fully-documented set of Java/XML APIs that are exposed through
multiple industry standard interfaces. This open architecture allows for easy
integration to other applications in the BSS/OSS suite and helps organizations
build towards a service-oriented architecture.

OSS/J can make interfacing and integration of applications
easier. OSS/J-based implementations are just beginning to be rolled out in the
first world. With successful completions of the proof of concepts it certainly
promises to bring in a new era of OSS/J-compliant OSS solutions, which would
provide seamless interconnectivity among each other. This would definitely give
a boost to the service providers opting for the best-of-breed solutions without
having to worry too much about their integration.

Archiving: Roles Others Can Play...

Given the fact that investments in OSS/BSS also demand huge
investments in network storage solutions, telcos are faced with capex-related
issues. A need has been felt for a closer cooperation with storage and other
vendors in this regard.

There are a few levels of rationalization that need to be
done and this requires the cooperation of multiple parties-application
vendors, system software vendors, storage vendors and service providers:

• Storage
  of online data needs to be rationalized. This has to be done by the service
  provider. For example, service providers need to limit online data to no
  more than 3—6 months in a billing system, no more than 1—2 months in
  mediation systems, no more than 30 days in network fault/traffic management
  systems, etc.

• Archiving options should be in-built in BSS/OSS
  application software. This is the responsibility of the BSS, OSS application
  vendor

• Archiving of data should be a standard operating
  procedure managed by IS teams within the service provider organization,
  rather than a fix that is applied during a crisis

• BSS/OSS applications should provide online monitoring for
  storage capacity utilization and raise alerts in case of excessive
  utilization

• Data marts and data warehouses should be used to store
  filtered, archived data, for further analysis

• Data compression techniques should be supported by all
  three parties-system software vendors (the RDBMS vendor), application
  vendors (billing system vendor), and storage vendors

• Storage and database vendors can collaborate to ensure
  optimized access speeds for online queries, analytical queries, and complex
  updates viz. orders

QoS and OSS/BSS Go Hand in Hand

Quality of service is an engineering issue and is linked with
various OSS/BSS elements. Advance planning for a few key items will go a long
way in supporting QoS:

• The
  network elements and network itself need to support different levels of QoS

• The network element should support continuous or sampled
  reporting of QoS levels through standard protocols such as SNMP or TCP/IP
  sockets

• A network management system needs to be used to track the
  QoS metrics reported by the network (this is within the domain of OSS)

• Mediation systems need to be able to collect the QoS
  metrics from the network or element management layer and 'message' this
  information

• Billing systems need to be able to provide differential
  charging based on class or quality of service

• Analytical systems need to be able to compare promised
  QoS versus delivered QoS and trigger alerts to various systems, including
  credit or debit triggers into billing system

Curbing Inter-operator Fraud

To identify and check such frauds, one needs to emphasize on
diligence of processes, in addition to specialized fraud management systems.
Traditionally, fraud management systems receive feeds from the network or from
mediations systems. However, in case of showing an ISD call as a local call, for
example, the fraud or the inaccuracy occurs in the billing system, much after
the fraud management system has received its inputs. As such, the fraud
management system may not detect this discrepancy at all. This leads to the
obvious conclusion that a diligent process needs to be set up by service
providers to check fraudulent activities in all BSS/OSS sub-systems. Also, each
BSS/OSS sub-system needs to support some level of fraud tracking and reporting.

Moreover,
much of the standard fraud management concepts could be used to tackle such
frauds. For example, illegal call landing can be detected through certain
patterns such as immovable SIMs, abnormal call ratios, etc. The only difference
would lie in the way the frauds are addressed. While operators would follow a
certain process with subscribers performing fraud, a completely different set of
processes and sensibilities would have to be followed with fraudulent service
providers.

SS7 signaling data can be used to address the problem quite
effectively. It is possible to do analysis on SS7 signaling-based records to
unearth disguising of calling party number by other operators.