Check out our White Paper Series!
A complete library of helpful advice and survival guides for every aspect of system monitoring and control.
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 TodayAs the manufacturer of the T/Mon alarm management platform, I'm required to ensure proper integration with a wide range of popular devices. In the world of telecommunications, it should come as no surprise that data transport equipment is among the most popular.
Just like I recently did for the best rectifiers, generators, and UPS systems, I'll now run through some of the most popular transport gear that integrates cleanly with T/Mon using its Device Modules (templates).
Let's get started:
The Calix mission statement strikes me as very similar to DPS. According to the Calix website:
"Our customers utilize the real-time data and insights from Calix platforms to simplify their businesses and deliver experiences that excite their subscribers. The resulting growth in subscriber acquisition, loyalty and revenue creates more value for their businesses and communities. This is the Calix mission; to enable communications service providers of all sizes to simplify, excite and grow."
Increasing customer loyalty through superior service is incredibly important. You accomplish this both via good transport gear and excellent reliability. Reliability is built upon good situational awareness to network threats, including power outages and HVAC failures, that threaten your uptime.
To help you monitor, T/Mon is able to process alarms from Calix Axos, Calix CMS, and Calix E7.
Unlike with some Device Modules for equipment that only sends SNMP trap messages (asynchronous), T/Mon leverages the ability of Calix equipment to respond to SNMP GET requests. This establishes a polling loop that will promptly detect whether your Calix is still online.
Any SNMP object within your Calix device is a potential polling target to T/Mon. For most standard Calix devices, you'll find that the "AlarmCondDesc" variable for each message contains a text description of the alarm condition.
Cisco is a positively huge name in the industry. I once attended a seminar where a member of their team was describing a "small, pilot project" that had "only 400 employees" assigned to it. I nearly fell out of my chair.
With so many different solutions available, Cisco necessarily describes their organization in philosophical terms:
"Cisco helps seize the opportunities of tomorrow by proving that amazing things can happen when you connect the unconnected. An integral part of our DNA is creating long-lasting customer partnerships, working together to identify our customers' needs and provide solutions that fuel their success."
Due to their popularity, it's not suprising that DPS clients want to tie Cisco into their central T/Mon master stations.
The alarms from other Cisco devices, like routers, are inherently fewer in number.
T/Mon can use SNMP GETs to collect alarms from a channel bank manufactured by Loop Telecom. This isn't a specific device name. As they note on their website: "The Loop-V4200-9 is a versatile 9-port device. Depending on the plug-in cards selected, this unit can be configured: as a CSU/DSU with drop and insert and voice capabilities, as a 4 E1 to 5 T1 converter or fractions of them, as a digital cross-connect system (DACS), as sets of ICSU combined in one box, or as a channel bank."
T/Mon has just two intrinsic alarms for a channel bank like this one: "Received SNMP Trap" and "Device not responding to SNMP GET".
Despite this apparent lack of alarm count, T/Mon can actually collect a large (theoretically infinite) number of alarm points.
That's thanks to "auto-databasing", the process whereby T/Mon uses an alarm description (usually from an SNMP variable binding) to create new alarm points on the fly.
If an OID (or unique varbind) has been seen before, the pre-existing alarm point is used. If not, a new point is created and immediately set.
The same principle applies to synchronous polling via SNMP GET and GETresponse communication.
This is another common piece of transport equipment that T/Mon monitors with its built-in library of Device Modules.
The Optima T:LAN is self-described as, "THE ALL-IN-ONE TOOLBOX. The T:LAN NetPro LAN/WAN interconnect system is a series of integrated networking products from Optima. It incorporates features of a multi-port Ethernet switch/router, an alarm aggregator and a console server. Some models also feature a traditional T1/E1 CSU, alongside a mini-DACS with optional path protection."
Much like the channel bank described above, T/Mon addresses the challenge of alarm monitoring in a dynamic way. All alarms, whether generated by received traps or GETresponse messages, are databased on the fly through auto-databasing.
NOTE: After a merger with Genband and rebranding, STP is now listed as a Ribbon product.
Ribbon describes the value of the STP on their site: "Despite the evolution of mobile markets and services, from older generations (2G and 3G) to 4G and 5G, the need for SS7 STPs will continue for decades. Ribbon's Diameter Signaling Controller solutions, DSC 8000 and DSC SWe, can be configured to provide essential STP functionality for core, edge and interconnect deployments."
T/Mon ships with the necessary Device Module pre-installed to interact with the STP. You'll simply need to install an SNMP Interrogator Software Module, which is a global one-time purchase for your T/Mon system. There are no ongoing licensing or per-device fees.
According to Tekelec-branded documentation available from Oracle: "Eagle is a large-capacity, multi-functional, fully scalable Signaling Transfer Point (STP). High capacity and scalability allow the Eagle to grow from a single-shelf, 80-link STP to a multi-frame, 1500-link STP."
T/Mon has custom tabs for the Eagle STP: Fault Alarms, Internal Alarms, External Alarms, & ASCII Rules.
T/Mon uses automatic ASCII text parsing to decode alarms written by the Eagle STP. The process is broken down into two phases:
When a new text-based message is sent to T/Mon (via printer port, serial, or via modern IP connectivity), the first step if for T/Mon to determine the source device. If your device uses a dedicated IP address or port, you might simply match all messages received. If there are multiple devices on a port, T/Mon looks for consistent elements (ex. punctuation) to recognize a certain device's format.
After a pattern has been matched, a second set of "extraction" rules are applied. These rules tell T/Mon where to find important alarm information, including: AlarmID, Site, Description, Severity, Time, & Date. This allows construction of a generalized alarm object in the T/Mon alarm space. That alarm object can drive notifications, if-then logic, SNMP traps to a higher-level manager, or a variety of other automated responses.
Product description from TelcoBridges: "The TelcoBridges Tmedia TMG800 is our low density carrier-grade VoIP gateway. Software upgradeable from 1 to 16 T1/E1, the TMG800 is the most cost-effective VoIP gateway solution for service providers currently available on the market."
TelcoBridges is a provider of telecom solutions. As they explain, "TelcoBridges designs, develops and manufactures carrier-grade telecommunications software and hardware. From its headquarters in Boucherville (Montreal), QC, CANADA, TelcoBridges performs R&D as well as assembly and testing of its products. TelcoBridges brands include: ProSBC, FreeSBC, Tmedia, Tsig, Ttrans, Tdev, and Tmonitor."
As I was doing research for this article, I became used to seeing mergers and acquisitions for several manufacturers. That doesn't seem to be the case on the TelcoBridges site. I was quite pleased to see an automatic "Support Agent" chat box for those who need support.
So, how does T/Mon collect alarms from TMG800? Much like other devices on this list, T/Mon uses SNMP GET messages to request alarm status from the TMG800 on a regular basis. Responses are logged in the generalized T/Mon alarm space.
Two alarms, in particular, stand out in the pre-databased list as particularly important: M2PA Link 1 Down & M2PA Link 2 Down.
According to a press release, "The Tellabs 7100 system aggregates SONET and MSPP services, such as Gigabit Ethernet, onto a single module that can add or drop traffic into a DWDM network. Telecom service providers can reduce infrastructure costs up to 50% by converging these functions into one hybrid transport network."
T/Mon collects alarms from the Tellabs 7100 via ASCII-based alarm rules (see Tekelec above for a detailed description of this process).
Many of the available ASCII alarms reflect the status of 8 discrete inputs on the DWDM 7100. Within the T/Mon Device Module, these are labeled: Point 1 - Point 8.
What is this Teltonika RutOS? As Teltonika Networks explains, "RutOS is highly customized openWRT by Teltonika Networks. It provides more functionality compared to standard openWRT."
The Device Module that T/Mon uses to talk to this device is very simple. On the "Internal" tab of alarms, just two are listed: "Device Offline" & "Ping Failed".
When only summary alarms are available at the alarm-master level, that usually indicates a common "drill down" strategy is used to monitor that particular device.
You can imagine seeing an indication in T/Mon of "Device Offline" or "Ping Failed". You might then launch a manufacturer-provided application or web interface to pursue additional details. If that interface is similarly unresponsive, you might truly have an offline device that requires a site visit (whether a short walk, a long drive, or a helicopter/snowmobile trip).
The combination of "air" and "fiber" is really an awesome pairing of concepts. As Ubiquiti says, "Introducing airFiber, a truly revolutionary Point-to-Point wireless platform from Ubiquiti. Housed in a compact, highly efficient form factor, airFiber delivers amazing wireless gigabit+ performance, low latency, and long range. airFiber ushers in a new era in price-disruptive wireless technology ideal for carrier backhaul, building-to-building enterprise use, or public safety applications."
T/Mon has two different Device Modules to cover this range: the airFiber24HD and the airFiber5XHD.
For both, there are fundamental Internal Alarms for "Received SNMP Trap" & "Device not responding to SNMPGET".
Fujitsu is another massive player in the space. As you might expect, T/Mon includes several Device Modules to process alarms.
Let's take a second for a basic overview of this range, using the Flashwave 4100 as an example. As Fujitsu's website says, "The FLASHWAVE 4100 ES Micro Packet Optical Networking Platform (Packet ONP) is ideal for Ethernet and TDM access service delivery and aggregation over networks up to 10 Gbps. For high concentrations of DS1, DS3, SONET or Ethernet services over OC-3/12/48/192, or when footprint is at a premium, the FLASHWAVE 4100 ES Micro Packet ONP is a compact, modular solution using a 2RU chassis. This system can operate as a standalone UPSR network element or terminal SONET shelf."
T/Mon uses a combination of ASCII (text) alarms, SNMP traps, and SNMP GETs to interact with and manage Fujitsu equipment.
The FW4100/4500 range have 8 digital ("discrete") inputs that get forwarded via ASCII messages. The Flashwave 4100 Module uses flexible auto-databasing SNMP to collect a wide range of different alarm points.
I'm glad you're still with me. That was a rocket ride through many different transport-gear providers who can be managed effectively with the T/Mon alarm management platform.
As I've mentioned several times here, Device Modules are all about creating generic alarm objects in the T/Mon alarm space. That's important, because then the entire T/Mon ecosystem opens up to you.
To set up a simple online web demonstration of T/Mon, just give me a call at 1-800-693-0351 or email me at sales@dpstele.com
Andrew Erickson
Andrew Erickson is an Application Engineer at DPS Telecom, a manufacturer of semi-custom remote alarm monitoring systems based in Fresno, California. Andrew brings more than 17 years of experience building site monitoring solutions, developing intuitive user interfaces and documentation, and opt...
