9 Guides To Alarm Monitoring Regulations, Requirements And Opportunities

These 9 mini-white papers will teach you the essentials of network alarm monitoring:

  • What regulations you must follow
  • Essential requirements for robust network alarm monitoring
  • How to select an alarm monitoring system that will save you time and money

How These White Papers Will Help You

Searching for the right alarm monitoring system for your network's needs can be complex, even frustrating. You don't have the time to learn the technology in-depth - but you can't just take a vendor's word that his system is right for your needs.

These nine short guides cut through the confusion. Covering topics that range from FCC regulations to tuning out nuisance alarms to the truth behind vendor hype, these guides will give you the essential facts you need to know before you select an alarm monitoring system.

Chapter 1: Top 10 Ways to Reduce Network Vulnerability 3
Chapter 2: 10 Reasons Why You Should Consider NEBS-Certified Network Equipment (and Why RBOCs Insist on It) 7
Chapter 3: The FCC Takes Antenna Structure Lighting Seriously - Shouldn't You? 9
Chapter 4: 7 Tips on Separating Vendor Hype from Reality 10
Chapter 5: How You Can Migrate Your Remote Sites to LAN without Killing Your Budget 11
Chapter 6: Dealing with Nuisance Alarms 13
Chapter 7: Does Your SNMP Manager Support These 7 Key Telemetry Functions? 14
Chapter 8: 8 Pitfalls When Integrating Incompatible Network Monitoring Systems and Protocols 16
Chapter 9: 23 Burning Questions for Vendors Under Consideration 18
Appendix: Protocols and Devices Supported by T/Mon NOC 19
What to Do Next 23

Chapter 1: Top 10 Ways to Reduce Network Vulnerability

A solid network reliability management plan begins with a few essential precautions against network outages. Unfortunately, too many network managers don't take these precautions.

In today's competitive telecommunications environment, managers are under pressure to increase efficiencies, reduce costs - and best practices for network reliability can be lost along the way.

Here are 10 essential first steps you should take to reduce your network's vulnerability to an outage. Use this checklist to make sure you're covering the basics of sound network reliability management.

Monitor every critical part of your network

1. Make sure that you have remote monitoring of every critical piece of equipment in your network

It may sound obvious, but it isn't. Many network outages are caused by failures of equipment that no one bothered to hook up to the network monitoring system. Even the humblest piece of equipment - a starter battery for the backup generator, for example - can bring down the network if it fails.

2. Don't rely on embedded scan points to report alarms

Telecommunications equipment with built-in alarm systems is not a substitute for a genuine network reliability management system. You can't trust your equipment to monitor itself. If the equipment fails, it will take your ability to diagnose and correct the problem down with it.

Backup power supplies are essential to protect your network

3. Have a backup power supply - and monitor and test it to make sure it's in working order.

Loss of commercial power is probably the most common cause of network outages. Make sure your power supply has several layers of redundancy: dual battery plants, uninterruptible power supplies, backup generators, backup fuel tanks. Test your backup power sources regularly, on a weekly or monthly basis. Monitor every layer of your backup power supply to make sure it's always available in an emergency - your final levels of defense have to be the most reliable in your system.

4. Have an alternate data path for transporting alarms in case the primary network fails

In too many networks, the only data path for transporting network monitoring information is the network being monitored. If the network fails, your monitoring is lost with it. You most need reliable, real-time alarm data when your revenue-generating network is down. It's an essential best practice to have an alternate data path in case the primary network fails.

Are you ready to recover from natural disasters?

5. Create a disaster recovery plan and make sure your staff knows what to do in case of a natural disaster.

A lot of network outages are caused by natural disasters beyond your control - but being able to recover quickly from a disaster will have a huge impact on your average reliability rate.

Your disaster recovery plan should include:

  • an analysis of the natural disasters that might occur in your region
  • a prioritized list of the network systems that will be affected by a possible disaster
  • established procedures for repairing critical systems under disaster conditions
  • an inventory of essential spare parts and supplies for disaster recovery

