Use Case: Distributed Alert/Event Monitoring and Management Control to non-NOC Stakeholders

A Communication Service Provider has many Tier 2 engineering users and remote technicians as well as customer CARE who need to log in through a browser and view as well as manage network resources and services, which are their responsibility. The NOC usually has responsibility to manage all alerts however views outside of the NOC are pre-filtered and authorized to specific owners by region, domain, and/or type of equipment/service. NETeXPERT NOC users use rich Java clients launched from NETeXPERT Command Center with Alert Navigator and Object Browser which have advanced features.

Use Case: Providing Corporate Customer Access to Monitoring and Management of Alerts

A Communication Service Provider (CSP) has corporate customer(s) who will be given a premium service where designated corporate users will be able to log in through a browser and view as well as manage their own alerts for network resources and services, which are monitored by the CSP. The corporate customers will only be authorized to see their specific alerts, which impact their network resources and services. NOTE: Since the Web Alert presentation layer is native HTML - the look and feel can be customized by you or through additional services (i.e.: "Bank of New York Premium IP Services, Acme Telecom Services Portal, etc...").

Web Alert Description:

• NETeXPERT Web Alert is accessible and runs natively within a web browser.
• Users can view NETeXPERT read-only alerts.
• Users can also be given authorization to manage alerts (acknowledge, clear, and trigger actions to URL scripts)
• Users can access rawdata
• Users can create their own filters and column definitions
• Filters leverage regular expressions.

Enhancement for Operator Filters

• NETeXPERT Web Alert will be extended to allow a super-user to specify authorizations with pre-defined filters.
• Web Alert Filters can be created against any Standard Alert Property or Extended Alert Property
• The concept is to allow configuration of the single filter based on operator or the operator group.
• When the operator user ID / password is used to log-in only the alerts meeting their filter criteria will be seen.

API and Platform Implementation Assumptions:

• The current plan is to continue to use Corba Access API between NETeXPERT IDEAS server and NETeXPERT Web Alert.
• We will not move to NX API currently due to unknowns and the effort would be potentially more costly.
• Corba Access does not support NETeXPERT partitions as tested.
• Corba Access is supported on NETeXPERT 5.0 and 6.0 platforms.

Filtering Assumptions:

The filtering mechanism today will allow alerts to be filtered upon Standard Alert Properties and Extended Alert Properties. For Operator Authorizations the following methods in filtering are recommended:

Filtering by Standard Alert Property: Managed Object Name

This is preferred given new managed resources with specific Managed Object Names would be installed, owned, and managed for a particular customer or key stakeholder

Filtering by Extended Alert property

This assumes rules have enriched the Extended Alert Properties with a location, customer name, customer ID, or stakeholder name.

The following methods of filtering have scoping limitations for the two use cases:

Filtering by Class

We believe that this may not provide enough granularity in partitioning alerts between corporate customers. For example a class of equipment router may contain all routers in a network and a subset of these routers would need to be visible to an end customer. Filtering by Managed Object Name would be required to identify which router alerts are visible to end users.

Filtering by Manager class

We believe this does not provide enough granularity given a Manager Class is specific to an Element Management System (EMS) or Network Element (NE), which may or may not be customer specific. For example an Element Management System may manage all equipment of a specific vendor type, and only a subset would need to be visible to an end stakeholder

Filtering by Object Relationship is not supported in Web Alert.

NETeXPERT Web Alert does not traverse the NETeXPERT MIB to determine what alerts to display. It is recommended that any relationship scoping of alerts be implemented with rules or policies against the NETeXPERT MIB and the related data be seeded into an Extended Alert Property, which can be filtered upon by NETeXPERT Web Alert filters.

NETeXPERT Web Alert Server Scaling Assumptions:

Since we do not know how many corporate customer users or user groups will be accessing Web Alert we will note that multiple NETeXPERT Web Alert servers may be required for a high number of users in the future.

Current licensing model: Currently a single Web Alert server license allows unlimited concurrent user clients and consolidation of an unlimited number of IDEAS servers. We do not charge based upon individual concurrent clients and number of IDEAS servers.

Current production estimates: We have customers currently running the system with 200 clients, <5,000 alerts, and integrating <5 IDEAS servers.

If greater performance, load balancing, or redundancy is required in the future it is recommended that separate Web Alert servers be implemented to service each unique corporate customer group, or user community. Each user environment will scale differently based upon number of alerts, extended alert properties, alert actions, internet bandwidth capacity, IDEAS load, filter criteria, etc.

Feedback: We welcome any feedback regarding this feature which we believe will help increase operational efficiencies and be a way to bring on new corporate customers, generating additional revenue with premium services.
Add Comments