Almost everywhere you look today, IP services are all the rage. Billing and mediation vendors are building convergent solutions in earnest, and service providers are touting their ability to deliver various types of traffic over IP and accurately bill for them. Yet even with this move toward an IP-based infrastructure, traditional high-speed network service offerings aren’t going away anytime soon.
Frame relay and ATM backbones have been the workhorses of wide-area networking for several years, and both are still heavily in demand and heavily in use, by carriers and large enterprises alike. However, billing for them can pose its own set of unique challenges. Some of these include collecting detail information, aggregating it and sending it to a billing system. Other concerns include how to factor in quality of service, type of circuit, port size and any number of other variables a customer might encounter when using one of these services.
Currently, most of the new development in usage-based billing is occurring in the IP world. Hard work is being done by the IPDR organization (www.ipdr.org) to create a record format for IP services; and both billing and mediation systems that can support usage-based billing for IP have been coming out in droves.
But frame relay and ATM billing needs are hardly being left in the cold. Although many of the services involving these two technologies are still billed for on a flat monthly rate, things are starting to change.
FRAME RELAY AND ATM BASICS
Both frame relay and ATM are connection-oriented technologies, in which permanent virtual circuits (PVCs) are established between customer sites or an ISP via a provider’s switch. These connections, as the name suggests, are available at all times. IP, on the other hand, is a connectionless protocol. With IP, there is not necessarily a dedicated path between customer sites, delivery is not guaranteed, and routers are required to get traffic from one point to another.
While frame relay and ATM have similarities, including the use of PVCs and their ability to move IP packets, they also have several differences. These include packet size: frame relay can carry variable-length IP packets, while ATM breaks IP packets up into 53-byte segments called cells. Frame relay service is also generally viewed at less expensive and easier to manage. Another key difference is bandwidth. While a frame relay port can operate up to T-1 rates, ATM tends be the choice for services operating beyond the T-1/E-1 rate, putting it out of reach for companies that don’t need gobs of bandwidth today or have fiber access into their building.
THE BILLING BASICS
For both frame relay and ATM, customers are typically large enterprises. Carriers usually present them with detailed and customized recommendations, such as the port and PVC size required, the type of customer premises equipment needed, and the quality of service level that makes the most sense.
Even the very first step of order entry into a provider’s system can be complex, according to Becky Dancy, senior solutions consultant at Intertech. “When you look at ATM and frame relay, there are just so many attributes that can determine price,” she says. “With long-distance voice calling, you have time of day, origin and destination; with frame relay and ATM you have bandwidth, port size and local loop access, for example.”
Dancy says that order entry for these services is complicated because of the data entry required. She adds that it’s crucial that a billing system be able to know when service has been activated so that charges can begin incurring. Carriers that have flow-through provisioning and closely linked order management and billing systems should be able to accurately track, define and rate the particulars of orders.
Once service has been provisioned, most carriers will assess customers a one-time charge for installation and setting up the connection. Then, providers will add recurring charges (usually monthly) that include the lease for the CPE, port and PVC, local loop access, and class of service. The port is generally a switch add-on at the company site where the connection terminates. The PVC is the actual medium over which packets flow. The local loop charge is for ILEC or CLEC access.
Class of service depends on which technology you use. In broad terms, ATM has several different service levels. Constant bit rate (CBR) service supports a guaranteed rate, making it ideal for real-time, delay-sensitive traffic such as voice or video. Variable bit rate (VBR) service, which doesn’t have the same QoS requirements as CBR, make it a good choice when latency is not an issue. VBR can be ideal for services like file and data transfer applications. Unspecified bit rate (UBR) service does not usually include service guarantees, including cell loss ratio or cell transfer delay. It is also not well supported by carriers.
On the frame relay side, the term “committed information rate” (CIR) is associated with service level agreements. The CIR is the information transfer rate (generally measured in kilobits per second) that a frame relay network carrier commits to deliver under normal circumstances. Note that the carrier can take the sum of all customer CIRs between frame relay switches and make sure enough bandwidth has been provisioned.
All of these variables need to be taken into account from a billing perspective, since each parameter will be priced differently. “After the initial cost of installation, monthly recurring costs include lease for the equipment, port and PVC,” says Judy Porter, director of application development at Sprint. “There could be multiple recurrent costs, depending on the product.”
Also, the bill presented to the customer can contain a number of details, since frame relay and ATM services are both defined by many attributes. “Some customers want to see the circuit ID, and others want to see port ID or local loops listed by node on their bills,” says Dancy. “Carriers have to be able to show this information on the invoice, otherwise the customer can’t make heads or tails of what they are being billed for.” Porter says that with Sprint high-speed services, invoices are very customized. “It’s based on what was negotiated, what’s in the contract and what the customer wants. How we bill these customers is very individualized,” she says.
BEYOND FLAT-RATE
Providers of ATM and frame relay services have not been proactive when it comes to usage-based billing. This is largely due to factors such as not being able to capture usage information, or having a legacy billing system that can’t support usage-based billing. Note that frame relay and ATM are at layer 2 of the OSI model, where addresses don’t have global significance, whereas IP is at layer 3, where addresses have global significance and can be used for billing, as telephone numbers are today. (See Dr. Jerry Lucas, “The Achilles Heel of ATM Service,” Billing World, May 1999.)
One reason usage-based billing for frame relay and ATM isn’t as far along as it might be can also pertain to the IP world. “Most companies have billing systems that aren’t particularly good at billing for usage,” says John Williams, director of field product management at Daleen Technologies. He adds that uncertainty and doubt may be keeping providers away from usage-based billing for the time being. “Who wants to be the first on the block to go to this?” he asks.
Although the most common method of billing for ATM and frame relay is on a recurring basis, Joshua Heimleich, senior product manager for Amdocs, says that currently he is seeing two types of usage-based billing: based on volume, or a threshold.
With volume, the number of megacells, for example, is calculated daily, and the customer is charged according to that usage. With a threshold, the carrier accumulates usage information, and if total usage goes beyond the predefined threshold, the customer pays extra.
Sprint is also billing ATM based on megacells; for frame relay, billing is based on the bit rate defined in the CIR, says Porter. She adds that while Sprint’s ION service will be offering usage-based billing for IP, currently there’s no similar plan in the works for existing frame relay and ATM services.
Another usage-based metric involves network traffic burst rate, says Williams. The ability to recognize bursts and bill for them is a feature Daleen has been developing. The idea is to capture usage information at predetermined time intervals. Part of that usage (such as the highest and lowest levels) is eliminated, and what remains is billed for. “If I go out and buy a CIR of 512 kbps, typically the contract will say that I can have sustained bursts of 150 percent to 200 percent” above the CIR, Williams says.
Problems can arise, however, if customers who are accustomed to flat-rate pricing send bursts often and disrupt other network traffic. “That kind of information should be recorded in some quality of service metric so it’s rated accordingly,” notes Williams. “I think that’s eventually where the industry has to go, but I don’t think they have the infrastructure in place to do that now.” Again, bandwidth inventory is an OSS must, particularly for real-time bandwidth on demand.
“We have set rules in terms of how much bursting is allowed on the network, and that is monitored by switch software,” says Nitin Krishna, market manager at Williams Network, whose customers include ISPs, RBOCs, CLECs and other providers. He says customers are allowed to burst up to a predetermined percentage level, which is easier to deal with in ATM because the class of service determines how much bursting can take place. Krishna adds that customers can subscribe at a particular level, and if Williams Network doesn’t live up to that, then an SLA will determine how that is reconciled with the customer.
SLA violations can be sent directly to a billing system, so a credit can be applied if a customer does not receive the service paid for, according to Steve Adams, vice president of marketing at CrossKeys. The company’s Resolve product collects data from network devices and management systems, compares the data to SLAs by customer, and when SLA thresholds are crossed sends that information directly to a billing system. However, even though this process can be automated, carriers hesitate to issue a credit automatically and still prefer manual review. So far, CrossKeys has demonstrated interoperability with billing systems from Amdocs, EHPT and Portal.
Identifying when packets and cells are dropped due to bursty traffic is important; but what is crucial is being able to make up for it to the customer. “There’s definitely a risk of customers not being able to send data traffic due to lack of bandwidth when you have flat-rate plans,” says Alison Poett, offer marketing manager at Kenan Systems. “Someone may be on the connection for a significant amount of time, and there may not be any variability of available bandwidth. If someone knows they are paying for what they use, they may monitor their usage, and that creates more available bandwidth.”
Poett believes that using monitoring tools at the network level to check traffic will better enable carriers to issue credits. She adds that providers need to make sure that once a credit is issued it actually gets recognized and picked up by the billing system. One question she raises is whether that credit is identified just after the incident occurs or only after a customer calls to complain.
Amdocs’ Heimleich says one way to deal with the inherently bursty nature of frame relay and ATM is to bill according to statistical usage. In this model, the average CIR a customer receives is evaluated, and if the average of 95 percent of the total usage is below the CIR, then the customer is charged less via credit or rebate. If the average of 95 percent of usage is above the CIR, then the customer is charged more. “This type of calculation takes into account bursts both above and below the CIR,” Heimleich says. “We ignore peaks and cut the edges so as not to be too influenced by very burstable activities.”
He adds that in packet-switched networks customers can overuse the network, so statistical billing enables a provider to see the actual average bandwidth that the customer used during the billing period.
Daleen’s Williams says that in one model customers would pay a monthly recurring charge for bandwidth, and if that’s exceeded they would start paying extra costs. Another model he mentions is tiered. “If you buy a specified bandwidth level of 512 kbps, the first 100 times you go over that we won’t charge you, but the next 1,000 times you get charged at a rate that brings you to 150 percent of your rate,” Williams says. “We’re charging them a higher rate for allowing them to have that variable bandwidth.”
Customers who occasionally need additional CIR or a higher class of service, such as for a videoconference session, have alternatives to sending bursty traffic and causing problems for others. Some plans allow for a higher service level as needed. The provider overprovisions that customer’s link for a particular period of time, preventing an excessive burst rate of traffic.
“This bandwidth-on-demand idea allows the customer to ask the provider for a higher bit rate and constant bit rate for a limited period,” Heimleich says. “The customer will have to pay a recurring charge for this bandwidth-on-demand option, and in addition they will pay according to the actual bandwidth that was provided during that period.”
Williams Network offers this service through its Flex-UNI frame relay service. Customers don’t have to be stuck with a 512 kbps PVC all the time, when their usage may fall significantly above or below this level at certain times. Instead, they can request a high CIR during the workday and a lower one for overnight hours when usage is traditionally low. “We decided to let the customer decide when they need bandwidth and when they don’t,” Krishna says. “If you needed a certain bandwidth level for a video transmission, we’d let you do that.” The customer is charged a fee each time the CIR changes.
COLLECTING DETAILS
Billing today can distinguish particular attributes of ATM and frame relay service, but in most cases it involves home-grown systems or customized packages from established billing vendors.
For frame relay and ATM traffic, detail information would typically collect on ATM switches or frame relay access devices (FRADs). From there, the information could be pulled off by a mediation platform and then sent to the billing system. “Each record that comes into the billing system from any source is recognized, and the system can tell whether it’s an IP, ATM or frame relay event,” Heimleich says. “That kind of information would need to be presented on the customer’s bill.”
Daleen’s Williams says that detailed information can be obtained from these devices. “You can have a field for packets sent and received, information about latency and jitter, and other indicators from which quality of service information can be derived,” he says. “We frankly don’t care what format the detail record is in—we can take any usage and do something with it.” Williams says that in addition to getting quality of service or bit rate information, Daleen is able to apply metrics to that information. “There’s a model where the first N percent they go over the contracted rate, or the first X number of times they go over a bit rate, it’s free. After that, we might throw out the highest 10 percent and take the next sample after that. If 90 percent of calls are up in the highest 10 percent of usage, we know they were using the bandwidth basically all month.” Williams suspects that once service providers are able to bill for very granular usage, it may influence behavior so customers are not hogging a link 24 hours a day.
Sprint uses an internal system of collectors to pull information from ATM switches and FRADs, Porter says. “We can pull an amazing amount of detail off the network, format it and send it to billing,” she says. Porter admits that billing for ATM and frame relay are much more complicated than traditional telephony, and today Sprint is doing a mixture of usage-based and flat-rate billing.
“From our perspective, it’s not so much a challenge for billing as it is to get data coming in,” says Kenan’s Poett. “The way we see it is that the whole point of having a packet-based network is to have a more efficient network. That means you can carry more traffic, and you should be able to charge for all that traffic. Yet what we’ve seen is that most carriers aren’t billing for usage, and so they are not necessarily taking advantage from a business perspective of all the extra capacity they have.”
She adds that the current lack of a standard for usage-based data may be part of the problem. The IPDR organization is going full-speed on this issue; the final version of its draft specification is close to completion. While it may not sound like an IPDR standard would affect ATM and frame relay, it would if carriers are running IP traffic over these high-speed technologies. When IP services are transported over ATM or frame relay, the billing model actually changes and becomes IP-oriented rather than based on the underlying transport mechanism.
“If it’s an IP event, then we consider the service as IP, and it doesn’t matter if it was transported over an ATM infrastructure, DSL, frame relay or anything else,” says Amdocs’ Heimleich. He adds that with pure ATM or frame relay traffic today, it’s not possible to get all the details that can be gathered with IP. That is also the case at Williams Network, where IP over frame relay and ATM can be billed for by usage, but pure frame relay and ATM cannot.
One billing vendor, German-based Telesens, claims its Billforce ATM product can perform usage-based billing for ATM traffic. “It’s much easier to take a CDR from an ATM switch and bill for it than to look at IP,” says Ralf Hellebrand, senior consultant at Telesens. “Looking at IP is harder, because you’re talking about something that never has an end-to-end connection and where data comes from a lot of different devices, which can cause problems like double records.”
Hellebrand says Billforce, which also has modules for IP, frame relay and DSL, receives data from the network and then converts that data into a single format. This format is a flat ASCII file. Each call or transmission is then correlated with a customer and IP address. The product then finds the tariff for that particular customer. Billforce calculates price, including discounts. Then usage processing takes place based on metrics such as whether the transmission was peak or off-peak.
Hellebrand says parameters such as class of service, going beyond the maximum burst size, and changing briefly from VBR to CBR all can be billed for via tariffs rather than tables. If-then situations can be customized, such as if a customer goes beyond the bandwidth they pay for, then they are charged extra. Or with a VBR connection, if the difference between sustained cell rate and peak cell rate is large, then the customer would be charged more.
Telesens has a significant customer for its Billforce software in Deutsche Telekom, which has been using the product since April 1999. Deutsche Telekom is billing on parameters such as class of service and bandwidth on demand. The carrier is also using Telesens’ product to bill for frame relay.
HIGH-SPEED FUTURE
Whether it’s pure ATM, frame relay or IP over one of these transports, providers should be able to migrate to a more usage-based model and bill for such features as volume of traffic and temporarily going from a VBR connection to CBR, and issue credits if traffic is delayed or a connection is incomplete.
The trend for high-speed services is leaning toward IP rather than ATM or frame relay. These high-speed transports won’t disappear; rather, they will be used as fast pipes for IP traffic. According to Amdocs’ Heimleich, “ATM and frame relay will be the infrastructure, but the trend is toward IP and the event-related or application content-related billing you can do.”