That's just a short list - your actual recovery plan should include much more.

Once you have your plan, don't let it sit in a file drawer - drill your staff on disaster recovery procedures regularly. If the worst happens, you want your recovery to run like clockwork.

6. Monitor and control environmental factors at your remote sites

Critical remote site equipment can be brought down by environmental factors like high temperature, humidity, flooding, fire, and so on. To monitor these effectively, your monitoring equipment must support full four-threshold analog alarms. You also need to be able to control on-site protective equipment like HVAC and fire suppressors from  your NOC. And make sure that you have monitored backup power for your environmental control equipment. This equipment is usually AC powered, and it is often overlooked in power backup plans that only provide for DC power.

7. Create a systematic sparing plan, and have spare parts for all critical equipment

An adequate supply of spare parts for mission-critical equipment is essential. You can't let your parts suppliers control your network's reliability. Establish procedures for maintaining your spare parts supply so that it's always fully stocked. And be sure to include spare parts for your network monitoring equipment in your sparing plan - as your defense against network threats, your monitoring system is also mission-critical equipment.

Security is a critical issue you must consider

8. Include remote site security in your network reliability management plan

Your unstaffed remote sites are vulnerable to all kinds of mischief - vandalism, malicious or incompetent acts by outside technicians, vindictive acts by disgruntled former employees. And in the post-9/11 world, you can't rule out the possibility of a terrorist attack on critical telecommunications infrastructure. Make sure that your network reliability management includes: secure facility access control; gate and door monitoring; and visual surveillance of remote sites.

Watching too many screens endangers your network

9. Integrate all your remote monitoring on one uniform platform

In a lot of networks, remote monitoring is covered by several different, incompatible systems, each one sending alarms to a separate monitoring console. This can be a big mistake. Multiple systems increase the chances that network alarms will be unnoticed, forgotten, or incorrectly prioritized. You can't be sure every problem in your network will be caught, and you can't trust that all those screens full of green lights really mean that your network is problem-free.

The secure way to monitor your network is from a single platform that incorporates alarms from all your equipment, with redundancy capabilities and alternate reporting paths to prevent single points of failure. Incidentally, integration is also the cheaper way, since it saves equipment and training costs.

10. Make sure you have quality support from your network monitoring equipment vendor

Your network monitoring equipment can only be effective if it's the most reliable and trustworthy element in your network, and that requires good support from the vendor. When selecting network monitoring equipment, look for things like 24-hour technical support, quality backed by a money-back guarantee, and a client-first attitude. Inadequate vendor support can threaten your network as much as any equipment failure.

Network reliability is a competitive advantage in today's telecommunications market

We've covered some of the basic precautions you should take to defend your network against service-affecting outages. These are important security measures, but they're just the first steps to what should be your overall goal - increasing your network reliability to competitive levels.

In today's competitive market, network reliability has emerged as a key point of differentiation between telecom providers. Reliable service is what customers care about most. Research has shown that, after better deals, poor network reliability is the number one cause of customer churn.

Poor reliability drives customers away. High reliability retains and attracts customers. Putting a proactive network reliability management strategy in place now can lift your network reliability to better-than-industry-standard levels - and put you several steps ahead of your competitors.

Chapter 2: 10 Reasons Why You Should Consider NEBS-Certified Network Equipment (and Why RBOCs Insist on It)

What is NEBS and why is it important?

Long a requirement for equipment used in the Central Office in the North American Public Switched Network, the rigorous Network Equipment Building System (NEBS) criteria have become a universal measure of network product excellence.

Reliability of the telephone system is considered a national security issue, is demanded by consumers, and makes good business sense. Therefore, NEBS testing is taken very seriously by both the RBOCs and other service providers.

Deploying NEBS certified network equipment is a key advantage for access providers including ILECs, CLECs, CAPs, ISPs, ASPs, and, of course, RBOCs. Products that are NEBS certified are also expected to be top performers in enterprise network environments as well.

