In the standardization of 3GPP (Third Generation Partnership Project) there is on going work to standardize user authentication routines, especially for the so called Generic Authentication Architecture (GAA) involving a mutual authentication between a client and an application server. In the communication network several different applications will be available for the client and these applications will be supplied by third party suppliers, i.e. different from the Service Provider (SP). However, a client accessing several different applications would like to make only one single authentication, a so called Single Sign On (SSO) service, providing the possibility for the user to only authenticate once during a session, rather than to authenticate to each new application server it wants to use. This will make the authentication procedure much easier for the client. Also this kind of authentication service can be offered to third party application service providers as a service from the Service Provider handling the network. The GAA is aiming for solving this problem and making such a service available in the 3GPP network. The generic authentication provides an authentication of the users on an application level based on the proven security mechanism in the Public Land Mobile Network (PLMN).
The GAA is specified through the 3GPP group and drafts of the specification may be obtained through their web site, for instance the documents TS 32.220 and TR 33.919 maybe mentioned as good starting points regarding GAA. The GAA system may be explained as follows: A number of applications share a need for mutual authentication between a client/user (called UE, User Equipment, in the standard) and an Application Server (AS) in order to allow for further communication. This is necessary when the user wants to access servers demanding authentication, e.g. content servers charging for their services, certificate demanding web sites (e.g. banks), and similar application servers. Since many applications share the same need, it has been considered to specify a Generic Authentication Architecture (GAA), providing the architecture for allowing application servers access to the infrastructure authentication systems. Thus, if the application server trusts the service provider, this architecture may simplify the authentication schemes both for the user and for the application servers. The user needs only to authenticate once during a session, rather than authenticating towards every application server accessed.
In a GAA based session the user authenticates with the network infrastructure by providing an ID to a Bootstrap Function (BSF), this ID may for instance consist of the UE IMSI number (International Mobile Subscriber Identifier), which is a unique number coupled identifying a user. The IMSI is relayed to the Home Subscriber System (HSS, also called Home location register system) and the HSS provides an Authentication Vector (AV) to the BSF. The BSF authenticates the UE based on the USIM (Universal Subscriber Identity Module) and the UMTS-AKA methods, and sends a TID (Transaction Identifier) to the UE.
Also at the same time, work is on going to standardize so called Flow Based Charging (FBC). FBC has the aim to make it possible to charge users for service usage on a finer granularity than what is possible today. For instance it is of interest to identify the type of IP session that a user is running, the type of applications involved and so on. For instance one would like to be able to differentiate the charging costs for different types of services, e.g. streaming video may be charged more than exchanging plain text messages like simple email messages. There are many different services that may be used including both user to user and user to network services. Service data flows from these services may be identified and charged in many different ways. The FBC method is used to set up charging filters that is used by the CRF (Charging Rules Function) for different applications.
The filters provided in the FBC method can be quite complex and may involve source and destination address, source and destination port number, and transaction protocol, enabling a fine granularity of charging. Charging models requiring even more complex data may use special filters that look further into data packets and may be defined by the TPF (Traffic Plane Function) and invoked by the CRF.
However, the above-mentioned two standardization works are not today aiming for an integration of the services they provide. This will in the future be crucial in order to be able to provide differentiated charging rules depending on the user and application connected to and at the same time ensuring the authenticity of the user towards the specific application server involved in the transaction. It should not be possible to, by only providing a fake IP number, getting access to services intended for other users or obtaining services at a wrong charging rate.
The work in 3GPP on GAA and FBC has been so far performed in parallel, and there is no concern taken to reuse functionality between the two functions. At some stage in standardization, interoperability between GAA and FBC needs to be built in. An integrated architecture will be necessary.
Specifically, the problem of supporting user specific charging for GAA authenticated users is not solved in FBC. The problem may be exemplified as follows:                1. A service provider has an application server providing a service, e.g. downloading a music file. This service is accessible for mobile users via the GPRS access network on the Gi interface. GAA ensures that the user is authenticated.        2. When the user downloads a music clip, he is charged by volume because the GGSN performs byte counting on the packets downloaded, and reports CDRs to the billing system. FBC can be used to enable that a specific rating is applied to the downloaded music file. FBC provides filtering in the GGSN that counts the specified service individually.        3. Now, the service provider might at some point provide the service for a special price for some users. In that case, it is needed to provide a specific filter for individual users. How that can be done is not specified today.        
In another standardization implementation, work is on going regarding policy decision functions such as the PDF (Policy Decision Function) for policy control of IP bearer resources, such as Quality of Service (QoS) for a specific user. Policy Decision Function relates a level of Quality of Service to a specific user and instant in time, enabling for instance a better Quality of Service for a certain type of application such as streaming video applications, or for a customer prepared to pay more for a higher quality of connectivity. It would be efficient to incorporate the PDF function with the GAA function in order to implement a more efficient network system.