Converged
Networks or Converged Services?
An
essay by Warren Montgomery (wamontgomery@ieee.org)
The push for converged networks, carrying all forms of communication in a single format, was a major driver for the telecommnications boom and bust of the late 1990’s. There are still many who claim that a converged, all packet future is inevitable, and that carriers who deny this or delay in their deployment plans are doomed to the fate of the railroads or the buggy whip makers. Of course many more who leaped straight into converged networking, both carriers and equipment makers, suffered the same fate as the internet companies who failed to understand how to build a profitable business around a cool idea. What is clear is that:
The remainder of this essay explores the reasons behind this.
Of course the answer should always be to make money by providing goods and services with a competitive advantage for customers. This sounds so simple that many forget it in the rush to deploy the latest technology, or in clinging to tradition when the competitive landscape or customers change. To understand which technologies really fit the goal of making a profit and where, let’s look at some key assumptions about the current state of telecommunications.
Everyone has heard it – declining revenue and margins for transporting voice, data, or pictures from one point to another means that carriers will increasingly look to services for new sources of revenue. Of course it’s even more important that that, because as transport becomes a commodity and open to competition, services become a key method to differentiate your offerings, so a carrier with good services can retain customers and even charge a premium for “commodity” transport.
Of course a lot of those services don’t come from the carrier or the equipment vendor, but they come from ideas by ordinary people inspired to solve a problem. Everyone cites the innovation in the PC industry or the internet as the pattern to follow, but the pattern of 3rd party innovation is far more common that that. The auto makers and road builders didn’t invent fast food, shopping malls, overnight package delivery, or any of the thousands of other innovations that grew up because of the universal availability of convenient personal transport. Even in cars themselves, innovations from turbocharged engines to high end audio have mostly come from 3rd parties.
No matter how pervasive the internet becomes, most of the people who want to communicate will have phones for the foreseeable future. Sure, some folks will use something like a PC as a phone, but the convenience and the sheer of phones deployed pretty much guarantees they will be around for a long time to come. Now, of course, the overwhelming majority of those phones connect to the world through analog wires, and most of the rest through digital circuits.
The digital revolution in telephony was driven internally in the carriers by dramatic cost reductions enabled through the use of digital technology. I do not believe that this will have the same pervasive effect in driving the deployment of converged networks. Why? Two reasons. First, when digital replaced analog, those miles of analog circuits and switches represented a large part of the cost of providing telephone service, which was still a pretty tidy chunk of change. Now, though, aggressive cost reduction of digital circuit technology has left little room for dramatic reductions in the cost of transport. Instead costs are in operating and maintaining the network, billing, and other areas not immediately impacted by a change in transport technology. To make matters worse, voice represents a decreasing share of the traffic being carried over all those facilities. Thus cutting the cost of carrying voice in half by going to a packet VoIP format just isn’t going to make a big dent. Worse yet, carrying voice in a packet network may even increase bandwidth needs. The reason is simple – Packet networks require a header on each packet, typically 10 or 20 milliseconds of speech, to identify the packet and where it is to be routed. For IP, that’s about 160 bits. At 64K bits per second, a 10 millisecond voice packet carries 640 bits of speech and that header represents a penalty of 25%. Too be fair, Voice over IP can use significantly lower coding rates, longer packets, and stop sending packets entirely during silent intervals, all of which significantly lower the bandwidth requirement and are common in PC applications that carry voice over modem connections, but all of these techniques also create voice quality problems that make them awkward for a carrier who cannot afford to offer a low quality product.
So what about all those claims that VoIP costs only about 1/10th of circuit switching? Some of them are apples to oranges comparisons, comparing a router, which is performing the core routing function with only a small number of high bandwidth connections, with a switch, which includes line and trunk interfaces to thousands of different connections and include connection testing and other operations functions not included with the router. Some show the effect of rapid technology learning curves, comparing a circuit switch designed built with parts now 10 years old with a router built with the latest technology. Others compare prices and tariffs, which often do not reflect the underlying costs – relevant if you are buying transport based on prices and tariffs but not if you are building based on the underlying costs. Where converged networking does have a real potential for cost advantage is by reducing those operations and maintenance costs by simplifying network structure and reducing the number of types of equipment to be purchased, deployed, and maintained.
If services are the need, open networks the enabler, and cost of transport isn’t compelling, who has the inside track on providing them? The incumbent largely circuit based carriers, or new carriers based on converged networking technology. The answer isn’t nearly as simple as many in the industry portray
The usual argument here runs along the lines above, that the need is to provide an open environment for innovation like the web, and this will rapidly outrun the slow pace of innovation in today’s circuit networks using services running in the switches and intelligent networks. Proponents of this view often make up a service on the fly such as the “Share the moment” service described by several at the May 2001 Pulver SIP summit. This hypothetical service allows you to arrange delivery of a gift (e.g. flowers), and automatically connect you to the party receiving it when it is delivered, all for a nominal (e.g. $10) extra fee. An open API in a converged network allows a savvy operator to conjure up a service like this and hack the mechanics together quickly. Implementing this kind of service in a traditional network would take considerable time and expense because the platforms in that network are not open, meaning that implementing any new service will require finding someone who can work with the particularly proprietary systems required and build the service. Furthermore since services and transport are tightly coupled in traditional networks, the service must be carefully designed and tested to insure that errors in it’s implementation will not interfere with other customers. This is not how innovative environments like the Web operate.
Thus the converged network operator with the open API gets the attention of entrepreneurs with innovative service ideas and can rapidly differentiate the services they offer.
The above example is as full of “apples to oranges” falicies as are all those misleading cost comparisons. Let’s look at what’s really going on. The “share the moment” service connects two ordinary telephones, which today at least are highly likely to be connected to incumbent carrier’s circuit switches and connected through the PSTN. In order to build the service, those phones have to be routed into the converged network through a gateway (or maybe two), under control of a softswitch or proxy server which offers the open API. In contrast the circuit carrier could provide the open API directly on one of the platforms (switch or service control point) already in their network and in the path of a normal call. Looking now at the cost to provide the service in the existing network or in the new converged network, the converged network has a distinct penalty – the need to pay for those gateways and extra interfaces to the PSTN required to drag what will become a call between two PSTN endpoints over to a point where they can control it. That’s not a recipe for business success.
The key word here is of course “could”. Today’s switches and SCPs don’t provide the kind of openness required to do the job, but the job in this case at least is really quite simple – initiate a call between two endpoints. In fact the functionality required from the network to build most, if not all the interesting services people are thinking of is absurdly simple. How much, after all, can you do with a voice connection? Other basic needs include the need to intercept and provide routing for calls and to screen both incoming and outgoing calls. While these are not broadly deployed today, they have been foreseen by an innovative architecture being developed by the Internet Engineering Task Force (IETF), known as PINT and SPIRITS. These two protocol standards specify interfaces between the PSTN and a server used to implement services that together provide all the important capabilities. Furthermore PINT and SPIRITS could (there’s that word again) be implemented easily using broadly deployed intelligent network capabilities, with no modifications required to switches or other elements in the carriers’ networks. If the incumbents can’t do this more cost effectively than installing the gateways, softswitches, and trunking required by the converged network solution, there is something seriously wrong.
So, it’s obvious that converged networking is a loser and incumbents will win the battle, right? -- Not always and not exactly. One of the keys is in those assumptions. The assumption that the endpoints involved in a new service are attached to the PSTN is true of many new services, but not all of them. A lot of services involve endpoints communicating either with a machine (e.g. an IVR or voice mailbox), or a human being sitting behind a private business communication system. These aren’t exactly normal PSTN endpoints. In the case of services communicating with a machine, half the call will route out of the PSTN to the machine, so the cost comparison becomes less clear. Whether the machine is a circuit switching based service node or a gateway connecting to a converged network routing packets to a computer somewhere doesn’t immediately suggest a cost advantage one way or the other. The converged network case might offer advantages, for example, by giving the operator more flexibility over where the service is provided and using the converged network to hide the real location of the service platform. Another curious thing about machine based services is they are not generally nearly as sensitive to delay as a human to human conversation. Machine recorded announcements can be sent ahead and buffered, allowing longer packets and silence surpression to be used in the converged network without the loss of quality that would occur in a human to human conversation.
The second assumption worth questioning above is that cost one. Yes, the costs of converge networks versus circuit networks don’t offer a compelling case, but the price comparison often does. So, if the new service involves, say endpoints belonging to a business which is buying the transport from a carrier, using a converged solution can be significantly cheaper than using a normal circuit solution. The carriers cost of providing the raw bandwidth and routing for either may be similar, but the cost seen by the business often doesn’t reflect that. This may provide a powerful driver for the development of new services.
Converged networking and Converged services will both happen, but not necessarily together and not in the same way that digital networks replaced analog. Instead these technologies have different drivers for their deployment that suggest the following focus: