This document describes a radio relay network (RRN) discovery and monitoring solution. It consists of 3 stages: 1. Node discovery using SNMP to identify devices, vendors, and hardware types. 2. Radio link discovery using SNMP to identify modem and frequency information to detect RF links between nodes. 3. Ethernet link discovery using SNMP port information to identify L2 connections between nodes. The result is an RRN graph with nodes and edges that can be used to verify EMS/NMS topology, create circuit maps in monitoring systems like Cacti, and document the network structure. This provides a complete, vendor-independent view of the RRN that traditional systems often lack.

1. Radio Relay Network
auto discovery

2. Who are You?
Engineer ?Manager ?
Both ?
• Actual interconnection status, including
capacity (bandwidth) info
and You`re dealing with operating, planning and designing of
transmission networks…
If You’re involved into the technical aspects of telecom business,
• Actual active nodes list
You need ACTUAL INFORMATION about Your
transmission network:
and, the most important part…

3. “So, what’s the Problem?” You say…
“I have:
Element / Network Management Systems (EMS/NMS) for
each TN segment
My EMS/NMS supports auto node/link discovery options”
And, It’s true… with the following limitations:
I. Nodes discovery & management
Vendor-specific EMS/NMS are usually used for ‘native’ hardware
Another vendor’s hardware support is limited and leads to extra costs,
as a result: “mono-vendor islands” in Your network and “operational gaps”
Yes, the Nodes Discovery is automatic, but
• accept Node into the system
• place Node into correct subnetwork, according to the current structure
it needs Operator manual acknowledgement to
If You`ve change management IP-address – system treats it as a NEW Node, so
Operator needs to align the topology regularly

4. II. Links discovery & management
• If You have EMS only – You can’t get information
about links and topology from it
Lets continue with our “Yes, but…”
• OSI L3 nodes (Routers) and L2 nodes (Switches) usually
supports auto link discovery protocols, for example -
LLDP
but, in order to integrate those autodetected links
into the NMS network topology, Operator
decision+action needed
• Special case – Radio Relay Hardware. Generally:
• There’s no LLDP support on OSI L2. If it is – for extra
money, or – in roadmap (extra money, tomorrow)
• There’s no L1 (radio link) auto discovery tools. If it is –
discovery uses “special tags”, that only this vendor
hardware understands (again – “mono-vendor islands” and
“operational gaps”). For example, Ericsson TN ODU uses
“Terminal ID”

5. What are the intermediate conclusions, for now?
• EMS/NMS scope limited with ‘native’ hardware, so the network
information is fragmented
• Even if all the EMS/NMS node/link discovery features are present –
‘Operator-dependence’ still exists. There is always human factor
between You and network information!
That’s why EMS/NMS network
information about nodes and
topology
IS NOT PRIMARY !
And that’s why we’ve decided not to rely on EMS/NMS data, and started to
develop alternative automated instruments for getting transmission
network PRIMARY INFORMATION!
• Node discovering is automated, but needs for Operator
manual acknowledge
• Link discovering needs for special protocols support, and
Operator manual acknowledge (in most cases)
HERETIC!!!

6. Our first goal was – Radio Relay Networks (RRN) as the most ‘desolated’
TN technological segment
The initial state:
EMS over NMS predomination (scarce topology info sources)
Weak vendor’s EMS/NMS automation functionality
Weak LLDP support on L2 layer
but (yes, you love those ‘buts’, don’t You?), at the same time:
RRN is the most massive TN segment – it’s nodes and links number by an order greater
than mobile backhaul
There are the most frequent changes
The most diverse ‘vendor’s zoo’, in compare with other technological segments

