Easing Internet Traffic on the PSTN and Billing for It?

It's no secret that increasing Internet traffic is creating congestion on the public switched telephone network (PSTN). While there are many technical reasons for this trend, at its core it comes down to a regulatory policy that encourages "all you can eat" flat-rate Internet access pricing.

The crux of the problem is that Internet Service Providers are still protected by the FCC's Enhanced Service Provider exemption. This means that ISPs are considered end-users, not carriers, and thus are not subject to the type of access fees that IXCs must pay. ISPs were granted exempt status, supposedly on an interim basis, in 1983...years before most people knew what the Internet was and long before the Web even existed. Today, ISPs pay only regular, business rates to LECs for the lines they use. Under this scenario, ISPs pay for usage based on the number of calls they originate. But ISPs receive Internet calls from their customers; they don't originate them. Thus, they do not pay LECs for carrying their traffic.

Today, the FCC is reluctant to take action, first, because it fears impeding the continued growth of the Internet, and second, because it fears being swamped with millions of e-mail messages from Internet users...voters...who love flat-rate pricing at $19.95 per month. The commission does not believe that the current access charge system applies to ISPs, and Congress refused to touch this politically sensitive issue in the Telecommunications Act of 1996.

Though the commission refuses to take any serious action aside from requests for comments, LECs claim that they have no choice but to do so. LECs say voice resources are tied up by Internet calls, which means that voice calls are blocked more frequently. The result is unhappy customers in a competitive environment where LECs need to keep customers as happy as possible.

LECs claim that to cope with the traffic, they have had to throw money into expanding switches and trunks, the costs of which are nowhere near justified or recovered by the minuscule revenue generated from Internet traffic. So two questions have become crucial: How does a carrier move data calls off the PSTN and onto dedicated data networks for delivery to ISPs? And can a carrier recover the costs involved in doing so? Tariff relief doesn't appear to be coming any time soon, so LECs are looking for the best methods to move Internet traffic off the voice network and onto packet networks. New technologies and products have been popping up to help ease the current problem and provide lower cost and more technically appropriate alternatives to increased investment in costly voice equipment. Many of these new approaches use SS7 to help detect and reroute Internet traffic, which billing executives should take notice of for the future.

A Voice Network Designed for Voice Traffic

One does not need to look far to figure out why the PSTN is having trouble with Internet traffic. The reason is pretty simple: The public, circuit-switched voice network is not optimized to carry bursty data traffic, but rather predictable voice traffic.

Voice calls, by nature, are best served by circuit-switched architectures, as they are today. Voice call holding times are three or four minutes on average with predictable busy periods, and the voice network was designed with this in mind.

The problem intensifies because Internet calls are an entirely different type of traffic. Internet calls, via dial-up modems, last about 20 minutes on average, and connect times of an hour or more are common because users don't pay any additional cost for long Internet sessions.

Moving the Internet off the PSTN

Bellcore recently released a white paper proposing several architectural approaches. These architectures involve detecting Internet traffic and routing it to a packet network via a network element, loosely referred to as an access server (AS), which connects the PSTN to an Internet transport facility or backbone. Several of the proposed architectures use SS7 to control call detection and routing, and thus require a type of SS7 node called an Internet Call Routing (ICR) node. This could be a stand alone, add-on device or an existing STP running ICR software. The key is that SS7, an existing voice network resource, lends itself to the type of detection and rerouting necessary to make these fixes work.

Pre-Switch versus Post-Switch

The Bellcore white paper defines two categories of offload architectures, pre-switch and post-switch. Post-switch architectures are most appropriate in situations where congestion occurs in trunk groups and terminating switches. Pre-switch is best for cases where the ingress switch is itself overloaded. The key to success for any of these architectures is detecting an Internet call, as opposed to a regular voice call. Bellcore proposes three methods for doing so.

The first involves intelligent network triggers. This means essentially that a database could be used to keep track of all ISP numbers so that when a subscriber dials in, the network can check the dialed number against the database, recognize the call as intended for an ISP and route it onto a packet network for delivery to that ISP. Bellcore also suggests that an IN single number service could be used in a similar fashion, or perhaps that a special service code, much like 800 or 900, be created to designate ISP numbers. Any of these methods are viable, but today the IN trigger model is most recognized.

Bellcore proposes three post-switch architectures, each relying on an ingress switch to detect and reroute Internet traffic. The first architecture is relatively simple (see Fig.1). In this case, the ingress switch detects an Internet call, possibly using any of the proposed methods, and automatically routes it to an access server, over a normal voice line or primary rate ISDN (PRI) interface, and out to a public packet network or dedicated transport facility. Line interfaces, however, are rather expensive, difficult to manage and do not allow for detailed traffic monitoring. PRI interfaces can be managed but, according to Bellcore, it is unlikely that the PSTN could support such interfaces on a broad scale.

