Justifying Your OSS Investment

 General, Strategy  Comments Off on Justifying Your OSS Investment
Nov 302013

OSS have been seen as the cost center since it was born. That’s why the business has been less motivated to invest in it.
We, as OSS professionals have struggled to justify the investments in terms of operational excellence, improved quality, increased productivity. These has been used multiple times for the justifications however I assure you these are not interesting the sponsors anymore.

To justify our OSS, we need to convert it to a product. We have to convert OSS functions to revenue generating functions and start selling them either as standalone products or add-ons.

Here are some areas where you can collect revenue from your OSS investment.

– Advanced Reporting Platform (OSS)
– Pay as You Grow Services (BSS)
– Advanced Notification Services (OSS)
– Customer based correlation (business) rules (OSS & BSS)
– Customer SLA Management (OSS & BSS)

Other ideas? Please reply on this topic or join the Linked-in discussion. Your valuable comments are always appreciated.

OSS Class of Service

 General  Comments Off on OSS Class of Service
Jun 072013
Today’s topic is “OSS Class of service”, a term probably has not introduced before.

After the data boom that we saw in fixed/mobile networks, many new concepts popped up. Cloud computing, big data, VoIP and M2M are some of these. With the introduction of OTT operators in the market, the services that are delivered became much more complex. Yesterday’s dump pipe services are not dump anymore.

During this shift, quality of  service that has been provided became the major focus of the operators. Customers demand continuous, consistent quality throughout their experience. We have now complex OSS tools such as SQM and SLA Management Systems to track the overall quality of the service.

But there is a major issue that rise from the very bottom level: device level. All of the OSS rely on the device and/or EMS systems as their main data source. The device sends SNMP traps or expose statistics through files / SNMP MIBs. On a typical day, the statistics and traps flow smoothly to the OSS platforms and necessary steps can be performed.
But what about a condition where the utilization of the device itself goes beyond expected limits? What if the CPU utilization reaches up to 99%? In theory, everything will work fine, and if set, a high utilization threshold alarm will be sent to OSS. But from the very field experience, I know that this does not work like this.

The device or EMS stops NBI processing to favor customer data traffic. It may not send traps, it may not process performance metrics. But this information is very critical to OSS systems. The OSS systems are not just monitoring tools. They act upon the quality violations, so they need to be up-to-date every time.

The device vendors should introduce a dedicated processing and memory space that should not be interrupted by other processes. When the main CPU goes high, the OSS plane should continue working smoothly. The other way around, when a configuration management platform requests a full dump of inventory, the system should not crash.

The device / EMS configurations can easily be introduced dedicated processing power/memory space parameters. Today’s vendors invest heavily on virtualization technologies so a virtual NBI manager can also be created on the devices.

This dedication can even be applied to the device/interface level. So, Interface A, which carries traffic that belongs to a VIP customer can be set to (for example) Gold OSS profile while the others are set to Best Effort OSS profiles.

A fault proof OSS is possible from the device level. And fault proof OSSs will let the service providers to provide what they promised.