Advertisment

SERVICE PROVIDERS OSS/BSS: Talk Components Talk

author-image
VoicenData Bureau
Updated On
New Update

That Indian telecom industry is growing at a phenomenal rate is a clichéd

statement. It surprises only the ignorant.

Advertisment

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.

Advertisment

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?

Advertisment

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.

Advertisment

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.

Advertisment

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.

Advertisment

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:

Advertisment
  • 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.

Experts

Panel

Atul Chopra,

CEO, Lifetree Convergence  



PV Thamban,
sr. solutions consultant, OSS sol., Agilent Technologies



Raghu Prasad,
CTO, CSG systems, APAC



Vinod Kumar,
senior product manager, Subex Systems

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.

Advertisment