Compliant vs. Certified

These terms are often casually used by equipment vendors as though they were synonymous. This is not the case. Most NEBS testing laboratories publish their testing procedures. Products that claim to be "compliant" are merely reproducing the rigorous testing procedures in-house (and very rarely perform them all).

While that makes for a better product than one that hasn't been tested in-house, it is still a long way from sending equipment to a nationally recognized testing facility and paying them tens of thousands of dollars to make absolutely certain that a piece of equipment meets the demanding standards NEBS certification requires.

10 Benefits of NEBS-Certified Network Equipment

  1. Ensure equipment compatibility with the telephone industry's electrical environment.
  2. Simplify equipment planning and installation.
  3. Protect telecommunications equipment from service outages caused by incompatible equipment.
  4. Prevent interference to licensed radio transmitters and other close proximity telecommunications equipment.
  5. Minimize the risk of fires to telecommunications equipment.
  6. Ensure equipment operation under the range of temperature, humidity, vibration, and airborne contamination present in telecommunications locations.
  7. Ensure equipment and service survivability in the event of earthquake.
  8. Protect personnel from injury.
  9. Greatly reduce equipment failure rates.
  10. Reduce customer churn. As new service offerings (call waiting, voice messages, etc.) slow down, customers are choosing providers with the most reliable network and minimum downtime.

The most successful telecommunication providers choose only NEBS-certified equipment. Shouldn't you?

Chapter 3: The FCC Takes Antenna Structure Lighting Seriously - Shouldn't You?

Imagine if a cellular tower light failed and went undetected for several hours - or even days. That tower is now a highly dangerous flight hazard to aircraft. Without warning, a simple light failure could cause a tragedy. The Federal Communications Commission (FCC) has several rules for antenna structures to ensure aircraft safety. Here are a few examples of FCC rules that tower owners should know.

Sec. 17.47 Inspection of antenna structure lights and associated control equipment.

The owner of any antenna structure which is registered with the Commission and has been assigned lighting specifications referenced in this part:

  1. Shall make an observation of the antenna structure's lights at least once each 24 hours either visually or by observing an automatic properly maintained indicator designed to register any failure of such lights, to insure that all such lights are functioning properly as required; or alternatively, shall provide and properly maintain an automatic alarm system designed to detect any failure of such lights and to provide indication of such failure to the owner.
  2. Shall inspect at intervals not to exceed 3 months all automatic or mechanical control devices, indicators, and alarm systems associated with the antenna structure lighting to insure that such apparatus is functioning properly.
T/Mon's text messages can provide specific instructions for handling tower light emergencies.
If your tower lights went out, would you know who to call? Would you know the correct latitude, longitude and height of your tower? You need to provide this information to the FAA immediately. T/Mon NOC puts all the facts at your fingertips.

Sec. 17.48 Notification of extinguishment or improper functioning of lights.

The owner of any antenna structure which is registered with the Commission and has been assigned lighting specifications referenced in this part:

  1. Shall report immediately by telephone or telegraph to the nearest Flight Service Station or office of the Federal Aviation Administration any observed or otherwise known extinguishment or improper functioning of any top steady burning light or any flashing obstruction light, regardless of its position on the antenna structure, not corrected within 30 minutes. Such reports shall set forth the condition of the light or lights, the circumstances which caused the failure, the probable date for restoration of service, the FCC Antenna Structure Registration Number, the height of the structure (AGL and AMSL if known) and the name, title, address, and telephone number of the person making the report. Further notification by telephone or telegraph shall be given immediately upon resumption of normal operation of the light or lights.
  2. An extinguishment or improper functioning of a steady burning side intermediate light or lights, shall be corrected as soon as possible, but notification to the FAA of such extinguishment or improper functioning is not required.

If you're a tower owner, you'll find the rules on construction, marking, and lighting of antenna structures very informative. You can also register new towers by visiting the FCC's Antenna Structure Registration (ASR) portion of their website.

