HP-TSD Discusses the Status and Future of SS7 Link Monitoring

Andy Belcher’s got a pretty tough gig. As general Manager of Hewlett Packard’s (HP’s) Telecommunications Systems and NetMetrix divisions, it’s his job to combine his company’s Internet business with its telco expertise. Though, like everyone else, he can’t be sure exactly what the next-generation network will look like, the one thing he does know is that SS7 is a major catalyst for its evolution. HP’s Telecommunications Systems Division (TSD), based just outside Edinburgh, Scotland, is focused almost solely on SS7 link monitoring technology-HP’s AceSS7 product-and developing applications to utilize it (see “SS7 Link Monitors: More New Technology That Will Affect Billing,” Billing World, May 1997). Link monitors started out as fraud prevention and network engineering tools, hiding in the catacombs telcos don’t like to publicize and where only hard core techies dare to lurk. With an increase in the number of CLECs and the growth of Internet traffic, SS7 link monitors are being applied to some of the biggest issues LECs currently face, from interconnect billing to network resource engineering and the battle over reciprocal compensation.

The Internet Curse

Most people agree the Internet is a good or even a great thing; however, anyone in charge of ILEC network resource planning would probably offer a dissenting opinion. The burden Internet traffic places on voice networks is well documented (see “Easing Internet Traffic on the PSTN, and Billing For It?” Billing World, January 1998). Basically, voice networks are designed for five-minute phone calls and assume that only about 1 in 10 customers will be on calls at any given time. Internet calls last for about an hour on average, and often longer. This means that switch and trunk resources are eaten up by dial-up Internet sessions, but they don’t generate incremental revenue.

ISPs don’t always stay with one provider, a fact that creates problems for network planning. When a contract is up, an ISP might switch LECs, sending all traffic destined for its network over a new path. Belcher says that with the rise of CLECs and ISPs, tandem switches are overburdened and exhaust too quickly. Tandem switches are expensive, so it’s worth a LEC’s investment dollars to identify its traffic flows and keep demands on the tandem at minimum.

Belcher says major service providers are using link monitoring applications to watch their traffic and determine how stressed network resources are. Network planners use this data to identify major traffic hubs and create direct routes between them in order to ease the burden on switching resources. In cases where abnormally large amounts of traffic hit a network segment unpredictably, for example in response to a radio contest, link monitors will produces alarms and enable network engineers to reroute traffic around network bottlenecks.

Reciprocal Compensation

The economics of Internet traffic are tangled in a morass of complex regulations. The problem for ILECs is that ISPs and CLECs tend to be on the same team. Quite often CLECs provide the bandwidth pipes that ISPs need. Of course, the ISP’s customers are most often ILEC customers as well. This means that when an Internet user dials up the ISP, the call travels over the ILEC network, to the CLEC network, and ultimately to the ISP. In this scenario, the ILEC is required to pay reciprocal compensation to the CLEC, often as a per-minute charge, for terminating the call. In other words, the ILEC provides the customer with access over a low-margin second line, and pays for the majority of the calls that ride it.

If you ask the ILECs, the cash is flowing in the wrong direction. They would like to see ISPs pay access charges, and would love to be able to hit Internet calls with per minute charges. The FCC isn’t likely to let that happen, however, so the ILECs will settle just for not paying CLECs for their Internet traffic. In order to make any headway with this argument the ILECs need proof of exactly how many Internet calls are traversing their networks and just how much this costs them in reciprocal compensation fees and network resources. This is where link monitors enter the picture.

Breaking the Curse

“The single biggest driver [for link monitoring technology] in the U.S. market has been reciprocal compensation on Internet traffic,” says Belcher. “It’s perhaps as much as a $1 billion issue. From the RBOCs I’ve spoken to, this is getting CEO-level interest. If they get a system in, first they can tell the FCC how much they’re losing. Then, if the regulations change, they can do something about it.”

HP has designed a link monitor-based application, as part of its Business Intelligence suite, that stores ISP dial-up numbers and tracks traffic bound for the Internet. Because of the nature of SS7 messages, tapping into them would enable the ILEC to see exactly where this traffic came from, where it’s flowing and how it affects the overall network. Though an end office switch could be programmed to detect ISP numbers as well, its more costly to reprogram switches and collect all of this data from multiple sources as opposed to tapping into the ubiquitous signaling network. As well, end office switches can’t see or record the call end to end. The SS7 network provides an overhead view of the call and every piece of a network it touches. If LECs are ever permitted to bill for this traffic, link monitoring applications can also produce what HP calls “enhanced” call detail records (CDRs) that can be delivered in standard formats such as AMA (see “SS7-based vs. Switch-based CDRs).

Keeping an Eye on Your Neighbor

