Charlie Toner on SNMP

TonerIf you want to know about SNMP, Charlie Toner is your guy. Charlie has been using this network protocol for system monitoring and other purposes as part of the engineering team for Pineridge Media and Durham Radio, which have eight stations in four Ontario locations -- each with separate WheatNet-IP audio networks linked together through Tieline Genie STLs.

WS: Whatever started you down the path of SNMP?

CT: SNMP has been part of my network engineering career since the early ‘90s. But in broadcast, it is companies like Nautel, Wheatstone, and Davicom, to name a few, that have made this more available to broadcast engineers. I see SNMP as being a way to manage growing networks and to monitor all aspects of the signal, from the mic to the transmitter.

WS: How so?

CT: For example, I can load the Wheatstone BLADE MIB files (or Management Information Base files, which contain relevant data) into my browser and see the details of the programming that’s in a BLADE and use that to monitor the packet rates and the health of the BLADE. Just recently, I pulled 800 or 900 lines of information from one BLADE using a straight MIB browser, everything from discovery and control of audio to the changing bitrates, plus the temperature inside of the BLADE. That’s all possible because of the logic inside the BLADE and also the fact that Wheatstone supplies a MIB file with each BLADE. By the way, I got an upgrade to my Nautel VS transmitter so I can do something similar, and gather and control raw data like VSWR, DC efficiency, DC power, and other aspects of the transmitter using their MIB file. My Davicoms (remote control) also have MIB files so I can gather data from that as well.

WS: Things had been fairly quiet on the SNMP front for some time, but all of a sudden there seems to be a surge of interest in SNMP by broadcasters. Why do you suppose that is?

CT: It’s the scale of networking anymore. For example, we have eight stations and four locations at least an hour apart. We have two or three networks per site: the main office, the studio network that WideOrbit runs across, and then we have the WheatNet-IP network. We have virtual LANs over fiber optic that are full gigabit duplex, and we could actually link all the WheatNet’s together and it would be seamless, but that’s a lot of traffic to pay for over fiber. So we use Tieline Genies with the WheatNet card for inter-studio communication between the sites, and for the occasional remote. There’s a lot going on and I don’t know of a better way to monitor and control it all than with SNMP.

WS: I think most broadcasters think of SNMP as a way to gather data and monitor packet rates. But it’s more than that, right?

CT: Yes. You can follow the path of AoIP using SNMP, as it goes through the studios, through the rack and to the STL and then the transmitter. But we can also change the route that data is taking to get to the transmitter, or in the future, be able to change the channel in the studio in case there’s a problem there.

WS: Okay, but some broadcasters might ask, “Couldn’t you do the same thing with GPIO and logic?”

CT: Not exactly. If you think about it, GPIO is just contact closures or measurable voltage and resistance. In most cases, it’s either on or off – if it’s off, silence is detected. Whereas in SNMP, you can take measurements on actual devices used to support or transport your AoIP data (found on managed switches and routers). You can detect silence before it even happens. If packet rejects and drop counts start to rise, and I set a threshold for it to not exceed a certain point, I can reroute (that port or feed) to an alternate source or data path. Essentially, SNMP could control anything with contact closures and logic, like a BLADE, for example. You can also do Boolean logic (and, or, not) in the WheatNet BLADE using salvos because it’s integrated with SNMP and can do all that multiple decision-making needed for some conditions. The idea is that if a problem is starting to happen, you can do something about it before it becomes an on-air issue.

WS: Where do you suggest broadcasters start with SNMP if they’re not familiar with it?

CT: I always suggest they start with a MIB browser like iReasoning. The MIB browser makes it easy because you can browse line by line any of the SNMP functions and pick what you want and then cut and paste those numbers into your logic. The MIB file is what gives you the descriptions of data points, which can be viewed through a MIB browser in a directory tree.

WS: What do you recommend for anyone who wants to do more and is looking into SNMP network managers? Some of those enterprise-level SNMP management tools can get costly.

CT: I use Spiceworks, which is an ad-driven network management tool, and I find that it can do almost anything I need it to do. There are actually hundreds and hundreds of SNMP products out there – relays, power controllers, light switches, and sensors for doing things on the cheap. I have a friend who had a remote transmitter site and wanted to be able to control ventilation when someone walked in the door and to send a relay to the old analog transmitter to reduce power for (tower) climbers. And he did it with SNMP relays. He was able to monitor that site and control it for 600 bucks. That’s what’s great about a protocol that has been around in the Internet industry since 1992.

WS: This is beginning to sound like the Internet of Everything, you know, the smart houses and smart appliances everyone talks about.

CT: Almost. We’re not far from the point of every appliance in the broadcast chain being able to talk to every other appliance. It’s companies like Wheatstone and Nautel and Davicom and Burk that are starting to drive the bus. For example, say the levels are coming up a little too hot at the transmitter and you’re seeing some clipping, the transmitter can talk to an external processor and tell it to, ‘hey, turn it down.’ This – SNMP -- is how you get appliances in the broadcast chain to talk to each other to provide the best quality without having to rely on human ears as often as we need to now.

WS: Are you talking about studio interoperability?

CT: Yes. The transport is there, AES67. But the discovery and control still need to happen. Whereas AES67 has been great at defining the clock speed for interoperable AoIP, SNMP might be useful for discovery and control in the interoperable studio. A lot has to happen for that to take place, but the standard, SNMP, is already there. In fact, I’ll be demonstrating the aspects of SNMP discovery and control through the WheatNet-IP next month at the CCBE (Central Canada Broadcast Engineers) conference, Barrie, Ontario, Sept. 15 to 28).

WS: We are definitely following your developments there. Thanks, Charlie. We’ll catch up with you at CCBE and continue this interesting discussion again soon.

Site Navigations