Chapter 4: 7 Tips On Separating Vendor Hype From Reality

It is an age-old problem ... getting an accurate view of how a vendor will perform after the sale.

It's difficult ... all vendors are on their "best behavior" and doing everything they can to keep from losing the sale.

The good news is that if you know what to look for you can see some of the cracks in the "image" that a vendor might be projecting ...

Here are 7 questions you can ask your prospective vendors. The answers can help you get a better understanding of what you are getting into:

  • How many people are on your payroll?
  • Do I get a personalized proposal… or a two-page fax?
  • Is part of the proposal a list of board member resumes?
  • Can you back up all your claims of superiority?
  • Do you ever talk to more than one person?
  • Do you have a money back guarantee?
  • What is the real core competency of the company?

In addition to these questions there are some other telltale signs that what your about to do may not be in your best interest:

  • Unrealistic beta pictures posing as production run/fully developed solutions
  • Claims that can't be substantiated
  •  "Ginsu" knife style sales pitch
  • Used car sales feel
  • Will sell you anything
  • Seems too good to be true
  • Doesn't feel right

If you're picking up little hints along the way they could turn into full scale "bad vibrations" after the sale.

So ... with a few questions and paying attention to some of your subtle concerns you can achieve a win-win relationship with your vendor.

Chapter 5: How You Can Migrate Your Remote Sites to LAN Without Killing Your Budget

Installing LAN connections at remote sites is a significant cost - it can be the single biggest expense of your SNMP implementation. Many remote sites are distant and isolated, making them difficult to be integrated into your corporate network.

Fortunately, you don't need a LAN connection at every remote site. SNMP data can also travel over an alternative transport, like PPP over a dial-up connection or dedicated line.

That's a good immediate solution, but in the long run you'll still want to move as many sites as possible to LAN. Compared to dial-up and dedicated lines, LAN is faster, more reliable - and most importantly, doesn't require repeating monthly costs.

So now you face a dilemma: avoiding the repeating high costs of a dedicated line means taking on the immediate and enormous costs of installing LAN at your remote sites.

How can you get through this dilemma? The answer is controlled migration to LAN transport.

How LAN Migration Works - Step One: Install an SNMP RTU with Dial-Up or Dedicated Line Capability

In a controlled LAN migration strategy, you first integrate your remote sites into your SNMP-based monitoring system, using existing transport.

To do this, all you need is an SNMP-based remote telemetry unit (RTU) or proxy device that supports both LAN transport and your existing transport.

A dial-up connection and a PPP server can connect your most distant remote sites to your LAN.
Figure 1. A dial-up connection and a PPP server can connect your most distant remote sites to your LAN.

In this diagram, a site that is originally monitored by a legacy RTU via a dial-up connection is replaced by an SNMP RTU that has both LAN and dial-up capability (Figure 1).

Alarm data is collected by the RTU, reported via dial-up to a PPP server which connects to the SNMP manager.

How LAN Migration Works - Step Two: Install a LAN Connection

When a LAN connection is added to the site, the dial-up connection is retained as a backup data path.
Figure 2. When a LAN connection is added to the site, the dial-up connection is retained as a backup data path.

Later, a LAN connection is installed at the remote site. The same SNMP RTU installed in Step One can be immediately transferred to LAN transport with minimal configuration - and without disconnecting alarm inputs. (Figure 2).

A dial-up connection can be retained as backup secondary connection in case of LAN failure.

You don't have to cut over all your sites at once - you can gradually migrate different sectors of your network to LAN, as your budget and installation manpower allows.

