Will we get reliable unified communications?

If unified communications (UC) is going to revolutionize the way we communicate, it must be reliable in order to deliver the utmost in user productivity. Gary Audin, president of Delphi Inc., shares his thoughts on maximizing the dependability of your UC deployment.

If unified communications (UC) is going to play a major role in increasing user productivity, it has to be reliable,

dependable and consistent in its delivery. This is no easy task. When UC is down, productivity is down, and users and enterprise customers are dissatisfied. The unreliable delivery of UC services will damage the reputation of UC. It will be harder to regain the user's confidence to return to the UC functions than it was to convince the user to try UC in the first place.

Reliability is the word most people use, but it is availability that really counts. Availability is the percentage of time the UC service will be fully available when a user attempts to access UC services. The PBX and PSTN worlds use 99.999% as their expectation of availability of telephone service. Shouldn't UC meet the same level of availability as the telephone? After all, UC is all about a wide range of useful communications capabilities. You can find a helpful article from Business Communications Review, "Reality Check on Five-Nines," at http://www.bcr.com/management/networking_intelligence/reality_five_nines_20020519301.htm. This article can help you understand the details of reliability and availability calculations and how to apply them to your own organization.

First let us look at what 99.999% means. Assume that UC features need to be available 24 hours a day, 365 days a year. The table below demonstrates the outage time allowed to meet the availability criteria.

 

Availability Per Year Annual Downtime
99.9999% 32 seconds
99.999% 5 minutes and 15 seconds
99.9% 8 hours and 46 minutes
99% 3 days, 15 hours and 40 minutes

 

Availability = Uptime (MTBF)
  Uptime + Downtime (MTTR)

So availability is the probability that a UC service will be usefully working when the user accesses UC features. Reliability is the Uptime number, Mean Time Between Failures (MTBF). MTBF does not cover how long the downtime is for the UC service. Downtime is measured by the Mean Time To Repair/Restore (MTTR) for the UC service.

The availability of UC depends on four factors:
 

  1. Hardware
  2. Software
  3. Network
  4. Electrical power

The hardware delivered for most IT systems is quite reliable, getting close to -- if not meeting -- the 99.999% goal. The software is another issue. If the software were as reliable as the hardware, we would not be seeing all the patches on the market. There is no standard method for predicting software reliability. It can be gained only through field experience. Solicit other customers' experience with UC reliability for the vendor you may select before making the final UC source decisions. Part of the problem for software is that it is prone to human design and installation problems. These problems may not be counted by your vendor in its availability estimates.

In fact, there are several issues that are not counted by the vendors in their calculations:
 

  1. Loss of electrical power
  2. A network loss, LAN or WAN
  3. Failure of the operating system
  4. Time out for installing and upgrading software
  5. Preventive maintenance
  6. Time out for hardware changes

UC reliability will be affected by all of these factors as well.

UC will depend heavily on the reliability of the network. Loss of any portion of a network means that some -- and possibly all -- users will suffer. The data network staff will have to monitor the network and may have to increase the network reliability BEFORE the implementation of UC.

The operating system used for UC components can play a role in the reliability of all the software operations. The OS reliability should be considered in the product selection for the UC functions.

Obviously, a loss of power means loss of service. What is not often considered is the reboot time of the software after electrical power is restored. This can be tens of minutes, a critical amount of time for the user. Since much of UC will depend on the endpoints functioning properly, the reboot time at the data center is only part of the reboot equation. The enterprise should investigate the boot and reboot times of the endpoints (PCs, laptops, PDAs, etc.) for restoration of the UC features.

As enterprises consider migrating to UC, they should audit their present operations and the aforementioned considerations. The productivity gains from UC will be directly proportional to the reliability and availability of the UC services delivered.

Gary Audin has more than 40 years of computer, communications and security experience. He has planned, designed, specified, implemented and operated data, LAN and telephone networks. These have included local area, national and international networks, as well as VoIP and IP convergent networks, in the U.S., Canada, Europe, Australia and Asia. 
 

This was first published in January 2008

Dig deeper on Developing a UC Strategy

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchMobileComputing

SearchNetworking

SearchTelecom

SearchITChannel

SearchEnterpriseWAN

SearchExchange

Close