It's autumn 2000 and a doomsday scenario has begun to unfold for service providers looking to compete in local, broadband and packet telephony. A federal agency has ruled the BOCs need not make their broadband network access devices or switches available to competitors. Within weeks, the incumbent carriers, which continue to own and control the equipment that provisions services over more than 95 percent of local loop connections in the United States, began announcing multibillion-dollar projects to deploy technologies that could make resale and arbitrage pricing of enhanced broadband services nearly impossible, rendering wholesale versions of broadband local loops generic, dull and unappealing.
The scenario is not far-fetched. Just as new industry standards emerge for controlling telephone calls and intelligent network (IN) services over broadband TCP/IP networks, SBC Communications Inc. (www.sbc.com) and BellSouth Corp. (www.bellsouth.com) announced plans not to deploy TCP/IP equipment, but rather ATM technology, a form of packet switching that uses fixed-length cells instead of the variable-length packets used in IP. With the change in transport also must come a change in the feature creation and provisioning systems for IN enhanced services--the key to service differentiation.
How can underdog, competitive service providers respond to the incumbents' fiendish end-run? According to several switch developers and industry observers, a potent answer may lie with extensible markup language (XML), a World Wide Web Consortium (www.w3.org) standard that can be used to create and provision telecommunications services, regardless of changes in underlying transport equipment or signaling systems that otherwise could limit enhanced service development and delivery.
Promising to free new competitors from being at the mercy of any reconstruction the RBOCs undertake, one next-generation switch designer, DTI Networks Inc. (www.dtinetworks.com) plans to deliver a voice switch and XML-based Telecommunications Service Portal "virtual machine" software that includes call control logic and an IN services development environment. According to the company, the system will enable CLECs or ISPs to support existing IN services and to create new ones, unfettered by whatever transport or call control signaling technologies the incumbents deploy.
Whether DTI's specific prescription flies with local telephony competitors, the coming sea of change in RBOC technologies is destined to force all of them to revisit the assumptions underlying their broadband, packet telephony and IN strategies.
ATM Moat
The groundwork was laid for a wave of RBOC network reconstruction investments on Sept. 15, 1999, when the FCC ruled incumbents need not unbundle their own DSLAMs nor their packet-switching facilities for discounted wholesale to competitors. The ruling freed RBOCs from the specter of having to create separate CLEC subsidiaries with DSLAM and packet-switch facilities protected from unbundling, and instead gave incumbents a green light to undertake massive broadband buildouts.
The key to those construction plans for the majority of the RBOCs, according to Tom Nolle, president of consulting firm CIMI Corp. (www.cimi.com), will be ATM.
Indeed, within a month after the ruling, SBC committed $6 billion to Project Pronto, a radical overhaul of its infrastructure. Among DSL leaders worldwide with more than 100,000 lines deployed, SBC says it is determined to make ATM-based DSL available to 80 percent of its customers. Concurrently over the next several years, it plans to scrap its entire circuit-switched, tandem trunking network in favor of voice trunking over ATM (VToA). This all adds up to "the kind of fundamental change that only comes every 60 years," says Sam Sigarto, executive director, ATM distribution network systems, broadband switching for SBC.
Several weeks later, on Dec. 15, BellSouth announced its own major infrastructure overhaul, saying it will build the world's largest fiber in the loop deployment designed to deliver ATM broadband services throughout its nine-state region. Bell Atlantic Corp. (www.bell-atl.com) also has indicated it will continue to build its packet networks around ATM technology. The DSLAMs all these incumbents have so far installed to provision broadband local loops already employ ATM transport and signaling.
"Is ATM optimized for voice?" SBC's Sigarto asks. "No, nor is it optimized for IP alone or video alone, but we need to build not six optimized networks for six separate services at six times the cost, but one network that can accommodate all those services, and ATM gives us the capability now to build that one network, and it may cost us one and one-half times what a single-service network would."
While SBC describes a technology-driven decision, Nolle and others say ATM is a sound way for the RBOCs not only to accommodate multiple services, but to also block arbitrage of those services. Indeed, the RBOCs would have no incentive to invest so deeply in new technologies if competitors could simply resell the services they enable and thereby cripple the return on the RBOCs' investments, Nolle says. "It's well established that investment in packet technology can lower the costs of networking, but that's meaningless if the savings gained can be wiped out by reseller arbitrage."
Executives at DTI Networks agree avoiding such easy arbitrage is driving incumbent ATM deployments. "Because IP is the native protocol of personal computer applications, there are a large number of services that a competitor could potentially offer just by buying a wholesale IP connection from the RBOC," notes Ron Nash, vice president of marketing for DTI. "However, ATM has never really caught on in the corporate networking space, and there are virtually no native ATM applications at the desktop."
Consequently, if the local loop connection the CLEC resells was IP, a CLEC could easily put together IP services such as PC-based VoIP using off-the-shelf parts. However, Nash adds, if the local loop connection is ATM, that straightforward VoIP service is forced to become a less full-featured VoIP over ATM service.
In short, say CIMI, DTI and others, each RBOC knows that CLECs forced to resell ATM connections also will be forced to either deploy their own ATM-capable IN custom feature systems or be relegated to selling less elegant IP over ATM services.
Indeed, IN services are a treasure for incumbent carriers, which according to Stuart Rosenfield, senior director of the network applications division for Alcatel USA (www.usa.alcatel.com), gain up to 20 times return on investment--incentive to build a kind of ATM facilities moat around their broadband IN castles.
"By not requiring incumbent carriers to unbundle DSL equipment, the FCC recognizes the importance of facilities-based competitors," Steven Gorosh, general counsel of national, facilities-based DSL competitor NorthPoint Communications Inc. (www.northpointcom.com) said at the time of the FCC ruling. That ruling, he added, will prompt further investment in facilities-based DSL deployment by both incumbents and competitors.
However, DTI Networks believes if competitors such as NorthPoint want to sell telephony and Internet access services, and want to match incumbent IN service innovation over DSL, they also will have to invest in new "Virtual Voice Services" platforms that are free from dependence on either the transport or call-control signaling systems employed by the RBOCs. By deploying such a platform, DTI says, CLECs will become as capable as any player in the market to create new, value-added IN services and to deliver them virtually instantaneously to their customers.
"CLECs that can develop voice services based on a different approach from traditional Class 5 switches could potentially offer features the incumbents are unable to match," says DTI's Nash.
|
Web-based Signaling System Independent Architecture
Source: DTI Networks Inc. (www.dtinetworks.com) |
Virtual (Switch) Machine
To achieve this goal, the CLECs' new service creation and provisioning systems must operate independently of either ATM, IP or time-division multiplexed (TDM) transport, says Nash. He adds that it is just as critical these systems also operate independently of both the SS7 and service control point (SCP) feature servers of the PSTN or on new gateway control signaling protocols embodied in media gateway control protocol (MGCP) and session initiation protocol (SIP) call-control signaling systems now being developed for IP networks.
This control signaling independence is required, says a new DTI Networks white paper, because feature creation and provisioning continues to be closely coupled with existing "message-coupled" signaling systems, each of which requires that network devices support a unified message set to support the entire collection of features. The paper reports, "feature richness in ATM voice is yet to be provided, and for the same reason is lacking in IP voice--we continue to depend on protocol enhancement to build features, just as we did in the SS7 world nearly everyone agrees was too inflexible."
To escape this straitjacket coupling of feature creation with signaling protocols, this month DTI plans to make available telephony switch hardware coupled with a new "virtual switch" software package designed to leverage web-data structure development languages for service creation and provisioning. In addition to supplying packet-circuit mediation switch hardware and telecommunications service portal (TSP) software, DTI also will deliver call policy markup language (CPML), a service creation language based on XML and adapted to routing, forwarding and other "primitive" functions associated with telephony switches.
DTI's Extensible Service Policy architecture enables a call policy server to consult an individual subscriber's web page written in CPML to determine the call behavior for each call. These CPML pages contain XML scripts that define how a call should be handled, including functions such as routing specifications, selection of a long-distance carrier for the call, forwarding instructions to another number based on the calling number, time of day or other parameters. In effect, a switch that originates a call will access a web "service page"--rather than a PSTN IN database or an IP gateway controller--to discover instructions for how to handle the call.
The architecture derives in great part from the widely deployed, machine-independent network applications model embodied in Sun Microsystems Inc.'s (www.sun.com) Java language. Just as Java applications can run on Java Virtual Machine software residing on any computer running any operating system, DTI describes its TSP as a "virtual switch/virtual machine" that houses call-control logic primitive functions, such as connect or redirect, similar to display functions found in a Java Virtual Machine. The TSP then can use IP transmissions to tell any IP switch, ATM switch, circuit switch or other real machine how to execute the primitive functions needed to deliver the IN service.
By making web pages the nexus of call control policy, DTI believes it can open call feature creation and provisioning control to anyone with authorized access to the web. Indeed, the developer would be assembling XML scripts on the same web service page the originating switch accesses for provisioning instructions. Therefore, a carrier might be able to offer subscribers the ability to customize the effect of "*" or other telephone keypad inputs, or to change their call forwarding numbers depending on their travel plans.
"The carrier could go further and have the phone switch figure out how to change my forwarding numbers by consulting my web-hosted personal calendar page, which I'm already editing on a
regular basis," says Nash. "Or it could be an application that uses XML-scripted text-to-speech components to give me a call whenever a certain stock moves past a certain price. This is the kind of thing you can do when you leverage the information-merging
possibilities of the web."
Just as Sun has sought to seed the network-hosted applications market by giving away the Java language to any and all applications developers, DTI "may just give CPML away, because we can still bring value in our ability to provide virtual machines that run CPML applications," Nash says.
BroadSoft Inc. (www.broadsoft.com), a competitor to DTI in developing next-generation service creation and control systems, agrees that XML could provide a unifying successor to all the various signaling systems in use today. However, says Scott Wharton, vice president of corporate marketing for BroadSoft, SIP is already gaining traction in the marketplace, and it provides a "lightweight protocol to get things going" and doesn't significantly gum up new feature creation. "We agree with the [DTI] vision, but we think it's going to take awhile," Wharton says.
Old, New Worlds
Larger, veteran telephone switch vendors also have their eyes on XML and the concept of the telecommunications web portal.
"We find XML very helpful in defining data needed to provide a service and to tie it into provisioning and billing systems," says Warren Montgomery, technology manager, next-generation service architecture for the IN group at Lucent Technologies Inc. (www.lucent.com). Lucent is seeking to provide applications programming interfaces for its Full Circle developer partners to control all Lucent switching platforms, ranging from current IN hosts to the 7R/E feature server add-on to the Class 5 switch, the new Lucent Softswitch and Lucent's Octel Messaging Systems platforms.
Among Lucent's early packet IN offerings, its Online Communications Center system provides a way to manage calls from a Java-based software client. By providing a common XML portal, Montgomery says, new features can be developed "without having to recode all the interfaces to billing systems and other areas." However, Lucent's use of XML in its Service Management System is designed to control deployment of services to Lucent's IN devices, which are embedded in the traditional, message-coupled PSTN SS7 systems.
"We've had a creation platform in IN for years, and it's evolving," says Beth Morris, senior manager, market management, IN, for Lucent. "Anyone can create a call processing server; the hard part is understanding all the back-office facing systems, like provisioning and billing, and we have a leg up in that understanding."
Alcatel, which has extended its IN platform to provision location-based applications for wireless carriers including BellSouth Cellular Corp. (www.bellsouthmobility.com), also argues the installed IN infrastructure can evolve across packet networks. "Going forward, IN remains the service creation platform for all networks because it's as important to manage the service as it is to develop it," says Alcatel's Rosenfield. "You can do that while continuing to build on an SCP that can work in any network environment."
Not so for CLECs and ISPs betting their telephony fortunes on broadband networks, says DTI's Nash, who notes that, although the initial DTI TSP will be coupled with a circuit-based switch, the RBOCs' ATM deployments will force a fundamental shift. "The next-generation end office requires the equivalent of a Class 5 switch for ATM, matching all the features," he says. "The CLECs are the attackers innovating for differentiation, and they can't do it if they're buying the very same Class 5s and IN systems the incumbents buy."
