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.