article page |
1 |
2
It is interesting to note that most operators already possess both OSS and NMS systems, but because of organizational boundaries, the two systems do not interface. If nothing else, the overall migration to IP-based networks and data-oriented services is forcing operators to re-assess how their Back Office operations are structured to accommodate integrations such as these. Integration of the OSS and NMS not only allows mapping of the network elements into the services provided, but also provides information on the services and their quality…even if no faults were detected by the OSS. Most importantly, such an integration provides “Closed Loop Management”, where instead of having the OSS simply signaling the fault, since the two systems are now integrated, the operator can start troubleshooting from the point the fault is actually detected.
|
|
Linking the NMS with the OSS allows the NOC and Customer Care to share data more effectively. |
|
increase in issues that can be resolved in Tier 2 and 3 support in Customer Care, before they ever become NOC issues.
It is also important that the NMS be able to export detailed customer and service information for analysis and processing by external systems, such as Performance
Management (PM), Service Quality Management (SQM) or OSS/BSS systems. This exporting typically happens through Key Performance indicators (KPIs) generated by the NMS. By providing accurate, fast and
|
|
|
|
|
Having worked closely with operators in all stages of core IP migration and IP service introduction in order to make such NMS/OSS integrations possible, it’s clear to us that the full menu of considerations and issues in such a migration are beyond the scope of this article (and even an entire book). However, a few elements stand out as being very important for the operator to consider.
For any form of NMS/OSS integration to occur, it is important that inbound data received by the NMS system is diverse and carefully groomed. Modern probes must not only be able to aggregate traffic from the network, services, subscribers and devices, but they must be able to trap and analyze traffic at line-rates up to 10 Gbps in order to generate the appropriate real-time xDRs (call/etc. Detail Records) and elapsed-time inputs to the management system.
Most importantly, linking the NMS with the OSS (and other customer-facing tools such as CRM systems) finally allows the NOC and Customer Care to share data more effectively. The result should be reduced trouble ticket times, more issue resolution efficiency and an
|
|
‘meaningful’ KPI’s a more accurate picture of the end user experience can be constructed. The NMs should also have the ability to export to the OSS alerts and alarms based on certain types of transactions or by thresholding KPI values. This type of integration requires careful planning, design and implementation to ensure a high level of consistency when the NOC and Customer Care are interfacing on an issue. If done correctly, this provides a new and meaningful data source for the OSS, in that the notifications and alarms are now based on real customer experience as it pertains to accessibility, reliability and performance of the service –and- the network.
To be sure, for the dream of a fully converged telecom environment where IP and voice-based services share the same network infrastructure and quality levels to become a reality, there are many transitions that must occur, and many operational models that must migrate. A first step in any successful endeavor is closely aligning the operator’s network monitoring and OSS functions.
|
|
