Ask anyone in telecommunications and you will be told that the IP multimedia subsystem (IMS) architecture represents the future of telecom. The IMS architecture finally paves the way for true telecom convergence because it decouples the subscriber management layer from specific network elements. The same subscriber profile, application profile and policy servers that are applied to a cable network, for example, can also be applied to DSL, Wi-Fi, WiMAX or cellular networks.

The IMS model also takes the concept of subscriber management to a new level by allowing subscribers to be managed based on pre-set policies via the home subscriber server (HSS). The HSS applies policies to subscriber profiles to support many functions, including authorization, service provisioning and billing.

Fortunately for wireless operators, many wireless network architectures already have a network element that handles this functionality--their authentication, authorization and accounting (AAA) system. And in many cases wireless operators can upgrade their existing AAAs to deliver the functionality required to support IMS applications while still supporting existing networks and applications--without investing in a completely new network element such as an HSS.

However, wireless operators be warned: Not all upgrade paths are alike. Some upgrade paths leave network operators with the same "silo-like" view of the network that they have today and without the benefits of a unified view of the subscriber and policies. In other words, some AAA upgrades still require the network to query multiple databases in numerous places to get a clear view of network activity and require multiple application programming interfaces to be developed for each application. This not only adds complexity, it also adds cost in the form of an estimated $200,000 in development and operational costs for each application delivered to customers.

A complete upgrade to the existing AAA system will provide specific capabilities within the following key HSS functional requirements: policy database functionality, a subscriber data store, a session state register and service control/application authorization. The upgrade paths and required capabilities are discussed below.

Making the rules: The policy database
The policy database contains the rules that define how a subscriber is allowed to interact with the network and also defines the IMS framework that runs the applications that a subscriber currently is using. For example, a policy rule based on network interaction might state that Subscriber A is allowed to use a public Wi-Fi connection between the hours of 7:00 am and 6:00 pm.

IMS-defined functionality takes policy management one step further, allowing policies to be defined based on specific applications. For instance, a teenage subscriber might be allowed to connect to use Instant Messaging, voice calling and video calling services anytime, but he can only use his mobile TV application between 6:00 pm and 10:00 pm (when he is not in school).

The policy database supports the allocation and use of bandwidth and quality of services (QOS). For instance, if a network only has the bandwidth to support a certain number of video connections, policies can be set that give gold Subscriber A's video connection priority over standard Subscriber B's connection.

From a high level functional view, the upgrade to an AAA requires upgrades to all of the key areas. The policy database needs to be extended with new policies relating to bandwidth, QOS and media types. The subscriber data store needs information used during the authentication of the subscriber, including rights and application profile information. A state management database must also be added to hold information on which IMS components the subscriber is using and the associated policy decisions. IMS applications need to be able to store information on the subscriber and this is held in the HSS or IMS AAA function. Therefore, the AAA must be upgraded to support the storage of large volumes of data. Since many AAA systems do not have integral databases, this can be a challenge. In non-functional terms, the AAA needs to be able to scale to very large numbers with subscribers in excess of 50,000,000 for large networks and transaction rates in the 1000s per second.

The new, upgraded policy database must have the ability to support a wide range of rules, including those based on time of day, week, application, bandwidth, etc. The number of policies directly relates to how flexible and fast service providers can be when offering new applications to subscribers. Wider range of policies, then, allows for higher revenue generation. Given the importance of policies and the effect they have on subscribers, policies should be tested prior to deployment to ensure that the customer experience is as expected.

Defining your customer: The subscriber data store
The subscriber data store contains the required information about the subscriber. In some cases, the demarcation line between the policy database functionality and the subscriber data store is somewhat blurred. For instance, one of the "policies" given as an example above--the policy that states that Subscriber A is allowed to use a public Wi-Fi connection between the hours of 7:00 am and 6:00 pm--is driven from the subscriber's definition which states the individual time limits. In this case, the subscriber would be defined as a customer with a start time of 7:00 am and an end time of 6:00 pm.

Particularly in a converged networking environment, where one service provider and one database covers customers that buy a range of services, the subscriber data store must have the ability to scale to an extremely large number of subscribers--preferably several thousand provisioned users to more than 50 million.

The optimal subscriber data store is one that is organized hierarchically instead of simply in groupings (see diagram). A hierarchical structure allows new policies to be entered only once, and they are automatically filtered down into subgroups. In contrast, a non-hierarchical system requires that new subscriber data be entered for each subscriber, requiring considerably more time and higher provisioning costs. For example, a service provider wants to launch a new service to 5000 subscribers in one enterprise customer. In many systems, this would require 5000 provisioning actions, which take time and cost money. Each provisioning action requires the delivery and storage of a 4KB data block. This means a total of 20,000KB of data must be transmitted from the provisioning system to the AAA and stored in the subscriber data store. In a hierarchical system, then, this can be achieved by a single provisioning action using 4KB of data and significantly reducing time and cost. (The wireless operator or subscriber can override the data at the individual level if necessary to provide a truly individual experience.)

Keeping it real-time: The session database
While the subscriber data store holds information that only changes infrequently, the session database is responsible for holding real-time session data, in particular the user's IP address and what network and IMS elements are holding the session for a subscriber. For instance, the information collected by the session state register allows a user to be removed from the network if his or her payment account is empty, such as with pre-paid applications.

Session state information is particularly important with IMS applications because IMS allows users to change media in the midst of a session, such as changing from a video call, which might require 256K of bandwidth, to a voice call, which might require only 32K. The network must recognize this to optimize network bandwidth usage and record the decision to enable features such as call access control and bandwidth management.

In order to support these new capabilities, wireless carriers must add the ability to store real-time data to their AAA systems. A superior session state register supports full data replication, redundancy and the ability to support high transaction rates.

Maintaining service control and authorizing applications
Controlling services involves implementing policy rules based on the subscriber data. In other words, it involves controlling a subscriber's access to the network or to particular applications, and ensuring that subscribers are whom they say they are and are authorized to access the applications they are trying to use.

Prior to IMS, service control involved simply authorizing a user to connect to the network. However, with IMS, controlling services becomes a bit more complex. Once a user connects, that subscriber's usage plan may restrict his or her access to certain applications or services. As a result, controlling IMS applications requires adding a new interface to the existing AAA, as well as significantly increasing the processing power of the AAA so that it can support in excess of 1 billion transactions per month.

The need to upgrade quickly
Already, new services are putting a strain on some wireless operators' current AAA systems, particularly given that the introduction of new services can cause traffic growth of up to 400% in just a matter of days.

Consider this example: One North American operator's AAA system was taxed soon after the introduction of multimedia messaging services (MMS) and push-to-talk services (PTT), simply because the AAA system could no longer support the increased network load.

The solution? In the short term, the wireless operator upgraded its AAA (using the same hardware) to allow it to scale between five and eight times more than the existing system and to support more complex policy-based processing. This allowed the operator to ensure that usage spikes would not affect the ability of subscribers to gain access to services.

The bottom line is that existing AAA systems can deliver the functionality needed to support IMS, if they are upgraded properly. Using an established wireless network AAA provides the foundation for an elegant, standards-based evolution into an IMS-defined HSS role, while reducing risk and cost to service providers.

Mark Denton is product manager for wireless at Bridgewater Systems.

Visit Bridgewater Systems online.