Over the past few years, carriers and network service providers have experienced profound changes in their industry. With the high-tech bubble bursting in the early part of the decade, service providers have been forced to dramatically adjust their cost structures to ensure their sustained profitability, if not survival, for the long term.
While lowering capital expenditures (capex) was the immediate focus in the early days of the downturn, the focus has since shifted equally to reducing operational expenditures (opex) through improved efficiencies and better use of available tools. Major service providers have stated publicly that their focus in this respect is optimizing their operating budgets via better management of their network infrastructure. This focus is understandable-in many cases service providers are using more than 1,000 disparate operational support systems (OSSs) to manage their networks and services corporate-wide.
It isn’t surprising then that carriers have named among their top priorities a desire to reduce the number of legacy point OSS implementations and achieve some degree of centralization in important functions like flow-through provisioning on their networks. Such initiatives, carriers believe, will help them reduce their network “build-out” expenses, reduce their opex, and reduce the time it takes them to deploy new services to anxious customers while generating much anticipated revenues.
When investigating (OSS/BSS) business-support-system infrastructures, much emphasis is placed on choosing OSSs at the top three layers of the TMN network management architecture model (see Figure 1). The element management layer (EML) of the network is, as such, often regarded as a “necessary evil” and relegated to a position of less importance. Yet, this disregard overlooks the EML’s important role as a cornerstone for higher-level network management systems (NMSs) while nurturing indifference in the development of element management systems (EMSs). Equipment vendors have instead understandably focused their R&D efforts on developing important features for their core systems while offering proprietary EMSs that provide basic functionality at a nodal level.So what are some of the issues involving typical EMSs? For starters, each system vendor typically provides a standalone proprietary EMS for each one of its products, resulting in a plethora of EMSs in the operating environment. Carriers often refer to this situation as “swivel-chair management,” a phrase that betrays the chaotic feeling network operators experience as they struggle to use differing user interfaces and inconsistent methods and procedures to effectively achieve the same end on different network elements (NEs) across the network. Ultimately, this non-centralized approach translates into substantial training requirements, the need to develop expertise on a multitude of systems (rather than just one), and so forth.
An ancillary problem involves the need to deploy many more servers and databases than would otherwise be the case for a multivendor EMS, with at least one server required for each EMS. This multitude of systems leads to real costs in terms of power consumption, cooling, and space requirements. By way of example, one tier two North American carrier employs 31 different EMSs to manage its 8,000 NEs. Each has its own hardware and power requirements. The total amount of rack-mount space required is over 60 RUs. That can be contrasted directly with a single multivendor EMS they can deploy to manage all 31 NE types while requiring only a 6-RU footprint and drawing roughly one-fifth the power.
A second problem with today’s systems is that many don’t scale very well. A typical EMS is designed to support a maximum of 500 to 1,000 NEs within a given family of products. In the large networks maintained by tier one and tier two service providers, that scope of coverage is limiting at best. Network operators cope by running concurrent instances of the EMS to get full coverage of that vendor’s NEs across the network, further extending the number of sessions and interfaces with which the operators must contend.
From a systems integration point of view, a multitude of EMSs means multiple integration efforts are required to tie into the higher-level OSS/BSS applications. That can slow the introduction of new NEs as they become available, since a major effort must be undertaken to integrate the EMS to the other OSS/BSSs of interest. Further complicating overall integration are the differences typically found in EMS flavors, with discrepancies in the interface protocols and standards used to interface with northbound applications, as well as incomplete or inconsistent implementations of interface standards like TMF814 from one EMS to the next. Finally, each vendor’s proprietary EMS will tend to use a proprietary object model that closely reflects their own NE but does not model others well, creating additional integration frustrations. Many of these challenges are now being solved using next generation multivendor EMSs that provide just a single point of integration to higher-level OSSs while providing coverage for all NEs.
In fairness, moving to one multivendor EMS can have its own limitations. The one most often cited involves unique applications that are offered on a particular vendor’s EMS that works only on that vendor’s NE type. In practice, these features don’t get used as often as might be expected simply because they are not available network-wide and apply only to one vendor’s equipment. The benefits of a multivendor approach in most cases should outweigh those of having access to an additional feature on just one vendor’s NE.
So why isn’t the multivendor EMS approach taken more often? Multivendor systems aren’t easy to build, and the problem is especially challenging for Layer 1 networks. Next generation optical NEs do in general make the problem simpler, since they offer strong manageability features. But the same cannot be said of most legacy optical NEs, with the irony being that legacy optical networks make up the vast majority of NEs deployed in transport networks today. So solving this problem is well worth the effort, and indeed a handful of independent software vendors are helping carriers do just that.
To illustrate the benefits of the multivendor EMS approach, consider the simplified example of flow-through provisioning in a small network (see Figure 2). With five different vendors supplying equipment to this network, a minimum of five EMSs would be required to attempt to provision a service for any customer requesting a Fast Ethernet service at the network’s Layer 2 edge device. The provisioning OSS would achieve that by logging onto five different EMSs to provision the equipment as necessary.
Ostensibly, the provisioning application is automated and network operators wouldn’t necessarily care if it had been integrated with each of the five single-vendor EMSs or only once into a multivendor EMS. And indeed either method can be effective. However, the difference in the integration and maintenance effort required in each case is significant. The first difference is in the cost of integration. The integration work itself required in this example will be roughly five times as expensive. The pairwise integrations will likely be inconsistent, since the APIs for each EMS (if open) will differ. In some cases, the integration is complicated because a particular vendor does not supply an EMS for its NE type. In other cases, the EMS only provides a basic nodal interface for higher-level provisioning systems, which is severely limiting for the purposes of provisioning. Finally, each EMS will make use of a different data model and northbound interface, significantly complicating matters in the integration effort.
Another consideration is the eventual need to introduce new NE types in the future. That can take from 12 to 24 months, depending on the official process and testing requirements once the integration of the new EMS is completed. In contrast, with a multivendor EMS, only a new adapter is required to provide an interface between the EMS and the new NE type. No integration effort is required between the provisioning application and the EMS (aside from testing), cutting deployment time severely.
There is another important benefit inherent in the use of a multivendor EMS approach. In contrast to the view that only the “lowest common denominator” of features is available network-wide when using disparate EMSs, a common EMS for all vendors provides the ability to overlay new features across all NEs, regardless of vendor. Such a capability circumvents individual EMS shortcomings and yields the opposite effect.
Not the least of these applications is network discovery, or the ability to auto-discover and track all network changes in near-real time. Some single-vendor EMSs provide this capability. But in a multivendor network, the value lies in extending that capability across the entire network, something not possible with a single-vendor EMS since the data model is confined to that vendor’s NE type. A combined multivendor EMS with a network discovery engine built into it provides a best of both worlds approach-it enables an accurate network-wide view of the system that is not otherwise possible with single-vendor offerings while providing a single interface for northbound applications.
Implementation approaches aside, the advantages of a network-wide discovery engine are substantial. Without an accurate model of the network as it exists at any given point in time, network operators face difficulties trying to automate any part of their operating procedures. To understand the depth of the problem, consider that various industry estimates suggest that inaccuracies in a carrier’s database of record will typically range from 20% to as high as 40%, with the problem tending to exacerbate itself over time. Associated problems include:
• Stranded bandwidth that forces otherwise unnecessary capital spending. Networks are over-provisioned both by design and due to a lack of clarity on which facilities are actually available in the network. In one study, “Network Resource Management: Inventory Takes Stage” (July 2002), industry researcher RHK (now Ovum-RHK) estimated that up to $10 billion in network assets in North America alone could be recovered and reused by deploying better software tools for database reconciliation in real time. That leads to network equipment purchases that would otherwise be unnecessary.
• Long provisioning cycles that delay revenues. Inaccurate data about the state of the network requires that the provisioning staff conduct time-consuming alarm source verification and database reconciliation with the network database before new services can be properly provisioned and activated.
• Trouble resolution and service assurance. Unmanaged faults derive from poor topological visibility. Without solid knowledge of the relationships between NEs and facilities, it is nearly impossible to understand the relationship between alarms and NEs or services.
• Northbound OSSs hampered by bad data. Northbound applications such as inventory management and provisioning applications provide actionable information to network operators-so long as they are fed accurate, recently acquired data. The repercussions of using stale data that is substantively inaccurate can be costly, with salient examples being revenue leakage and unnecessary capex amounting to billions of dollars in losses annually in the industry.
Aside from these problems, network discovery enables improvement in inventory management, cost accounting, and workflow efficiencies through the automation of operations tasks, security/password authentications, and the like. Perhaps most important, it helps accelerate new device deployment, provisioning, and time-to-revenue by feeding accurate data to the higher-level applications like provisioning and service activation.
There are strong advantages to a multivendor EMS approach. System vendors are reducing R&D budgets relating to EMS development in favor of partnering with third parties to develop cost-effective, best-in-class systems. As such, multivendor EMS and network discovery systems will rapidly emerge as cornerstones of service provider OSS deployment strategies.
Costa Constantakis is director of marketing at Nakina Systems (Ottawa, Ontario, www.nakinasystems.com).