5 Wd Description

29.2343GPP3GPP system to Wireless Local Area Network (WLAN) interworkingStage 3TS

5.1 Functionality

The Wd reference point is defined between the 3GPP AAA Proxy and the 3GPP AAA Server. The description of the reference point and its functionality is given in 3GPP TS 23.234 [4].

Therefore, this reference point is used in the roaming case only.

5.2 Protocols

The Wd reference point shall use only a single AAA protocol per WLAN session. RADIUS or Diameter based protocols shall be used.

The Wd protocol reference point shall contain the following protocols:

1) RADIUS, as defined in IETF RFC 2865 [17], including the following extensions:

– IETF RFC 2869 [9], which provides RADIUS extensions to support the transport of EAP frames over RADIUS.

– IETF RFC 5580 [16], which provides RADIUS and Diameter Extensions for Public WLAN to identify uniquely the owner and location of the WLAN.

– IETF RFC 3576 [13], which provides RADIUS extensions to supports, amongst other capabilities, the capability to immediately disconnect a user from the WLAN AN.

– GSMA PRD IR.61 [25], which provides a Visited-operator-id attribute and a detailed encoding of a chargeable user identity (e.g. MSISDN or IMSI) for the RADIUS Chargeable-User-Id attribute.

– IETF RFC 4372 "Chargeable User Identity" [26], which provides RADIUS Extensions for carrying a chargeable user identity from Home PLMN to Visited PLMN.

2) Diameter Base, as defined in IETF RFC 3588 [7], as well as IETF RFC 4072 [8], which provides a Diameter application to support the transport of EAP (IETF RFC 3748 [11]) frames over Diameter, and IETF RFC5580 which provides RADIUS and Diameter Extensions for Public WLAN which are used in order to uniquely identify the owner and location of the WLAN. In addition, Diameter Base (IETF RFC 3588 [7]) and NASREQ (IETF RFC 4005 [12]) specify the accounting messaging to be exchanged. IETF RFC 5729 [36] defines the procedures related to the routing of Diameter requests when Decorated NAIs (as defined in 3GPP TS 23.003 [22]) are used.

The 3GPP AAA Proxy and the 3GPP AAA Server shall support both 1) and 2) over the Wd reference point. The 3GPP AAA Proxy, depending on the WLAN ANs characteristics, shall use either 1) or 2) over the Wd reference point. See subclause 5.3 for more information of when either 1) or 2) is used.

The Application-Id to be advertised over Wd reference point corresponds to the EAP, NASREQ or Diameter Base Protocol Application-Id, depending on the command sent over Wd.

5.3 3GPP AAA Proxy and 3GPP AAA Server behaviour when Interworking with RADIUS/Diameter WLAN ANs

If a WLAN AN attached to the 3GPP AAA Proxy is Diameter based, Diameter messages shall be passed on to the 3GPP AAA Server through the 3GPP AAA Proxy. If a WLAN AN attached to the 3GPP AAA Proxy is RADIUS based, the RADIUS messages sent by the WLAN AN shall be either passed on to the 3GPP AAA Server through the 3GPP AAA Proxy, or translated by the 3GPP AAA Proxy Translation Agent into Diameter messages to be sent on to the 3GPP AAA Server by the 3GPP AAA Proxy. This protocol translation shall be done as follows.

The 3GPP AAA Server needs to be aware of what kind of client it is serving in order to adapt its operation to the capabilities of the WLAN AN.

The 3GPP AAA Proxy is the only network element in direct contact with the WLAN AN and therefore it is the only network element aware of whether the WLAN AN is RADIUS or Diameter based. The following rules shall apply for the 3GPP AAA Server to determine this:

If the Wd reference point uses RADIUS then:

– The 3GPP AAA Server shall assume that the WLAN AN is RADIUS based.

If the Wd reference point uses Diameter then:

– The 3GPP AAA Server shall assume the WLAN AN to be Diameter- based unless the 3GPP AAA Proxy specifically indicates that the WLAN AN is RADIUS based (see subclause 5.3.1.3).