Benefits of LAN Migration

  • Spread the expense of installing LAN over several budget cycles.
    Completing a major installation in one budget cycle can strain your Cap-X and staffing budgets. With controlled migration, you control the pace of migration, so it happens as quickly or as slowly as you like.
  • Minimize equipment costs.
    With LAN migration, you only have to buy one SNMP RTU for each of your remote sites, and it's compatible with both your old and your new transport.
  • Implement SNMP monitoring now at all your remote sites
    Without LAN migration, you'd need to maintain a separate legacy alarm monitoring system to monitor your non-LAN sites. Operating two unintegrated alarm systems is a bad idea - it means higher maintenance costs, higher training costs, and watching multiple screens to monitor your network.

Chapter 7: Does Your SNMP Manager Support These 7 Key Telemetry Functions?

SNMP is a standard protocol that has wide acceptance in the industry and is flexible enough to describe almost anything. (See the SNMP Tutorial for more information.) Because of these advantages, many network managers have come to believe that SNMP should be used for all telemetry monitoring applications.

SNMP certainly has its place in an effective telemetry monitoring solution, but this doesn't mean that any off-the-shelf SNMP manager can provide adequate visibility and control of your network.

The typical off-the-shelf SNMP manager is not designed for displaying and processing telemetry data for effective alarm management, especially for the kind of real-world monitoring tasks network managers most need performed. These capabilities can be added to an SNMP manager, but it usually requires substantial custom software development.

Before you buy, make sure your SNMP manager supports these 7 key functions

Here's a list of seven key telemetry functions that off-the-shelf SNMP managers typically do not support. These are essential functions that you need for best-quality monitoring of your network. Before you buy an SNMP manager, make sure it supports these seven essential functions.

  1. Complete, precise alarm descriptions
    A basic SNMP manager doesn't record the location, time, severity, or a precise description of alarm events. To adapt an off-the-shelf SNMP manager to monitor these factors, you must create and maintain a master alarm list representing all the monitored points in your network - and then also create and maintain a database associating all the traps that may be sent to the SNMP manager with the alarms on that list. (Traps are a type of SNMP message sent from an SNMP agent, such as an RTU - see our SNMP Tutorial Series to learn more about SNMP.)
  2. Identification of cleared alarms
    Even more database work is required to identify whether a trap corresponds to an alarm condition or a clear condition. Creating this addition to the trap association database often requires analyzing multiple variable bindings within the trap packet.
  3. Standing alarm list
    Relying on a basic SNMP manager for alarm management can potentially result in completely losing visibility of threats to your network. A basic SNMP manager doesn't maintain a list of standing alarms. Instead, the typical SNMP manager maintains an event log of newly reported traps and a history log of acknowledged traps. As soon as a trap is acknowledged, it is considered cleared. Imagine what might happen to your network if a system operator acknowledges an alarm, and then, for whatever reason, fails to correct the alarm condition. Who would know the alarm is still standing?

More Essential Telemetry Functions for SNMP Managers

  1. System operator identification
    Basic SNMP managers do not record the identity of the system operator who acknowledges an alarm. In the example of the negligent system operator, it would be impossible to determine who had made the mistake or to assign responsibility for the resulting problems.
  2. Multi-user security
    Out of the box, the typical SNMP manager is not designed for multi-user security. All traps are posted to one alarm list; all users may view all alarms, and all users may acknowledge all alarms.
  3. Alarm sorting and organization
    Basic SNMP managers have no built-in functions for organizing alarms by logical category, posting the same alarm to multiple logical categories, or sorting which alarms the user wants to see. If Jones is in charge of all equipment for the Western region, and Smith is in charge of power plants, both need to know about a generator failure in Tucson, but neither one needs to know about all the alarms in the network. And if one manager corrects the alarm condition and acknowledges the alarm, the other manager needs to know it was acknowledged and by whom. Unfortunately, standard SNMP managers will not support these functions.
  4. Nuisance alarm management and after-hours notification
    No SNMP manager supports the advanced features necessary for best quality telemetry monitoring, such as notifications escalation, legacy protocol mediation, nuisance alarm silencing, automatic control relay operation, and automatic notifications by pager and email.

