Why multi-vendor networks need one management system

A modern telecom network is almost never built from one manufacturer’s equipment. The modem comes from one vendor, the antenna controller from another, the accelerator from a third, and the routers and switches from a fourth. Each arrives with its own management application, its own conventions and its own idea of what an alarm is.

The cost of a window per vendor

Once a network operation centre has to keep four or five applications open to see one network, several things go wrong at once, and none of them are the fault of the equipment.

• Correlation becomes manual. A carrier drops. Is it the modem, the amplifier, the antenna pointing, or the satellite? Answering that means reading four screens and comparing timestamps that are not synchronised.
• Provisioning is repeated. Adding a remote site means entering overlapping data in several tools, which is slow and, more importantly, is where inconsistencies are introduced.
• Training does not transfer. An operator who is fluent in one vendor’s interface is a beginner in the next, so staffing a 24/7 rota needs more people than the network size suggests.
• Alarms lose their meaning. When every tool defines severity differently, operators learn to ignore the noisy one. That is the alarm that eventually matters.

What a single management layer changes

A network management system that sits above the vendors does not replace the equipment’s own capabilities. It normalises them. The practical differences show up in day-to-day operation.

• One hierarchical view of the network, from the teleport down to an individual remote unit
• One alarm console with a single severity scale, so filtering by priority is meaningful
• Configuration of many devices of the same type in one operation instead of one at a time
• Firmware upgrades driven from the same place that monitors the result
• Role-based interfaces, so an operator sees what they are allowed to change
• One interface language, or several, chosen per operator rather than per vendor

The hard part: equipment that does not speak SNMP

The obstacle in most real networks is not the modern equipment. It is the older or specialised device that offers a serial console and nothing else, or a controller whose protocol was never meant to leave the rack. A management system that can only speak SNMP will leave those devices outside the picture, which defeats the purpose.

Two things solve this. The first is a management system whose device model is protocol independent, so a driver can be written for a device rather than the device having to conform. The second is a hardware bridge where no driver can reach: our Protocol & Port Converter exists precisely for the case where two devices have no common interface, presenting a serial device over IP and SNMP so it can join the same tree as everything else.

Where to start

Begin with an inventory that records, for every device type in the network, how it can be managed: SNMP, serial, a proprietary API, or not at all. That list decides everything that follows, and it is usually shorter and more surprising than people expect.

From there the choice is between adapting an existing platform and building one against your own requirements. We do both: RAMSTER is the development suite for teams who want to build and own the application, and our Network Management Systems service delivers the finished application when you would rather not.