Download our free Monitoring Fundamentals Tutorial.
An introduction to Monitoring Fundamentals strictly from the perspective of telecom network alarm management.
1-800-693-0351
Have a specific question? Ask our team of expert engineers and get a specific answer!
Sign up for the next DPS Factory Training!
Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.
Reserve Your Seat TodayUnlike polled protocols, TL1 sends autonomous messages to your master. While this reduces network traffic, it also means that you do not automatically receive notification that a network element is down. If you're not receiving autonomous alarms from a device, you don't know for sure whether the situation is normal or your TL1 device has failed. You must send a command to act as a "ping". If you receive a reply, you will know that your network element is online.
In TL1, The RTRV-HDR ("Retrieve Header") command is commonly used to confirm a network element is online. Both the command and the response are simple, but they achieve the intended purpose of testing device status.
RTRV-HDR Command Format:
Example RTRV-HDR Command:
Example RTRV-HDR Response:
You must insert the TID of the device you are pinging and specify a CTAG. If you receive a response with the same TID and CTAG you used, you have confirmed that the TL1 device you pinged is online.
While manual RTRV-HDR commands can be useful in some situations, a good alarm master can be programmed to send RTRV-HDR commands to devices at regular intervals to ensure that failures will be detected within a reasonable amount of time. RTRV-HDR can also be used check the NE's current time-of-day and to avoid being logged off due to inactivity.
In my experience, clients who think hard about cost justification have a more important concern than just price. They want to make sure that they're not spending their company's money on a system that doesn't work as advertised.
That's smart. You have to be careful when working with equipment vendors, especially on protocol mediation projects. Most vendors can't support all your legacy equipment, and they don't have the development capabilities to make integration work.
Some vendors will charge you large NRE (non-refundable engineering) fees up front for custom work, and give no guarantee that the resulting product will meet your performance requirements.
Personally, I think that's a lousy way to do business. I give all my clients a 30-day guarantee: If my product doesn't completely satisfy you, return it for a full refund. If I can't give you a solution, I don't want your money. If I'm doing custom work for you, I don't expect you to pay for it until I've proven that it works to your satisfaction.
Very few vendors will make that guarantee. But you need to demand the best level of service from your vendor to ensure that your implementation is 100% successful.