Once the 3GPP AAA Server is aware of which AAA protocol that the WLAN AN is using , it shall adapt its operation over the Wd reference point.

If the WLAN AN is determined to be Diameter based, the operation mode of the 3GPP AAA Server shall be the normal behaviour as described in Diameter (IETF RFC 4072 [8]) and the Diameter Base (IETF RFC 3588 [7]) for authentication and NASREQ (IETF RFC 4005 [12]) for accounting.

If the WLAN AN is determined to be RADIUS based, the operation mode of the 3GPP AAA Server shall be the following:

If the Wd reference point is using RADIUS then:

– Normal behaviour for RADIUS as specified in the first bullet in subclause 5.2.

If the Wd reference point is using Diameter then:

– The normal behaviour for Diameter as specified in the second bullet in subclause 5.2, but shall be modified as follows to ensure RADIUS compatibility:

  • Diameter AVPs to RADIUS attributes compatibility:

– 3GPP AAA Server shall restrict itself to use only Diameter AVPs that are compatible with RADIUS attributes. In general, 3GPP AAA Server shall use Diameter AVPs with codes not greater than 255. See section 9.5 in IETF RFC 4005 [12] for further detail.

  • Diameter specific procedures when interacting with RADIUS clients:

– 3GPP AAA Server shall not attempt server-initiated re-authentication.

– 3GPP AAA Server may attempt server-initiated re-authorization and server-initiated session termination.

5.3.1 Requirements in 3GPP AAA Proxy for RADIUS/Diameter "Translation Agent"

A RADIUS/Diameter Translation Agent has the following requirements:

– Receive RADIUS requests (sent to UDP port 1812);

– Diameter proxy functionality (communicate over TCP/SCTP port TBD, mandatory support for IPSec, optional support for TLS, etc.);

– Convert RADIUS requests to Diameter requests;

– Convert Diameter responses to RADIUS responses;

– Advertise to the 3GPP AAA Server whether the client located in WLAN AN is RADIUS or Diameter based;

– Managing the transaction state information of the RADIUS requests.

The Diameter protocol defines a common space for many RADIUS information elements (AVPs), so that no conversion is necessary when transporting them. However, there are certain AVPs that do need translation and differences of the message formats and transport protocols need to be handled.

5.3.1.1 Conversion of RADIUS Request to Diameter Request

When receiving a RADIUS Request on the Wa reference point, the 3GPP AAA Proxy Translation Agent shall translate it into a Diameter Request to be forwarded on the Wd reference point, as described in IETF RFC 4005 [12].

If the RADIUS Request contains EAP frames, additional actions described in IETF RFC 4072 [8] are taken by the 3GPP AAA Proxy Translation Agent to convert this into a Diameter Request containing EAP frames. Typically, RADIUS Access Request command is translated into Diameter-EAP-Request command.

If the RADIUS Request contains the 3GPP-WLAN-QoS-Filter-Support attribute indicating support of the 3GPP-WLAN-QoS-Filter-Rule attribute in the WLAN AN, the 3GPP AAA Proxy Translation Agent shall translate it into a Diameter QoS-Capability AVP indicating support of the QoS-Resources AVP.

5.3.1.2 Conversion of Diameter Response to RADIUS Response

When receiving a Diameter Response on the Wd reference point, if the WLAN AN supports only RADIUS based Wa reference point, the 3GPP AAA Proxy Translation Agent shall translate it into a RADIUS Response to be forwarded on the Wa reference point, as described in IETF RFC 4005 [12].

If the Diameter Response contains EAP frames, additional actions described in IETF RFC 4072 [8] are taken by the 3GPP AAA Proxy Translation Agent to convert this into a RADIUS Response containing EAP frames. Typically, Diameter-EAP-Answer command is translated into RADIUS Access-Accept/Reject/Challenge command.

