Functional Requirements:

The NMS is expected to support the fill range of fault, configuration, accounting, performance, and security (FCAPS) functionality. Based on these, the key requirements are given below.

• Scalability :

i. Typically, such a network has a large number of manageable devices including switches, servers, routers, base stations, multiplexers, etc. These may range in number in the thousands in a large enterprise or Tier-3 telecom network to several million in the largest Tier-I telecom networks.

ii. In most networks, the number of elements grows with time. By scalable we mean that the same NMS can be deployed in networks of different sizes merely by changing the hardware platform.

iii. For example, if dual-processor servers with a 2-GB RAM and a 200-GB hard disk are sufficient for a network with N elements, a network with 10N elements may require a 16-processor server with a 32-GB RAM and a 1-TB disk. This requires a software design that can exploit the concurrency of the 16-processor server.

iv. Scalability is important to the network administrator. Having invested in one NMS and having developed experience in using it, the administrator would expect the same product to be useable as the network grows in size.

• Heterogeneity:

i. As the network evolves over many years, it encompasses a diversity of technologies, vendors, and types of equipment.

ii. These may support different management protocols such as SNMPv1, SNMPv2, SNMPv3, CMIP, etc. Some devices may use proprietary protocols.

iii. The NMS should easily accommodate this diversity without increasing the complexity faced by the operator.

• Geographic Spread:

i. Managing networks with a wide geographic spread, which has three implications.

ii. First, the WAN links used to connect the NMS to distant NEs may have a limited bandwidth, say 64 Kb/s or less, compared to 100 Mb/s or more for a 100m LAN connection.

iii. This bandwidth may have to be shared with subscribers' traffic. Hence, the amount of management traffic generated must be limited.

iv. Second, the end-to-end delay for an IP packet may be 10s or 100s of milliseconds or even several seconds compared to a submillisecond on a LAN. Third, long-distance links are likely to fail from time to time resulting in temporary disconnection of some parts of the network.

• Bursty Load:

i. Some activities such as polling ifinOctets for performance reports are done at regular intervals. These present a steady, predictable load to the NMS.

ii. Other activities such as handling faults are unpredictable. They are characterized by long periods of quiet with short bursts of activity.

iii. Figure2 shows the number of events generated in a live telecom network, measured at 15-minute intervals during a 24-hour period. The minimum number of events during an interval is 10, the maximum is 947, and the average is 153.

Occurrence of fault events in a Typical Telecom Network during a 24-hour Period

iv. It is generally too expensive to dimension the server hardware for the extreme peak load. Hardware is dimensioned well above the average load, but below the peak.

v. NMS software must be designed to handle peak overload conditions gracefully. It may temporarily delay or discard less important events, but it should not fail altogether.

• Real-Time Response:

Fault notifications require responses within a short time. This may range from under 1 second to 10s of seconds depending on the nature of the event. The response may be an automatic control action by the NMS, or it may involve manual intervention by an operator.

• Batch Processing:

Performance monitoring, especially for capacity planning, requires a periodic analysis of large volumes of polled data. While imposing a heavy load on the server hardware, this should not be allowed to degrade the real-time response.

• Diverse Users:

  The NMS has a variety of users. These include:

1) Administrators: These are experienced and privileged staff who have a high level of responsibility for the management of the network. They may perform sensitive tasks such as bringing a major switch online or offline, reformatting the disk in a server, granting permission to other NMS users.

2) Operators: Many staff performs routine operational tasks that affect management aspects of the network to a lesser extent. These include generating traffic reports, diagnosing and repairing an individual port in a switch, answering customer queries, etc.

3) Subscribers/Clients: Customers of the network may be given access to see the health of their access to the network, to sec reports of their SLA agreement such as bandwidth use, etc. They may be able to configure some parameters of their service, e.g., whether or not an email warning is sent when they near their monthly download limit. They cannot change anything else in the network or view other customers' information.