July, 2000 Volume 18.7
Netwatcher (ISSN 0890-5800) is a monthly publication of CIMI Corporation. Subscription information is available here. Copyright © 2000, CIMI Corporation. All rights reserved. No publication or reproduction of this document is permitted without the express written consent of CIMI Corporation.
 |
Management Briefing |
One of the most difficult issues that our industry is facing is the role of voice services in the future public network. Today, voice dominates both revenues and profits, with even the large data-centric carriers earning two-thirds of their bucks from good old voice. But there are disquieting signs that voice revenue dominance is threatened by lack of growth. Can voice service be unseated by data? Can voice revenue growth be resuscitated? Will voice services and infrastructure change without any demand or revenue stimulation?
Good questions, we hope, and ones we’ll at least try to address here.
Let’s start with some baseline numbers. According to the FCC, long-distance voice service usage has grown at a relatively modest rate (about 8.4% per year). This growth rate has been relatively uniform, despite the fact that voice pricing has been subject to considerably more competitive pressure over the last four years. In the local exchange, where most customers have zero-marginal-cost calling (fixed price per month), call minute growth has been similarly slow.
Another measure of voice market stagnation is the duration of the average residential voice call. It’s been largely static for the last three years, and this again suggests that residential rate reduction doesn’t stimulate larger call-minute volume.
What this seems to us to mean is that we’ve reached the limit of price/demand elasticity in voice communications. The cost of calls may still inhibit some callers, but addressing these inhibitions wouldn’t materially increase calling overall, and the result of price reductions aimed at call volume increases seems to be revenue declines rather than revenue growth. Short of breeding more humans, we’re at an impasse in voice call minutes.
In the data services area, usage growth is much better than in the voice space; we estimate that the growth rate over the last decade has been more than double that of voice, and some segments of the market (like the Internet) are growing faster than that in usage or traffic terms.
Data revenue growth, however, has been more difficult. Data revenues are growing more slowly than data traffic in all areas, and in the Internet there’s virtually no positive revenue flow from which we could baseline growth discussions. To make matters more difficult, some of the growth in data services over the last decade can be attributed to a desire by companies to leverage private network bandwidth released by voice services through migration of “private” voice to a form of software-defined network.
There is also some indication that data service growth can be attributed in large part to the empowerment of “fringe” sites in the network—smaller branch offices, and even remote terminals like ATMs. This form of growth is clearly subject to a sharp ceiling limit, linked as it is to business density goals. You can’t have an ATM on every corner, or a branch office in every city. In fact, there is some indication that public data networking might reduce the incentive to branch out, reducing the private network data revenue cap levels.
The likely meaning of this basic combination is simple; voice profits and revenues would gradually increase as they have, but not fast enough to overcome the impacts of competition. The effect would be felt first and most in the interexchange market, where technology has reduced the barriers to entry and where regulatory reform has enabled new competitors.
The impact of this prediction would likely be the gradual decline of IXCs, and a reluctance of new competitors to enter the IXC market in a broad or “pure” play. Instead, they’d focus on niches that were economically viable, like data long-haul services. But even this couldn’t sustain margins, under our baseline model above, because of the plateauing of the data market as penetration approaches 100% of sites.
In the local exchange, this stagnant market model would combine with increased RBOC modernization to effectively kill local exchange competition. In fact, the emphasis of regulators would probably shift (by about 2004) from promoting competition to insuring that any player, including the incumbent, wanted to stay in the market. In short, the relaxation of the traditional monopolistic rules in local access creates a kind of loophole for the incumbent LECs to escape reliance on local access service revenues. As this loophole is explored through subsidiaries, the emphasis of these firms could shift toward information services or something of higher revenue/profit value, threatening our basic infrastructure.
The RBOC modernization will open the door for a shift from traditional voice services to other services like entertainment video and application hosting (both of which have been announced by SBC). If these services are successful, the access modernization is proved out in a profit sense, and voice falls to a sustaining mode.
Sustaining voice means letting the current CO investment rest on its current capability/commitment laurels, with capacity expansion focused on improved support of the new ATM-based fiber remotes, and with modest upgrades to switch capacity to support call growth. The gradual use of the new ATM outside plant to unload Internet calling would decrease the growth pressure on Class 5s for some time, so it’s very possible that modernization of the current switch plant would be deferred until the end of the decade.
Breaking out of this mold might, for voice services, involve the generation of significant profits outside of traditional calling—meaning the custom calling services. These have already earned more profits for the ILECs than data services, and that’s without any significant technology improvements in service feature creation.
Increased service revenues from advanced calling services would offer improved profit and margins in the voice space, a direct benefit to the local exchange providers who offer most of these features. To some degree, the model might also increase calling overall, which would improve voice margins for other carriers.
Another model of voice revenue enhancement already visible in the market is a shift of consumers from fixed-wire phones to mobile cellular/PCS instruments. Buyers are willing to pay a substantial premium for mobility. Buyers of PCS instrument plans are also tolerating a much higher toll charge on their long-distance calls—if one measures effective toll charge by dividing toll call-minutes into the monthly rate of the premium “all-calls-included” plans. Thus, the use of portable instruments generates higher margins and revenues.
It seems clear that the long-distance players will have to adopt some form of cellular/PCS program if they want to stay in the voice business, since their options to generate voice custom calling feature revenues are largely linked to their ability to bypass the ILEC.
For the IXCs, then, the strategy of the future for voice profit and revenue protection would be migration to PCS-based calling to provide both direct mobile revenues and to gain control of the custom calling feature market for their mobile customers. For LECs, the strategy would be to develop a custom calling feature leadership position and a PCS position to defend against the IXCs, while continuing to attempt to support a shift from voice-based revenues to data-driven revenues, or even to video-driven revenues.
The Internet, in this, isn’t the battleground. ISP profits are low, and unless a higher-margin market can be developed out of the Internet market of today, getting a leadership position in even the most profitable portion of the Internet (the content provider support part) wouldn’t be enough to guarantee anyone’s future.
So we’re embarked either on a shift of voice priorities, or a shift of priorities away from voice. The former, because it would largely at least sustain current revenue levels and growth, could result in a faster deployment of new service technology. The latter, because it might create a serious shortfall of revenue during the period when a non-voice profit model was being honed (if, indeed, it could be honed at all), might also stop public network progress in it’s tracks.
Voice, folks, is a good thing. |
In the Know |
The navigation of technology issues these days isn’t helped by the fact that the signposts seem to be unreadable. Issues are clouded by a morass of acronyms and standards, and users are often left with no idea of what’s really going on.
This confusing situation is perhaps most critical in the area of new-generation voice services. Voice communications is fundamental to human activity, and voice services are at the core of telecommunications revenues and practices. We’re proposing major changes to these services, and these changes could have widespread impact on the services that are the glue binding all industrial societies together.
In past issues (notably our May-July 1999 series on the topic), we’ve explored the question of what an ideal voice architecture might be, and we’ve also periodically reviewed the state of regulatory policy and network evolution, insofar as their impact on voice service and technology is concerned. We now propose to outline some of the “formal” activities aimed at the redefinition of voice services and technology.
Before we can do this, however, we need to set a baseline. Relevance to the issues would be an attractive one, but we think using it might exclude much of what is getting public attention. In any case, We don’t want to repeat our own recommendations on architecture, so we’ll propose a simple architecture model. We’ll then try to fit what’s happening (relevant or not) into that model.
A voice network consists of a voice appliance and a voice service facility. To obtain voice services, the voice appliance signals its desires to the network in the form of a client service signaling protocol. That same protocol provides feedback on the status of the request.
Our pervasive DTMF “black phone” protocol is an example of this sort of thing. Dialing phone digits results in dual-tone signals that are collected by a switch and interpreted as a call or feature request. The status of the network’s fulfillment of the request is fed back in the form of audio waveforms like dialtone, busy signals, etc.
The same signaling protocol also must handle the reception of a call. The “ring” function we’ve made an integral part of our culture is an example of an “incoming” service signal. “I’ll give you a ring” has become a part of the popular vocabulary, and the term “call” has come to mean any communications relationship between parties; a “data” call or “video” call is the example.
If the network that did all of this was a humungous box in St. Louis or somewhere, to which everyone was wired via access loop, this would pretty much define voice communications. What messes up the simple model is the fact that communications over a network typically benefits from concentration of traffic that’s flowing along parallel paths. Clearly, the cost of wiring a New York or LA user to St. Louis on a discrete copper loop would be higher than the cost of developing a collective traffic trunk over that same distance. Thus, introduction of a hierarchy of network devices to concentrate and then distribute traffic is logical.
A simple set of multiplexers could be used to concentrate traffic in our model, a device set that didn’t include any real intelligence. This would allow us to contain the service intelligence—the interpretation of the client service signaling protocol—in our St. Louis center. What changes this noble goal from logical into impractical is the fact that most calls tend to be less than national in scope. The routing of a call to your neighbor to a switch a thousand miles away isn’t really too logical.
Introducing awareness of the client service signaling protocol into the intermediate devices in the network—our concentrators—would allow these devices to “short-circuit” a call route for connections that were essentially local, metro, or regional in nature. But when multiple intelligent devices are used to fulfill a network service mission, a special problem occurs.
Our St. Louis switch had a big technical advantage. It knew the status of the called party, the caller, and the network facilities all in one place. All of those “statuses” are needed to determine how to place a call and what to signal for service status. When we break the service network up into a web of smart devices, the status of the network at large isn’t directly visible to any individual device. Voice services must now be viewed as originating in a network of cooperating devices. The question, then, is how they are made to cooperate.
The logical answer is another protocol, a service control protocol exercised among the devices in the network for the purposes of providing the customers’ services. When a customer signals for service, the serving network device uses this service control protocol to pass the request through the network to the agents or destinations of the request. Along the way, the devices can communicate any relevant status information back to the originating node, reflecting things like “destination busy” or “resources not available”. At the destination end, the service control protocol’s notification of a request can be translated into client signaling format for delivery to a partner.
Service control protocols can also deal with the problems that arise out of our practice of multi-carrier networking. When multiple carriers must participate in a call, the decision to use a single central service point isn’t practical for administrative reasons, leaving technology issues aside.
As professional network programmers know, protocols are finite state machines, meaning that there is a set of network events and processing states whose relationship determines just what reaction a node will generate to a given stimulus. The combination of these states and events, in fact, determines what happens in the network under all conditions. In effect, it provides a “model” of behavior.
The client service protocol’s state/event model is a call model. This call model determines how client signaling will be interpreted—how it will be converted into either local device behaviors (“when offhook, assert dialtone”) or to inter-nodal signals (“when number_complete signal IAM”). Similarly, a state/event model for the service control protocol can be said to create the service model of the network, the range of features or elements that the client can call on as a network service.
Well, then, we have a simple voice model. A network would have an external client service signaling protocol and an internal service control protocol. Both contain state/event models to describe the calling and service fulfillment process. As it happens, that model describes the current voice network, where DTMF and SS7, respectively, fill those roles. Data networks sometimes obey the same model; packet networks use X.25 as the client protocol and X.75 as an inter-network protocol.
Can this then be applied to the current voice service issue set?
A new technology for voice telephony—a new network—wouldn’t necessarily imply a new client signaling protocol. The nature of a client signaling protocol is dictated by the combination of the features of the device expected to originate the service request, and the nature of the services to be requested.
Since virtually everyone in an industrial society has used a phone these days, it’s clear that there is already a client service signaling protocol of some considerable credibility. The notion that another one is needed, or that the current one needs rehab, must be based on one or both of two assumptions; that there is a new population of call instruments that would find the existing PSTN DTMF protocol unwieldy, or that there are features or capabilities that future users will want, that current voice signaling doesn’t support.
That there is a new population of signaling instruments is clear. Desktop computers represent the largest population of consuming devices for two-way communications, after “black phones”. That there are at least some features that current PSTNs don’t provide but which are plausible future requirements is also clear; video telephony is an example. Thus, we can justify a new signaling protocol.
H.323, it could be argued, is that protocol. An international standard directed at multimedia relationships, H.323 supports both the concept of a computer-based or non-traditional client population, and the idea of non-voice services. H.323 is a packet-mode multimedia standard that doesn’t have any explicit low-level protocol affiliation, so it’s suitable for VoIP as well as for VoATM.
The Internet community, one could argue, isn’t particularly happy about absorbing the standards of others. Not surprisingly, H.323 isn’t considered a complete (or even useful) solution to the new-gen voice space by much of the I-people. For these, and particularly for the IETF itself, the standard-bearer (no pun intended) is the Session Initiation Protocol, or SIP.
SIP was formulated to facilitate multi-party, multimedia, relationships in real time using IP-based infrastructure. Its apparent competition with H.323 is excused by the fact that it takes a somewhat higher-level cut at the issue of calling, defining a series of call-related activities that can actually supplement H.323 as well as replace it. However, the basic documents on SIP seem to make it clear that the use of SIP in conjunction with H.323 would be primarily to support the use of non-IP network channels in a computer-based voice/video application that was dominated by IP networking.
Both H.323 and SIP are message-oriented (“functional signaling”, as opposed to DTMF which is “stimulus signaling”) and thus provide a simplified call model. Both SIP and H.323 work on the theory of the “gateway”, a network component that fields calls and provides service connection support. Gateways find destination addresses and also provide for forwarding and other call functions. Thus, it’s likely that advanced calling features would have to be provided by the gateway, using customized call messages or customized decoded addresses.
The benefit of SIP that’s hard to argue is simplicity, and that translates into some performance benefits as well. SIP sets up calls about half-again to twice as fast as even the newest H.323 version. SIP implementations take less time, require less program size, and have fewer moving parts to break. SIP also supports third-party call control, which might be valuable in many packet voice applications where servers redirect calls. On the other hand, H.323 is more robust, has better extensibility to add features, and its stateful operation is more in keeping with current phone system operations, which might help its adoption in a world dominated by circuit-switched voice.
The big question with client service signaling may be infrastructure commitment and not features. Neither SIP nor H.323 is necessarily limited to support for packet-mode voice transport, but the truth is that both can be said to be explicitly targeted at packet calling instruments. SIP’s sponsors in the IETF seem to be bent on extending that relatively harmless assumption to an assumption that the entire infrastructure has moved to IP. Since this isn’t going to happen (the access network, at least, is going to be dominated by ATM), we must question whether SIP will end up inheriting a lot of “IP-religion” baggage that will compromise its value in the general market.
In short, SIP isn’t a drop-dead winner over H.323, and it’s not completely clear whether it would achieve full support. There are a ton of H.323 products out there, after all. However, SIP networks can be made to work with H.323 clients, so there are at least options for reconciling the two approaches. Whether that reconciliation occurs may be a factor not only in SIP acceptance, but in packet voice acceptance. Multiple standards are, after all, equivalent to no standard at all.
Even if we assumed that packet-mode voice equipment swept the market (which it demonstrably hasn’t, given that computers are such devices and the call volume via computer is negligible), we’d still have to account for the hundreds of millions of ordinary phones in the US alone. Doing that is the mission of the “media gateway”, in the VoIP/VoWhatever lexicon.
A media gateway is a linkage between a legacy calling environment and a packet infrastructure. The gateway’s primary mission is to act as a format converter for the call data itself—it converts PCM-coded analog voice to digital packet voice of some sort. In this regard, it’s an information-plane element.
The signaling conversion issues of the process are traditionally assigned to a “gateway controller”, which is another device completely, linked to the gateway via its own data path. The gateway controller may exist in two variations—one designed to support SS7 and the other to support inline subscriber signaling from black phones.
It’s true in both cases, but it’s especially clear that the process of subscriber signaling involves state-event behavior; what is called “dial-digit collection” and “triggering” in Class 5 switches. In the case of gateway controllers and media gateways, this process of state control for call management is handled by the gateway controller, which provides the media gateway with a table of trigger events. Many believe that this process of “remote call management” is too slow to scale.
Signaling triggers for service creation aren’t limited to black phones, either. Will an infrastructure for voice where nearly all customers use black phones be able to justify a SIP-based on H.323-based feature creation architecture that doesn’t play in black phone services? It’s more likely that whatever mechanism for creating call features on black phones will be applied to other non-traditional instruments as well. Thus, the concept of a “media gateway” and controller may be applied to even IP-based appliances like desktop computers. We’ll certainly need feature controllers, and we may even need gateways (there are, in fact, devices called “gateways” in both the SIP and H.323 architecture).
The protocols that link the gateway controller to the media gateway are, not surprisingly, called “gateway control protocols”, and the one that’s most recognized is MGCP (Media Gateway Control Protocol). MGCP provides a standard way that gateway controllers can control the behavior of the black-phone gateways in a packet voice network.
MGCP was an Internet activity, but the process of gateway control is now being absorbed in the international standardization of the gateway/controller process. H.248 is the new standard, and the IETF activity associated with it is called MEGACO (Media Gateway Control). MEGACO isn’t all that different from MGCP in terms of architecture and even in terms of the controller-to-gateway relationship. The biggest differences are in MEGACO’s support for a broader range of networks—ATM, for example.
We’re going to use the modern MEGACO reference to displace MGCP (itself a construct by Nortel to reconcile differences in Bellcore/Telcordia gateway control protocols and those of Level 3), but there are some differences in the approaches of the “old” MGCP and the “new” MEGACO. Purists should look at the specs to get the skivvy on this, if necessary.
The essential concept of a media gateway architecture is a separation of call handling and call handling logic. The media gateway provides the call handling, and the gateway controller the logic. In effect, it’s a distributed version of a standard telephone switch, though the application of MEGACO is normally one of IP telephony.
The basic concept of MEGACO is that a controller handles the call processing events and a gateway the actual information flow. The controller establishes a set of “listens” that wait for particular events, which the gateway then looks for. When the events are detected, the controller drives the gateway through the appropriate procedure. It’s really a lot like the function of a standard telephone switch, except that the call-handling logic is separated from the switching plane and installed on a remote processor.
Virtually all of the so-called “softswitch” products and initiatives are related to MEGACO, meaning that they use it to separate the handling of calls into a signaling processing element (the gateway controller) and an information-plane element (the gateway). Most often, these products are seen as ways to support VoIP, but in theory a softswitch could be used in any voice environment as long as the media gateway supported the client/networking technology involved.
Gateway management is seen by some (perhaps even most) VoIP purists as the service control issue of future networks. However, gateway management is to a degree a structural requirement; if you elect to separate gateways and controllers, you need it. If not….
Real service control is something so basic to telephony it’s surprising that more attention isn’t paid to it, yet it’s an issue that often gets ignored by the media and vendors. At issue is not only the basic nature of voice services, but the interworking between current voice networks and (possible) future packet voice networks.
Service control is needed among network devices if the fulfillment of a user requirement cannot be carried out by one node alone. The need for multiple device coordination may be related to the very nature of the service, or to the service architecture.
Today’s voice network is a quasi-centralized system in feature terms. Each voice line is owned by a local switch (the Class 5), and that switch acts as an agent for the phone. This agency lets the phone be dumb and universal, because the switch provides call handling control on its behalf.
Most features are controlled by the call agent in the switch, in this model. Calling line ID, last-number redial, voice mail, call forwarding—all these are primarily mechanized by the “home” switch. In fact, there are models of service behavior that allow all the current features to be centralized in the local switch, which is why many would say that the PSTN is a centralized architecture despite its multiplicity of devices.
The centralized model of today’s PSTN is carried on to a large degree in H.323. An H.323 gateway is in effect a switch; it keeps call state and thus has a knowledge of the feature context of its users. In an H.323 network, therefore, we could expect to see SS7-like behavior act as the service control language, with at least a reasonable degree of efficiency.
Where service control beyond SS7 is needed is in support of transitioning to a more distributed model. With today’s PSTN, we really have some decentralization, because the call agent at the caller side of the relationship has call progress signals (like “busy”) from the network side to use in feature control, and because some features are explicitly linked to the destination switch. Thus, we can “forward” a call by having the destination switch simply extend a kind of “call stub” from the original destination to the “new” destination. This call stub is really another call, and the forwarding subscriber pays the cost.
Most services, as it happens, work adequately with the service model that confines switch feature control to the originating or destination switches. That limits cooperative switch behavior to the function of call placement, which is what SIP tends to do. But competitive interest in custom calling services could change that.
One problem with today’s system is that it can set up “non-optimum” paths. A person might call a friend across the country to be forwarded to the house next door, where the friend happens to be visiting. Today, that would create two transcontinental calls, and even if network cost is low, that might create for the carrier a revenue-sharing or settlement requirement. A better strategy would be to “know” that the called party is really next door and place the call only to the real destination. That requires some service control.
SIP extensions have been proposed to provide a means of communicating call-connection or user-location data between SIP elements, and the problem is generally easier in connectionless architectures because there is no durable connection made to the destination switch in any case.
H.323 has a problem here, in short, and SIP may not. With any connection-oriented protocol, efficient transfer of calls or forwarding of calls will require “route pruning” to optimize the path, because intermediate devices maintain call state.
But it’s clear that this relatively simple level of custom calling expansion isn’t the end of the story. More complex custom calling features can easily be devised, requiring smart integration of multiple switches, and this is where SS7 would be used today. Is it enough?
The problem of service control protocol adequacy is that it may be bound in with questions on service definition. If we hearken back to last year’s series on new-generation voice, we know that feature customization extended to the subscriber would allow the called and calling parties to diverge on the way special conditions were handled. Suppose the calling party sets a “no-forwarding” rule and the called party has an “always-forward-transparent-to-caller” rule? Who prevails? To arbitrate this, it’s clearly necessary to have a defined way of communicating details of each party to the switch of the other, then reconciling any contradictions according to service policy or law. It’s likely that this would be done in a way that integrated well with service definition, so service definition defines service control.
That, of course, means that we can’t really answer the question of SS7’s adequacy, or of the future of service control protocols. We’ll have to wait for service/feature management to develop.
The casual reader of this section might well decide that the issues of new-generation voice protocols aren’t decided. They’re right. In large part, that’s because we’re presenting many of the options in a manner that reflects not requirements but objectives, and the objectives are those of vendors or other opportunistic players rather than ones representing the public interest.
Another factor, and perhaps the telling one, is that the goal of the real players in the telecommunications market is to affect a transition from a totally voice-dominated service environment to one in which multiple service types can be supported without cross-arbitrage of service rates. This means that it’s likely that the future of voice services will be linked to the future of non-voice services. In particular, alternative voice will develop not when there are alternative technologies, but when there are alternative revenue sources.
We’re actually on the verge of seeing the nature of the new public network as it develops, not as it’s hypothesized. That development will answer a lot of questions, including the ones we’ve posed directly and indirectly in the new-gen voice space.
All things come to those who wait, they say. We’ll see.
 |
Strategies |
In a period when there has never been as much hype or nonsense published about the future, it’s ironic that we’re nevertheless on the verge of the greatest infrastructure change in the history of public networking, and probably the greatest service change as well. Over the next decade, providers will spend nearly two hundred billion dollars on modernization.
Who gets the money is a key question, of course. In any period of market confusion, the incumbent has the advantage, and yet even incumbents seem confused by the market conditions. And, while the sands of time and the associated dollars have been slipping away, there’s still time for most players (though not all) to recover a position from which future strength can be developed. It’s not anyone’s game, our networking future, but it’s still a populist playing field.
What are the strategies that players might use to save
themselves? Clearly, that depends
on who the player happens to be, but there are some general rules that can be
presented here as a blueprint for market success, and we can make some
vendor-specific comments besides. Sorry,
Internet readers; this is for subscribers only!
 |
Down the Line |
We’re still watching the developments in the Asub space, and we hope to cover the detailed plans of BANDI and ASI when the regulatory dust settles. Next month, we'll start our series on the hot and getting hotter service management space.