It is true that many, but not all, of these functions can be added to standard SNMP managers, but implementing telemetry monitoring in a basic SNMP manager usually involves a substantial amount of custom software module development. Even when pre-built software modules are available, they usually require custom tweaking to perform exactly as you want them to.

The need for extensive customization eliminates the advantage of using a simple open standard, and it is difficult to justify significant development costs after purchasing an already expensive SNMP manager. Why take the time, trouble, and expense to recreate capabilities that are already present in a high-quality, SNMP-capable network alarm management system?

And in fact, it is much easier to adapt a traditional telemetry master to process SNMP traps than to adapt an SNMP manager to perform telemetry functions. There is no question that SNMP is right for many applications, and it is clear that SNMP will be increasingly used in the future.

SNMP can be an effective tool, but it's only one item in your telemetry monitoring toolkit, and it can be used more effectively when it is part of a total alarm management solution.

Chapter 8: 8 Pitfalls When Integrating Incompatible Network Monitoring Systems and Protocols

  1. An alarm master that does not support multiple protocols.
  2. A vendor that does not have the engineering resources to support nonstandard interface protocols.
  3. A vendor that does not have the ability to do a site survey and determine a solution based off of an evaluation of my network.
  4. You end up $250K into your installation and nothing works (and no refund!)
  5. You select a system that has never been tested in YOUR network.
  6. You select a system that does not come with a money-back guarantee.
  7. You are proposed a buy-it-all-at-once solution instead of an incremental solution.
  8. You are proposed a system that does not have engineering flexibility.

How to Avoid These 8 Pitfalls

T/Mon NOC supports hundereds of different devices
T/Mon NOC supports hundreds of different devices - can your alarm monitoring system do the same?
  1. Be tough with every alarm equipment vendor you're considering. Be skeptical. Ask the hard questions, and don't be satisfied with anything less than an honest, straightforward answer.
  2. Demand nothing less than a perfect fit solution - an alarm system that works with your existing equipment AND provides a long-term upgrade path.
  3. Make sure your next alarm system supports all the protocols and devices that you use. (For a sample of the kind of versatility you should expect, please see this list of protocols and devices supported by T/Mon NOC.)
  4. Don't waste your time on vendors who immediately tell you to buy their product, without getting to know you or your specific requirements.
  5. Make sure your alarm monitoring equipment vendor can custom engineer a solution to meet your exact requirements.
  6. Look for equipment that supports gradual upgrade paths, so you can replace old equipment over several budget cycles.
  7. Ask all vendors you're considering if they guarantee their product - and then ask if that means you get all your money back if you're not satisfied for any reason.

Want more information on selecting a perfect-fit alarm monitoring system?

Visit www.dpstelecom.com/white-papers for a series of comprehensive guides to alarm monitoring issues and best practices.

Chapter 9: 23 Burning Questions for Vendors Under Consideration

  1. Have you done this before? Who and where?
  2. Do you poll my currently installed remotes, or do I have to do a wholesale swapout?
  3. What protocols do you support?
  4. Do you have references or testimonials or am I your first customer?
  5. Do you support transport diversity (RS-232, RS-422, LAN, 202) or will I have to reinvest and purchase a new transport layer?
  6. Can you port my database from my existing master or will I have to manually re-enter the data?
  7. Is this solution affordable, or will it cost me a ton of money?
  8. Will you support me during the transition or am I on my own once you are paid?
  9. If surprises crop up - do you have the ability to reengineer the solution to make sure I am up and running?
  10. Does your remote support dual interfaces / protocols for both my new sites as well as my legacy sites?
  11. Do you offer installation and training or does my staff have to figure it out from the manual (if they even read it)?
  12. Do you have the ability to custom engineer a perfect fit solution or is your sales staff just a bunch of order takers?
  13. After you design the perfect system - do you have materials and tools that I need to successfully present this to upper management?
  14. As my network grows - is there a clear upgrade process for my equipment?
  15. Are you able to customize my master to support my "special" needs - or do I have to hire a full time programmer?
  16. Do you have a master, or are you simply selling remotes?
  17. Do you have remotes, or are you simply selling master stations?
  18. What type of remote and network debugging and visibility do you have built-in to your products to aid me in troubleshooting communication problems?
  19. If I have a problem at 4:00 A.M., can I get emergency tech support?
  20. When I have an issue, will I get an automated call system or will I get a real voice?
  21. Are you a vertically integrated supplier - or are you part of five-team consortium?
  22. Will you fly someone out here, do a site survey to review my alarms, transport, and general needs, help me design a perfect fit solution, field trial it with me, and support me after installation?
  23. Does your solution fit with my manpower and resource availability?

