1 / 48

Telecommunication Network Management TNM Overview Week-1 Lecture - 2

Telecommunication Network Management TNM Overview Week-1 Lecture - 2. Khalid Ibrahim Qureshi - Dept. of Computer Science CIIT - Wah. Telecom Evolution History. Telephone Voice Networks The original 7 RBOCs Bell Operating Companies (BOCs) were formed from the 1984 breakup of AT&T

kimo
Download Presentation

Telecommunication Network Management TNM Overview Week-1 Lecture - 2

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Telecommunication Network ManagementTNM OverviewWeek-1 Lecture - 2 Khalid Ibrahim Qureshi - Dept. of Computer Science CIIT - Wah

  2. Telecom Evolution History • Telephone Voice Networks • The original 7 RBOCs Bell Operating Companies (BOCs) were formed from the 1984 breakup of AT&T • Radio networks (Started 1906) • CATV / Cable TV networks (Started 1948)

  3. Telecom Evolution History • Computer Data networks (Started 1969, PCs in 1983) • 1969: first ARPAnet (Advanced Research Projects Agency) node operational. • 1970: ALOHAnet satellite network in Hawaii. • 1972: ARPAnet first e-mail program. • 1983 - TCP/IP replaces ARPANET at U.S. Dept. of Defense, effective base for Internet. • LAN, MAN, WAN etc after 1983. • 1989 - SNMP status as the de facto TCP/IP network management framework. • 1982: SMTP e-mail protocol defined, 1983: DNS defined for name-to-IP-address translation • 1985: FTP protocol defined • Early 1990s: Web HTML, HTTP: Berners-Lee, 1994: Mosaic, • later Netscape, late 1990’s: commercialization of the Web

  4. Telecom Evolution History • Internet (ISPs started in 1995) • In 1991, NSF lifts restrictions on commercial use of NSFnet (decommissioned in1995)

  5. First Computer Network - ARPANET • By the end of 1969 there were four nodes on the "ARPA NETWORK",. These were: • University of California Los Angeles (UCLA) • University of California Santa Barbara (UCSB) • University of Utah • Stanford Research Institute (SRI)

  6. Network Management • Definition: • Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning (OAM&P) of networked systems.

  7. TMN Network Management (OAM&P) • Operation: deals with keeping the network (and the services that the network provides) up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before users are affected. • Administration: deals with keeping track of resources in the network and how they are assigned. It includes all the "housekeeping" that is necessary to keep the network under control.

  8. TMN Network Management (OAM&P) • Maintenance: is concerned with performing repairs and upgrades - for example, when equipment must be replaced, when a router needs a patch for an operating system image, when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run "better", such as adjusting device configuration parameters.

  9. TMN Network Management (OAM&P) • Provisioning: is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.

  10. Network Management Definition: “ Network management can be defined as monitoring, testing , configuring, and trouble shooting of network components to meet a set of requirements defined by organization.” • These requirements include smooth, efficient operation of the network that defines predefined quality of service for users.

  11. Management Functions and Domains • A common way of characterizing network management functions is FCAPS - Fault, Configuration, Accounting, Performance and Security. It is ISO Architecture for Network Management. The five functional areas form the basis of all network management systems for both data or telecommunications.

  12. Management Layers / Domains

  13. Network management System • We can say that the functions performed by a network management system can be divided into five broad categories: configuration management, fault management, performance management, security management, and accounting management.

  14. Conti…

  15. Configuration Management • A large network is usually made up of hundreds of entities that are physically or logically connected to one another. • These entities have a initial configuration when the network is setup, but change with time. • For example application software may be updated to a new version, and also users can be moved from one place to another.

  16. Conti….. • The configuration management system must know the status of each entity and its relation to other entities. • Configuration management can be divided into two subsystem: Reconfiguration and Documentation.

  17. Reconfiguration • Reconfiguration which means adjusting of network components and features can be a daily occurrence in a large networks. • There are three types of the reconfiguration • Hardware Reconfiguration • Software Reconfiguration • User account reconfiguration

  18. Hardware Reconfiguration • Hardware reconfiguration covers all changes to the hardware. • For example a desktop computer may need to be replaced. A router may need to be moved to another part of the network. A subnet work may be added or remove from the network. • All these things needs time and attention of the network management.

  19. Software Reconfiguration • Software reconfiguration covers all changes to the software. For example a new software need to be installed on servers or clients. • Fortunately most software reconfiguration can be automated. For example updating an application on some or all clients can be electronically downloaded from the server.

  20. User account Reconfiguration • User account reconfiguration is not simply adding and deleting users on a system, here you also consider the user privileges. • For example a user may have read and write permission with regards to some files, but only read permission with regard to other files.

  21. Documentation • The original network configuration and each subsequent change must be recorded meticulously. It means that there must be documentation for hardware, software and user accounts. • Hardware documentation normally involves two sets of documents: Maps and specifications. • Maps track the each piece of hardware and its connection to the network.

  22. Conti…… • All software must be documented. Software documentation includes information such as software type, the version, the time installed and license agreement. • Most operating systems have a utility that allows the documentation of the user accounts and their privileges. The management must make sure that the files with this information are updated and secure.

  23. Fault management • Complex networks today are made up of the hundreds and sometimes thousands of the components. Proper operation of the network depends on the proper operation of each component individually and in relation to others. • Fault management is the area of the network management that handles this issue.

  24. Configuration database • All CM information should be maintained in a configuration database. • This should allow queries about configurations to be answered: • Who has a particular system version? • What platform is required for a particular version? • What versions are affected by a change to component X? • How many reported faults in version T? • The CM database should preferably be linked to the software being managed.

  25. Fault management Subsystems

  26. Reactive Fault management • A reactive fault management system is responsible for deleting, isolating, correcting and recording faults. • The first step taken by a reactive fault management system is to detect the exact location of the fault.” A fault is defined as an abnormal condition in the system”. When a fault occurs either the system stops working properly or the system creates excessive errors.

  27. Conti…. 2. The next step taken by the reactive fault management system is to isolate the fault. A fault if isolated, usually affects only a few users. After isolation the affected users are immediately notified and given an estimated time of correction. 3. The third step is to correct the fault. This may involve replacing or repairing the faulty components.

  28. Conti…. 4. After the fault is corrected, it must be documented. The record should show the exact location of the fault, the possible cause, the action or the actions taken to correct the fault, the cost and the time it took for each step. • Documentation is extremely important for several reasons. • The problem may reoccur. Documentation will help the present and future administrator to solve a similar problem.

  29. Conti…. • The frequency of the same kind of the failure is an indicator of a major problem in the system. If a fault happens frequently in one component, it should be changed to avoid the use of that component.

  30. Proactive Fault management • Proactive fault management tries to prevent faults from occurring. Although this is not always possible but some types of failures can be predicted and prevented. • For example if a manufacturer specifies a lifetime for a component or a part of the component. Then it is a good strategy to replace it before that time.

  31. Conti…. • Proactive or reactive? • Know problem before users and boss • Solve the problem before their complain Or Wait for problem to happen, and customers complain?

  32. Performance management • It is closely related to fault management tries to monitor and control the network to ensure that it is running efficiently as possible. • Performance management tries to quantify performance by using some measureable quantity such as capacity, Traffic , throughput and response time.

  33. Capacity • One factor that must be monitored by a performance management system is the capacity of the network. • Every network has a limited capacity and performance management system must ensure that it is not used above this capacity. • For example, if a LAN is designed for 100 stations at an average data rate of 2 Mbps, it will not perform properly if 200 stations are connected to it.

  34. Traffic • Traffic can be measured in two ways: internally and externally • Internal traffic is measured by the number of packets travelling inside the network. • External traffic is measured by exchange of packets outside the network. • During peak hours when the system is heavily used blocking may occur if there is excessive traffic.

  35. Throughput • We can measure the throughput of the individual device (such as router) or the part of the network. Performance management monitors the throughput to make sure that it is not reduced to unacceptable levels.

  36. Response Time • Response time is normally measured from the time a user requests a service to the time the service is granted. • Other factors such as capacity and traffic can affect the response time. • Performance management monitors the average response time and the peak hour response time.

  37. Security management • Security services: generating, distributing, storing of encryption keys for services • Exception alarm generation, detection of problems • Uniform access control to resources • Backups, data security • Security logging

  38. Accounting Management • Identifying consumers and suppliers of network resources - users and groups • Mapping network resources consumption to customer identity • Billing

  39. Change management • Software systems are subject to continual change requests: • From users; • From developers; • From market forces. • Change management is concerned with keeping track of these changes and ensuring that they are implemented in the most cost-effective way.

  40. Change control Board • Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint. • Should be independent of project responsible for system. The group is sometimes called a change control board. • The CCB may include representatives from client and contractor staff.

  41. Derivation history • This is a record of changes applied to a document or code component. • It should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented. • It may be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically.

  42. Version and release management • Invent an identification scheme for system versions. • Plan when a new system version is to be produced. • Ensure that version management procedures and tools are properly applied. • Plan and distribute new system releases.

  43. Release management • Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes. • They must also incorporate new system functionality. • Release planning is concerned with when to issue a system version as a release.

  44. Release problems • Customer may not want a new release of the system • They may be happy with their current system as the new version may provide unwanted functionality. • Release management should not assume that all previous releases have been accepted. All files required for a release should be re-created when a new release is installed.

  45. Release decision making • Preparing and distributing a system release is an expensive process. • Factors such as the technical quality of the system, competition, marketing requirements and customer change requests should all influence the decision of when to issue a new system release.

  46. System release strategy

More Related