Section: NETWORK MANAGEMENT

If there was any lingering doubt that operations support systems (OSSs) are playing a starring role in carriers' business plans, a visit to Halls A and B at Supercomm this year would have dispelled them. The "other show floor" -- home to the OSS vendors -- was a ghost town in 1998, but a mob scene last month. Booths so swarmed with customers and financial analysts that the lowly press occasionally had to wait for a demo.

But if the importance of OSSs is no longer under debate, another issue is taking its place: how those OSSs are going to be connected and managed. The telecom industry has long held up the Telecommunications Management Network (TMN) model as the ideal blueprint for operations management. As carriers begin to standardize and streamline their back-office systems, however, the question on everyone's mind seems to be whether TMN works as well in practice as it does in theory. Many industry members aren't too sure.

TMN TURNAROUND

Vertel (Woodland Hills, Calif.), which until recently dubbed itself "The TMN Company" on its tagline, has definitely rethought its position. "The TMN model is irrelevant to the future," says Ruth Cox, vice president of marketing. "Going forward, it's not going to be the management architecture of choice."

Part of the problem lies in the original definition of TMN as formulated by the ITU -- in particular, for many of the interfaces. Traditionally, the TMN model uses the Q3 interface standard and is built on existing open systems interconnection (OSI) standards, including the common management information protocol (CMIP) and the guidelines for the definition of managed objects (GDMO).

Meanwhile, however, the computer industry was developing its own protocols and technologies, which were often nonstandard and competing. That changed in 1991, when the Object Management Group (OMG) -- a group of high-tech companies including Unisys Corp. (Blue Bell, Pa.), Sun Microsystems (Palo Alto, Calif.), Hewlett-Packard Co. (Palo Alto, Calif.) and 3Com Corp. (Santa Clara, Calif.) -- introduced Common Object Request Broker Architecture (CORBA). Developed as a standardized, vendor-independent technology for object-oriented applications, CORBA basically allows applications to communicate with one another, regardless of where they are located or who has developed them. As a result, information can be exchanged transparently.

The telecom industry has generally been slow to adopt CORBA, preferring instead to stick with traditional TMN protocols. Over the last six months, however, CORBA's popularity has skyrocketed, driven largely by two issues that are near and dear to the hearts of most carriers -- cost and time to market. Because CORBA was developed within a broad information technology framework, there is a large development community and set of tools to support it. Vendors, therefore, have the resources to build CORBA-based products faster and cheaper than those based on CMIP.

"Three years ago, the protocol was CMIP, and CORBA was a very emotional issue," says Gerry Egan, president of Lumos (Santa Monica, Calif.). "Now everybody is saying that CMIP would have been good if it took off in a wider sense, but with CORBA, we have a lot of tools because it's widely used in other industries, which means lower cost and faster development times."

As a result, OSS vendors are increasingly migrating their products to CORBA. Vertel, for example, announced at Supercomm an initiative to develop CORBA-based embedded intelligent network agents in collaboration with Sprint for Sprint ION. Other major vendors -- including MetaSolv (Piano, Texas), Quintessent (Bellevue, Wash.) and Telcordia (Morristown, N.J.) -- have announced over the last few months that they are either building products based entirely on CORBA or adapting their solutions to support CORBA.

"If you ask most OSS vendors, they support CORBA or have plans to do so," says Karl Whitelock, OSS program director at Stratecast Partners (Lakewood, Colo.). "The capability to support the common bus that CORBA has touted for so long is finally here."

THE TWO FACES OF TMN

The question, then, is what this migration to CORBA means for the future of TMN. The best answer may be that it depends on what aspect of TMN you're talking about. While TMN can be looked at as a technical model, with a focus on interfaces and protocols, it can also be interpreted as a logical model comprising five layers (see Figures 1 and 2):

• Network element layer, which presents the TMN-manageable information in an individual network element;

• Element management layer, which manages the network elements, including network element data, logs and activity;

• Network management layer, which has visibility of the entire network, based on information provided by the element management systems;

• Service management layer, which uses information from the network management layer to handle the actual services that are being delivered; functions include provisioning, billing, fault management, etc.; and

• Business management layer, which handles high-level planning, business level agreements, and other such details.

Beth Adams, chief executive offer of the TeleManagement Forum (TMF; Morristown, N.J.), argues that technology changes do not affect the viability of the logical model that TMN provides.

"We've been lobbying for many years that if there is going to be value to the TMN model, you cannot have strict technical interpretation of what the model is and how it is implemented," she says. "Sometimes TMN can be interpreted very narrowly, but now even the ITU is pulling away from that narrow definition and is even blessing CORBA technology."

In fact, Stratecast's Whitelock believes that the logical TMN model is key to the development of end-to-end, multicarrier OSS solutions. "Before, a carrier would put out an RFP that said, `I need all of the OSS functionality necessary to support service delivery,' which in its mind could be everything from customer service negotiations to designing the circuits to inventory management to service activation," he says. "It got to be very confusing and difficult for service providers and vendors to talk back and forth."

Even those industry experts who are critical of the technical architecture of TMN would tend to agree. "I don't think TMN can have its demise because I don't think it ever got rolling," says Mike Schwartz, executive director of OSS strategic planning at Telcordia. "The good part about TMN was the layered architecture -- separating things by basic function like element management, network management, service management, so that when you build an application, it's isolated from changes in other applications."

Others believe that the logical model of TMN is simply common sense and is best used to help carriers craft and implement their business processes. "TMN plays a useful role as long as you don't get too caught up in it," says Lumos's Egan. "At the end of the day, the real problem is order management, fault management billing -- carriers need to get that to work, and that's where TMN can help."

Many industry members, including Telcordia's Schwartz, believe that the ultimate solution is the integration of CORBA into TMN's logical model. "The original dream of TMN has been realized with different technology -- namely CORBA,' Schwartz says. "TMN is different, not dead."

But Adams is reluctant to characterize CORBA -- or any technology -- as the end-all solution. Ultimately, she wants to see the perception of TMN move from a rigid technical architecture to a more flexible model.

"No matter what you do, this all has to start with process, not with technology," she says. "We have CORBA today, but five years from now, CORBA may be replaced by something else. The idea is to use a model so that once that happens, all the business agreements and processes are still basically good and can be implemented in the brand-new XYZ 2500 protocol. That's the flexibility issue, and that's what's important."

Figure 1: The basic TMN Model

Figure 2: Breakdown of the network, service and business management layers

~~~~~~~~

By Shira Levine