A Network Operations Center (NOC) forms a central location for a data center of any medium or large-scale network monitoring effort. In it, your NOC engineers will monitor for and respond to network problems. Your NOC services forms the vital link between the detection of a network problem and the implementation of a solution (usually in the form of a technician dispatched to the remote site).
While many NOC operation centers (yes, the word "centers" is redundant, but it aids understanding), are open 7x24x365, this isn't always the case. Some companies are in a transitional phase of growth. Their network is large enough to have warranted an investment in NOC center construction, but they can't yet justify the expense of staffing it outside of regular or possibly extended business hours. In this case, companies use after-hours alarm notifications (to email or phones) to alert on-call technicians of alarms in the network.
The core of any NOC room is one (or sometimes more) central master console. This console accepts inputs from the handful, hundreds, or thousands of remote devices in your network.
As you are building your NOC from scratch, remember to avoid several common pitfalls that will negatively impact your performance.
You need to work hard to make sure that all alarms throughout your network can be integrated into one unified monitoring system. Otherwise, you're increasing the difficult and staffing requirements associated with monitoring alarms. If you've never been cursed with having to monitor a lot of incompatible monitoring systems, you can't really appreciate how much of a hassle it is. You'll have to keep your head on a swivel, learn a lot of interfaces, and struggle to tie in related alarms from the different systems (which are divided by equipment compatibility, not by any logical division like geography).
You also need to make sure whatever central console you deploy in your NOC network can filter nuisance alarms. Any network has its share of alarms that are good to log, but really don't require a response from the operator. The more of these you have in your NOC, the more you're training your NOC technicians not to pay attention to alert messages. A good central console can hide unimportant messages from staff, allowing the truly important messages to rise to the top of the list.
To become more familiar with what a NOC requires, it will be helpful now to review an equipment example. I like to use the T/Mon LNX central console, since it contains many of the concepts I just mentioned.
The most useful thing about T/Mon is its ability to know lots of protocols (both modern and legacy). The count is actually around 25 at this point, and this enables T/Mon to avoid the multi-screen headaches I described above. It's very likely that you'll be able to put all of your alarms into one central system, allowing computers to do the busywork instead of your staff.
T/Mon can also intelligently filter your incoming alarm messages to keep your staff focused on the important alarms. You can configure simple rules that T/Mon will use to make a show/hide decision for each new alarm message. T/Mon will still log all inbound alarms received at your network actions center, so you can still review all alarms received after an incident.
When choosing a central console for your NOC, it's also important to choose one that has a convenient and intuitive interface. You don't want your staff to waste time trying to figure out what an alarm means when they could be reacting to it. Every minute wasted in your NOC surveillance means more expenses for you and a greater potential for a missed problem leading to extended network downtime.
T/Mon includes a pair of interfaces that meet this standard. The most commonly used within the NOC is T/GFX software. This runs on Microsoft Windows and used MapPoint maps as a backdrop for your alarms. Because your alarms appear on actual geographic maps instead of a non-visual list of text messages, your staff - even those who have not been extensively trained - are able to and easily know where alarms are occurring. This is especially helpful if you are trying to interpret the root cause of many simultaneous alarms. When you can see that alarms are clustered around a single area, it becomes very obvious where the problem must lie.
Sometimes, however, you're not in the NOC. Sometimes you have to be out in the field. Wherever you have a PC workstation, including your laptop out at a remote site with LAN access, you can access the T/Mon Web 2.0 interface. Designed for quick alarm review, this web interface uses color coding in place of geographic maps.
The beauty of any alarm interface, of course, is that you don't have to install any software to use it. All you need to do is enter the IP address of your T/Mon into your web browser and hit "Enter". After a single page load lasting just a few seconds, T/Mon will no longer require any more page refreshes. This is the hallmark of Web 2.0 technology. The page will update itself, but no conventional refresh will ever be required. You will always have current alarm data.
Network Management System
Remote Alarm Management.
Alarm Monitoring Tutorial.
Alarm Monitoring Systems.
Working with Alarm Collectors.
Network Temperature Sensors - Measure and report via IP LAN.
Critical Factors for Selecting a Fault Reporting System.
How to Create A Derived Alarm for an Event That Doesn't Happen.
Collect Element Management System Alarms and Display Them at Your Operations Centers.