The prepaid market is expected to drive significant revenue over the next five years. According to Gartner Group estimates, revenue is expected to grow from $1.3 billion in 1999 to $14.2 billion by 2004. However, prepaid services are among the most difficult to conquer in terms of AAA—authentication, authorization and accounting—and these requirements are only going to become more complex. If these issues are not resolved, growth expectations could be hampered.
In mobile IP and telephony, the ability to implement AAA for prepaid users entering networks will be complicated. The ability to prerate users and examine account balances in real time will require close integration between billing systems and networks.
In the past, AAA has not been problematic in flat-fee or postpaid environments. For example, with an unlimited-usage flat fee, billing systems provision services to AAA servers, and generally there is no other interaction needed, except to send usage information for generating reports. With postpaid services, supervision is necessary, and accounting is done in real time to support credit limits.
However, with prepaid services, whether for VoIP, traditional calling cards or wireless, the challenge lies in the fact that AAA servers need information about account balances, data types and time allotments. For these services, there are very real problems tearing down calls and doing intercepts with IVRs.
“In an environment with real-time rating, you have to worry about verifying not only who the user is, but what services they can access, what types of data, what credit limits they have, and how they can refresh those limits in real time. And then you have to worry about how to make sure to get compensated properly when they are roaming into other networks,” says Balaji Pitchaikani, vice president of engineering at Apogee Networks. “Authentication, authorization and accounting of the user will be so much more important in prepaid.”
He notes that service providers run into problems when their subscribers want to run multiple call sessions on the same prepaid account. “They can’t track the drainage on the account, which is why most service providers restrict use,” he explains. Additionally, there are concerns about handling taxes and tariffs in real time.
Expectations and Limitations
Unfortunately, most of the AAA servers in today’s billing systems merely send messages to access devices; they don’t store enough data. “Theoretically, if a subscriber is warned of time limitations at the inception of a session, he or she should be able to dynamically change that. But that is difficult today, since there are no unsolicited messages between access servers and AAA servers,” says Richard Perlman, AAA product manager at Lucent Technologies. Its products include NavisRadius, an AAA server designed to enable service providers to track network events, as well as provide a complex scripting engine.
Part of the problem is that most solutions are still based on RADIUS (remote authentication dial-in user service). While RADIUS is deployed in every ISP and dial-up provider, the need for end-to-end security cannot be satisfied by RADIUS.
“Billing vendors are realizing traditional RADIUS implementations aren’t going to cut it,” says Pitchaikani. He notes that RADIUS originally was designed for use among NAS (network access server) and RADIUS server vendors since the early 1990s, when access servers supported less than 100 ports. Today, these same access routers support many tens of thousands of ports. “What RADIUS manages to do is keep a record of what subscriber accessed what service,” notes Malcolm Lewis, head of mobile software for billing with Lucent Technologies. “The problem is you still don’t know if they actually used the service or when.” This, he says, is important if operators offer movie previews or download services. “You need to know which clip they looked at. You need something on the network to monitor the packets.”
“The limitations of RADIUS come from the fact you cannot tell the NAS when time will run out. Predictions can be made with one session, but not two because of the complex mathematics,” notes Perlman. “With RADIUS, you can try to authenticate again after you refresh your minutes, and the server can try to reauthenticate you, but many vendors don’t implement that capability.”
With RADIUS, service providers need SNMP, but that makes things difficult in a multivendor environment. “Not many operators buy all their access servers from the same company,” adds Perlman.
The expectation, however, is that with DIAMETER—which has a separate IETF request for comment (RFC) focusing on IP mobile extensions--there is space for unsolicited messaging. However, this is not to say DIAMETER lends itself to prepaid models. While DIAMETER is being designed to resolve certain next-generation issues with a richer set of instructions used by the AAA server and access devices, it still has limitations. “It still doesn’t define or discuss what transpires within an AAA server,” contends Perlman.
Whether that will be resolved in its framework document and Internet draft for roaming operations for mobile IP is yet to be seen. Early in March, four implementations testing the basic protocol and mobile IP extensions and accounting took place during a “Connectathon”; however, no companies have implemented DIAMETER, nor do any network access servers support it.
Regardless, there will be momentum. “Now that wireless networks are beginning to take off, we want a peer-to-peer protocol like DIAMETER, not a client/server one like RADIUS,” says Basavaraj Patil, network architect with Nokia. “We will continue to work with Nortel, Lucent and other manufacturers, as well as 3GPP and 3GPP2, to incorporate DIAMETER into our offerings.” He predicts a base specification will be completed by mid-July.
Pat C. Calhoun, the principal designer, coordinator and editor of DIAMETER, notes the protocols are in “bug-fixing” mode: “No more features are going into the protocol; new requirements are shut off.” He expects to distribute the document for final comments in July.
Take Control
Operators traditionally get AAA functionality by tying into AAA servers through their billing systems. All billing systems have to support AAA servers, so they usually have APIs that talk in CORBA or COM to AAA vendors and equipment manufacturers.
“We have three types of ‘competitors’ in terms of AAA,” notes Thomas Pedersen, senior vice president for product management and marketing at Digiquant, which provides IP services and applications based on IP networks. He cites pure AAA vendors like Bridgewater and Funk; equipment manufactures like Cisco, Nortel and Lucent; and IP billing vendors.
In terms of delivering AAA functionality over service activation, billing, mediation, rating and customer care, Digiquant is forming some working relationships, particularly Cisco, who also has a stake in the company. In addition to its work with Cisco, Digiquant is working to integrate to gateways for Ericsson, Nokia and Lucent. Pedersen believes partnerships are key, “specialized AAA vendors and equipment manufacturers have limitations in handling the complexities, particularly the challenges of prepaid, because they default back to standard billing systems.” He believes independent vendors that integrate AAA with their billing systems will have the marketplace advantage. Hardware vendors, who do just basic authentication, “don’t have the scalable AAA functionality, since they usually focus on their own hardware.” He says it is the independent vendors that package solutions to include APIs to all the main players will be important.
Regardless of whose AAA server an IP biller uses, it is the billing system that ultimately enables the service providers to see what time is left, buy new time, prepare an itemized bill and send it out to subscribers, and even provide methods for resolving disputes about QoS or services provided. But it is the AAA server, says Lucent’s Perlman, that has to notify the access server when a session should end and communicate that to a database, which then clicks off the time. “It is imperative that the service providers make sure their billing software manages what happens inside the AAA server. That is key,” he says.
Marrying Real-Time and Batch Processing
In prepaid environments today, AAA is used primarily for VoIP. As VoIP becomes more prevalent, companies will no longer be able to circumvent regulation. “A VoIP call can typically generate more than 12 records. Therefore, with some billers, you might have to generate 24 records for each event if you calculate local, state, national or international taxes in real time,” says Ander Garmendia, senior marketing manager within Daleen.
“Companies will eventually have a tremendous problem, in that they will have to rate in real time, but apply taxes and tariffs in batch mode,” adds Scott Mellett, senior marketing manager at Daleen Technologies. “Trust me, you don’t want to provision or bill for that in real time, because it will bog down systems. You have to be able to do batch and real-time processing simultaneously for the same call.”
Digiquant, which integrates AccessRegister from Cisco, claims to have built real-time interfaces to four elements: mediation, rating, billing and customer care. “You need all four if offering OSS to BSS. Vendors in each area have to build real-time interfaces and two-way touch points to have end-to-end, real-time transactions,” says Pedersen. “It used to be you were happy to have two Oracle environments talking within a week; that is going to change drastically. In the new economy, whenever it comes, we’ll see the day when every business operation is treated from inception to final storage on a database as a single transaction in real time.”
Scalability and Flexibility
For providers that are moving ahead with softswitch technology implementations, there will be issues of scalability and throughput, particularly as they move toward prepaid VoIP. To get there, scalability and flexibility will be major hurdles for service providers. “Traffic in billing systems can grow by a factor of five when you turn on SMS, because of faster links. It will increase exponentially, so rather than a few thousand authentications per second, you may have 10,000,” adds Pedersen.
Service providers should anticipate that every subscriber will have many services, so when calculating scalability, they should count services, not just subscribers. A database of 25 million users might really end up being a database of 250 million subscribers.”
Pedersen says Digiquant, for one, was recently benchmarked in a Paris lab as handling 3,000 prepaid calls per second. “If a company claims to do 68 million ratings a day, don’t get blown away. Read the fine print. Most likely, they do 68 million RADIUS authentications, and on something like an HP 16 processor machine,” says Apogee’s Pitchaikani. He claims Apogee, for one, can scale up to 400 transactions per second per CPU (to 64 million). The company has been certified by independent research firm, Progressive Strategies, to perform consistently beyond 400 rated transactions per second per CPU. That adds up to 1,600 rated transactions on a Quad CPU machine (34.5 million rated transactions per CPU, which translated to 168 million rated transactions per day on a Quad CPU machine). “We scale linearly, and when we say ‘rated transactions,’ we mean assigning dollar value to the usage, as opposed to others, who use RADIUS authentication numbers for performance numbers,” adds Pitchaikani. He says that those numbers demonstrate the level of scalability that soon will be needed. Additionally, revenue assurance for auditing and reconciliation will be a key factor for billing systems. “With PrePaid scenarios discrete events become key for recording and auditing prepaid authorizations and usage events,” adds Pitchaikani.
Another factor will be data storage. Billing systems will have to have archives for usage and billing information for data warehousing and mining purposes in standard high availability databases. “Companies will have to have that if they are to analyze information with standard OLAP tools.” For that reason, most billers solutions will have to leverage common LDAP, UNIX, SQL, and NIS/NIS databases. Many are embarking on partnering with the larger ERP and database players. “Because of anticipated storage needs, we are partnering with Oracle and Microsoft,” notes Pitchaikani. The reverse is also happening, with companies like Oracle and SAP getting into the billing space, although they are not yet emphasizing that.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article