If the Diameter Response contains the QoS-Resources AVP, the 3GPP AAA Proxy Translation Agent shall translate it into a RADIUS 3GPP-WLAN-QoS-Filter-Rule attribute. If the 3GPP AAA Server determines that the WLAN AN is RADIUS based (see section 5.3.1.3), it shall construct the Diameter QoS-Resources AVP such that it can be translated into a RADIUS 3GPP-WLAN-QoS-Filter-Rule attribute.

5.3.1.3 3GPP AAA Proxy advertisement of RADIUS or Diameter client to 3GPP AAA Server.

Some Diameter AVPs are defined specifically for use in Diameter messages that result from the translation of a RADIUS message into a Diameter message, or for use in Diameter messages that are to be translated into RADIUS messages. When the 3GPP AAA Proxy receives RADIUS messages on the Wa reference point, it may use these AVP’s in the Diameter message it sends to the 3GPP AAA Server on the Wd reference point to indicate to the 3GPP AAA Server that the WLAN AN is RADIUS based. The 3GPP AAA Server shall modify its Response to the Diameter command in such a way that the Diameter Response message can be translated into a RADIUS Response by the 3GPP AAA Proxy Translation Agent, to be sent on by the 3GPP AAA Proxy to the WLAN AN.

The 3GPP AAA Proxy shall indicate to the 3GPP AAA Server that the WLAN AN that it is attached to is RADIUS based by including one or more of the following Diameter AVPs in the resultant Diameter command that is sent to the 3GPP AAA Server:

– NAS-IP-Address AVP.

– NAS-IPv6-Address AVP.

– State AVP.

– Termination-Cause AVP.

Further details on usage of these AVPs can be found in IETF RFC 4005 [12].

5.3.1.4 Managing the transaction state and session state information

The 3GPP AAA Proxy Translation Agent shall maintain the session state and transaction state, as indicated in IETF RFC 3588 [7].

The 3GPP AAA Proxy shall be able to keep the relationship between the RADIUS-Request and Diameter-Requests, as well as for Diameter-Responses to RADIUS-Responses.

The 3GPP AAA Proxy for every RADIUS-Request received shall maintain RADIUS transaction state information as follows, see IETF RFC 4005 [12]:

– RADIUS Identifier Field in the RADIUS-Request as described in IETF RFC 2685 [17].

– Source IP address of the RADIUS-Request message.

– Source UDP port of the RADIUS-Request message.

– RADIUS Proxy-State in the RADIUS-Request as described in IETF RFC 2685 [17].

Additionally, for every Diameter-Request that is sent to the 3GPP AAA Server, the 3GPP AAA Proxy shall maintain a Diameter transaction state information based on the Diameter Hop-by-Hop Id as described in IETF RFC 3588 [7].

Upon the reception of a RADIUS-Request, translation of that RADIUS-Request to a Diameter-Request and sending out of that Diameter-Request to the 3GPP AAA Server, the 3GPP AAA Proxy shall create the RADIUS transaction state and link it to the Diameter transaction state.

When receiving the Diameter-Response corresponding to the Diameter-Request sent to the 3GPP AAA Server, it should be possible for the 3GPP AAA Proxy to relate it to a RADIUS-Response based on the information available in the Diameter-transaction state and RADIUS transaction state.

Every RADIUS-Request received, translated to Diameter-Request and sent to the 3GPP AAA Server by the 3GPP AAA Proxy, shall be linked to a Session State as described in IETF RFC 4005 [12]:

– If the RADIUS-Request contains the State attribute and "Diameter/" prefixes its data, the data following the prefix is the Diameter Session Id.

– If the RADIUS-Request does not contain the State attribute and it is an Access_Accept, a new Diameter Session Id is generated in the 3GPP AAA Proxy.

The Diameter Session Id is included in the Session-Id AVP in the Diameter-Request.

5.4 Procedures description

5.4.1 WLAN Access Authentication and Authorization

This procedure is used to transport the WLAN Access Authentication and Authorization information between the 3GPP AAA Proxy and the 3GPP AAA Server.

Diameter usage in Wd:

This procedure is mapped to the Diameter-EAP-Request and Diameter-EAP-Answer command codes specified in IETF RFC 4072 [8] tables 5.4.1.1 and 5.4.1.2 show the information elements that should be exchanged across Wd. If the User-Name AVP contains a Decorated NAI as defined in 3GPP TS 23.003 [22], then the Diameter request routing shall follow the procedures defined in IETF RFC 5729 [36].

Table 5.4.1.1: Diameter EAP Request

Information element name

Mapping to Diameter AVP

Cat.

Description

User Identity

User Name

M

This information element shall contain the identity of the user

EAP payload

EAP payload

M

Encapsulated EAP payload used for WLAN-UE/3GPP AAA Server mutual authentication

Authentication Request Type

Auth–Request-Type

M

Defines whether the user is to be re-authenticated only, re-authorized only or both. AUTHORIZE_AUTHENTICATE is required in this case.

NAS-IP address

NAS-IP Address

C

IP address of the hot-spot

NAS-Ipv6 address

NAS-Ipv6 address

C

IPv6 address of the hot-spot

Visited-Network-Identifier

Visited-Network-Identifier

C

Identifies the VPLMN and shall be present during the first DER message of either authentication or reauthentication sent by the 3GPP AAA Proxy to 3GPP AAA Server.

WLAN UE MAC address

Calling Station-ID

Carries the MAC address of the WLAN-UE.

Supported 3GPP WLAN QoS profile

QoS-Capability

O

If the WLAN AN supports QoS mechanisms, this information element may be included and shall contain the WLAN AN’s QoS capabilities.

Operator Name

Operator-Name

M

Hot Spot Operator Name.

Location Information

Location-Information

M

Contains meta-data about the location information.

Location Data

Location-Data

M

Contains the civic or geospatial location of the hotspot operator.

Basic Location Policy Rules

Basic-Location-Policy-Rules

O

Contains basic policy rules for controlling the distribution of location information.

Extended Location Policy Rules

Extended-Location-Policy-Rules

O

Contains a URI that indicates where a richer set of policy rules for controlling the distribution of location information can be found.

Location Capable

Location-Capable

M

Allows the RADIUS client to indicate support for the functionality specified in IETF RFC 5580.

Table 5.4.1.2: Diameter EAP answer message

Information element name

Mapping to Diameter AVP

Cat.

Description

User Identity

User Name

M

This information element contains the identity of the user.

EAP payload

EAP payload

M

Encapsulated EAP payload used for UE-3GPP AAA Server mutual authentication

Result code

Result Code

M

Result of the operation. Result code as per definition in NASREQ.1xxx shall be used for multi-round, 2xxx for success.

Session Alive Time

Session-Timeout

O

Max no of seconds the user session should remain active

Accounting Interim-Interval

Accounting Interim-Interval

O

Charging duration

Subscription-ID

Subscription-ID

C

This AVP shall contain the MSISDN and/or the IMSI of the user. This AVP shall be present if the result code is set to "Success", 2xxx.

Pairwise Master Key

EAP-Master-Session-Key

C

Shall be sent if Result Code is set to "Success".

Authorized 3GPP WLAN QoS profile

QoS-Resources

O

If both supported 3GPP WLAN QoS profile of the WLAN AN and subscribed QoS profile were received by the 3GPP AAA Server, this IE may be present.

This IE contains the 3GPP WLAN QoS Profile authorized by the 3GPP AAA Server based on the subscribed QoS parameters from the HSS, WLAN AN’s QoS capabilities and other information, e.g. operators’ policies.

Routing Policy

Routing-Policy

O

This AVP includes the routing policies and IP filtering. This AVP shall be present when Operator Determined Barring requires additional filtering information to be passed to the Access Network. The exact format of this AVP is specified in section 10.1.24.

Basic Location Policy Rules

Basic-Location-Policy-Rules

O

Contains basic policy rules for controlling the distribution of location information.

Extended Location Policy Rules

Extended-Location-Policy-Rules

O

