radio relay network auto discovery
TRANSCRIPT
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: [email protected]
Skype: dimaskype_51
Thank You for Your attention!