For service providers, highly available services via cost-effective systems remain crucial to their success. The combination of deregulation and increased competition has them focusing more and more on the economics of their solutions, yet they are unwilling to sacrifice the determinism of their legacy
systems.
Several factors play a role in enabling service providers to generate services revenue, including
• Extending a deployed solution’s time in market; especially as the network migrates from the TDM world towards the packet (or IP) world
• Increasing a solution’s availability; when they are not operating, they are not making money
• Bringing new services to market as quickly as possible and extending the capacity and performance of existing systems as cost-effectively as possible. Innovative new services increase the service providers’ subscriber bases and allow them to aggregate their fixed overhead costs over a larger revenue-generating population.
Service providers are continually looking for ways to reduce the total cost of providing services – or total cost of ownership (TCO), including the cost of procurement, development, deployment, and operation. To help meet these requirements, they are demanding ever cheaper and more flexible systems that can still satisfy the availability, quality, and performance characteristics of existing proprietary installations. This places increasing pressure on their suppliers – telecommunications equipment manufacturers known as TEMs.
Traditionally, critical communications applications were hosted on expensive, proprietary monolithic systems, built with specialized hardware and software, and designed from the ground up to deliver a high level of availability and determinism. However, the high cost of building, deploying, maintaining, and operating these systems did not compare favorably with the low cost, open standards approach found initially in the desktop PC arena and now becoming pervasive in the next generation IP-based networks modeled after the Internet. As a result, many TEMs have begun looking at the COTS approach much more closely.
It is well accepted that COTS components have the ability to drive down total system costs. COTs can enable service providers and TEMs to generate revenue and remain competitive due to component cost optimization, decreased time to market, component quality and performance improvements driven by the increased competition, multiple component sources, reduced development risk, scalability, and predictable reliability and performance (or determinism).
COTS component developers have the expertise to build horizontal, cost-optimized building blocks that can be applied in a wide range of vertical solutions. For example, a well-architected building block, such as a network interface may be used for telecom switching, voice mail applications, and interactive voice response (IVR) applications. Subsequently, the supplier can market the products to several TEMs and build more of the same thing at a substantially reduced cost. In the traditional model, each TEM would need the expertise to build these common-function building blocks and, due to their specialization, would build fewer of them. With a COTS building block approach, TEMs can concentrate on adding specialized vertical business logic on top of generic building blocks to meet the needs of their customers. This significantly curtails their overall development efforts and the cost of developing the lower level components. It has been shown repeatedly that open standards-based COTS components that are highly interoperable with other elements of a solution can substantially decrease a TEM’s development costs and time to market.
With building blocks available from multiple sources, TEMs can also avoid vendor lock-in while benefiting from the competition among suppliers that drives lower prices and rapid component improvements.
For service providers, COTS can help minimize the TCO, since the decreased solution development costs are passed along to them along with lower deployment and operations costs.
Calculating Availability
Many often equate reliability with availability, and certainly both concepts are critical to the concept of high availability. So when defining availability, it is helpful to note the subtle differences in the terminology:
• Reliability is the probability that something will not fail during a specific period of time
• Availability is the ratio of time that a service is available to total time. In other words:
Availability = MTTF/(MTTF + MTTR), where MTTF stands for Mean Time to Failure and MTTR stands for Mean Time to Repair.
Availability approaches 100 per cent as the MTTF increases to infinity, and the MTTR decreases to nothing; the higher the ratio as a percentage, the better.
As the chart suggests, availability is typically discussed in the range that is very close to 1. Although 99 per cent uptime sounds good, it still results in over three and a half days of down-time per year. Most solutions are not considered highly available till they get close to 99.9 per cent uptime – roughly nine hours of downtime per year. However, the telecom industry is used to availabilities in the range of four to five nines.
The problem is that the higher the availability, the higher the cost of providing the service.
The big challenge for service providers, and their system and component suppliers, is striking the right balance between availability and cost.
Total system availability can be determined by progressively decomposing the system into the individual components – the hardware and software. The availability of hardware can be further attributed to the availability of the platform and the availability of the I/O boards, and so on for software.
Not every component in the network must provide availability to the same level; typically, the number of nines is specified from an end user perspective. Component suppliers do not need to provide all components that are five nines, but they must deliver components that enable services that meet high aggregate availability requirements. The way components are combined in a system has a big effect on availability, as does the way systems are arranged in a network.
Part two will focus on the network’s impact on availability