Contains a URI that indicates where a richer set of policy rules for controlling the distribution of location information can be found.

Requested Location Info

Requested-Location-Info

O

Allows the 3GPP AAA Proxy to indicate which location information about which entity it wants to receive.

Error Cause

Error-Cause

O

The 3GPP AAA Proxy shall include this attribute with a value of "Location-Info-Required" if it did not receive the requested location information as specified in IETF RFC 5580 [16].

RADIUS usage in Wd:

– This procedure is mapped to the RADIUS Access Request, RADIUS Access Challenge, RADIUS Access Accept and RADIUS Access Reject specified in IETF RFC 3579 [14].

5.4.2 Immediate Purging of a User from WLAN access

This procedure is used to communicate between the 3GPP AAA Proxy and the 3GPP AAA Server that the 3GPP AAA Server has decided that a specific WLAN-UE shall be disconnected from accessing the WLAN interworking service. The procedure is Diameter or RADIUS based.

Diameter usage in Wd:

– This procedure is mapped to the Diameter command codes Diameter-Abort-Session-Request and Diameter-Abort-Session-Answer specified in RFC 3588 [7]. Information elements are as per described in section 4.3.2.

RADIUS usage in Wd:

– This procedure is mapped to the RADIUS messages Disconnect-Request and Disconnect-Response specified in RFC 3576 [13].

5.4.3 Ending a Session

Session termination occurs when a user de-registers from the 3GPP AAA Server. This occurs via the Session Termination Request (STR) and Session Termination Answer commands (STA), defined in the base protocol IETF RFC 3588 [7]. Information elements are as per described in subclause 4.3.3.

5.4.4 Authorization Information Update Procedure

The authorization information update procedure is used in roaming case to modify the authorization parameters provided either to the WLAN AN or to a PDG located in the visited network. This procedure is invoked by the 3GPP AAA Server and is used to communicate with the WLAN AN or the PDG through the 3GPP AAA proxy.

The procedure is Diameter or RADIUS based.

– Diameter usage in Wd:

– If the 3GPP AAA server issues an unsolicited re-authentication and/or re-authorization request towards the WLAN AN, the 3GPP AAA proxy shall forward the request to the WLAN AN, which triggers the WLAN access authentication and authorization information update procedure described in the section 4.3.4.

– If the 3GPP AAA server issues an unsolicited re-authentication and/or re-authorization request towards the PDG located in the visited network, the 3GPP AAA proxy shall forward the request to the PDG, which triggers the access and service authorization information update procedure described in the section 8.3.5.

RADIUS usage in Wd:

– The Wd interface is used to transport the RADIUS messages CoA-Request and CoA-Response only for communication between the WLAN AN and the 3GPP AAA server. These messages are specified in RFC 3576 [13].

5.5 Information Elements Contents

5.5.1 Authentication Procedures

ABNF for the Wd Diameter EAP Request/Ansewer messages are given below:

<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Origin-Host }

{ Origin-Realm }

{ Destination-Realm }

{ Auth-Request-Type }

{ EAP-Payload }

[ Destination-Host ]

[ User-Name ]

[ NAS-IP-Address ]

[ NAS-IPv6-Address ]

[ Calling Station-ID ]

[ Visited-Network-Identifier ]

[ QoS-Capability ]

* [ Proxy-Info ]

* [ Route-Record ]

[ Operator-Name ]

* [ Location-Information ]

* [ Location-Data ]

[ Basic-Location-Policy-Rules ]

[ Extended-Location-Policy-Rules ]

[ Location-Capable ]

* [ AVP ]

For the DEA, the following are necessary:

<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >

< Session-Id >

{ Auth-Application-Id }

{ Result-Code }

{ Origin-Host }

{ Origin-Realm }

{ Auth-Request-Type }

[ EAP-Payload ]

[ User-Name ]

1* [ Subscription-ID ]

[ EAP-Master-Session-Key ]

[ QoS-Resources ]

* [ Proxy-Info ]

[ Basic-Location-Policy-Rules ]

