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.
Greater details
First let me introduce a couple of acronyms: MIB and OID. MIB stands for management information base. This is just a small file (which you can copy and paste to a text editor if you want to see what it really looks like) that (conceptually) is like a map that tells an SNMP manager what variables are available to be read and where they are. (If you want to get in to more details about how a MIB is constructed then check out the IETF RFC 1157). OID stands for object identifier. The format of the OID is a string of integers separated by decimals. The MIB is basically a structured collection of OIDs.
If you have a device that supports SNMP and will operate as an SNMP agent, the first thing you will need to do is to obtain the MIB from the device manufacturer. Usually that comes with the device when it’s new out of the box (on a CD). Sometimes you can obtain it by browsing the device itself, or by obtaining it from the support Web page of the device. If the device supports SNMP then the MIB will be available somehow.
There are at least two devices out there that can function as SNMP managers: Audemat Relio and Burk ARC16 PlusConnect.
Take for example the case in which two Relios talk to one another; one being a manager, one being the agent. As the user you would do three things: Find the MIB for Relio (downloads from the unit), and make it available for the Scripteasy software (upload to a location accessible by Scripteasy). In the script on the manager, identify the IP address of the agent, and specify the MIB to be read when querying the agent.
Scripteasy is a scripting program done completely with symbols — all laid out visually. It’s particularly easy to see the OIDs with Scripteasy, so it makes for a good example.
In Figure 3, you see part a small part of a script running on the agent. I’ve highlighted a symbol that corresponds to a temperature probe in our transmitter space. On the right, you see I’ve highlighted the OID. Figure 4 shows the script on the manager. The symbol you see corresponds to SNMP get (in this case, getting an analog reading from the agent). You see that I’ve highlighted the OID again; obviously it’s the OID from the agent (note the OID is the same). You can also see where I referred to the agent in the link to section (right above the OID).
What you will then have is a remote, real-time meter on the manager Relio that corresponds to the same meter over on the agent Relio. Making dynamic graphs with information gleaned by way of get request is a common function with SNMP. I should also note that this same agent will respond to multiple managers; I could paste this same analog temperature meter in multiple places, all at the same time.
Of course there are plenty of other devices that support SNMP and will act as agents. After you obtain an SNMP manager you will then need to configure it with the agent’s address and its appropriate MIB. Let’s review the necessary steps again:
Obtain an SNMP manager (can be software or a device like Relio)
See whether or not the device you want to monitor supports SNMP (if not, stop right here)
Obtain the MIB of the device you want to monitor
Determine the write community and read community names. These are like rudimentary passwords. The manager will use these as it accesses the agent.
You’ll need another piece of software now known as a MIB browser. The MIB browser reads the MIB, and after connecting to the device you want to monitor, reads the real-time data that is available, and tells you the OID that corresponds to pieces of information that you want. We use a freeware MIB browser from iReasoning that you can download at ireasoning.com/mibbrowser.shtml.
I’ve used our microwave receiver at Times Square as an example. See Figure 5. I obtained this entire graphic by telling the MIB browser to perform what is known as a WALK command (which it does by sending get-next-request messages to the agent). What you see is a huge collection of information — way more than you’ll ever need to use. (If you look at the left window, you’ll see the MIB opened with the tree icon at the top, and leaf icons all the way at the end of the branches. Leaves correspond to the actual data being read.) Experience has shown that it is much easier to use a GUI or Web browser to determine just what you really want to monitor later via SNMP. (Ask yourself which variables are the most important while you study a device in real-time by way of its GUI or a Web browser). Other times the descriptions of the OIDs are easier to figure out. In the example you can see that I’ve highlighted receive level and when I do so, the actual OID for that leaf is shown at the top/center of the picture. Copy and paste that OID in to the appropriate spot in your SNMP manager, so that it knows where to look for the data you want it to read. Configure your manager to read the data and let you know if something happens to it (like it goes to zero, for instance).
I’ve barely scratched the surface on what can be done via SNMP. This is the sort of thing you can teach yourself on a rainy day. It’s nothing new — our IT colleagues have been using it for years – but since network connectivity is still a relatively new feature at many remote broadcast sites, protocols designed for use over networks are just now making their way in to our technical vernacular.
Irwin is transmission systems supervisor for Clear Channel NYC and chief engineer of WKTU, New York. Contact him at [email protected].
