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.