[ Extended-Location-Policy-Rules ]

[ Requested-Location-Info ]

[ Error-Cause ]

* [ AVP ]

5.5.2 Abort Session Requests and Answer AVPs

ABNF for the ASR and ASA commands on the Wd interface are identical to those on the Wa interface described in section 4.4.2.2

5.5.3 Session Termination Request and Answer AVPs

ABNF for the STR and STA commands on the Wd interface are identical to those on the Wa interface described in section 4.4.2.3.

5.5.3A Authorization Information Update Procedure

ABNF for the RAR and RAA commands on the Wd interface are identical to those described in section 4.4.2.4.

ABNF for the AAR/AAA commands on the Wd interface are identical to those described in section 8.4.2.

5.5.4 RADIUS based Information Elements Contents for Authentication and Authorization

Table 5.5.4.1: RADIUS based Information Elements Contents

IE NAME

IE description

Access Request

Access Accept

Access Reject

Access Challenge

Attribute

RADIUS Client Address

This Attribute indicates the identifying IP Address of the RADIUS Client. It should be unique to the RADIUS Client within the scope of the RADIUS server. More detailed description of the IE can be found in IETF RFC 3580 [15].

Mandatory

NA

NA

NA

NAS-IP-Address

NAS-IPv6-Address

USER ID

This Attribute indicates the identity of the user to be authenticated. More detailed description of the IE can be found in IETF RFC 3580 [15] and 3GPP TS 23.234 [4].

Mandatory

Mandatory

NA

NA

User-Name

Operator Name

Hot Spot Operator Name as defined in IETF RFC 5580 [16].

Mandatory

NA

NA

NA

Operator-Name

Location Information

This Attribute contains meta-data about the location information, such as sighting time, time-to-live, location-determination method, etc, as defined in IETF RFC5580 [16]. It also indicates the type of location profile (civic or geospatial) contained in the Location-Data Attribute.

Mandatory

NA

NA

NA

Location-Information

Location Data

This Attribute contains the civic or geospatial location of the hotspot operator as defined in IETF RFC 5580 [16].

Mandatory

NA

NA

NA

Location-Data

Basic Location Policy Rules

This Attribute contains basic policy rules for controlling the distribution of location information as defined in IETF RFC 5580 [16], e.g. retention expiry, URI of human-readable privacy instructions.

Optional

Optional

NA

Optional

Basic-Location-Policy-Rules

Extended Location Policy Rules

This Attribute contains a URI that indicates where a richer set of policy rules for controlling the distribution of location information can be found as defined in IETF RFC 5580 [16].

Optional

Optional

NA

Optional

Extended-Location-Policy-Rules

Location Capable

This Attribute allows the RADIUS client to indicate support for the functionality specified in IETF RFC 5580 [16].

Mandatory

NA

NA

NA

Location-Capable

Requested Location Info

This Attribute allows the RADIUS server to indicate which location information about which entity it wants to receive as specified in IETF RFC 5580 [16].

NA

Optional

NA

Optional

Requested-Location-Info

Error Cause

The 3GPP AAA Proxy shall include this attribute with a value of "Location-Info-Required" if it did not receive the requested location information as specified in IETF RFC 5580 [16].

NA

NA

Optional

NA

Error-Cause

EAP Message

This attribute encapsulates Extensible Authentication Protocol packets so as to allow the NAS to authenticate users via EAP without having to understand the EAP protocol. More detailed description of the IE can be found in IETF RFC 3580 [15].

Mandatory

Mandatory

Mandatory

Mandatory

EAP-Message

State information

This attribute may be sent by the 3GPP AAA server to the WLAN-AN . If the RADIUS client in the WLAN-AN receives such an attribute, it shall be included in subsequent Access Requests.

Conditional

NA

NA

Optional

State

Session ID

This attribute is sent by 3GPP AAA server to the visited network. If the RADIUS client in the WLAN-AN receives it, it should be included in subsequent accounting messages.

NA

Mandatory

NA

NA

Class

Session Alive Time