Alarm Monitoring Solutions from DPS Telecom

Alarm Monitoring Masters


T/Mon NOC: Full-featured alarm master for up to 1 million alarm points. Features support for 25 protocols, protocol mediation, alarm forwarding, pager and e-mail alarm notification, Web Browser access, multi-user access, standing alarm list, alarm history logging. Available SNMP software:


T/Mon NOC LT: Light capacity SNMP-only alarm master. Supports SNMP Trap Processor software module, up to 10 SNMP devices, and up to 20 DPS Telecom remotes. Features pager and e-mail alarm notification, Web Browser access, standing alarm list and alarm history logging.

Remote Telemetry Units

NetGuardian 832A

NetGuardian 832A: RTU monitors 32 alarm points, 8 analog inputs, 8 control relays, 32 ping targets, 8 terminal server ports; reports to any SNMP manager, T/Mon NOC or T/Mon LT.

NetGuardian 216

NetGuardian 216: RTU monitors 16 alarm points, 2 analog inputs, 2 control relays, 1 terminal server port; reports to any SNMP manager, T/Mon NOC or T/Mon LT.

NetGuardian 480

NetGuardian 480: RTU monitors 80 alarm points, 4 control relays; reports to any SNMP manager, T/Mon NOC or T/Mon LT.

RAB 176N

Remote Alarm Block 176N: Wire-wrap alarm block monitors 176 alarm points, 4 controls; reports to any SNMP manager, TL1 master, T/Mon NOC or T/Mon LT

DPS Telecom Guarantees Your Success - or Your Money Back

When you're choosing a network alarm monitoring vendor, don't take chances. Be skeptical. Ask the hard questions. Above all, look for experience. Don't take a sales rep's word that his company can do custom development. Ask how many systems they've worked with, how many protocols they can mediate and integrate, and check for client testimonials.

DPS Telecom has created hundreds of successful alarm monitoring implementations for telecoms, utility telecoms, and transportation companies. (Check out www.dpstelecom.com/case-studies for some examples.) DPS Telecom monitoring solutions are proven performers under real-world conditions.

You're never taking any risk when you work with DPS Telecom. Your alarm monitoring solution is backed by a 30-day, no-risk, money-back guarantee. Test your DPS monitoring solution at your site for 30 days. If you're dissatisfied for any reason, just send it back for a full refund.

Appendix: Protocols and Devices Supported by T/Mon NOC

    • Any device with plain text formatted output (craft ports, etc.)
  • ROP (Report Only Printer) ports
  • PBX Switches
  • Class 5 Switches
  • Microwave radios
  • Routers
  • AEB
  • Alcatel DACS
  • CDMA
  • CEB
  • Cerent OC48
  • Cisco 15454 (SONET)
  • Cisco OC48
  • Definity System 75
  • Digtac
  • Ericsson Switch
  • Fujitsu FLM 150
  • Harris Radio
  • Lucent 5ESS
  • Lucent ECP
  • Lucent OC48
  • Motorola CBSC
  • Motorola EMX
  • Nokia Switch
  • Nortel DMS-10
  • Nortel DMS-100
  • Nortel DMS-250
  • Nortel DMS-500
  • Nortel MTX250
  • Nortel OC48
  • Nortel PCS
  • OMC System
  • Paradyne 740
  • PBX Switches
  • Tellabs DACS
  • Tellabs DACS 5500