Another major issue to which link monitors are being applied is interconnect billing, both between ILECs and CLECs, and between LECs and IXCs. Link monitors are being used as the mediation engines for interconnect billing in general, tracking all calls-originating, terminating or transient-on a LEC’s network.

Interconnect is an area fraught with expense, inaccuracy and alleged dishonesty, according to Belcher, so sending bills isn’t the only application for link monitors. A major problem is that the company paying the bill usually has to rely on the company sending the bill to report how much is owed. The paying company often doesn’t have a means for tracking any of its interconnect data. It doesn’t know how much traffic crossed its network on the way to another one, so it has no choice but to trust the interconnect partner and pay the bill. SS7 link monitors are being deployed to track just this sort of usage and insure that interconnect partners are billing correctly (see “Using SS7 for Jurisdictional Reporting of Interconnection Traffic,” Billing World, May 1998). “What we’ve discovered [in tests with RBOCs] in almost every case we’ve measured is that the IXCs numbers are on the hopeful side to the extremely inaccurate, with several percentage points difference in the IXC’s favor. We’ve never yet seen a case where the numbers were in the RBOC’s favor,” says Belcher. Link monitors are also playing a role in reciprocal compensation for voice traffic between CLECs and ILECs (see “CLECs Turn to Automated Reconciliation Systems to Keep Tabs on Billing,” Billing World, May 1999).

Closing Loopholes

Belcher points out that interconnect billing can become even more complicated when carriers begin abusing loopholes in various interconnection agreements. “ ‘Arbitrage’ is the expression that’s often used to describe how, at an interconnection point, some of the newer carriers have been creative in taking advantage of the contracts,” explains Belcher. “One of the things that’s semi-legal, but clearly undesirable, is that some carriers, rather than terminating traffic directly into another, pass it through a third or fourth party before coming back into the main carrier. What they’re doing is looking for another carrier, perhaps even wireless, that has a more attractive settlement agreement with the terminating party, hence bypassing the traditional route and saving a few fractions of a cent per minute.” Switches usually track originating traffic only, so they can’t determine where exactly a call came from. The SS7 network would know, however, so service providers are using link monitors to track where calls are flowing and which loopholes the “arbitrageurs” are abusing. By identifying them, the LEC can then close them down when contracts are renegotiated.

Link Monitoring’s Future

It’s generally agreed that as hybrid networks emerge, packet network technologies will need to tap into SS7 functionality. Voice-over-IP gateways, for example, need SS7 connectivity to enable single-stage dialing and intelligent network service delivery. Standards are being developed to create interoperability between SS7 and IP networks (see “Telecom Needs a Bridge,” Billing World, November 1998). As more and more interconnect arrangements are made across network technologies, SS7 will control the exchanges, which means it will remain a source for interconnect data.

SS7 won’t always be part of the picture, however. In many cases networks are, for example, pure ATM from end to end. ATM networks don’t use SS7, but ATM network operators would like to the see the kinds of applications SS7 link monitors enable. Belcher says HP is working to develop link monitoring-type technology for ATM and IP networks that can also integrate with SS7 link monitors to provide a singular view of a hybrid network. He also says that there is more and more of a demand for such technology as service level agreements become more prevalent and sophisticated. He says that as high-bandwidth services are rolled out, service providers will want to know more from their ATM switches than the fact that cells are flowing through okay.

“Typically what they do is monitor the cell level,” says Belcher. “They may be able to say that everything is fine, but they may not be able to see down inside the Internet protocol. Because of line noise and other factors, there are thousands of retransmissions going on. As for the true throughput of data, most of the cells are basically empty, they’ve just got retransmission data in them. You really need to say what the true throughput is that the customer’s getting.” Though HP has not yet announced any specific new product in this area, such technology would allow automated systems to check end-to-end QoS for specific applications and compare it against an SLA. Most SLAs today are based on generic network statistics, not data pertinent to specific users or applications.

SS7-based vs. Switch-based CDRs

The following chart compares the information and “enhanced” data in an SS7-based CDR with the information in a traditional switch-based CDR. The general advantage, particularly for interconnect billing, is the end-to-end call data the SS7 network naturally tracks versus the origination-centric view from a switch.

SS7 Call Detail Records Switch-based data

Data collection is independent of the switches. Data collection depends on the switches and may affect their operation.

Includes details on parts of the network not normally available, such as detailed calls on links to interconnecting carriers. May not include these details.

Covers the whole call, including call and transaction information provided in instances such as 1-800 or Local Number Portability (LNP) calls. Relates only parts of the information relating to the call.

Includes details on call routing, covering originating and terminating information. Does not provide call routing or terminating call information.

Includes details of every call made, including failed and unanswered calls. Does not cover statistics on failed calls.

Source: Hewlett-Packard Telecommunications Systems Division