This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. A more detailed description of the IE can be found in IETF RFC 3580 [15].

NA

Optional

NA

Optional

Session-Time-Out

Charging Duration

This attribute indicates the time between each interim update in seconds for this specific session. A more detailed description of the IE can be found in IETF RFC 2869 [9].

NA

Optional

NA

NA

Acct-Interim-Interval

Termination Action

This Attribute indicates what action the NAS should take when the specified service is completed. More detailed description of the IE can be found in IETF RFC 3580 [15].

NA

Optional

NA

Optional

Termination-Action

Pairwise Master Key (PMK)

This IE is used to carry the Pairwise Master Key. More detailed description of the IE can be found in IETF RFC 4186 [28] and IETF RFC 4187 [29].

NA

Mandatory

NA

NA

Vendor-Specific (MS-MPPE-Recv-Key)

Message Authenticator

Message Authenticator.

Mandatory

Mandatory

Mandatory

Mandatory

Message-Authenticator

WLAN-UE MAC address

Carries the MAC address of the WLAN-UE for verification at the 3GPP AAA Server.

Mandatory

NA

NA

NA

Calling-Station-Id

Chargeable User Identity

This Attribute shall contain the MSISDN and/or the IMSI of the use. The encoding of the MSISDN and the IMSI is defined in GSMA PRD IR.61 [25].

Optional

Mandatory

NA

NA

Chargeable-User-Id

Visited Operator Identity

Identifies the VPLMN as specified in GSMA PRD IR.61 [25]

Mandatory

NA

NA

NA

Vendor-Specific (Visited-Operator-Id)

Supported 3GPP WLAN QoS Profile

If the WLAN AN supports QoS mechanisms, this attribute may be used to indicate the supported WLAN AN’s QoS capabilities.

Optional

NA

NA

NA

3GPP-WLAN-QoS-Filter-Support

3GPP WLAN QoS profile

If the WLAN AN supports QoS mechanisms, this IE may be present in the reponse. In that case, this IE contains the 3GPP WLAN QoS Profile authorized by the 3GPP AAA Server based on the subscribed QoS parameters from the HSS, WLAN AN’s QoS capabilities and other information, e.g. operators’ policies.

NA

Optional

NA

NA

3GPP-WLAN-QoS-Filter-Rule

NAS Filter Rule

This IE enables the provisioning of Layer 2-4/7 filter and redirection rules on the NAS by 3GPP AAA Server/Proxy. More detailed description of the IE can be found in IETF RFC 4849 [30].

NA

Optional

NA

NA

NAS-Filter-Rule

The parameters listed above as ‘mandatory’ are only optional in the particular RADIUS (extension) specification in which they are originally defined. However, in order for 3GPP WLAN-IW to function, these attributes shall be passed in messaging over the Wd interface as per the definition in the table. In this sense they are mandatory. In practice, this means that, should any of these parameters labelled ‘mandatory’ be missing from the RADIUS messaging over Wd, this will result in a higher level failure of WLAN-IW procedures to function properly and consequently in a denial of the RADIUS request (even though this was a valid RADIUS message).

5.5.5 RADIUS based Information Elements Contents for Accounting

Table 5.5.5.1: RADIUS based Information Elements Contents

IE NAME

IE description

Accounting Request

Accounting Response

Attribute

USER ID

This Attribute indicates the identity of the user. More detailed description of the IE can be found in IETF RFC 3580 [15] and 3GPP TS 23.234 [4].

Mandatory

Mandatory

User-Name

RADIUS Client Address

This Attribute indicates the identifying IP Address of the RADIUS Client. It should be unique to the RADIUS Client within the scope of the RADIUS server. More detailed description of the IE can be found in IETF RFC 3580 [15].

Mandatory

NA

NAS-IP-Address

NAS-IPv6-Address

Acc-Session-ID

According to IETF RFC 2866 [20], this attribute is an accounting ID which uniquely identifies the user’s session.

Mandatory

Mandatory

Acct-Session-Id

Operator Name

