[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Overview of IMS AAA Server AAA Functions

Authentication

Authentication in the IMS AAA Server is performed using either of the following methods:

Authentication requests are transported using either the RADIUS or Diameter protocol. The clients for these authentications are Diameter or RADIUS equipment providing network access, as well as Packet Data Gateways (PDGs) which initiate authentication when the subscriber sends a tunnel creation request. The attributes used for EAP-SIM or EAP-AKA authentication are retrieved from an HSS via Diameter Wx, or from an HLR (Home Location Register) via Diameter to RADIUS proxy to SBR SIM Server (requires the Juniper Networks SBR SIM server).

The authentication and transport encoding is entirely standards-based. Hence, the IMS AAA Server supports clients developed for previously existing EAP-SIM deployments, such as the Juniper Networks Odyssey Access Client or other standards-compliant clients connecting to a standards-compliant 802.1x access point. In this manner, the IMS AAA Server meets the WLAN 3GPP Interworking goal of supporting existing network deployments.

Authorization

Authorization requests are issued by either the WLAN access device or the Packet Data Gateways (PDG).

RADIUS or Diameter-based WLANs request authorization of network access for the WLAN UE. This authorization is typically performed together with the authentication, and takes the form of authorization attribute value pairs (AVPs) returned with the RADIUS Access-Accept packet. For Diameter, a Diameter-EAP-Answer message would be returned with the Result-Code set to DIAMETER_SUCCESS. This message would also include the appropriate authorization AVPs required for the service requested.

A PDG requests authorization separately from the authentication request. For example, the WLAN UE might initiate a tunnel towards the PDG, which results in an authentication and tunnel establishment. If the same WLAN UE requests an additional tunnel in the same session, authentication need not be performed. Instead, the additional tunnel will be granted without full authentication being required. The PDG can request authorization of W-APNs in subsequent authorization requests.

The primary profile data used for these policy decisions is downloaded from the HSS, however the IMS AAA Server also supports local policy storage (seeLocal IMS Policy48).

Accounting

Both online charging and offline charging functionality is defined in 3GPP TS 23.234. This implementation of the IMS AAA Server supports the offline charging functionality, implemented by a Diameter interface carrying charging events towards the Charging Data Function (CDF). It is the CDF that has the responsibility of integrating these charging events into Charging Data Records (CDRs.)

Accounting information is generated and reported for Direct IP Access and for the tunnels used in WLAN 3GPP IP Access.

The WLAN AN is responsible for generating and reporting WLAN access usage to the appropriate 3GPP system (for example, the visited network in the roaming case and home network in the non-roaming case).

A WLAN AN can issue an Accounting-Request whenever it chooses, for example upon establishing a successful connection. Each time an Accounting-Request message arrives at the IMS AAA Server, an accounting transaction begins. During this transaction, the server handles the message by examining the Acct-Status-Type and other attributes within the message, and taking the appropriate action.

For WLAN Direct IP Access in the HPLMN, the IMS AAA Server reports (accounting) charging data to the home Offline Charging System. For WLAN Direct IP Access in a roaming situation, you can configure the routing of charging data using the Explicit routing feature of the IMS AAA Server. Using this feature you can route the charging data to either the visited network's CDF, or to the downstream CDF in the subscribers home network.

NOTE: Accounting requests from a RADIUS-based WLAN AN are always converted to Diameter since the CDF is Diameter based.


Proxy Routing

The functionality of the 3GPP AAA Proxy server described in 3GPP TS 23.234 is integrated into the IMS AAA Server. This functionality includes routing of all RADIUS and Diameter protocols by realm name and, when necessary, performing RADIUS-to-Diameter and Diameter-to-RADIUS proxy translation.

This enables all possible roaming scenarios, which place the PDG and/or WLAN access equipment in a visited network, to be supported. The IMS AAA Server can also expend profile information to specify which roaming scenarios are permitted for a particular subscriber.

The proxy functionality with protocol translation also permits the IMS AAA Server to proxy Diameter Wm requests to RADIUS Wm, enabling them to be authenticated on an HLR, making use of Juniper's SBR SIM server product. This is useful in implementing an IMS network where there is no HSS present yet.

Proxy routing is applicable to authentication and authorization messages only. Protocol translation for initial authentication and authorization requests is straight-forward. The same is not true for dynamic changes in authorization. While Diameter intrinsically supports changes in authorization and session termination, RADIUS dynamic authorization requires additional logic to route requests back to the correct device. The IMS AAA Server supports generation of RADIUS disconnect messages (DM) towards RADIUS WLAN devices or Proxy servers. The proxy-capable IMS AAA Server will perform request routing both towards the access devices and towards any downstream servers (such as network elements in the home network.)

For a complete description of how the IMS AAA Server processes CoA/DM, see RADIUS Change of Authorization/Disconnect Messages.


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]