Possible Network Configurations

At least in theory, there are multiple possible network configuration scenarios. In one scenario, the GGSN interfaces with a single AAA server, which then is programmed to proxy toward RADIUS authentication servers, accounting servers, and application servers. This offloads to the AAA proxy server the complexity of interacting with all the other subsystems, but it also adds flexibility, since the AAA proxy server may be a programmable platform, with much more storage and cheaper computing power than the GGSN.

In another scenario, the GGSN directly interfaces to one authentication server, one accounting server, and one application server. This adds load to the GGSN in that it has to interact with multiple entities and keep state and resources adequate for this purpose. In another scenario, the GGSN interfaces only to an application server, if the wireless access authentication is sufficient (i.e., IMSI-based authentication taking place at network attach time) and no extra level of authentication is necessary for gaining access to the network where the application server is. This is typically the case with WAP applications, where time-based charging was used or data-volume usage data was collected via the Ga interface.

Yet one can imagine having the GGSN interact with an authentication server as well, if an additional level of authentication is deemed necessary. Note, however, that the use of RADIUS accounting to deliver volume or time-based usage is not strictly necessary if the information contained in GTP'-based [3GPP TS32.015] accounting is used. However, RADIUS-based accounting may prove to be necessary when the network where application servers are hosted belongs to a third party that requires usage data be delivered in RADIUS format. Because of all these possible scenarios, a GGSN should come with the ability to configure separate accounting and authentication servers, and possibly an additional RADIUS accounting interface to an application server.