One of the most useful aspects of having network access to a remote site is being able to look at the functionality of various remote devices simply by opening a Web browser and connecting to them over the Internet. Dial-up remote controls have, for many years, given us a way to monitor the basics -- such as power output, plate voltage, tower phase and ratio, and the like. They could be programmed to call us in the event some pre-configured conditions were met. Some of them could even be programmed to carry out macros -- a series of actions based on programming -- such as changing transmitters.
Within the last 10 years, more and more devices had Ethernet access included in their designs, giving us the capability to look deeper and deeper inside of them by way of IP; audio processors, and newer transmitters are perfect examples. Along with network access naturally came SMTP (simple mail transfer protocol) and therefore the ability of the unit to send e-mails when some pre-configured conditions were met. This gave engineers the ability to know more about what was going on inside a remote unit -- without having to be made aware by way of a phone call (at 3 a.m.). In New York we still use the call-out capability to be made aware of red-alert conditions - such as dead-air or a transmitter being off; however, we use the e-mail capability of our remote controls to inform us of less urgent matters -- like silence on a secondary or tertiary STL.
Let's go a step further now. Obviously when you use HTTP to look at your remote devices, you're only getting information that you want to see when you have the browser open. You proactively instigate a session. Of course, as I just mentioned, you can have remote devices e-mail you when they detect a problem. Naturally you should ask yourself the question: What will happen if my network connectivity is lost? How would I know that? What if you want devices - pre-programmed by engineering -- to exchange information all the time, and to actually take action when conditions warrant? There is an easy way to do that, and it's known as SNMP (simple network management protocol). That's what this article is about.
The most basic set-up for SNMP is shown in Figure 1. At the remote end is a device that will communicate via IP, and that supports an SNMP agent. The agent is simply software that resides in that device. At the HQ end, there is another device that is a manager. The SNMP manager is software that is used to communicate with the remote agent. The manager sends messages to the agent via UDP/IP, using port 161. The agent will respond to the manager using UDP/IP port 62. The device that runs manager also runs an NMS (network management system) on which the various commands (seen below) are executed. Variable is the term for the condition or parameter measured or detected at the site of the agent.
There are five different types of SNMP (version 1) messages:
Get-request, which is a query sent by the manager to the agent about a variable.
Get-next-request (more on that when I talk about MIB browsers later)
Set-request, which is used by the manager to alter a variable on the agent.
Get-response,, which is sent by the agent to the manager as a reply to a query about a variable.
Trap, which is sent from the agent to the manager, regarding a variable.
Devices that support SNMP usually allow you to configure traps that correspond to a state of some variable. The manufacturer gives you choices about what the traps are. Let's look at a real-world example of trap configuration, which is show in Figure 2. This is a microwave receiver at our 4 Times Square transmitter site. (Keep in mind this particular set is blank -- we don't use traps in our facility; we use get requests.) As you can see, there are four spaces on the left side for (up to) different manager addresses where the traps are sent. On the right side, you see four columns (that correspond to the four manager addresses). There is a box inside that you check when you want a trap associated with that condition, and the severity of the condition (see the lower columns on the right side.) There are 55 possible trap configurations per manager location. An NMS would be used to collect and view the traps.
Get-request is a message originated by the manager, and sent to the agent. Get-response is the agent sending a reply to that query; so it's pretty obvious that your manager can tell something is wrong (like the network is down) when it fails to hear from the agent on the other end. You gain one important piece of information from the lack of another. What happens if your dial-up remote control's phone line dies? Nothing. It can't call you to say so. Don't get me wrong - I still use them, and they have their place -- but the ultimate capability of an older unit is a small fraction of what can be done with a remote control that has IP capability and SNMP support.
-- continued on page 2