Embed Size (px)
Citation preview
Design and implementation of a multivendor Network
management system (NMS) user interface with the aid of
HUAWEI, ZTE and CISCO network elements.
UNIVERSITY OF ZIMBABWE
FACULTY OF ENGINEERING
DEPARTMENT OF ELECTRICAL ENGINEERING
Submitted by
Chance Kandishaya (R1713508)
DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF REQUIREMENTS FOR
THE AWARD OF A MASTER OF SCIENCE DEGREE IN COMMUNICATION
ENGINEERING
Supervisor: Dr T Marisa
Faculty of Engineering
The undersigned certify that they have read, and recommend to the Faculty of Engineering for
acceptance, a thesis entitled Design and implementation of a multivendor Network
management system (NMS) user interface with the aid of HUAWEI, ZTE and CISCO network
elements submitted by Chance Kandishaya in partial fulfilment of the requirements for the
degree of Master of Science Communication Engineering degree.
---------------------------------------------
Dr T Marisa (Supervisor)
Date: --------------------
ABSTRACT
Network monitoring system were developed to play an important role in providing remote
access which is now an important feature in modern day networks. The system has a role of
device management, configuration, network security, and alarm and faults management.
Network monitoring system are installed in network operation centre manned by first level
staff to observe network changes through events, happening in the network with the goal of
providing an alarm free network which operates within the threshold set by international
telecommunication union (ITU). The new features of service monitoring are coming on board
will incorporates the addition of performance module and develop a system which is capable
of adding third party module to manage third party networks. The most important aim of
developing this unified monitoring system is to reduce cost which are related to license costs.
The costs of licences is too high reaching to 10% of total revenue generated annually and costs
can reduced by developing simple SNMP monitoring system which works the same as vendor
proprietary systems which are currently available. The vendor systems are settle in foreign
currency which is limited supply and the implementation of this solution will save the foreign
currency component if this proposed solution is adopted by local operators. The proposed
network monitoring system in this thesis, solves the problem of device monitoring and included
features which are present in all the systems. The system was improved to monitor all vendor
network elements unlike vendor specific solutions. Therefore, the advantages of this system, is
the ability of being used by first level users who have minimum knowledge. According to the
points submitted throughout this thesis, this designed application could be used for access, core,
and IP and transmission equipment. The NMS was further developed to monitor third party
equipment as the network are evolving user requirements are changing. Lastly, the system was
developed future proof to easily interoperate with other future solutions which are coming like
software defined network (SDN) and network cloud engine (NCE).
Keywords: Network monitoring, Remote Access, Software Defined Networks, Network
cloud, Network Security, Network Management System
Acknowledgements
Firstly I would like to thanks the Almighty God for giving me the opportunity to study towards
the completion of this project works. Furthermore, I thank for the physical capability, spiritual
support given by the Almighty towards the attainment of this degree program which was
completed during the harsh times of the COVID 19 pandemic which has defined a new order.
I thank whole heartedly DR T Marisa who helped us in providing guidance and support
throughout giving us knowledge on python programming at the initial stage of the project.
Thanks also to all faculty members of the University of Zimbabwe, Electronic and Electrical
department who conducted lecturers and others who contributed behind the scenes. The lessons
learnt through the lectures is reflected throughout this thesis. I am happy with the good and
wonderful environment for researching and studying provided by the University of Zimbabwe.
Moreover, I am thankful to powerful connections which we built with my friends at UZ.
This whole works are fully dedicated to my wife and my late mother who passed on during the
2019. Your contribution will be forever cherished and preserved.
List of Abbreviations
Glossary
NMS Network Management System
Email Electronic Mail
SMS Short message service
IP Internet protocol
IMS IP multimedia subsystem
NetSNMP Net Simple Network Management Protocol
NEs Network Elements
MVT Model, Veiws, Templates
HTML Hypertext Markup Language
PHP Hypertext Preprocessor
NOC Network Operation Center
RMON Remote Monitoring
UTP Unshielded Twisted pair
OID Unique Object Identifier
MIB Management Information Base
MTTR Mean time to Repair
IDs Identifications
CL Command Line
Telnet Terminal Network
NEs Network Elements
SSH Secure shell
Table of Contents List of Figures .................................................................................................................................... 9
List of Tables ................................................................................................................................... 10
CHAPTER ONE: INTRODUCTION ......................................................................................................... 1
1.0 Background and Problem Statement .................................................................................. 1
1.3 Project Objectives .................................................................................................................... 4
1.4 Significance of the Study .......................................................................................................... 5
1.7 Feasibility Study ....................................................................................................................... 5
1.7.1 Technical feasibility ........................................................................................................... 5
1.7.2 Economic Feasibility .......................................................................................................... 5
1.7.3 Operational Feasibility ...................................................................................................... 6
1.8 Project Organization and Thesis Structure ................................................................................ 6
CHAPTER TWO: LITERATURE REVIEW ................................................................................................. 8
2.0 Overview ................................................................................................................................. 8
2.0 Related Works ......................................................................................................................... 8
2.1 Network Management System: ............................................................................................ 8
2.1.1 Dashboard: ....................................................................................................................... 9
2.1.2 Configuration System: ....................................................................................................... 9
2.1.3 Service Polling: ................................................................................................................ 10
2.1.4 Graphing: ........................................................................................................................ 10
2.1.5 Notifications and Events.................................................................................................. 10
2.2 Network Monitoring Systems currently being used in my organization: ................................. 10
2.2.1 Huawei U2000: ............................................................................................................... 11
2.2.2 Alcatel SAM:.................................................................................................................... 15
2.2.3 Fiber-Home UNM2000: ................................................................................................... 18
2.2.4 Dyhan SmartMan ............................................................................................................ 19
2.2.5: Vigilo NMS ..................................................................................................................... 21
2.2.6 Kaseya_Network_Monitor .............................................................................................. 22
2.2.7 Solar winds ..................................................................................................................... 24
2.2.8 Unimus ........................................................................................................................... 25
2.2.9 Wireshark ....................................................................................................................... 26
2.3.0 NetXMS ........................................................................................................................... 27
2.3.1 Zabbix ............................................................................................................................. 29
Conclusion ................................................................................................................................... 30
CHAPTER THREE: METHODOLOGY ................................................................................................... 31
3.0 Overview ............................................................................................................................... 31
3.1 HIGH LEVEL SYSTEM Architecture .......................................................................................... 31
3.1.1 Data Collection layer ....................................................................................................... 31
3.1.2 Processing layer .............................................................................................................. 32
3.1.3 Presentation Layer .......................................................................................................... 32
3.2 Functional Requirements of an NMS ...................................................................................... 32
3.2.1 Dashboard Presentation .................................................................................................. 32
3.2.2 Device Management ....................................................................................................... 32
3.2.3 System Administration .................................................................................................... 33
3.2.4 Alarm Surveillance .......................................................................................................... 33
3.2.5 Fault Localization ............................................................................................................ 33
3.2.6 Performance Measurements ........................................................................................... 33
3.3 Design Consideration ............................................................................................................. 34
3.3.1 Simple Network Management Protocol (SNMP) .............................................................. 34
3.3.2 Collection of OIDs and MIBs Files .................................................................................... 35
3.3.3 SNMP Data Flow Diagram................................................................................................ 36
3.3.4 Entity Relationship Diagram for the unified NMS ............................................................. 37
3.4 System Lower level Design ..................................................................................................... 38
3.4.3 URL and Views Modules ...................................................................................................... 39
3.4.3.1 How URL and Views module process a request in Django ............................................. 39
3.4.6 Libraries .......................................................................................................................... 39
3.4.7 Modules .......................................................................................................................... 40
3.4.8 Templates ....................................................................................................................... 41
3.5.0 NMS User Interface ............................................................................................................. 41
3.5.2 Fault and Configuration Management Process ................................................................ 42
3.5.2.1 Device Status................................................................................................................ 44
3.5.3 Performance Management ............................................................................................. 44
3.5.4 Capacity Utilization Formula ............................................................................................ 48
3.6 Project Approach ................................................................................................................... 48
3.6.1 High Level Programming Language .................................................................................. 48
3.6.2 Multi-threading ............................................................................................................... 49
3.6.3 Data Storage ................................................................................................................... 49
3.6.4 SNMP Configuration ........................................................................................................ 49
3.6.5 Data Cache ...................................................................................................................... 50
3.7 Implementation ..................................................................................................................... 50
3.7.1: Django framework ......................................................................................................... 50
3.7.4: Celery task to save trap data. ......................................................................................... 51
3.7.5: Device Management module Code ................................................................................. 52
3.7.6. SNMP details template. .................................................................................................. 53
3.7.7: Device database model .................................................................................................. 53
3.7.8: Celery & Reds task to collect performance data ............................................................. 54
3.7.9: Celery settings configuration .......................................................................................... 54
3.7.10: Interface trap and performance database models ........................................................ 55
3.8 Summary ............................................................................................................................... 56
CHAPTER 4 ...................................................................................................................................... 57
4.0 RESULTS AND ANALYSIS ......................................................................................................... 57
4.1 Results of NMS system ........................................................................................................... 57
4.1.1 Device Management window .......................................................................................... 58
4.1.2 Alarm Management window ........................................................................................... 59
4.1.4 System Configuration ...................................................................................................... 60
4.1.4 System administrator ...................................................................................................... 61
4.2.1: Comparing Python Vs C programming languages ............................................................... 64
4.2.2: Parallel vs Serial Approach (language: Python) ................................................................... 65
4.2.3 Request based approach vs Always ready approach ............................................................ 66
4.2.4 Alarm alert response Time .................................................................................................. 68
4.3 Performance Measurement Results ....................................................................................... 69
4.4 Summary ............................................................................................................................... 70
CHAPTER 5 ...................................................................................................................................... 71
5.0 CONCLUSION AND FUTURE WORK ......................................................................................... 71
5.1 CONCLUSION ......................................................................................................................... 71
5.2 FUTURE WORKS ..................................................................................................................... 72
5.3 RECOMMENDATIONS............................................................................................................. 72
LIST OF REFERENCES ........................................................................................................................ 74
List of Figures
Figure 2.1: Shows the U2000 dashboard view ..................................................................... 11
Figure 2.2: Shows the U2000 topology ............................................................................... 12
Figure 2.3: Showing the U2000 modularised architecture .................................................... 13
Figure 2.4: Shows Alcatel lucent Assurance Manager Login page. ...................................... 15
Figure 2.4: Shows Advanced fault management software’s ................................................. 16
Figure 2.5: Shows dashboard view of Dyhan SmartMan monitoring system ........................ 19
Figure 2.6: Shows the link performance measure window. .................................................. 20
Figure 2.7: Shows the Vigil performance system ................................................................. 21
Figure 2.8: Shows the Kayesa monitoring system ................................................................ 22
Figure 2.9: Shows the Solar Winds monitoring system. ....................................................... 24
Figure 2.10: Shows the Unimus management application .................................................... 25
Figure 2.11: Shows Wireshark network traffic analyser ....................................................... 26
Figure 2.12: Shows the dashboard of NetXMS system ........................................................ 28
Figure 2.13: Shows the Zabbix monitoring system .............................................................. 29
Figure 3.1: Shows the High Level System Architecture Diagram [1] ................................... 31
Figure 3.2: Shows the Data collector data flow diagram. ..................................................... 36
Fig 3.3: Shows the Entity Relationship Diagram for the unified NMS ................................. 37
Figure 3.4: Shows the System Lower level Design .............................................................. 38
Figure 3.5: Shows the NMS User Interface Data Flow Diagram. ......................................... 41
Figure 3.6: Shows the code snippet for Celery tasks ............................................................ 52
Figure 3.7: Device Management module code snippet ......................................................... 52
Figure 3.8: Shows the SNMP details template ..................................................................... 53
Figure 3.9: Shows Device database model code snippet. ..................................................... 54
Figure 3.10: Shows how performance data is collected. ....................................................... 54
Figure 3.11: Shows Celery application configuration........................................................... 55
Figure 3.12: Shows the performance database model code snippet. ..................................... 55
Figure 4.1: Screen Capture of the NMS GUI showing the main dashboard window. ............ 58
Fig 4.2: Screen capture showing NMS device management window. ................................... 59
Fig 4.3: Screen capture showing NMS alarm management window. .................................... 60
Fig 4.4: Screen capture showing NMS System Configuration Window................................ 61
Fig 4.5: Shows the execution speed of comparing Python, Cython and C ............................ 65
Fig 4.6: showing Multi-threading vs Non multi-threading ................................................... 66
Fig 3.10: Shows the graph for the results. ............................................................................ 70
List of Tables
Table 3.1: OIDs values showing Alarms on NEs ................................................................. 43
Table 3.2: Variables Required For Performance Management ............................................. 45
Table 4.1: Shows the comparison of the developed Unified NMS and other vendor specific
NMSs .................................................................................................................................. 63
Table 4.2: Shows the results obtained from the tests. ........................................................... 69
1
CHAPTER ONE: INTRODUCTION
1.0 Background and Problem Statement
A network management system (NMS) is a system designed for monitoring, maintaining,
and optimizing a network [1]. It includes both hardware and software, but most often an
NMS refers to the software used to manage a network. Network management systems
provide multiple services. These include, but are not limited to:
Network monitoring - NMS software applications monitors network nodes to guarantee
that all elements connected are operating within the thresholds which are expectable and
are not close or at full limit. Alarm alerts are automatically presented on the dashboard to
isolate and resolve problem areas.
Device detection – Detection involves the identification of node that it has be connected
to the network, the system using protocol available will recognize the nature of the device,
commission the node on the network, and added the element to a subnetwork [1]. The
whole process defines the activities conducted by NMS during device provisioning.
Performance measurement- NMS includes separate modules which carryout performance
measurement and analysis of traffic going and out of the network. The system measure in
real time the performance of the system through current performance statistics which can
be presented on real time on the dashboard. Also, the performance module has the
capability of storing historical performance data which is used to assess the performance
of nodes or links of period of time. The data is required by clients when drafting the service
level agreements. The expected threshold required is about 99, 95% on network with
redundancy for backbone links. It also, record performance data detecting network
bottlenecks were bandwidth is almost reaching the maximum available. This data is used
to carryout traffic optimization and alert the planning department to plan for the
deployment of new network.
Device management – the NMS system provides a platform to remotely control and
manage network elements from a central point which is the network operations centre
(NOC). This central location is equipment with software’s which can configure and modify
the status of the devices connected to the network. The activities which can be achieved
2
on device management platforms are installation of network nodes on the NMS and setting
up performance measurement counters on certain networks links.
Fault management- This module deals with the management of alarms or faults as they
happen on the network. The module has been equipped with the necessary tools to detect
device or link failures in real time and the platform can initiate traffic reroute without
human intervention. This is achieved using faults algorithm technique embedded on the
system. When the fault cannot be resolved automatically alarms or notifications are shown
on the NMS dashboard for the administrators to assign team to attend to the faults.
In the field of telecommunications operators uses network monitoring systems to
continuously monitor the whole network topology for bottlenecks, equipment failure and
notifications are forwarded to the administrators using phone calls, email, SMS or alarms
on the dashboard when there is any problem [2]. The network monitoring is a function
which is found in the network management module. Network management is required to
ensure that the network is working as expected without any alarms [3]. The network
management system must have these basic properties automatic and continuous
monitoring of the network, inform the administrator as soon as alarm arise, it should be
intelligent enough to point out the problem [4] and its exact location in the network
topology and many more. The current developmental trends vendors are developing their
own specific NMS to monitor a selected range of equipment for example Huawei
equipment’s for transmission, access network, IP core and IMS [6] have different
management system with different administrators. Large telecommunications service
providers like TelOne, Econet and Net-One they will be having different equipment’s from
different vendors with their own NMS. This arrangement will require more staff to carry
the monitoring and this set up is very difficult to manage hence operators are going for
multivendor NMS were all network elements can be monitored from single or
multiplatform [7].
The need of developing multivendor NMS is also being propelled by huge costs of licence
fee which are required by these equipment manufacturers which charging foreign currency
for these service on yearly basis. Other foreign companies like the Solar winds are
developing Orion which is a generic-purpose tool which all so does the monitoring of third-
party equipment’s but again this comes at cost. The open source systems are limited and
they customizable to a certain degree.
3
The purpose of this research proposal is to design a multivendor NMS which will able to
monitor every network device across the network. We split the project into three part other
two members developing the NMS for Huawei and ZTE while doing for Fiber-home
equipment. Fiber-home is a Chinese company that specialises in telecommunications
equipment manufacturing.
1.2 Research Problem
The technological trend nowadays, telecommunications companies are developing customized
unified NMS which monitors their whole network equipment including third party up to
customer end [8]. This development has increased the need for building a unified management
system which will be connecting specific network EMSes to the main management platform.
The development of these NMS will automatically translate to a reduction in cost of license
which are charged by the vendors. The license are charge per device connected to network
and big operators they pay more for license fees. Other operators around the globe have started
investing in developing their own NMS like a number of operator is USA they are only
purchasing the hardware and the underlying management software they will rely with they
own. This have seen a significant decline in they expenses towards license fees. In Zimbabwe,
the current trends is vendors are developing proprietary NMS to monitor selected equipment
subnetworks for example vendors NMS for transmission, access network, IP and IMS. These
different systems will be managed by different administrators and they can be brought together
on one system hence the proposal of developing a unified NMS. Ultimately the huge costs of
license which is required by the vendors for these service on yearly basis will fall off.
The main reason of having the NMS is to enable remote supervisor of the network and the team
from the Network operation centre (NOC) will carry out remote configuration without the need
of travelling to the sites [9]. The team will be controlling the whole network from a
single/multiple dashboard having all the rights of doing all the network works as the same as
they are own site. This move will save cost as the field technician will be roped in when it is
really necessary saving the operational costs. Having a customized NMS is an advantages
because every registered member has got to have a valid license to be able to carry out changes
on the network. Companies like TelOne, NetOne, Econet and Telecel they will be having
almost 200 employees each requiring access to the network remotely and the cost can be too
high.
4
The other challenges which these operators’ faces is failing to raise the amount required for the
upgrades. When operators are using the NMSes from the vendor upgrades are required
frequently and these works comes with a cost which should be factored on yearly basis. These
cost can prove to be too much for third world operators which sometimes work with outdated
NMSes due to lack of funds. The heavy reliance on these vendor NMSes will give vendors
full access to operators network and the can carry out changes which can ground the network
for them to provide support to justify the need of the support contract. The need of operator to
develop they NMS is not only to reduce the cost of license only but to also gain control of their
network.
Above are the challenges which operator are facing from the vendors and vendors are now
taking advantages of the situation by developing the NMSes which are proprietary to manage
their network elements. The NMS are scalable at costs. This situation will leave operator with
little works to do on their network because the whole network can be easy managed from
different location. They is growing need of operators to develop their own scalable NMSes to
monitor the network thereby creating or maintaining the jobs for the locals. They is growing
fear that if these trends remain many jobs are going to be lost especially in Africa and network
will be remotely managed by the vendors.
Other foreign companies like the Solar winds are developing Orion which is a generic-purpose
tool which all so does the monitoring of third-party equipment’s but again this comes at cost.
The open source systems are limited, they customizable to a certain degree and they are
associated with some other challenges like lack of network visibility, and one can’t see a
portion of a network or track a particular performance metric. Using Orion, the network
performance parameter are not very clear to understand. They also have challenges in
determining useful performance and insights, and establishing network performance baselines
[10].
The purpose of this research proposal is to design a multivendor NMS which will be able to
monitor every network device across the network
1.3 Project Objectives
The objectives of this project are:
To design a unified NMS that monitors Cisco, Fibre-Home and ZTE network elements.
To develop a friendly web user interface that will output connected network elements.
5
To design an NMS which carry out performance measurement and output service
alarms on the dashboard.
1.4 Significance of the Study
The significance of the research proposal is targeted at designing a unified network monitoring
system with faults resolution techniques and performance measurement module which is
scalable. The proposed research is very important because it seek to solve real problems which
is affecting telecom operators in Zimbabwe. There is growing need of locally developed
products to reduce to amount of foreign currency required to support the network. Also, the
research is multidisciplinary in that it combines concepts in information theory, microwave,
economics, computer networks, telecommunications and business to address the issues in
questions. The main goal is to develop and design a real time working unified NMS to monitor
the network.
1.7 Feasibility Study
A feasibility study and analysis was carried out to make sure if the project needs to proceed
given all the necessary resources and technology and to determine whether the final product or
system will benefit its intended users and also to determine whether the alternative solutions
will eliminate the existing problems in terms of inconsistences, performances and functionality.
The following feasibility studies were conducted:-
1.7.1 Technical feasibility
On technical feasibility, a set of technological tools that govern the design of the project were
considered which include proposed tools for web based application for design of both the front-
end and the back-end. The use of Html, CSS, JavaScript and bootstrap framework for front-
end and PHP5, MySQL and Maria Db can make the project more compatible with the current
technology. And also Visual studio 2017 makes it possible for the mobile application design.
1.7.2 Economic Feasibility
The economic feasibility study was conducted based on the given resource constraints. The
required resources are readily available and other utilities can be archived freely or at low cost
Later
6
In terms of development and operational costs the project is going to use more of free software
tools for design of the prototype up to the implementation of the final functional system. The
cost and benefit of each alternative was calculated and the system is compatible with a variety
of hardware as it is a multivendor unified Network Management System [11]. The project is
going to use minimal costs starting from the concepts development and prototypes until the
release of the working system and in return. After this study we concluded a reliable judgment
that this project was worthy and solving this problem was a worthwhile.
1.7.3 Operational Feasibility
Earlier in the Feasibility study and requirements engineering, we clearly analysed that the
system would be used after development. The problems from the current existing system
included too much costs, large license fees and also required more staff to carry the monitoring
as all the network elements were not able to be managed from a single platform .Through the
benefits of this unified network management system the system will be much appreciated by
most end-users as it is the alternative solution to the problems mentioned above.
The main objective of the operational feasibility study was to achieve the project goals and
objectives for both development and operations and to make sure it will serve the required
purpose while functioning as well as being appreciated by its users.
1.8 Project Organization and Thesis Structure
The project is organized into five chapters, including introductory chapter. The first chapter of
the report gives introduction the background, objectives of the study and the methodology of
this project. In addition, a brief description of the need for power usage optimisation in
Zimbabwe was presented, and the motivation for carrying out this project. Chapter Two
focuses on the literature review of systems, all the theories involved in this project, and
technologies in the field of Network management in telecommunications. Chapter Three
presents a detailed methodology of this project. A block diagram of the overall system design
is presented and the components of the project are analysed and selected, with justification
where appropriate. The system design of this project is presented at the end of the chapter. In
chapter Four, a detailed results analysis is done and works NMS application is presented. It
then explains the result of the project and the proceeds to discuss the results that were obtained.
In addition, the details of testing process that is done on the system are included. In Chapter
7
Five, a summary of the research work is presented to for this thesis. Limitations of the project
are cited. Recommendations and the potential further works are clearly stated in this chapter of
the thesis. References, appendices and the project Gantt chart of the project will be inserted at
the end of this thesis.
8
CHAPTER TWO: LITERATURE REVIEW
2.0 Overview
This chapter reviews the past developments in network Management Systems and some other
related technologies. Some important theories related to the project are also presented in this
chapter. In addition, it also presents an overview of network management architecture. The
chapter also explains the targeted components, network protocols and techniques as they apply
generally to network management. Upon completion, a basic theory of the Network
Management System technologies should have been understood [12].
Prior to the submission of research proposal, a sufficient research on the published literatures
related to this topic, had been done. The main idea of this research was inspired by the previous
works which were done by equipment vendors and others who develop monitoring system. The
two main goals of this project which are useful for the implementation of the proposed system,
were identified, which are the design and implementation of network monitoring system and
NMS user interface[2]. The purpose of this research design will be defined and concepts, which
have been helpful, in understanding technologies used in development of the proposed
application design will be collected. This proposed design goal is to come up with a system
that will monitor and give a high level topological view of the network, showing all types of
alarm to trace events which will be happening in the network. This move is possible only if
there is a proper network management and performance monitoring tools which can supervise
all the network elements [3] [13]. The network being managed whether in core, access,
transmission network element must show the topological view of network device connected in
that subnet showing performance metrics, faults re-routing using available algorithms and
escalates faults to second level teams.
2.0 Related Works
2.1 Network Management System:
When networks grow and become considerably bigger such as for Econet and TelOne, the cost
of licence fees to support the NMS become very expensive to maintain the entire network.
When such a scenario happens, cost effective solutions have to be developed to meet the same
standards that are being presented by equipment vendors. The network management system
have been developed for commercial and enterprise use using the existing software packages
9
creating systems which can monitor and manage networks [1]. It achieves this by storing the
collected information in a database .The database might be developed using SQllite or any
other Database Management Systems depending on the structure of the data to be stored and
maintained by the database. It uses some effective techniques or algorithms to evaluate the
state of the network. This system also provide performance data on how well the network is
being utilized [5].
Moreover, a network monitoring system should be able to monitor all events occurrences on
the network without putting undue load on the devices being monitored. Not many monitoring
system are able to achieve this feature. They are different techniques which are used by network
monitoring system to monitor the network. In the literature review section I will focuses on the
features required in ideal network monitoring system and those that should be provided to
produce a general purpose network monitoring system.
2.1.1 Dashboard:
A dashboard is a user interface that provides a visual display of information using a single/multi
screens such that all the network devices can be monitored at a glance [8]. This is very useful
for NMS because it allows the whole network to be monitored from a large monitor usually
placed in the network operation center (NOC) in of the system administrator and active search
to manually identify problems is eliminated. The current dashboard which are there includes
graphs that provides the performance measurement on the network or a particular transmission
line. It should streamline the process of finding faults by ensuring that it is easy to discover the
root cause of an event and by providing the direction to user were they should start any further
investigations. Lastly, it showed output alarms depending on the nature of the fault.
2.1.2 Configuration System:
Automatic configuration systems are important in today’s NMS, because they automatic learn
the changes in the network through machine learning and quickly effect changes on the
network. The changes are done with the aid of system administrator and this eliminates black
holes in the network i.e. nodes which are not being monitored in the network. If the network
monitoring system is easy to initiate and its configuration is easy to maintain, the model of the
network should be more accurate [14].
10
2.1.3 Service Polling:
Service polling is a type of network test where the network monitoring system regularly checks
for device/node availability and unavailability through ping test [13].
2.1.4 Graphing:
Time series graph depicting performance data drawn by network monitoring system can be
useful for identifying trends and anomalies [14]. In the event that large data quantity are
presented, such graphs are frequently used to summary and identify the change state of the
network. Graphs need to tailor according to the network being monitored. Most common time
series graphs are CPU and bandwidth usage these two shows how far the system is running to
full capacity. The bandwidth usage graph are more useful to system administrator and can be
used to plan network upgrades and identify likely bottlenecks [15].
2.1.5 Notifications and Events
Every network change should reach the network administrator no matter how serious the
change is to the network. NMS achieve this notification feature using event systems. Event
system is a simple system the continuously check that system parameter values are still with
the threshold or they have deviated. If there is change, an event may be triggered. Nevertheless
for complex systems like the NMS for enterprise anomaly detection is used to identify event
that can affect the network.
2.2 Network Monitoring Systems currently being used in my organization:
In my organisation and the telecommunications industry at large are being faced with the
shortage of foreign currency to service the licence fees for the network [15]. This is leaving us
with no choice but to diverse alternative systems which perform as the one’s currently on the
market. The current vendor supplied NMS are very expensive but they offer robust monitoring
systems that offer all of the above features and many more [15]. I will briefly examine the
NMS in use below.
11
2.2.1 Huawei U2000:
Figure 2.1: Shows the U2000 dashboard view
Huawei U2000 is an equipment management system developed by Huawei. Huawei provides
vender specific solutions using future proof management solution which can also carryout
power management and network functions. Figure 2.1 presents the dashboard view of the
U2000 management software. The Huawei solution is called the U2000 and they are migrating
to offer the new network cloud engine which will be cloud based. The U2000 manages the
transmission. Access, core and IP networks. Specifically, the U200 manages all the devices
which are presented in figure 2.2 which includes Huawei SDH, DWDM, OTN, radios,
switches, FTTX, voice switches, firewall and services nodes. Using SNMP and ICMP
protocols the U2000 software is also capable of managing and monitoring third party
equipment and services by directly collecting management information data for network
elements.
12
Figure 2.2: Shows the U2000 topology
The U2000 topology shown in figure 2.2 shows the network elements which can be monitored
on U2000 transmission platform. The elements are many showing that the database required
store the information must be huge and the U2000 solution supports hierarchical database,
web/client application and service processing system. It uses the modularized architecture
technique which is scalable to achieve the requirements of the management of complex and
very large network size, as depicted in figure 2.2 [16]. The system is built with the aid of object
oriented programming. Multithreading, multiprocessing, modularization and component
architecture design. This component design technique which is employed reduces coupling of
network elements as result the U2000 increases its management capability to monitor multiple
domains when the application is installed on different domains. The increase the system form
single domain to multi domain using this concept. The system was developed to easily integrate
with different NBIs systems.U2000 allows upgrades and maintenance of subsystems to be
independent because of the loose coupling framework. The system allows multiple clients for
different location to connect to the server at the same time with causing any problems. These
users can get access to same information and modify the data from different client concurrently.
13
Modularised architecture
Figure 2.3: Showing the U2000 modularised architecture
The Basic functions of the Huawei iManager U2000
The U2000 provides comprehensive management functions at the element management layer
and network management layer. This topic presents an overview of functions and features of
the U2000.
Security Management -This topic describes how to implement security management, such as
user management, login management, rights- and domain-based management, and security
policy management, to ensure the security of the U2000. Security management also includes
log management, which manages logs about the login, user operations, and running of the
U2000. In addition, the high availability (HA) scheme and data backup are supported to provide
a comprehensive security solution.
Topology Management -In topology management, the managed NEs and their connections are
displayed in a topology view. You can learn the network structure and monitor the operating
status of the entire network in real time by browsing the topology view.
Alarm Management -When an exception occurs on a network, the U2000 needs to notify
maintenance engineers in a timely manner so that they can recover the network quickly.
14
Fault Diagnosis -The fault diagnosis tool is used to detect network connectivity and perform
troubleshooting for the carrier network.
Performance Management -The performance of a network may deteriorate because of internal
or external factors and faults may occur. To achieve good network performance for live
networks and future networks while controlling costs, network planning and monitoring are
necessary. In addition, network efficiency needs to be measured in terms of the throughput rate,
resource usage, and error rate. The performance management function enables you to detect
the deteriorating tendency in advance and solve the potential threats so that faults can be
prevented. In addition, iManager U2000 Unified Network Management System Product
performance measurement based on service packets is implemented to collect performance
indicators, including the packet loss rate, delay, and jitter.
Inventory Management -The U2000 supports unified inventory management of physical and
service resources on the entire network. The U2000 provides clear and easily-accessible
information to users so that they can acquire an accurate and complete understanding of the
network-wide resources. The inventory information serves as a reference for service and
expansion planning.
Log Management -Logs are used to record the information about operations that were
performed and important events that occurred on the U2000. The U2000 allows administrators
to query and save logs and collect statistics on logs periodically. This action facilitates fault
analysis and detection of unauthorized logins and operations. Specifically, by browsing and
collecting statistics on logs, you can query the client from which a user logged in to the U2000
server and query the operations performed by the user after login. You can also dump and print
logs. Logs also can record operations that the OSS performed on NEs through NBIs.
Database Management -Database management includes managing NE databases and U2000
databases, and maintaining data consistency between the U2000 and NEs. The U2000
communicates with managed NEs successfully only after the connection parameters are
correctly set.
DCN Management -The U2000 communicates with NEs and manages and maintains network
nodes through a DCN network.
NE Software Management- also called DC, is an independent subsystem of the U2000. The
DC is used to manage NE software and upgrading or downgrading NE software. Managing NE
15
software includes saving, backup and policy management. Upgrading or downgrading NE
software includes loading, restoration, task management and managing Software etc. For
security, recommend to use SFTP as the transfer protocol between U2000 and NE.
Report Management -The U2000 provides reports on alarms, logs, and resources. You can print
the data or save the data as a file. The reports in tabular format can be filtered by equipment
type and saved in XLS, TXT, HTML, or CSV files.
System Monitoring -The U2000 provides a GUI-based system monitoring tool, which is used
to manage the U2000 and query the system information.
Network Management System Maintenance Suite -The network management system
maintenance suite (M-Suite) is a tool offered by the U2000 for commissioning, deployment,
and maintenance of HA systems and distributed systems, and database management.
2.2.2 Alcatel SAM:
Figure 2.4: Shows Alcatel lucent Assurance Manager Login page.
16
The Alcatel-Lucent Service Aware Manager is an equipment management system developed
by Alcatel. The figure 2.4 shows the Alcatel lucent NMS which used to monitor all the Alcatel
nodes and capable of monitoring end to end service management of service of their network
elements. The system is also equipped with additional software to monitor third party NEs.
The NMS recognise the third party elements as generic NEs/GNEs [17]. The NMS monitoring
software is referred as the SAM it allows users to carryout service provisioning with fewer
command line configuration and across vendor scripting performance to reduce errors. The
scripting technique also reduces the deployment time of network during change over. The SAM
system can provide monitoring for the transmission equipment by speeding up the installation
of integrated IP/optical systems which monitors service level agreement which pre-set alerts
which validate point to point service. The transport application provides diagnostic to IP and
optical paths to prevent service degradation using point to point power control, fault
localization, tracing and monitoring. Lastly, the application have inbuilt technique which
correlate network faults to diagnose the location of the fault and the cause. This feature which
is in SAM makes fault finding easy and faults are isolated way before they affect the working
service.
Figure 2.4: Shows Advanced fault management software’s
The snapshot above in figure 2.4 shows the fault management window for the SAM system.
The 5620 SAM series for Alcatel has the capability of doing the advanced fault diagnosis taking
17
snapshots of the whole network at glance. The system is also built using object oriented
programming coupled with its advantages it is able to provide network health check
automatically. The system platform has advanced sophisticated tools which are tightly
integrated to provide comprehensive fault management, service configuration, performance
measuring, accounting and security functionalities for the network. The service aware system
provides a way of managing the service provided to clients end to end creating a direct
interrelationship between managed objects network resource, the services being provided and
clients whom are using the service. The tools provides operators with the insight and control
of the network. These tools allows service providers to resolve network issues in real time
reducing service downtime.
The tools which are used by the SAM management system to determine the extent of network
issue on managed services are as below:-
The system uses the intelligent alarm system and correlation use of per-alarm
configuration scheduling. The system also couple the use of color-coded active alarm
alert system to remove duplicate alarms and reporting logs to analyse trends of events.
The use of GUI point and click configuration templates, profiles, topology form of the
network and service configuration reduces the provisioning time of service.
Comprehensive use of performance statistics counters to manage the service enable the
operators to measure usage of the clients accurately and clients are billed accurately
based on usage based models and the flat rate or destination based whichever is
applicable to the companies policy.
The platform also include an important feature of the collection and retrieval in real
time of current and historical performance data which measures the performance
stability of the links or service. The module also does the collection of performance
service statistics.
It includes simple templates to carry out the configuration of services and policies to
implement differentiated SLAs.
It has the security control module which is used to create use access privileges based
on the account settings of the individual or a group and provides controlled access to
network elements.
18
2.2.3 Fiber-Home UNM2000:
The UNM2000 Network Convergence Management System implements the convergent
management of platforms such as ultrawide band (UWB) and SDN and supports unified
management for FiberHome bearer and access devices [18]. The UNM2000 management
system is developed using low level languages with the capability of monitoring all the
elements from a single NMS platform. The system provides future oriented operation E2E,
highly reliable and intelligent maintenance solution. This improves the value as well as
operators and improves the company operation competiveness on the market.
The UNM2000 is backward compatible with all control and management functions of the other
version the OTNM2000 and ANM2000. The system inherits the scalable design and
modularized architecture which makes it easy to introduce new modules. Furthermore, the
system flexibly achieves the requirements of managing homogenous network and allows the
smooth expansion to multi-domain from single domain management to move towards the
requirements for convergence network development.
Advantages
UNM2000 implements convergence monitoring for core, IP, access and transmission
network elements with the capability of managing 50000 physical network elements.
The system offers convergence management and large capacity monitoring. With all
these capabilities the system has a processing power to manipulate massive data with a
single day processing of up to twenty billon performance entries.
The system provides the topology view which allows the operators to visually monitor
the NEs from a centralised point and this helps to understand the architecture of the
network and the status of the device on the network. It provides end to end service
monitoring ability of access service, OTN, SDH and IPRAN to meet client
requirements to effectively reduce the service development. The features of the system
are end to end service configuration, service management and monitoring dashboard.
The system was developed in cooperation with other OSS developers to design fast
northbound interfaces to allow the easy integration of the systems. It supports the
following northbound interfaces XML, CORBA, TCL and RESTful. It also supports
SNMP, TCP and UDP as southbound interfaces which are supported by the system.
The support of these two southbound and northbound are centred on the modularized
design of the system.
19
2.2.4 Dyhan SmartMan
Figure 2.5: Shows dashboard view of Dyhan SmartMan monitoring system
The figure 2.5 presents the Smart Grid monitoring system dashboard which shows the chart
view of the network elements which are being monitored on the NOC management platform.
The grid monitoring system was developed to be scalable, it adopts rich features and it’s
customizable. It can monitor smart power meter infrastructure and other active devices in the
utility network. The system was built with a capability of managing SNMP enabled devices
therefore it can manage networks that connects the infrastructure. The monitoring system
supports both the wired and wireless access plants. Dyhan system it has customizable based
component architecture. The system was built integrating different modules following the
modularized building rules. This technique makes Dyhan system more customizable for the
smart grid network and the development is more efficient and cost saving when building
futuristic systems. The system supports multiple operating system and database. The Dyhan
system was developed using Java and J2EE based technology. It runs on both the Linux and
windows operating system. Since, the system is JDBC compliant, it supports a lot of database
for example derby, Oracle, MySQL and PostgreSQL.
The Dyhan monitoring system supports the following protocols southbound and northbound
protocol.
20
Southbound protocol, the system supports ICMP, SNMP, CLI and DNP3. Furthermore, the
system was developed to be customized to equip it to support other proprietary southbound
protocols.
On Northbound protocols, the Dhyan monitoring system supports XML and SNMP over
HTTP. It uses these northbound protocols to communicate with the systems applications.
Apart from the protocols the system can support it comes with an intuitive NMS user interface
that makes it easy to monitor all of the network elements and improves network operator’s
productivity. The user interface shown below in figure 2.6 was designed with the operator in
consideration in order to improve their works. It incorporates the modern technologies for
example Flex, Flash and AJAX. The system has rich user experience interfaces and these
advantages allows operator to increase their productivity.
Figure 2.6: Shows the link performance measure window.
Dhyan monitoring system was built to be scalable requirements for the metering infrastructure
system, which have a wider radius to monitor in terms of meters. The system supports clustered
deployments. The servers are added to a network cluster to increase additional scale. This move
will increase the scalability of the system. This system has been deployed at large scale in
America and they are monitoring millions of smart grid meters. The system was developed
using EMS based technology.
The Dhyan system adopts the following features:
21
It has the cost effective smart Grid monitoring solution which is yield from the design
method which is employed in building the system. The system is designed using
modular based approach. The feature enable the design of minimal management
solution. The new features and functions can be included as and when required,
reducing the costs of deployment.
The system supports a wider range of hardware platforms depending on the size of the
network being managed. This management monitoring system can be deployed on any
platform form personal computer to clustered configuration design.
The system can be deployed with redundancy to protect the system against hardware
failures.
2.2.5: Vigilo NMS
Figure 2.7: Shows the Vigil performance system
The figure 2.7 presents the Vigilo performance management system. The system is modular
and the development allows it to monitor large systems which require its elements to be
monitored for performance. The monitoring system performs network management of device
status monitoring, device metrology, mapping and correlation. The market is dominated with
very monolithic and poorly adaptive monitoring solutions. The Vigilo management system
22
stands out and offer solutions which are adaptive and can be integrated into diverse. The system
allows operators to monitor the performance and availability of the links under monitoring.
The system offer the following advantages, the system is designed to monitor any size of the
network, and it has optimal standard features for network management, modular and
customizable. It offers essential tools that anticipate for malfunctions and resolve them in real
time without affecting the services.
2.2.6 Kaseya_Network_Monitor
The Kasey Network Monitor, servers and performance monitoring developed to monitor
UNIX, Linux, SNMP and windows enabled network elements. The system was previously
named Intellipool network monitoring system to monitor the same elements as the new
application. The commercial applications was designed and sold by the Swedish Intellipool AB
Company which was later purchased by Kaseya in May of 2011.
Figure 2.8: Shows the Kayesa monitoring system
The Kayesa NMS is presented in figure 2.8 on the dashboard above shows the list of elements
which can be monitored. The system does performance monitoring as well and provides
algorithms for automatic faults resolution.
23
The system has the following features:-
Patch management
User-activity monitoring
Agentless monitoring
Remote management
License management
Compliance management
Hardware inventory
Capacity monitoring
Event logs
Software inventory
The main benefits of using the Kaseya NMS
The main advantages of Kaseya network management system is that it used for managing and
monitoring of SNMP enable devices which include telecommunications and IT network
elements and processes, it allows the connection of remote management of devices and
provides for internet automatic updating of the system. Below are some of the features which
are provided by the system;-
Monitoring of IT-related processes- The system allows users to monitor IT related
network elements which allows automation and central monitoring of network
elements. The system manages more reliable, predictable and secure solutions for
business environments of any size. It is equipped with management tools which can be
used to identify network issues and moreover, faults are restored before they affect the
service. The system allows the operators to increase their productivity in other areas to
handle network issues in the field and to be assigned on critical network issues.
Devices and Network monitoring- The system offers a centralised dashboard which is
shown on the Kaseya network performance monitor presented in fig 2.7. The
performance module allows the technical operators to know important information
related to the network for example the monitoring of link bandwidth, memory size,
24
CPU usage, logs, disk usage and files. The monitoring system also manages the state
of workstations, servers, network status, remote workstation and many more.
Extends IT/Telecoms reach- The platform provides remote monitoring and
management capability. The operators are able to connect remotely, secure and work
from a distant end carrying network changes like they are working on site. This boosts
their reach and save on travel costs. The users uses the web browser environment to
connect to the device in the network without the distance limitation. They uses
advanced reliable connection links to gain access to computers and control them
securely with the help of these connections.
Automatic system updates- the Kaseya system application software provides the
workstations, remote personal computers, and network servers to update their software
versions to the current or latest software. The system is built to automatically handle
updates of devices and software applications with important software and security
patches.
2.2.7 Solar winds
Figure 2.9: Shows the Solar Winds monitoring system.
25
Solar winds are the leaders in providing commercial network management software and
monitoring tools. The rich graphical user interfaces shown in figure 2.9 shows the monitoring
tool that is used to monitor telecommunications network elements. In point form Solar winds
provides the following features:-
Network automation
Performance monitoring
Bandwidth Analysis
Manage configs
IP address management
Switch port management
VoIP monitoring
Troubleshooting tools
2.2.8 Unimus
Figure 2.10: Shows the Unimus management application
The Unimus is a network configuration management monitoring system which is deployed to
monitor the network elements and provides a performance measurement tools. The system
26
presented in 2.10, provides automation, device management, data disaster recovery and
configuration. The advantages of the systems are listed below.
Advantages
It supports the management of all network devices from the major telecommunications
vendors.
The deployment of Unimus application software to monitor the network elements is
very easy to set up.
It was developed to be very easy and intuitive as much as possible, so they is no need
of reading too much documentation
The system can be deployed to operate on Linux and windows environments and
supports wide range of hardware and application software
GUI web interface makes the system preferable and fast to work with the system with
minimal knowledge
The Unimus monitoring system is designed using modern technology and its adaptive
to the latest architecture and security trends
2.2.9 Wireshark
Figure 2.11: Shows Wireshark network traffic analyser
27
The Wireshark network traffic analyser is the one of the best leading tools on the market and
the tool was developed for security experts. The application software is free and enables
network users to analyse network traffic usage in real time. The tool is also used for
troubleshooting the network. The figure 2.11 shows the Wireshark analyser dashboard,
showing how packets are analysed when they are transmitted throughout the network. The
software display individual packets and details inside the transmitted packet. Network experts
uses the system to analyse the network and to resolve issues if they are present. Wireshark has
many features, some of the main features is that it can monitor packets in real time network
environments. The system also captures the packets and packets are presented on a rich GUI
interface which captures all the events.
Advantages
Provides an easier way of monitoring and faulting network elements.
The application software increases productivity because of easy dashboard tools which
are incorporated in the system
Provides real time management of network traffic
Disadvantages
Cisco proprietary. It does function on other network elements which are not Cisco.
May be expensive.
2.3.0 NetXMS
NetXMS is an open-source network monitoring system. The system was developed to monitor
the whole network infrastructure, and can also provide monitoring to SNMP enabled devices
which include hardware and application servers. Victor Kirhenshtein and Alex Kirhenshtein
are the original authors and current maintainers of NetXMS. The figure 2.12, below shows the
NetXMS monitoring software which equipped to monitor SNMP enabled devices.
28
Figure 2.12: Shows the dashboard of NetXMS system
Advantages
The main advantage of NetXMS is the ability to run a script on a problem node in response to
a trigger.
It allows Centralized configuration: the network elements configurations can be
changed through a management channel
The system is more secure: communication between nodes is encrypted and
authentication before use is required.
The node uses TCP unlike the connectionless UDP to establish communication with
nodes. TCP connection oriented helps in the case of poor quality network links.
Remote command execution- it provides remote configuration of network nodes and
commands can be installed remotely
Proxy functionality
SNMP proxy: nodes can be used to connect to other SNMP remote nodes
Extensible
Easy to upgrade
Disadvantages
Lack solid customer support teams.
29
Historically difficult to install and not user friendly.
The tool is time consuming
CLIs require extensive input of commands.
The GUI is difficult to navigate
The system is difficult to customize and to produce performance report
Tools lack customization and report generation.
2.3.1 Zabbix
Figure 2.13: Shows the Zabbix monitoring system
Zabbix is a free open-source management software tool for diverse communication
components, which includes networks, network nodes, virtual machines, servers and cloud
services. Zabbix shown in figure 2.13, provides performance monitoring metrics, among
network link utilization, CPU and disk space usage. The monitoring system configuration can
30
be achieved by the use of XML templates which contain nodes to be monitored [2].The
software monitors operations on Linux, UNIX, Mac OS, Solaris and other operating systems.
The windows systems can only be managed through agents. The Zabbix monitoring system
can use MySQL, SQLite and Oracle to store data [3]. The system was developed using C at the
backend and the frontend system was written using PHP. The system offers several monitoring
options:-
Simple checks can verify the availability and responsiveness of standard services such
as SMTP or HTTP without installing any software on the monitored host.
A Zabbix agent can also be installed on UNIX and Windows hosts to monitor statistics
such as CPU load, network utilization, disk space, etc.
As an alternative to installing an agent on hosts, Zabbix includes support for monitoring
via SNMP, TCP and ICMP checks, as well as over IPMI, JMX, SSH, Telnet and using
custom parameters. Zabbix supports a variety of near-real-time notification
mechanisms, including XMPP.
Conclusion
From the research they is need of a unified network management system which carry out
performance measurement and output service alarms on the dashboard as well as Aggregating
all the three EMS into an OSS which monitors multivendor network elements i.e. Cisco,
Huawei, ZTE and Fiber-Home network elements. This has been evitable as most of the
telecommunication companies in Zimbabwe seeks to reduce the license fees and costs of using
vendor based Network management systems. Also above Network management systems and
monitoring tools can only be used to do what they are designed to do and they cannot be
customized to suit our needs. However the currently used platforms.
31
CHAPTER THREE: METHODOLOGY
3.0 Overview
The chapter focuses on the overall design of the whole system of the project. The main
components used in the project are highlighted and justification is presented where it is
appropriate. The software codes used to design the system are also presented to together with
the code involved.
3.1 HIGH LEVEL SYSTEM Architecture
Figure 3.1: Shows the High Level System Architecture Diagram [1]
The diagram above shows the system high level system architecture model used to develop the
system. The system follows a three layered approach as shown in figure 3.1. The layers are
divided into three parts which are the data collection, storage and the presentation. The part
were briefly explained and the parts will be further discussed in the sections to follow.
3.1.1 Data Collection layer
This is the first layer which deals with the collection of data from the NEs to the database
(SQLlite) using SNMP protocol. They are many protocol available which can be used for the
collection of data from NEs but for this project standard SNMP protocol was preferred for its
advantages.
32
3.1.2 Processing layer
Layer two is the process layer, responsible for data calculation, storage, arrangement and
organization.
3.1.3 Presentation Layer
The third layer is that the application layer for graphical interface, facing the administrator, the
topology display, network performance analysis results display, alarm events management
operation and network event management and display [2].
3.2 Functional Requirements of an NMS
The NMS activities are defined in figure 3.1 through a user interface data flow diagram
presenting the functionalities of a good NMS [3]. The diagram presents all the basic foundation
on which the Network management functional requirements are defined.
The design clearly shows how information flow from all the stages until it is presented on the
GUI of the system. The system use a web based GUI because of its advantages [4]. The
functional requirements pertaining the design will be discussed in this chapter in detail. The
expected functional requirements of standard network management system design are design
are presented below:-
3.2.1 Dashboard Presentation
1. Network Elements should presented on a network topology showing all physical and
logical connection.
2. The dashboard should have separate subnets differentiating networks e.g. core,
transmission and access network.
3. Network elements must be easy to add or remove on the network Topology
4. The dashboard must be tightly synchronised with database to display real time events
3.2.2 Device Management
1. Creation of new devices to the network
2. Deletion or removing of devices to the network should be easy and involves fewer steps.
3. All devices are identified by IP address and IDs which should be allocated in a
systematic manner to avoid duplications.
33
4. All devices should be listed on the network topology subnetwork on the main
dashboard.
3.2.3 System Administration
1. Network nodes must be detected using devices OIDs received using SNMP protocol
and verified using MIB files.
2. OIDs received must be filtered to identify parameters required to be monitored from
the MIB files
3. Compare each vendors OIDs with manufacturers MIBs files to check for parameters to
be monitored.
4. Assign network IP address and IDs for the Network elements.
3.2.4 Alarm Surveillance
1. Faults must be detected using alarms received from the MO
2. Faults alarms must be filtered to remove redundant alarm information and then logged
in a database
3. The filtered alarms are presented on the dashboard and reported to the Network
Administrator
3.2.5 Fault Localization
1. The fault alarm information received from the Alarm Surveillance activity is analysed
to localise the fault
2. To isolate the faults, the fault management service queries a database containing
equipment topology information
3. All localised alarm information is presented to the systems dashboard
3.2.6 Performance Measurements
1. The activity of this module is to measure the performance status of interface ports and
capacity utilisation
2. The results are captured in the database and presented on GUI as in tabular form or
graphical presentation.
3. The results can outputted in real time or as historical data from the Database.
34
3.3 Design Consideration
Before designing the NMS, several design considerations had to be taken into account. These
considerations include the use of SMNP to access network elements, the need to develop a
scalable NMS, the need to develop a network management system that manages heterogeneous
networks and the need to design reusable components [5].
3.3.1 Simple Network Management Protocol (SNMP)
The project was designed using SNMP. The management protocol is required to give the
knowledge of the managed object’s information which will be used to monitor the devices or
network elements [6]. Most of the network device which are used in telecommunications
system supports SNMP and standard monitoring interfaces comes inbuilt in the network
elements. SNMP use was carefully chosen because of its advantages and wide spread use
within the industry. The protocol gained widespread use in 90s as standard of monitoring
connection oriented networks (TCP/IP) and also including the private networks. Internet
engineering task force developed SNMP and then it was used to monitor TCP/IP networks as
explained above. The advantages which comes with this protocol are its very simple to use,
interoperable with other protocol, easy to implement and consumes minimal processor and
network resources [6]. The SNMP defines the client and server relationship, the client program
will be stored in the agent which makes virtual connections to the server program that acts as
SNMP manager which executes polling instructions to collect information about the agent. The
database which is controlled by the SNMP manager is referred as SNMP management
information base (MIB). The MIB is a standard set of statistical and control values. SNMP also
aspects the use of private MIB’s which is the case with other vendor specific network elements
which uses standard set of statistical values [7]. This values used differ from vendor to vendor
as observed in this thesis. The SNMP protocol provides four basic functions to collect the data
from network elements which will be briefly explained below:-
Get Request: Specific values can be fetched from the network element via the “get” request to
determine the performance and state of the device. Typically, many different values and
parameters can be determined via SNMP without the overhead association with logging into
the device, or establishing a TCP connection with the device.
Get Next Request: The SNMP standard allows network managers to “walk” through all SNMP
values of a devices (via the “get-next request) to determine all names and values that a device
supports. The “walk-through” feature is accomplished by beginning with the first SNMP object
35
to be fetched, fetching the next name with a “get-next”, and repeating this operation until an
error is encountered (indicating that all MIB objects names have been “walked”).
Set Request: The SNMP standard provides a method of effecting an action associated with a
device (via the “set” request) to accomplish activities such as disabling interfaces,
disconnecting users, clearing registers, etc. The “set request” provides a way of configuring
and controlling network devices via SNMP.
Trap Message: The SNMP standard furnishes a mechanism by which devices can alert the
network manager on their own to notify the manager of an event which had occur on the device.
The trap function typically requires each device on the network to be configured to issue SNMP
traps to one or more network devices that are waiting these traps.
For this design, SNMP was primarily used for receiving Trap messages from the managed
network elements. The limitation of Trap messages facility is that manager’s network address
had to be pre-configured into the SNMP agents, so that the agents can issue traps to them.
During the design, Net-SNMP framework was used which is the set of command line tools and
libraries used for building the SNMP on enterprise networks. The framework preferred due to
its widespread use and can support all operating system including UNIX and Linux
environment.
3.3.2 Collection of OIDs and MIBs Files
The collection of OIDs and MIBs file for the agents which are three nodes under monitoring is
very important because it provides information of parameters to be monitored by the NMS. We
have chosen three different agents which are cisco, ZTE and Huawei switches the ODIs are
different and MIB files can be sourced from the manufactures or by reverse engineering when
the information in not available. During the project to gather MIB files for cisco was not
challenge but for other vendors were had to use other means of collecting the data. The MIBs
is the network’s information structure and data attributes collected from the network agent to
enable the manager to understand the information retrieved from an agent. The information is
the used by upper layer protocol to manage the network. SNMP walk was used for the
collection of information from the three switches which are SNMP enabled. The SNMP walk
provides ways of retrieving OID parameter available on the SNMP device. This will present
the parameter which are targeted for monitoring.
36
3.3.3 SNMP Data Flow Diagram
The data flow diagram blow presents the steps which are carried out when adding a new device
on the NMS and also steps to collect OIDs information from an agent.
Figure 3.2: Shows the Data collector data flow diagram.
37
3.3.4 Entity Relationship Diagram for the unified NMS
Fig 3.3: Shows the Entity Relationship Diagram for the unified NMS
38
The ERD shows entities in the NMS and how they are related. The Entities within the system
are network devices, systems administrator, NMS user interface, switch, Device management
interface, Fault management interface, performance management interface, SNMP agent,
polling module, Database, Fault/alarm, Graph and statistical information. Like Indicated above
on fig 3.3, the SNMP agent collects data from the network devices sending it to the polling
module which then updates the database. The NMS user interface has the performance
management interface, Fault/alarm management interface and the device management
interface. The performance management interface displays the statistical information in form
of graph and the fault management interface raise an alarm in case of a fault as well. The
systems administrator adds or remove network devices as well as maintaining the database.
3.4 System Lower level Design
Django Framework
Library
Module
Control
View
URLsClient
Interface
SQLITE 3
Templetes
Agent
snmp
SNMP TRAP
Library
CELERY
Tasks
Reds
Figure 3.4: Shows the System Lower level Design
39
The above figure 3.4, shows the system low level architecture, each module will be discussed
in detail and their use will be justified.
3.4.3 URL and Views Modules
The Django framework allows us to create URL configuration (URL config) module in python
language which will be used for mapping. The module is code in python programming code
and provides mapping between URL path expressions to python functions [8]. The mapping is
designed to be as short as possible. Using the python language, the mapping can be constructed
dynamically and it incorporates way of translating URL to active language.
The view module executes tree tasks it accepts HTTP request, applies business logic provided
by python classes and methods and HTTP responses to clients requests. In other words, the
view fetches data from a model and either give each templates access to specific data to be
displayed.
3.4.3.1 How URL and Views module process a request in Django
In this section we present how a request is processed when a request is received from the NMS
dashboard to the network management system. The system follows an algorithm to determine
which python code to execute:
Django determines the root URLconf module to use
Django loads that Python module and looks for the variable urlpattens. This is the
sequence of django.urls.path() instances
Django runs through each URL pattern, in order, and stops at the first one that matches
the requested URL, matching against path info
Once a match has been found, the framework imports and calls a given view.
If no matches, Django invokes an appropriate error handling view.
3.4.6 Libraries
Django framework comes with its own set of libraries for solving common tasks. A Django
software library includes prewritten software codes, classes, procedures, scripts and
configuration data [9]. In the development of the code libraries were used to the code to provide
more functionality and to automate a process without manually writing new code. This move
reduces the time to market a product.
40
In this project, Django REST framework was used, which is a framework responsible for
building application programming interfaces. The API allows the conversion of python codes
into a language that can be understood by the frontend program. The implementation section
shows the code snippets of a library which were used to build the code.
Django has an inbuilt object-relational mapper (ORM) that helps developers interact with the
database. AN ORM is a library that automatically transfers data stored in database into objects
commonly used in application code. The ability of Django’s ORM to extract information
speeds up web application development and helps developers build working prototypes in no
time. Developers don’t necessarily have to know the language used for database
communication to manipulate data. Additionally, Django’s ORM helps developers switch
between relational databases with minimal code changes. On the project since it is small we
are using SQLite and it is to switch to MYSQL in enterprise development.
3.4.7 Modules
The modules plays an important role to interfaces with the databases being used in the
development of the system. In the project SQLite and Reds are being used for different
purposes to store data. The SQlite comes with the Django framework and when the project
become bigger external SQL database can be used. The Reds is a small database which is used
to store temporary instructions awaiting execution to speed up the system processing speed.
The tasks will be executed from the queue fetching them from the Reds database individually
and this improve the performance of the system. The modules is a single, definite source of
information about the data [9]. It contains the essential fields and behaviour of the data being
stored. The model points to a single database table. The framework provides a python class and
a subclass. Each attribute of the module represent a database field. After defining modules, you
need to instruct the framework that the modules are going to be used. The works achieved by
editing the setting file and changing the installed application setting to add the name of the
model that contain the model.py.
41
3.4.8 Templates
In this project, we are going to use templates which comes with the Django framework in the
development of the system. The framework comes with a very powerful template engine and
its own markup language with many tools. In the development of the NMS system templates
were used to render data. The templates are files with HTML code that’s used to render data.
The contents of these files can be static or dynamic. The code snippets of the templates are
presented in implementation section.
3.5.0 NMS User Interface
The user interface presentation is very important in the development of NMS because it shows
the whole system works from a single or multiple dashboard. A good design of the user
interface will capture clients to purchase the system and clients wants a system which is easy
to use and can shows the whole topology of the network from a single dashboard. In this design,
efforts were made to capture all the network from a single dashboard and as illustrated on the
data flow diagram in figure 3.5 below capturing all the modules for device management,
fault/alarm management, security management and also performance management. These are
the main modules which will provides with event or information to be displayed on the GUI.
START
Open server url
ERROR?
Verify if server is running
Verify connectivityOK?OK? YES
NO
Start Server
YES
Click dashboard
Dasboard listiing is displayed
YES
NO
Click Device Management
List Devices Create Device
System Administratoin
NO
Vendors SNMP
Alarm Management
Interface Alarms History Alarms
Figure 3.5: Shows the NMS User Interface Data Flow Diagram.
42
The data flow diagram above presents us with the modules which can be accessed after opening
the NMS application. The NMS will present a dashboard with a list of icon which can link the
user to the modules. The basic function of the GUI is to display all the information which is
processed by backend of the NMS. The user of the frontend application can monitor the status
of the network in real time and also be able to retrieve historic performance data from the
system. The system was developed using distributed approach were modules can be accessible
from differently. The design of the system is line with available standard for the development
of NMS. The use of standards allows the design to have different modules .i.e. fault,
configuration, accounting, performance and security which are the basic modules for any NMS
development. The modules were included in the design and each module use will be discussed
in detail.
3.5.2 Fault and Configuration Management Process
The fault and configuration management process is responsible for showing the system status
and reporting abnormal conditions on the network through the use of alarms on the dashboard.
The process is regarded as simpler when is compared to the performance management which
involve monitoring various conditions of network elements which are aggregated to come up
with the system performance. The fault and configuration management process uses the OID
values and using the MIB file from the vendor status of the NE can be monitored with involving
additional computation ability. The OIDs values are collected from the NEs which are required
to perform fault management functions. The information collected shows the operational status
of the network element interfaces status, the hardware components and software components.
The NEs have been configured to read and write mode. This in tells that the values cannot only
be read but changes can be effected to the data residing on the NEs. The state of the NEs can
be changed to up or down by the use of command line or GUI. Using the configuration process
module present on the system the uses are able to perform configuration by changing the state
of the devices. The table below shows a table of variables indicating faults in the Cisco NEs.
43
Table 3.1: OIDs values showing Alarms on NEs
Variable Object Identifier Description & Value
IfadminStatus 1.3.6.1.2.1.2.2.7 Shows the state of interfaces in the
network.
Up (1)
Down (2)
Testing (3) Sending dummy
bits through an interface
hrDevicestatus 1.3.6.1.2.1.25.3.2.15 Hardware running Status
Unknown (1)
Running (2) device up
Warning (3) Error
Testing (4) testing state
Down (5) device down
HrDevicestatus 1.3.6.1.2.1.25.4.2.17 Software running status
Running (1) software is running
Runnable (2) Waiting for resources
Runnable (3) Loaded & waiting for
event to start the process
Invalid (4) software not running
The collection of OIDs have been described in section 3.2 on the SNMP data collection
dataflow diagram. The same process is followed when collecting values for the faults
management variables. The information captures the current event information pertaining to a
specific NE. The SNMP manager poller initiates an SNMP session with a SNMP Get request
and stores these values status on the SQLite database which is being used for this project. When
changes are to be effected on the network element, the manager uses the SNMP set operation
in order to modify the status variable in table above.
44
3.5.2.1 Device Status
The NMS captures device status on the dashboard and displays the current status of the NEs at
any given point in time. The information collected from agents and NEs is manipulated in the
device modules by assigning the respective OID to represent a condition to be display on the
dashboard. The Agent and NE are different, an agent is a software resident in the NE which is
responsible of establishing communication with hardware resource server and NE is the
hardware and software components of the device. The following information of the OIDs were
retrieved from the NE .ie. 1.3.6.1.2.25.3.2.1.59 and 1.3.6.1.2.1.25.3.2.1.5.1., showing that the
hardware component are working properly. This condition is displayed as green colour on the
dashboard showing that the hardware is working properly as expected. Nevertheless, if the
condition changes, the respective OID value is sent to manager and process through the relevant
code module to capture the changes which will be to the database. The changes are sent through
traps and the NMS will capture the fault indication by showing a red alarm colour on the
dashboard.
The other important parameter that is monitored on the switch is the status of the interfaces.
The agents monitors the status the interface by sending traps to the manager of the changes in
interface condition. The NE can show an up state on the interface showing that everything is
in good order and can also show a down state on the interface showing a fault. These status are
collected using SNMP using ifadminstaus OID. The SNMP set operation can be effected to
modify the status of the interfaces.
3.5.3 Performance Management
Performance measurement is one of the important feature of the NMS were the performance
of NEs are monitored to come up with the over system performance of NEs [9]. The
performance of a network can be assessed by interrogating all the NEs in the domain. In our
project we physically simulated a network by interconnecting NEs using physical connection
to form a network. The NEs were connected using FE interfaces through CAT5e cables. The
code will automatically calculate the performance of the system. The NMS uses polling of data
from agent to capture required object values from agents which require constant monitoring.
The use of MIB variables are not a representative indicator of the network status and variable
require to be aggregated with several variable to come up with the required performance
measurement formula. The section below presents the calculation that have been performance
control module to calculate performance. The performance function are recommend by the
ITU-T.
45
3.5.3.1 Performance Management Parameter
The table below lists the messages that are required for monitoring performance functions. The
information as well as the values have been defined and stored in the agent’s MIB database.
The messages is identified by unique OID value in the MIB tree. This means that whenever a
message request is received by the agent, the message name is mapped into the OID equivalent
and the agents reads the stored value from the MIB. There are different fixed numbers of
datatypes which are used by the values of OIDs. The value types used for performance variable
are timetick, counter32 and Gauge32. Timetick represents an unassigned integer that represents
the time. The range of the timetick is 0 to 2^32 in hundredth of seconds. Counter32 represent
a non-negative integer which increases until it reaches a maximum value of 4294967293 when
the counter reaches the maximum value. Then it starts to increase again from zero. Gauge32
represents an unsigned integer, which may increase or decrease but cannot exceed a maximum
number.
Table 3.2: Variables Required For Performance Management
Variable Name OIDs Description Value Type
SysUpTime 1.3.6.1.2.1.1.3 The time since the managed
node was last re-initialize
TimeTicks
ifInErrors 1.3.6.1.2.1.2.2.1.14 the no. of inbound packets
with an error
Counter32
ifOutErrors 1.3.6.1.2.1.2.2.1.20 the no. of outbound packets
with an error
Counter32
ifInUcastPkts 1.3.6.1.2.1.2.2.1.12 the count of inbound unicast
packets
Counter32
ifOutUcastPkts 1.3.6.1.2.1.2.2.1.17 the count of outbound
unicast packets
Counter32
ifInNUcastPkts 1.3.6.1.2.1.2.2.1.11 the count of inbound non-
unicast packets
Counter32
ifOutNUcastPkts 1.3.6.1.2.1.2.2.1.18 the total outbound number of
non-unicast packets
Counter32
IfInOctets 1.3.6.1.2.1.2.2.1.10 Total number of octets
received on an interface,
including framing characters
Counter32
46
ifOutOctets 1.3.6.1.2.1.2.2.1.16 Total number of octets
transmitted out of an
interface, including framing
characters
Counter32
ifSpeed 1.3.6.1.2.1.2.2.1.5 Interface’s current
bandwidth in bits per second.
Counter32
ifInDiscards 1.3.6.1.2.1.2.2.1.13 Number of inbound bytes
that have been discarded to
free up the buffer space.
Counter32
ifOutDiscards 1.3.6.1.2.1.2.2.1.19 Number of outbound bytes
that have been discarded to
free up the buffer space.
Counter32
ifInUnknownProtos 1.3.6.1.2.1.2.2.1.15 For Packet-oriented
interface, the number of
packets received via an
interface which were
discarded because of an
unknown or unsupported
protocol.
Counter32
ipOutDiscards 1.3.6.1.2.1.4.11 he number of output IP
Counter32
146 packets for which no
problem was encountered to
prevent their transmission to
their destination, but which
discarded (i.e. lack of buffer
space)
Counter32
ipOutNoRoutes 1.3.6.1.2.1.4.11 The number of IP packets
discarded because no route
could be found to transmit
them to their destination
Counter32
ipFragFails 1.3.6.1.2.1.4.18 The number of IP packets
that have been discarded
Counter32
47
because they needed to be
fragmented at this node but
could not be (e.g. their D
ipOutRequests 1.3.6.1.2.1.4.10 Total number of IP packets
which local IP user-
protocols supplied to IP in
requests for transmission
Counter32
ipForwDatagrams 1.3.6.1.2.1.4.6 The number of input packets
that request to find a route to
forward them to their final
destination.
Counter32
3.5.3.2 Total Packets Received Calculation
The system is able to calculate the total IP packets received at a NE’s interface. The formulas
are inputted in the system’s performance module designed to monitor the performance of the
system. The total IP packets received (TR-IP) is count which measures the number of packets
received at a NE’s interface [10]. The total number of packets received across an interface is
given by sum of all inbound packets. Furthermore, the inbound packets is composed of the
following packets unicast, non-unicast, discarded, packets with errors and packets discarded.
The equation for calculating the total IP packets received by a NE’s interface is depicted in
equation (3.5.1). The following packets which makes the following equation are acquired by
from SNMP OID variables.
Below is the equation for calculating TR-IP:
TR-IP = ifInUcastPkts + ifnNUcastPkts + ifInDiscards + ifInErrors + ifUnknownpotos (3.5.1)
3.5.3.3 Calculation of Total Transmitted Packets
The above formula 3.5.1 gives the total transmitted IP packets through an interface. The
number of successfully transmitted packets (TT-OK) over the link is as given on the below
formula:-
TT-OK = TT-IP- Total Errors (formula 3.5.2)
Where, total errors is given by:-
Total Errors = ifoutDiscards + ifOutErrors (formula 3.5.3)
48
3.5.4 Capacity Utilization Formula
The capacity utilisation formula measures the utilisation of an interface over a period of time.
The formula is expressed as percentage in which the resource total usage is compared to its
maximum operational capacity. Capacity utilisation is the principle for determining how full
the network links are. This measure enable us to monitor links with congestion throughout the
network. In this project, WAN connections were used which uses full duplex mode allowing
communication in both directions concurrently. If the utilisation rate is over 80% is noted as
an overloaded and traffic required to be transferred to less congested routes or an upgrade. The
calculation of utilisation rate, is very complicated and needs to sample the interface or link over
a period of time. The values acquired from the agents are octets meaning that the each octet is
one byte. So the formulas need to be multiplied by 8, eight times to get the rates in bit per
second. The NEs has modes of communication which preconfigured which are half and full
duplex. The duplex status is indicated by the value of OIDs. Since, full-duplex is being used
(FDU), the capacity utilisation formula calculates the larger value of the input and output octets
(bytes) and output the capacity utilisation percentage. The calculation of capacity utilisation is
given as below:-
CA = Max [(ifinOctets- ifInOctects), (ifOutOctects-ifOutOctets)]*8*100/ (formula 3.5.4)
[(sysUptime – sysUpTime)*ifSpeed]
3.6 Project Approach
This section aim to describe the design approach which was employed during the development
of the system. The primary objective of the project, is to design a NMS which can be used to
monitor heterogeneous network elements with the idea of aggregating the organisation NMSs.
The below highlights the different approaches that were used to improve the design of the
NMS.
3.6.1 High Level Programming Language
The system was develop using python a high level language. The language is easy to code and
to process data. The language has a drawback of the speed of execution which is less than other
low level programming languages [11]. The programmers are reverting to use python
programming because of its short turnaround time. The other companies are using python
programming because the code be easily further developed while list the application is in use.
The complied programming language C have a small memory footprint than the interpreted
49
language python which requires large memory storage space. The issue of memory size is no
long an issue nowadays as we have technologies which can develop large memory devices
easily. The python programming language is compatible with various operating system (OS)
and also across different forms of architectures.
3.6.2 Multi-threading
The development of the project was developed around the concept of employing multithreading
techniques. The approach was used after previous solutions failed due to serial approach which
they followed in designing the management tools. This tool was developed keeping in mind
that multithreading was the important component of the project. The project designed using
threading solutions divides the project into different sets of modules each module responsible
for a different function. The tool is easy to upgrade and to add other different module in the
future to keep in trend with technological changes. The individual modules within the code
operation could be executed in parallel thereby increasing the processing speed of the system.
The python language works well using single threading and changes had to be made using
python interpreter lock. This module allows the python code to do multi-threading. The python
libraries were made to be thread safe.
3.6.3 Data Storage
This project uses SQlite, celery and reds database for information storage. The celery and reds
storage are used for storing tasks which are awaiting processing. This were included to
increasing the speed of processing. It provides secondary storage and the primary storage is
provided by the SQlite. The primary storage store various files from NEs through the
information which collected by SNMP and files are created included node and network
information. Files collected information are advantages when using information from one
system to another. The file are stored in different files within the network in hierarchical order.
This move allows node information and timestamp data to be searched through easily. The use
of different files makes it easier for parallel information access on the database.
3.6.4 SNMP Configuration
The SNMP configurations is used for the collections of meta information about the interfaces
within the nodes which includes name (ifName), description (ifDescr) and many more. This
kind of information is collected once and are stored for use by the visualization module and the
meta is refreshed each day. When the SNMP is used for enterprise, the mapping from the MIB’s
50
files needs to be looked up to reference the collected objects. The mapping is also done once
at the beginning.
3.6.5 Data Cache
The cache memory is used to store data temporary within the storage units. When data is
collected after each iterations, its timestamped and temporary stored for use by the visualization
module. The catching is done for meta-information which include interfaces names and
descriptions, status information and performances data. The data in the cache are flushed after
the end of 24 hour cycle.
3.7 Implementation
3.7.1: Django framework
The project is being built using python programming language, because of its wide spread use
nowadays as shown in backend design diagram in fig 3.3 below. The figure shows all the
modules which were used to come up with a working system and also how each module is
integrated to other modules. The programs built using python they can be achieved using
various methods using frameworks which incorporate already coded libraries which allows
teams to develop a working system with in the shortest period. In the project the Django
framework was chosen over other frameworks which are available because it’s a framework
which is now very common in the development of web applications. Django is defined as a
model view templates (MVT) web framework. The framework is robust and simply to help
web developers write clean, efficient and powerful code as compared to other python
frameworks. The framework is being widely used by international company and government
agencies like Instagram, Youtube, Google and NASA to develop their applications with the
shortest period of time. In this project will discuss the libraries, control module and scripts
which comes with the framework in detail. The code snippets of all these modules will be
presented to show how there are integrated in the project.
This framework surpass other python frameworks which are available today which are
Charmpy, Webpy, Tornado and other frameworks. The advantages and disadvantages of the
Django framework are as tabulated below.
51
3.7.2: Advantages of Django Framework
Django is defined as a batteries-included framework. It comes with a lot of stuff out of
the box that are available for use by importing packages.
Django uses python, it leverages some of the fame and power of python to its own
benefit. Python is arguably one of the easiest if not the easiest programming language
to lean for beginners.
Django’s community is one of the best. They are helpful and actively working on
making the framework more friendly and stabilizing the framework while adding new
features. The framework has quite thorough and is useful as a standalone tutorials.
The framework is scalable
The framework has a built-in administrative interface at the backend to manage your
data with basic CRUD operations.
Security Users of Django will be impressed with the level of protection from all
possible security-related errors like clickjacking, SQL injections, cross-site scripting,
and forgery.
3.7.3: Disadvantages of Django
The URL specifying with regular expressions it’s difficult to accomplish for at least
beginners.
Templates errors fail silently by default, it requires experienced developers to
understand what’s wrong on the code/application.
The following are the code snippets of the network management system. It shows the celery
tasks to perform different operations.
3.7.4: Celery task to save trap data.
This section seeks to present the codes snippets used to develop the system. The code was
developed including the celery database as highlighted in the network relationship diagram
presented in figure 3.3. The code snippet in figure 3.6 shows how traps are save in the
temporary database while awaiting execution. The trap is save a received trap. This tasks
invokes methods from the unmslibrary for processing and saving the traps received. In celery
52
database, before the traps are saved they need to be parsed to check if device is configured in
the system, enterprise and OID.
Figure 3.6: Shows the code snippet for Celery tasks
The code snippet above shows a function save trap (data) .It collects network device data
information by the use of SNMP.
3.7.5: Device Management module Code
Device management module code snippet presented below in fig 3.7 manages the device
availability on the network management. The devices SNMP management OIDs are monitored
to check if the device is offline and online. The managed devices addresses were used to locate
the device in the network and on this project three device were used. When the network grows
device addresses needs to be carefully shown and planned.
Figure 3.7: Device Management module code snippet
The above code snippet shows the task to check the status of the main code, database, and
interface response.
53
3.7.6. SNMP details template.
SNMP details template captures the SNMP device information of the network elements in the
network, version and SNMP security level. Figure 3.8 snippets shows how the code was
configured to collect these details from a network element.
Figure 3.8: Shows the SNMP details template
SNMP details template shows the SNMP details for device and the SNMP details list as well.
3.7.7: Device database model
The device database model presents the code for storing the device information in the database
for presentation by upper layers. The project use SQlite because of its easy to upgrade and cost
was another factor which influenced its use. In the code presented in fig 3.9 the structure of the
database used is shown and the types of information to be captured. The important information
highlighted is the device name, type, vendor, model and many other useful information needed
to monitor a device on a NMS.
54
Figure 3.9: Shows Device database model code snippet.
The code snippet shows the device database model .It defines some attributes of the database
as shown.
3.7.8: Celery & Reds task to collect performance data
In this project, celery and reds temporary storage were used to collect performance data. This
configuration was done to reduce the processes which are carried out by the system to fetch
performance indicator from the system. The configuration will speed up the system execution
time through using other small database to collect data. Fig 3.10 below shows the configuration
used to collect performance data from device interface.
Figure 3.10: Shows how performance data is collected.
The code above collects performance data from the interface.
3.7.9: Celery settings configuration
Figure 3.11 below shows the code snippet for celery settings configuration.
55
Figure 3.11: Shows Celery application configuration
The code snippet shows the celery application configurations.
3.7.10: Interface trap and performance database models
The code snippet in figure 3.12 below shows the performance database model. The code sends
interface traps to the system capturing changes observed on the interface. The model used for
this system captures and store the interface related performance monitoring updates/ traps. The
system is configured to capture or monitor utilisation, received and transmitted octets.
Figure 3.12: Shows the performance database model code snippet.
56
The code snippet shows the interface trap and the performance database model. It’s a model to
store interface related performance monitoring.
3.8 Summary
This chapter 3 presented the overview of how the system was designed. Clearly showing out
how each and every module is interrelated to one another with the aid of relationship diagrams.
The design constraint were explained and justifications of using different technical approaches
than the one found on the commercial NMS was also explained. On the implementation section
the code was presented showing how module in this system were configured and dataflow
diagram were added to simplify the understanding of data flow within the system. The next
chapter will briefly present the results and depth analysis was presented to compare the results
obtained with the working systems.
57
CHAPTER 4
4.0 RESULTS AND ANALYSIS
Chapter 3, presents an overall design of the network management system detailing software
components, physical components and the graphical user interface (GUI) software components
used. The chapter clearly showed how these components interact with each other to provide a
working NMS. Chapter 4, presents the results and analysis of the developed network
management and comparing with other vendor specific and generic systems which are already
there in the market. In section 4.1 the results of NMS designed are outlined based on the
functionality of the system, 4.2 results are analyzed comparing with the existing systems on
the market and 4.3 simulation of results using the bandwidth throughput tests (RMON) using
EXFO Ethernet Tester.
4.1 Results of NMS system
On this section, results of the developed system will be discussed looking at different
capabilities of the system which were spelt out during the design. The unified NMS was
developed to substitute the current vendor specific and generic NMS which are licence based.
The system presented is custom made which can be tailored to suit the need of the operator
with minimum cost fees. The system was developed to monitor every telecom network element
network, therefore the solution is best suited for very operator. The solution was designed with
a friendly GUI which is the same as for other vendor NMS which makes uses of graphs and
subnet networks topology to easy one understanding of the network. This design was made
possible by the use of python and HTML programming languages which have strengths in
visualization and graphical presentation [1].
Comparably, to other NMSs the system manages data, it also analysis of statistical data collect
to the servers, provides an improved data visualization and makes prediction using
mathematical algorithms which is inherently embedded on the framework which uses modules
which can carry out calculations to predict errors and faults in the network. Figure 4.1 below
shows the network management system dashboard, device management network window
which shows the elements connected to the network and their connections whether fibre,
58
copper UTP cable or microwave connections. The system like any other provides
configuration, performance and faults windows [2] which will be discussed in detail.
Figure 4.1: Screen Capture of the NMS GUI showing the main dashboard window.
The above screenshot in figure 4.1, shows three devices which are connected to the network
and they are online. They are cisco, ZTE and Huawei switches which are the three physical
devices used in the development of the system to represent NEs since the collection of the OIDs
and the MIBs file will differ from vendor to vendor. On the dashboard as well we observe a
total of 122 interfaces and from the total 18 are active and the rest are disconnected.
4.1.1 Device Management window
The device management window snapshot is rendered based on the functions the system can
perform compared to the other systems on the market. On the snapshots the device management
windows does the node addition to the network, service configuration, network parameter
settings and network element deletion on the network [2]. All these are basic function of NMS
which is achieved by all the systems discussed in chapter 2. Fig 4.2 shows the snapshot of the
device management window from the system. The add icon is used to add additional network
elements in to the network subsystem whether a new installation or a replacement. The nodes
carry a unique IP address which is used to add them to network. In this project, SNMP was
used to collect node specific information for monitoring. The device can also be deleted from
network topology using the delete icon.
59
Fig 4.2: Screen capture showing NMS device management window.
The dashboard shows the device lists with three devices on the host field, there is the type field
which shows the type of equipment installed whether it is switch or router and also the version
field which shows the version type of the equipment. The NMS system capture the city and
region information to easy the works of the NOC team in identifying location of faults and
support teams.
4.1.2 Alarm Management window
The alarm management snapshot is presented to show the results presented by the alarm
module and this module is very important in the telecommunication field as it reduce the mean
time to repair (MTTR)of service rendered. Fig 4.3 shows the alarm management window
snapshot. On the snapshot it shows different types of alarms which are minor, major and critical
using the convectional colours which are used by every developer distinguish them. Blue
colour is used to indicate a minor alarm represents (10^-12) for a non-service affecting alarm
nevertheless is shows the degradation of the quality of service. This alarm assist in faults
prediction [3]. Yellow/or Orange colour represent (10^-9) a major alarm for service affecting
alarms and these alarms are used by performance management modules to initiate service
60
rerouting. Lastly, the red colour represent critical alarms which usually fall below 10^-6 usually
shows that the service is down due to hardware failure or break in the link.
Fig 4.3: Screen capture showing NMS alarm management window.
The alarm window shows the alarms in the network the alarms are set to certain thresholds in
the system when the threshold is reached the alarm is triggered and outputted on the dashboard
alerting the responsible authority to take action.
4.1.4 System Configuration
The system configuration snapshot is presented to show the results of the configuration module.
The module was developed following the standards used to develop network management
systems which are currently on the market. The goal of configuration management module is
to monitor network and carry out system configuration of service required by clients. The
module was developed with integration software to allow different vendor equipment whether
hardware or software to interoperate, observed and monitored on a single platform [4]. Fig 4.4
shows a snapshot for the system configuration which shows how the services are configured
on the network. The platform provides GUI service configuration for any devices. The solution
presents a quicker way of achieving the goal allowing the running codes to assist in the
automation of the configuration process.
61
Most vendors have developed NMSes with a system configuration module which automates
configuration using GUI and the action have shorted the service delivery time. Below is a
snapshot of the service configuration module which presents the same results as others.
Fig 4.4: Screen capture showing NMS System Configuration Window.
The system allows the configuration team to assign service to various interfaces on the nodes
and add new devices. The team can also do traffic shaping and bandwidth management on the
ports of inbound and outbound traffic. Labelling of clients port is other feature which is
provided by this module. With the increase in the number of network elements deployed, it is
paramount to be able to accurately identify the location of network device. The location
information is a detailed description captured in the remarks section which is used to assist the
NOC team in assigning correct resources when a problem occurs.
4.1.4 System administrator
The system administrator icon the main dashboard provides the security management of the
system which is to control access to network resources according to the rules of the operator.
The security management module prevents network sabotage whether intentionally and
unintentionally [5]. The security administrator subsystem includes user management, NE
management, and access control and resources management subsystem. These subsystem are
the basic features of good NMS because without proper security the network will be exposed.
62
This section discuss the results of the security management subsystem comparing to other
system and we selected three systems i.e Huawei U2000, Alcatel Lucent ISAM and Fiberhome
UNM 2000. The results obtain were tabulated on the table below on Figure 4.6. The field of
security management is very vast and vendor have invested a lot in security, therefore in this
project we are only discussing security related to SNMP and basic node access security.
4.1.4.1 Devices Access Security
The Access control list is one of the three security which will be discussed, the access control
which is found in the user management subsystem. This provides access level security to grant
and to forbid access to the system users who doesn’t have valid username and password into
the system. The password are set by the system administrator who overly manages the system.
These features are also present in every NMS and the system administrator can further provide
access levels in the system denying other users to access certain network elements.
The feature also presents the user IDs and passwords local to device. This feature provides
access to site technician to view the network while troubleshooting and it is helpful when the
NMS is unable to make changes to NEs due to break in communication. The credentials given
can be allocated levels of access in the system.
The NE controller is another feature which is added to control the access for the nodes on the
network management system. This feature allows the node to have login parameters before
being connected to the network. This prevents operator from viewing the other operator’s
equipment and to make changes which can affect the running of the network. The operator’s
networks are connected through physical media and only the NE controller password can
separates networks. This feature is very common and operators usually request for this security
during project development.
4.1.4.2 SNMP security
We compared the level of security being provided at SNMP protocol level and observed that
the system was offering the same level of security with other products. The SNMP protocol
can be used to make configuration changes on a network element similar to those issued from
the command line (CLI) [6] because they provide a channel which gives access to the device.
The system provided proper security on the network device to prevent unauthorized access and
changes through the use of SNMP channel. The community strings followed the standard
63
password guidelines for length, characters and difficulty of guessing. This system prompts the
administrator to change the community strings from their public and private defaults. For
further enhancement of security all the SNMP management host(s) are required to have a static
IP address and be individually granted the SNMP communication rights with the network
device by that pre-assigned address and access control lists. These system provides security
features that ensure that only authorized management stations are allowed to perform changes
on the network devices.
4.1.4.2 Tabulated Security Management Results
Discussed above on section 4.1.4 are security management results which is a subsystem of the
project that deals with security. The results were tabulated to clearly show the strength of the
system compared to three system which were chosen. The results are as below:-
Table 4.1: Shows the comparison of the developed Unified NMS and other vendor
specific NMSs
Security Feature Unified NMS Huawei U2000 Alcatel ISAM FiberHome UNM200
Device Access
security
Access Control
Lists
User’s ID and
Password for
local Device
Access
NE management
security
SNMP security
CLI security:
Telnet and SSH
64
4.2 Comparing NMS Results with Market available Products
Section 4.2 compares the system with other network management system currently on the
market and in use in our organisation. The system was compared of execution speed,
scalability, modularity, multiprocessing and request approach as highlighted below. The
system showed that some module are performing as expected and other are not nevertheless
with the advantages of other module the system can produce the desired results as others.
4.2.1: Comparing Python Vs C programming languages
Most of the implementation of NMSs were developed using C language on the backend and
the frontend they mix javascript and HTML programming language for most NMSs discussed
in chapter 2. Developers are starting to use python programming language because of its
strengths. Despite the challenges of slow runtime, its relatively slow when compared to other
languages in terms of speed of execution. Since, other NMSs are developed using C they take
months to develop dedicating full time teams to work on the program.
Django frameworks provide simple platforms to develop system which can reach market as
quickly as possible. With its advantages the language was preferred over compiler languages.
In the collection of results different scenarios were compared python program, cython (mixture
of C with other languages) and C language program. The changes were done, to consider one
of the claims of the tool which the speed of execution. The speed of execution of compiler
languages like C and java is claimed to be faster than interpreted languages like python. Also,
improvement were done on the program to mix python and C and tests were done to check for
the effects.
The memory footprint left behind by the C implementation is lower than for python but these
is no longer an issue since hardware devices being developed nowadays have bigger memory
sizes. Fig 4.5 results justify the improvement in speed as a result of mix the languages i.e
python and C to improve the speed of execution [7]. The results will be the same as for other
programs developed using C language only which are listed in chapter two. Also, the results
shows a slow execution speed which is being ignored by developers which are now using
python like YouTube and Google to reduce developmental time [8].
No of iterations: 10
65
Fig 4.5: Shows the execution speed of comparing Python, Cython and C
The implementation for the above, consisted of threads issuing Net-SNMP requests and storing
the result. The codes were then processed as per visualization. The above time was noted, by
calling the function time before and after the code runs and subtracting the result to get the
running time. It can be seen from the visualization, that the total running time of the C and
Cython (mixing python & C) implemented codes are fast in execution. And also from
visualization, it shows that python code are slow in execution but the disadvantage can be
leveraged by mixing the languages to improve speed.
4.2.2: Parallel vs Serial Approach (language: Python)
Multithreading (parallel) it is way of achieving multitasking, multithreads within a process
share the same data space with the main thread and can therefore share information or
communicate with each other more easily than if they were separate processes [9]. A thread
has the start of execution sequence and the end. It has an instruction pointer that keeps track of
where within its context it is currently running. Python has poor performance working on
multithreading environment and Python usually uses non multithreading which is the serial
66
approach. In CPython, multi-threading is supported by global interpreter lock (GIL) [10]
nevertheless this is not recommended.
Fig 4.6 shows the comparison of the implementation with threading involved in various stages
versus a non-threaded implementation using GNS3 software. The results were collected using
GNS3 because of limited number of nodes which were available
Fig 4.6: showing Multi-threading vs Non multi-threading
In a threaded environment, multiple threads pull network data and store them. Different set of
threads then parse those data and temporary store them locally. In a non-threaded environment,
the above process is done by single threaded. Hence, only one connection to any node exists at
any given time for pulling the network information. Only a single thread probes through all the
results to get the stored data. In fig 4.6 that multithread environment pulls data faster than single
thread environment were data is pulled and store in single file.
4.2.3 Request based approach vs Always ready approach
Request based approach is referred as client side were data is requested from the all the nodes
in the network before it is displayed on a GUI. The client side approach runs on a low memory
and they produce good visualization as compared to always ready approach which runs from
the server and programming languages which runs on the server side are python, c, Java, PHP
and VB. The client side approach mostly deals with the user interface with which the user
interacts in the web [11]. It is mostly a browser, in the user’s machine, that runs the code using
scripting language eg Javascript or html.
67
The project was implemented using python for the backend and the frontend we are using
HTML to interface with backend programs. The other NMSes comes with both the client side
and the server side approach and user will have a choice to choose from the two. Personally, I
had a privilege of you both on the current NMS which will are using. The Huawei client and
server side approach both are good and they have the same functions.
The data is implemented in python which writes the results data to the files in the SQLlite
databases after the HTML request. The information is represented HTML format and send back
to the client.
The tests included a comparison of whether a whether a client side based approach is faster
than a server side always approach.
The total running time is calculated as:
Total Time = Δ Client Side Process + Δ Server Side Process
1. Where Δ Client Side Process = Time at which response is received by client – Time at
which request is issued by client.
2. Δ Server Side Process = Time taken to complete an iteration of the entire process and
Δ Server Side Process = Time taken to complete an iteration of the entire
Fig 4.7: Shows Server side vs client side approach.
The figure above clearly shows that server side always ready approach as the best approach
but due to the advantages poised by client side approach it was preferred. This result cannot
be general case, but always ready approach works well in this scenario because the client is
68
requesting the same data for the nodes at certain interval. The move will delay it in response
time.
4.2.4 Alarm alert response Time
The other important thing to measure is the alarm response time which is the time it take for
an alarm to appear on the dashboard. The results will presents how synchronised is the NMS
dashboard with the database and show how fast is the processing in executing the instructions.
To achieve this we used nodes with alarms and nodes with no alarms. In our designed system
we used three NEs which were not enough to collect desired results. For the purposes of
collecting good results we used the GNS3 software and simulated as many nodes as we can
introducing various types of errors on the nodes. We measured the time it take for the node to
reappear on the NMS after it has been delete in its state with alarms and without alarms. The
NEs with alarms took longer to reappear on the NMS while the one with no conditions took
less response time as shown in Figure 4.8. This is supported by the theory because node without
errors will have fewer instructions to execute thereby responding faster. This can be attributed
to the fact that they are fewer active request and during SNMP walk, data is returned in a single
query [12]. While the nodes with alarms the active instructions will many, causing multiple
request response between the system and the node. Below is the results after taking some tests:-
Fig 4.9: shows a high response time for nodes without error.
69
4.3 Performance Measurement Results
In this project, we use SNMP to collect different performance metrics at the device, interface
and also at protocol levels at regular basis. The polling engine in a network management system
is used for the collection of data from NEs. In general most network management systems are
capable of collecting, storing and presenting polled data [13]. The wed based interface solution
as the one we designed is favoured by operator as it allows access to performance data
accessible from anywhere in the enterprise environment. In this project we have designed the
performance data module which presents the same result as other current enterprise solutions.
The performance module was tested using the remote monitoring (RMON) of packets at
interface level measuring the inbound and outbound traffic on an interface. The results were
compare with the recorded results on the traffic generator and results were with the range. The
traffic generator was used to generator traffic through the network created through all three
devices. This test was done on a test bench to eliminate the pre-configuration condition of a
GNSS3. At the outbound interface Ethernet 850 test equipment was installed to measure the
traffic receive and traffic transmitted was measured at inbound port. The process was repeated
varies the amount of traffic transmitted and results were recorded to compare the results with
the one captured by the system (NMS). While results were recorded the NMS was set to
measure the same traffic remotely on an NMS and results were outputted in tabular and
graphical form. The results on the NMS and test equipment were the same as in table 2 and the
graph below.
Table 4.2: Shows the results obtained from the tests.
Traffic Generator
Transmitted traffic (Mbps)
Traffic measurement Tester
(Mbps)
NMS Results from RMON
(Mbps)
20 20 20
40 40 40
60 60 60
80 80 80
100 100 100
70
Fig 3.10: Shows the graph for the results.
4.4 Summary
This chapter presented the results contained from the system, compare the results with existing
enterprise solutions and analysis of performance management system. The overall system
results meets the benchmark sets by other vendors but still some modules need to be included
since the design of NMS takes time, teamwork to complete and to include all the modules
required. Other vendors are now including sophisticated copper and fibre testing tools to
monitor the copper and fibre links like the fibre doctor and N2310 copper tester. This before
the advent of NMS solutions operators were using physical test equipment and today they are
software module which are added on the NMS to carry out network tests. The project still need
further works and these results can be further improved by including modules and selecting
equipment with high processing power.
71
CHAPTER 5
5.0 CONCLUSION AND FUTURE WORK
Through the presentations made in this project, fundamental mental concept of network
monitoring, remote control and other future concepts like network cloud monitoring, had been
reflected on. The works which were previously done by `equipment vendors and third parties
in the field of NMS, were investigated and comparison between the existing and the developed
applications had be given in chapter four of this project.
5.1 CONCLUSION
This project clearly outline the step by step procedures required to build a standard NMS which
meant the requirements of thus ever changing environment. With the regards of this thesis, a
more robust NMS was developed which have the same features as the one which are in use.
The feasibility researches, have been conducted prior choosing the topic. The research showed
that all the network management system have all the required software tools that is the case of
propriety NMS. The point is not true for open source NMSes which monitors mainly the service
be carried by the NEs and they can’t fully monitor the behavior of the network element. In
addition, the tools have a complicated proprietary use interface which require trained personnel
to user. With all this points, the existing tools requires license which are paid annually by
service providers. The fees are settled in foreign currency and the amount is proving to be too
high for service providers hence the development of local NMS which monitor and provide the
same features with these commercial available products. The thrust of this project to provide
an NMS which can commercial compete with proprietary products was met and the developed
product is as friendly like all the product currently in the market. The purpose of developing
the project was to provide a competitive NMS which capture all the needs of the users. This
NMS captures the performance management system which is now an important feature of the
NMS. Over and above the primary functionalities of the system, the system comes with
network configuration, security and device management. The NMS implemented in this thesis,
can fully work as other NMS which are commercially available and third party software.
72
5.2 FUTURE WORKS
This NMS was developed in way that new features can be added to the application, such as
providing performance report, configuration modules, device management and network
security modules. Furthermore, the platform was developed to run on all windows and Linux
operating system.
NMS platforms are involving from distributed to centralised network cloud engines (NCE)
were the monitoring system is centralised. This approach improves the system in reducing the
number of secondary storage devices required. The centralised approach allows the use of
cloud storages which reduces the cost of hardware and upgrades.
5.3 RECOMMENDATIONS
The following are the list of recommendations made to the proposed design solution to
improve its functionalities to meet other products already on the market:
The new requirements of the telecommunications sector are changing the
management priorities of how network elements are monitored with the network
monitoring system. The previous solution were hardware based and these priorities
are changing to service oriented. To achieve this goal the system was designed in way
that it is modular and modules can be added to include specific functions with the
code.
Implementation of monitoring system which is easily upgradeable to interoperate
with network cloud monitoring system with minimum additions.
The system was built to monitor any SNMP enabled device. In this research we used
cisco, ZTE and Huawei because of the availability of the hardware.
Designed a system that offers all the network active tools to substitute the fragmented
management solutions. This improve the operations team to remain effective and
knowledgeable to the tools they use.
The solution was designed taking into account the need of security and network
operations (NetOps). The network operators are now using risk related techniques to
73
measure network performance and as such we have integrated system with security
processes.
74
LIST OF REFERENCES
[1] http://www.techopedia.com/definition/20974/network-management accessed on 19/12/19
[2] Richard, T. & Watson, (2007), Information Systems, University of Georgia.
[3] Information Sciences Institute, University of Southern California. Internet protocol. RFC
791, RFC Editor, http://www.ietf.org/rfc/rfc791.txt,September 1981.
[4] Fang, W., Zhijin, Z. & Xueyi, Y., (2008), A New Dynamic Network Monitoring
Based on IA, International Symposium on Computer Science and Computational
Technology, IEEE, Vol. 2, pp. 637 - 640.
[5] Martin P.Clark, (2003), Dta Networks, IP and the Internet: Protocols, Design and
Operation
[6] Jyrki T.J. Penttinen, (2015), The Telecommunications Handbook: Engineering Guidelines
for Fixed, Mobile and Satellites systems.
[7] Paolo Bellavista, (2009) Telecommunications Systems and Technologies-Volume II
[8] Stephen Few. What is a dashboard? In Information Dashboard Design: The Effective
Visual Communication of Data, page 34. O‟Reilly Media, Inc, 2006.
[9] Alan Willner, (2020), Optical Telecommunications Volume V11
[10] Cajetan M, Akujuobi, Matthew N.O Sadiku, (2007), Introduction to Broadband
Communication Systems
[11] Noite.pl (2009), The SNMPD (net-snmp) sever: LINUX services. AL3-079
[12] William S. Vincent (2020), Django For Professionals
[13] Juan F Gomez Fernandez Adolfo Crespo Marquez, (2012), Maintenance Management in
Network Utilities: Framework and Practical Implementation.
[14] Asko Riitahuhta, Antti Pulkkinen, (2012), Design for Configuration: A Debate based on
the 5th WDK Workshop on Product development.
[15] NTT Technical Review, Vol 3, Issues 1-6, Telecommunications Association, 2005
[16] Huawei Technical Review Handbook, 2016, U2000
75
[17] Alcatel User Manual Handbook, ISAM Network Manager system
[18] Fiber home User Manual Handbook, UNM2000
[19] Quanmin Zhu, Ahmad Taher Azar - 2014 - Technology & Engineering
[20] Mani Suramainian, Dorbing KInderslay, 2010, Network Management: Principles and
Practise
[21] Jithesh Sathyan, 2010, Fundamental of EMS, NMS and OSS/BSS.
[22] Edited by Anirban De, Tanushyam Bhattacharjee, Dabranjam Sharhar, January 28-30,
2014, Proceeding of International Seminar on Application of Communication and
Information Technology in Library.
[23] Xu Chen, 2010, Toward Automated Network Management and Operations: A
dissertation submitted in partial fulfilment of the requirement for the degree of Doctor of
Philosophy.
[24] Mark A Miller, 2005, Technology and Engineering
[25] David Perkins, Evan Mc Ginns, 1997, Understanding SNMP MIBs
[26] Dan Sanderson, 2009, Programming Google App Engine: Build and scalable web
applications on Google’s Infrastructure.
[27] Kenneth Reitz & Tanya Schlusser, 2012, The Hitchhikers Guide to python: Best practise
for development.
[28] Gerardus Blokdyk, 2019, Network performance monitoring
[29] Alomari Zakaira etal, 2015/04/02, Comparative Studies of six programming languages
[30] https:// www.geeksforgeeks.org/python/ accessed on the 3/3/2020
[31] R. Jain,The Art of Computer Systems Performance Analysis: Techniques for
Experimental Design, Measurement, Simulation, and Modelling. New York, NY: John Wiley
& Sons, 1990.
[32] Wei-Hua Baiet al, "Performance Analysis of Heterogeneous Data Centers in Cloud
Computing Using a Complex Queuing Model, “Mathematical Problems in Engineering,vol.
2015, pp. 1-15, 2015.
[33] J. A. Arieset al, "Capacity and performance analysis of distributed enterprise
systems,"Communications of the ACM,vol. 45.
[34] K. Tuisku, "Network Management System Dimensioning with Performance Data”,M. S.
thesis, University of Tampere, Tampere, Finland, 2016.
76
[35] https//:www.cisco.com/support-docs/nms: accessed on the 3/3/2020
[36] Estefania Serrano, Javier Garcia Blas, Jesus Carretero, Monica Abella, Manuel Desco,
"Medical Imaging Processing on a Big Data Platform Using Python: Experiences with
Heterogeneous and Homogeneous Architectures", Cluster Cloud and Grid Computing
(CCGRID) 2017 17th IEEE/ACM International Symposium on, pp. 830-837, 2017.
[37] M. Pilgrim, Dive into Python, 2004, [online] Available: www.diveintopython.org.
[38] Python Global Interpreter Lock, https://wiki.python.org/main/GlobalInterpreterLock
[39] B.O.L. Sanden, Design of Multithreaded Software: The Entity-Life modelling Approach,
2011.
[40] Q. Aston. Acton, PHD, Issues in Information Science- Information Technology, Systems’
and security, 2013
[41]“simple-Network-Management-Protocol-(SNMP): ww.cisco.com/wrap/public/535/3.html
[42] J.A.Arieset al, "Capacity and performance analysis of distributed enterprise systems,
“Communications of the ACM, vol. 45,No. 6,pp. 100-105, 2002.
![Network Implementation[Www.veyq.Ir]](https://img.dokumen.tips/doc/110x75/55cf985b550346d033972d7d/network-implementationwwwveyqir.jpg)