Protocols and Devices Supported by T/Mon NOC - Page 2

  • Badger
    • Badger 481
    • Badger 1200
    • Larse 1200
    • Badger Mini-Master
    • Badger 482
  • Cordell
  • Datalok
    • Pulsecom Datalok 10A
    • Pulsecom Datalok 10D
    • Other Pulsecom Datalok devices
  • DCM
    • Dantel 460 Alarm & Control System (ACS)
    • Dantel MAT
    • Dantel CPM
    • Dantel VDM
    • Dantel SBP sub-assembly
  • DCP (DCP, DCPf, DCPx, DCP1)
    • Any DCP enabled device
    • DPS Telecom remotes
    • Dantel 460 Alarm & Control System (ACS)
  • E2, E2A
    • Any E2 or E2A enabled device
    • DPS Telecom KDA-E2A
    • DPS Telecom NTP (Network Telemetry Processor)
    • Lucent DAS (Digital Alarm Scanner) remote
    • Lucent APR (Alarm Processing Remote)
    • Lucent ATP (Advanced Telemetry Processor)
    • Lucent GTP (General Telemetry Processor)
    • Lucent SAC (Status and Command) remote

Protocols and Devices Supported by T/Mon NOC - Page 3

  • Felix
  • FX8800
  • Granger 8000 Alarm System
    • Any network enabled device (printers, servers, routers, RTUs, etc.)
    • Any Modbus ASCII device
    • Any Modbus RTU device
    • Any Modbus TCP/IP device
    • Analog and contact closure sensors
    • Environmental sensors (temp, humidity, etc.)
    • Tridium Jace-512
  • NEC 21SV
    • NEC - 21SV supervisory & control remotes
    • NEC - 21RB supervisory & control remotes
    • NEC - 21GTX fault-management system
  • NTP
    • Network Time Protocol
    • Synchronize the T/Mon clock to Network Time Servers
  • TABS
    • Any device that supports the TABS protocol
    • NEC RC-28D digital multiplexer

Protocols and Devices Supported by T/Mon NOC - Page 4

  • TBOS
    • Any device that supports the TBOS protocol
    • DPS Telecom remotes
    • Alcatel DML-3X50 Digital Muldem/Lightwave multiplexer
    • Lucent DDM 1000 DS3 multiplexer
    • Lucent DDM 2000 OC-12 multiplexer
    • Lucent DDM 2000 OC-3 multiplexer
    • Microwave radios
    • Multiplexers
    • NEC Async
    • NEC FD-39001 multiplexer
    • Nortel FD-565
    • Nortel Async (now CTDI Async product line of Digital Loop Carriers (DLCs), Channel Banks, and Multiplexers)
    • OC-3s from various manufacturers
  • Telco Systems Teltrac devices
  • TL1
  • Any device that supports the TL1 protocol
  • PBX Switches
  • Class 5 Switches
  • Microwave radios
  • Routers
  • SONET equipment
  • TMonNet (Network of multiple T/Mons)
  • POP3 - Email acknowledgment of alarm notifications in T/Mon
  • SMTP - Email notifications of alarms sent from T/Mon
  • SNMP
    • Any device that supports SNMP

What to Do Next

Before you make a decision about your alarm monitoring, there's a lot more you need to know. There are dangers you want to avoid - and there are also opportunities to improve your remote site maintenance that you don't want to miss.

Get the information you need - register now for a free, live Web demonstration of alarm monitoring solutions with the T/Mon NOC Remote Alarm Monitoring System. There's no obligation to buy - no high-pressure salesmen - just straightforward information to help you make the best decision about your network monitoring. You'll get complete information on hardware, software, specific applications, specifications, features, and benefits … plus you'll be able to ask questions and get straight answers.

Call 1-800-693-0351 today to schedule your free Web demo of SNMP monitoring solutions

Or register on the Web at www.dpstelecom.com/tmon-webdemo.