7. The best source of object information – is the object itself
Universal, vendor- independent way to collect information about TN object is well-known: SNMP
Our algorithm takes 3 stages:
Stage 1. Nodes discovery
1.1. Special script scans predefined “management IP
ranges”
1.2. Script queries SNMP fields for device vendor,
hardware type 10.100.1.1
TN management range: 10.100.0.0/16
10.100.51.3
10.100.100.11 10.100.100.13
MLTN 6p
OmniBas 2wOmniBas 4w
MLTN 20pStage 2. Radio links discovery (L1)
2.1. Script gathers information about:
2.1.1. Active modems, ODUs
2.1.2. RX/TX frequencies
2.1.3. DCN channels and neighbors
2.2. Script detects RF linked nodes, based on the
previous step information
Stage 3. Ethernet links discovery (L2)
3.1. Script gathers information about L2 switch ports
3.2. Script detects ethernet ports interconnections
based on topology information, gathered on
previous stage, and step 3.1.

8. The result of discovery algorithm – is
the RRN GRAPH
It consists of
Vertices = nodes (subracks)
and
Edges = RF links (L1) and/or
Ethernet links (L2)
The resulted graph has no “gaps” or “white spots” – it
seamless, unlike NMS-based topology.
The main condition – is SNMP and appropriate MIB-files
availability
Graph data stored in any relational database, or – in GraphML format (XML-
based)

9. The use of the network graph
1. Verification of the EMS/NMS integrated objects relevance
2. Construction and use of circuit topology in various systems
3. Transformation of graph data into the network structure
documentation

10. 1. Verification of the EMS/NMS integrated objects relevance
This application – is Your FEEDBACK for network O&M with EMS/NMS
Network Graph
Node/Edge list
EMS/NMS
Node list
Compare/verification
algorithm
NMS
Link list
Required activities list :
- Integrate Node/Link
- Remove Node/Link
- Remove duplicates
- Rename object
- Edit parameters (i.e. BW)
-etc..
NOC
Operator/Administrator
The RESULT – ACTUAL network information in EMS/NMS, and
ACTUAL Inventory, Fault and Performance data consequently.
You can be assured, that EMS/NMS data supplied to the higher-level
OSS is correct and up-to-date
Reconciliation period can be various: daily, weekly, monthly…

11. 2. Construction and use of circuit topology in various systems
As a working example - we use network graph in open-source solution called “Cacti”, in
order to
automate charts deployment
automate topology maps deployment
Topology map in Cacti organized as a text file. It contains information about nodes and
it’s XY-coordinates, and – information about nodes interconnections. All this information
is manually textmode edited – there is no GUI editor. So, the “traditional” topology map
creation in Cacti is very time-consuming task. Topology map relevance maintenance in
Cacti – NOC’s nightmare!
How does network graph make this task easy?
Take a look at our flowchart:
Algorithm generates
network graph
in GraphML format
Arranging nodes in
Gephi tool in GUI mode
(various auto-layout
algorithms available)
Applying XSLT template
to convert GraphML
into Cacti weathermap
text format
Deploying
Weathermap file
to Cacti server
Graph mesh:
vertices+ edges
Vertices with
layout:
XY coordinates
Text file in
Weathermap
format
[ graph fragment ]
[ after map rendering ]

12. Here’s some Cacti automated deployment samples:
RRN L1 (RF links) Weathermap
RRN L2 (Ethernet links) Weathermap
Ethernet link traffic chart
ODU RX level charts

13. 3. Transformation of graph data into the network structure
documentation
The very similar processing scheme used while converting RRN graph to NetVIZ text
format:
As a result – Your Network becomes self-documented

14. Further development
We’ve made scripts, gathering RRN L2 service information (VLAN IDs)
The new applications become available:
1. VLAN path trace
2. RRL fault to RBS fault dependency (RRL L2 port RBS VLAN
configurations)
VLAN path trace:
RRL fault to RBS fault dependency

15. Requirements
Scripts:
bash, perl, XSLT 2.0
OS:
Linux/Unix – based
Feedback/Questions:
email: dimas51@rambler.ru
Skype: dimaskype_51
Facebook
Thank You for Your attention!