1. Managing the links

To begin with, the management of a wireless network does not just involve the management of individual base stations, access points, and CPEs in the network. It is equally important to discover and manage the links between devices and be able to provide a clear picture of the network’s topology. Tracking the availability of the access points is also essential for a backup plan. This backup plan is quintessential for managing wireless networks.

In wireless networks, there can be different types of links. These types of links include active, standby, or backup. It is important for the EMS to distinguish between the link types so that they can be accurately portrayed for the network administrator.

2. Tracking the clients

Another key challenge for the EMS is to track and manage the clients connected to the wireless access points in a network. Since clients attached to an access point could be extremely dynamic, client connectivity maps would be useful to a service provider for network planning purposes. For example, a client could connect to the network from one access point and later connect to the network from another access point. An EMS needs to be intelligent enough to track and manage these dynamic clients efficiently, allowing it to derive a meaningful usage pattern.

3. Examining throughput

Since the throughput depends on the signal strength and interference from other access points, clients get different throughput at different locations. An EMS should be able to identify the problematic areas so that the network administrator could try to resolve them.

The ability of the EMS to depict the available throughput for each client pictorially in the topology diagram helps network operators plan for the potential throughput requirements – this feature delivers a lot of value. The throughput of a link can be depicted in a variety of ways: such as using a color-coding scheme or varying the thickness of the line.

Only a few wireless networks support full-duplex connectivity. Therefore, it will be necessary for the EMS to provide link health in both directions (upstream and downstream). This makes it easy for the network administrator to monitor the link.

4. Dynamic discovery

Since many wireless networks allow the dynamic addition of new access points, the EMS should automatically discover new access points and be able to provision them as well (using a predefined policy). It is a mandatory requirement for any EMS that supports a dynamic network.

5. Frequent inspections over devices

Wireless networks are highly dynamic, and the network topology of a wireless network can change very often. An EMS should be able to immediately identify such network changes and display them to the administrator in real-time. To achieve this, the EMS must be able to check the status of the device frequently. It comes with its own set of challenges, especially if the network scales up.

Similar correlation logic might be required at the device level when alarms are raised by multiple cards or ports to report the same fault within a network element (NE).

Typically, an EMS server is informed of a device’s status via asynchronous notifications from the device (such as SNMP traps and TL1 autonomous messages). The EMS can also periodically poll the device for its status. However, when the number of devices in the network increases, it becomes difficult to do frequent polling.

Let us examine the following scenario:

The number of devices in the network is 2000. The time taken to do status polling is 1 second. (Note: If the device is not reachable, it will take at least five to ten seconds to timeout based on the timeout configuration.)

Therefore,

• The amount of status polling that can be done per minute is 60 – when assuming a best-case scenario in which all the nodes are available and able to respond within a second.
• The time taken to poll all the 2000 nodes is 2000 seconds (33 minutes and 20 seconds). In other words, a device can only be polled once every 33 minutes. This polling frequency only gets worse as more devices are added to the network. The outcome would be totally unacceptable.

How to curb this inefficiency? 

Approach #1:

A multi-threaded environment can reduce the time between polling. For example, if we have a thread pool of ten to fifteen, the time between polling could be reduced to about two to three minutes. In practical situations, two to three minutes may be an acceptable solution rather than a satisfactory one. But the situation might still be undesirable: there is a chance for some of the nodes to go offline which would increase the time to do polling.

Approach #2:

The next option is for the EMS server to be notified whenever a change occurs in a device. If the device has to notify the EMS server, then it may work under the following two conditions:

• When the device is still able to maintain its connectivity with the EMS even after the change occurs.
• When the device is able to predict the impending change and proactively informs the server.

The implementation won’t work when a change or a fault condition occurs in a device quite abruptly (which also causes it to lose its connectivity). In this case, since the device would not be able to send a notification to the EMS server, a backup option must be implemented. The backup option could be for the parent (or other devices) to send the notification to the EMS. This notification would happen whenever a loss in connectivity is detected for the device under consideration. Similarly, the parent or other connected device should be able to send a notification to the EMS server whenever a new connection is established to a device. This is due to scenarios in which the new device may not be aware of the EMS server. If there are multiple notifications for a single device, the EMS server should be smart enough to correlate those notifications.

The problem with the notification approach is that most devices only support trap-based notifications. Since traps are based on UDP protocol, they are not very reliable.

Approach #3:

Combining both the aforementioned approaches provides a more meaningful solution. In this solution, the EMS server is designed to act based on a trap notification. It is also required to poll the device frequently (for example: every 5 minutes). As a backup, and to ensure that the EMS server remains in sync with the network (just in case any notification was missed), the EMS server could also poll the device immediately after it receives a trap. This reconfirmation is done in addition to periodic status polling.

NetMan, a premier EMS/NMS, follows the third approach – thus providing you the best of both worlds. We have been solving challenges in the Telecom/Networking and IoT field for over 17 years. Talk to us to know the ways in which we could add value to your company.