The second and third architectures are a bit more complex (see Figs. 2 and 3). These architectures take advantage of the SS7 network by using an ICR node to provide the AS with signaling capability. Keep in mind that access servers basically act as modem banks and are not generally capable of SS7 signaling on their own. The ICR node, communicating with the SS7 network, tells the AS on which circuit a detected Internet call is coming in from the switch. Using an SS7 trunk interface to the switch, rather than a line or PRI interface, the AS can then grab that call and route it out to the proper transport facility. An SS7 trunk interface is manageable, lends itself to detailed traffic monitoring and, according to Bellcore, shouldn't create any problems if deployed on a large scale. The third architecture is similar to the second, but more advanced, as the ICR node handles both signaling and transport between the AS and the packet network, thus improving traffic management and monitoring capability.

This third approach could create a revenue opportunity for voice network operators. Because the AS provides modem functions, it is possible for a carrier to lease ports on the AS to ISPs. The ISP would then be freed from having to maintain a modem pool and could lease a virtual presence in disparate areas without having to maintain a physical presence. It would also allow LECs to monitor Internet traffic closely. This architecture is the one that Nortel has incorporated into its Internet Thruway product.

Nortel's Internet Thruway

Internet Thruway is essentially an ICR and an AS. The AS is connected to a switch via an SS7 trunk on one side, and connected to an SS7 a-link and then into an STP pair on the SS7 network on the other. When a data call comes through, the SS7 network can deliver the dialed or directory number, identified as an ISP number using the IN trigger method, to the Thruway to check if there is a port available from the group the target ISP has leased. If there is, the session is connected. If not, the user is sent a busy signal. Carriers can also use overflow ports for which they can charge the ISP an added premium.

ISPs maintain control of their security and subscriber information, however, by the use of a tunneling technology called L2F or level two forwarding. There is also a new protocol coming out based on L2F, called L2TP or level two tunneling protocol. What this protocol does, essentially, is take the point-to-point protocol (PPP) session and encapsulate it. It doesn't look at the information within the session, but simply wraps it up and delivers it to the ISP's router. The gateway router then unwraps it and the ISP performs all the necessary log-in, security and accounting functions. Thus, the ISP maintains the privacy of and control over its subscriber base. Thus far, Nortel's main customer for this product is SBC Communications. The local service giant has installed the system in 12 of the largest cities in its home territory.

Pre-switch Architectures

Pre-switch architectures look basically the same as post-switch (see Fig.4), except for one essential difference. In a pre-switch architecture, a data switch is installed in-front of a voice switch. For example, Internet Thruway uses an "access node" for scenarios where ingress switches are being overloaded. In this scenario, an IN trigger in the ingress switch detects Internet calls and signals the "pre-switch" to reroute them before they hit the ingress voice circuits. With this method, Internet calls never touch the PSTN. The problem with this approach is that installing the pre-switch is extremely complicated and costly. The Bellcore whitepaper's authors suggest that it should only be done in cases where there is a critical level of congestion at an ingress switch.

Other Approaches

Nortel isn't the only vendor selling a solution to the congestion problem. Lucent Technologies recently released a series of software upgrades for its 5ESS line that help create extra capacity, both for switches and trunk groups, to deal specifically with Internet traffic. Siemens Stromberg-Carlson recently unveiled a new EWSD switch with a built-in Internet traffic concentrator that can route Internet calls onto a packet network. DSC Communications has developed its Intelligent Internet Solutions product, which integrates with existing DSC hardware, also to reroute Internet traffic. While all these approaches address the congestion problem, they do not provide the revenue potential of AS-based architectures.

What Does This Mean for Billing Execs?

It is generally agreed that some sort of metered billing will be necessary for Internet calls, if for no other reason than capacity demands from new multimedia services and/or Internet telephony will force the issue. ISPs won't get a free ride forever, and it is likely that they will be subject to some form of access charges, though not the same access charges IXCs face today. Once LECs are legally allowed to bill their ISP customers for their traffic, how will it be done?Any billing mechanism will need to differentiate Internet traffic from voice traffic, just as offload systems do. Trying to filter this information out of a central office switch would be unnecessarily difficult. SS7, however, may hold the key.

"For the foreseeable future there's going to be some kind of arbitrary distinction between traffic types. Without SS7, you can't keep that stuff straight," says Jeff Reynolds, vice president-access and costs at Alltel. Just as off-load architectures use SS7 to identify Internet traffic, billing systems could do the same. Further, SS7 messages carry a higher level of detail about network traffic than any switch can collect normally. Thus, SS7 lends itself to the type of detailed billing LECs will eventually need to provide to ISPs. "Being an end of the network company, capturing and recording traffic has always been a major issue for us. [SS7] is, in fact, the way to do recording," suggests Reynolds.

Many billing providers, including Alltel, are already creating SS7 feeds into their billing systems and integrating them with SS7 data capturing devices commonly known as link monitors, which have been on the market for some time now. These devices, produced mainly by Inet and Hewlett-Packard, have been the subject of previous Billing World articles (May '97) and are finding many uses, especially for real-time billing and other billing applications where extreme detail is required.

Congestion is just one side effect of the continuing convergence of the PSTN and the Internet. Billing executives will do well to keep an eye on this convergence as it drives new services and thus new demands for more and more complex billing.