Hot Spot Operator Name as defined in IETF RFC 5580 [16].

Mandatory

NA

Operator-Name

Location Information

This Attribute contains meta-data about the location information, such as sighting time, time-to-live, location-determination method, etc, as defined in IETF RFC5580 [16]. It also indicates the type of location profile (civic or geospatial) contained in the Location-Data Attribute.

Mandatory

NA

Location-Information

Location Data

This Attribute contains the civic or geospatial location of the hotspot operator as defined in IETF RFC 5580 [16].

Mandatory

NA

Location-Data

Basic Location Policy Rules

This Attribute contains basic policy rules for controlling the distribution of location information as defined in IETF RFC 5580 [16], e.g. retention expiry, URI of human-readable privacy instructions.

Optional

NA

Basic-Location-Policy-Rules

Extended Location Policy Rules

This Attribute contains a URI that indicates where a richer set of policy rules for controlling the distribution of location information can be found as defined in IETF RFC 5580 [16].

Optional

NA

Extended-Location-Policy-Rules

Acct.Status Type

Indicates whether this is:

(i) Accounting Start.

(ii) Stop.

(iii) Interim Report. Accounting start indicates that this is the beginning of the user service, Account stop the end.

Mandatory

N/A

Acct-Status-Type

Acc-Input-octets

Indicates the number of octets sent by the WLAN UE over the course of the session. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Interim" or "Stop".

Conditional. Shall be present if Acct-Status-Type set to "Accounting Interim" or "Accounting Stop".

N/A

Acct-Input-Octets

Acc-Output Octets

Indicates the number of octets received by the WLAN-UE. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Interim" or "Stop".

Conditional. Shall be present if Acct-Status-Type set to "Accounting Interim" or "Accounting Stop".

N/A

Acct-Output-Octets

Acc-Session-Time

This attribute indicates how many seconds the user has received service for. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Interim" or "Stop".

Conditional. Shall be present if Acct-Status-Type set to "Accounting Interim" or "Accounting Stop".

N/A

Acct-Session-Time

Acc-Input-Packets

Indicates the number of packets sent by the WLAN UE over the course of the session. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Interim" or "Stop"

Optional

N/A

Acct-Input-Packets

Acc-Output-Packets

Indicates the number of packets received by the WLAN-UE over the course of the session. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Interim" or "Stop".

Optional

N/A

Acct-Output-Packets

Acc-Terminate-Cause

Indicates how the session was stopped. Cause values are as per specified in IETF RFC 3580 [15]. According to IETF RFC 5080 [39], updating the IETF RFC 2866 [20], shall only be present if ACC Status Type is set to "Stop".

Conditional. Shall be present if Acct-Status-Type set to "Accounting Stop".

N/A

Acct-Terminate-Cause

Event Time Stamp

Number of second elapsed since January 1st 1970. UTC time.

Mandatory

NA

Event-Time-Stamp

Chargeable User Identity

This attribute shall contain the MSISDN and/or the IMSI of the user. The encoding of the MSISDN and the IMSI is defined in GSMA PDR IR.61 [25].

Mandatory

NA

Chargeable-User-Id

Visited Operator Identity

Identifies the VPLMN as specified in GSMA PRD IR.61 [25]

Mandatory

NA

Vendor-Specific (Visited-Operator-Id)

Session ID

This attribute is used to link related authentication and accounting sessions and should be included unmodified to accounting request messages.

Conditional. Shall be present if received in an Access Accept.

NA

Class

The parameters listed above as ‘mandatory’ are only optional in the particular RADIUS (extension) specification in which they are originally defined. However, in order for 3GPP WLAN-IW to function, these attributes shall be passed in messaging over the Wd interface as per the definition in the table. In this sense they are mandatory. In practice, this means that, should any of these parameters labelled ‘mandatory’ be missing from the RADIUS messaging over Wd, this will result in a higher level failure of WLAN-IW procedures to function properly and consequently in a denial of the RADIUS request (even though this was a valid RADIUS message).