“Genius takes time, but stupidity can be achieved in a heart beat, and usually is.”
Anonymous.
There are many network devices that have the ability to publish data at intervals in time, or upon the incidence of an event occurring. An example might be a network device failure sending a notification to its element manager (EMS), which then sends a notification to its OSS.
There are other types of devices, often older ones, which don’t send notifications. They have to be polled by the OSS at set intervals for the OSS to keep a near real-time view of the network’s health.
The former is probably the more ideal method because it allows the OSS to be more real-time in its presentation of data. The down-side is when an interface sends notifications upon an alarm occurring, you then rely on the device or EMS being highly reliable. For example, if the device/EMS has actually had a catastrophic failure, it won’t be sending any alarms, giving the OSS the belief that it is behaving perfectly.
To overcome this issue, heart-beat mechanisms were developed, whereby the OSS would poll the device/EMS if it hadn’t received any updates from it recently. If the heart-beat poll received a response from the device/EMS, then the device/EMS is in fact operational.
But the potentially harmful by-product of all this polling is it loads the network and it’s devices with management overhead, risking the delivery of payload traffic. There are even some smart networks out there that can recognise congestion in the network and/or high load on the device/s so they delay their heartbeat poll for a certain period (eg a few poll cycles) in the hope that the congestion subsides.