Radio Relay Networkauto discovery

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…

“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 & managementVendor-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

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”

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!!!

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

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 discovery1.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, ODUs2.1.2. RX/TX frequencies2.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.

The result of discovery algorithm – is the RRN GRAPH

It consists ofVertices = nodes (subracks)

andEdges = 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)

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

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/NMSNode list

Compare/verification algorithm

NMSLink 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, andACTUAL 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…

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 deploymentautomate 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 ]

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

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

Further development

We’ve made scripts, gathering RRN L2 service information (VLAN IDs)

The new applications become available:1. VLAN path trace2. RRL fault to RBS fault dependency (RRL L2 port RBS VLAN

configurations)

VLAN path trace:RRL fault to RBS fault dependency

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!